http://joxi.ru/82QYoQyIjjRKN2

Наша цель -
* получить список юз кейсов (пояснения - https://docs.google.com/document/d/14VNBSVuTY0xGFI_OYSxDCae02BQG_yr68DLoNcll08Q/edit?usp=sharing)
* описать их в лаконичной таблице с учетом работы на разных фильтрах
* в описании - оперировать такими понятиями, как покрытие и приоритет
    * для всех юз кейсов на всех контекстах - определиться с приоритетом
    * после этого - можно будет распланировать, что нужно покрыть в нашем е2е сценарии, который будет реализовывать Smoke покрытие
**********************************
По списку юз кейсов
    * базовые операции над тасками (не все можно выполнить на любом из фильтров)
    * операции переходов по фильтрам - тут в общем-то все понятно
    * Additional edit operations = операции, начинающиеся как редактирование, но
        * либо результат у них другой
        * либо у вторая часть операции = отличается от стандартного редактирования
    * Items left - снизу слева списка тасок - есть счетчик активных задач,
    который после любого из действий - отражает количество активных задач в списке
*****************************************
/*

        Additional edit operations - подробнее

        юз кейс edit мы уже описали
        он реализуется так
            даблклик на таске
            ввод нового значения
            энтер
        его уже рассматривать не будем
        но есть еще похожие варианты )

        есть и другие варианты развития событий при редактировании
        например, если новое введенное значение = пусто
        или в конце - нажимаем не энтер, а ..., или делаем еще что-то

        выделим их в отдельную подгруппу - для дополнительных операций редактирования
        (именно дополнительных, т к стандартное редактирование - уже в нашем списке есть
        и не надо его в новом подпункте дублировать)

        строим фразы так - что получим + как получим
        т е - описание результата + описание пути его достижения

        пример - если при редактировании текст изменить на пустую строку, то таска удалится
        такой пункт формулируем - delete by emptying text

        есть еще варианты -
        для 2-ух способов подтверждения редактирования(не с помощью нажатия на Enter)
        и одного способа отмены редактирования
          начали редактировать, внесли новый текст для таски,
          нажали Escape,
          результат - у таски старый текст - именно потому отмена редактирования
*/
*******************************************
По легенде
    * Приоритеты и покрытие - суть 2 разные категории
    * И нам для каждого юз кейса и контекста - нужно обозначить и приоритет, и покрытие
    * Чтоб табличку было легче читать - лучше обозначить это по-разному
    * В этом примере - покрытие = цвет фона, приоритет = буква(ну или цифра, сам решишь).
        * 2 шкалы - покрытие и приоритет - это нужно сделать
        * а вот как их обозначить - подусай сам
        * мне кажется удачным привеенный способ
        * разве что приоритеты я бы обозначила цифрами а не буквами
        * в легенде - описаны полностью эти 2 шкалы
        * для приоритетов - я бы использовала 3 градации (высокий/средний/низкий) - уже достаточно подробно, но все еще просто
            * советую остаться в таком варианте
            * если делать его детальнее - придется платить более подробным описанием каждого из приоритетов
            * если делать проще (высокий/низкий) - может не хватить точности
        * пока для покрытия - будем обозначать следующее
            * что покроем в новом е2е тесте
            * что покрыть невозможно
            * что покрывать не будем
    * На примере add - я показала, как будет выглядеть обозначение (указали и покрытие, и приоритет)
*******************************************
С приоритетами, приведеными в таблице (например, для items left) - можно не согласиться
Высокий приоритет - показан в общем корректно
*********************************************
Первый блок задач
    * разобрать каждую строчку таблицы - что имеется в виду - что это за действие, как его выполнить
    * подумать над приоритетами
    * получить свою табличку - со своими шкалами и обозначениями - для покрытия и для приоритетов
********************************************
Про приоритеты
Приоритет действия высокий если
            - нерабочее действие не позволяет использовать приложение
            - у действия нет альтернативы
            - действие - часто используемое
            - действие - стандартное для многих приложений

                Примеры высокоприоритетного
                        - добавление задачи - высокоприоритетная штука, потому что если отвалится - приложение не работает
                        - отмена редактирования с помощью esc - во-первых, стандартное поведение, во-вторых - нет альтернативы
                        - закомпличивание/раскомпличивание одной задачи - часто используемое и критично чтоб работало - важный функционал

                Так вот - низкоприоритетные вещи - в smoke-тесте не нужно покрывать.
                Чтобы оставить smoke тест эффективным

                А вот Reopen All - уже имеет приоритет пониже - т к реже будет использоваться, чем тот же reopen

                Проверка счетчика Items left - в общем-то - это не высокоприоритетная штука.
                Т к даже если это не будет работать - приложение будет все равно функционально.
                С другой стороны, на состояние этого счетчика влияет любая выполненная операция.
***************************************************
Далее - будем делать вот это задание - https://docs.google.com/document/d/17ZU5K7BGVfJKdJS8LQiFDExzHjChietETMxhZLk7A6Q/edit?usp=sharing

    Чтоб его сделать - нам пригодится тест-план, который у нас уже готов, чтоб отмечать покрытие
    и планировать его сразу - неизбыточным

    Почитай описание задания, почитай описание ниже,
    Советую начать с планирования, и затем уже начинать кодить
    Также разумно дождаться ревью на первую работу - до того как начать кодить
    Чтоб в 2-ух местах не исправлять одинаковые ошибки
******************************************************
    Ниже - описаны моменты, которые часто вызывают вопросы

  Мы реализуем е2е сценарий для smoke покрытия
    это значит - что достаточно покрыть высокоприоритетный юз кейс лишь единожды, на одном из контекстов

    т е - покрыли edit на active - все, этого достаточно
    конечно, с добавлением таски так не получится )
    но - и того количества тасок, что ты создал - не нужно

    но с остальными операциями - это получится вполне

    задача smoke покрытия - быстро дать нам фидбек = все высокоприоритетные операции работают
    не все высокоприоритетные операции работают на всех контекстах
    а именно вот так - что они работоспособны

    разумно уже на этом уровне - распределить покрытые операции по фильтрам - поравномернее
    так ты получишь лучший фидбек от теста - мы узнаем что операции над тасками работают (или не работают)
    на разных фильтрах

    дальше - если smoke тестирование пройдено - можно глубже тестировать приложение
    а если нет - так нет смысла продолжать тестировать - есть серьезные проблемы и надо их устранять


про использование неявных проверок через действие
          вариант 1
          add("task1"");
          edit("task1", "task1 edited");
          delete("task1 edited");

          вариант 2
          add("task1", "task2");
          edit("task2", "task2 edited");
          delete("task2 edited");

       Вариант 1 = правильное использование таких проверок через действие

       Вариант2 = не правильное использование
       Т к последующие действия не проверяют состояние ВСЕХ тасок в списке

       Таким образом - ты сможешь эффективно использовать неявные проверки через действия только в случае,
       если в списке тасок будет видима лишь одна таска

       Также не забывай - после каждого действия должна быть выполнена проверка
       Сразу
       Не получается использовать неявную проверку через следующее действие - используй явную
       Но - действие должно быть обязательно проверено сразу