- Тесты — тоже код
- Попытка улучшения SDLC
- Законы:
- 1. Тестируют все (то есть все)
- 2. Смотрите на риски, а не выжимайте 100% покрытие
- 3. Тестируйте то что важно для бизнеса
- 4. Шире, не глубже
- 5. Пользователь решает
- 6. Код не годится, пока он не пришел в тестабельный вид
- 7. Каждый тест = одно действие
- 8. Тестируйте точки взаимодействия с пользователем
- 9. Не связывайте тесты между собой
- 10. Туже затяните петлю фидбека
- Люди любят поспорить
Тесты — это тоже код
«В ИТ-командах принято относиться ко всему, что не является кодом, как к чему-то неважному. Менеджмент понимает, что без тестирования не обойтись, и что надо уделять внимание, однако то и дело видим команды, которые относятся к автоматизации QA (и артефактам) как к чему-то второсортному. Зря, потому что тесты — это важнейшие документы о поведении пользователей, неразрывно связанные с требованиями, и с кодом имплементации функций.
Если тесты представляют ценность, а это безусловно так, то они должны быть версионированы, должны поддерживаться, и относиться к ним следует так, как если бы они были неотъемлемой частью продукта. Кроме автотестов, о которых идет речь, сюда следует отнести спецификации тест-кейсов, артефакты дизайна и техническую документацию, а также баг-репорты.
Это советы по улучшению процессов в SDLC
Казалось бы, чем больше времени команда тратит на функцию, тем больше времени на ее доработку, оттачивание, тестирование и доводку. Это справедливо для разработки по старым принципам, с тестовым окружением, staging-окружением, и множеством гипотез о том, как пользователи будут с взаимодействовать с продуктом.
Приведенные далее законы — попытка описать возможные улучшения SDLC-цикла в современном мире небольших инкрементных изменений в коде, которые обкатываются на небольшой аудитории, прежде чем выходят в мир. «Keyboard-to-production in 10 minutes» — этот принцип ведет к более быстрому и качественному фидбеку, меньшему количеству дефектов.
Собственно, законы
1. Тестируют — все
Каждый участник технической команды, независимо от процесса в котором участвует, независимо от степени участия в продукте, независимо от специфики компании — каждый несет ответственность за качество продукта. Дизайн, разработка, тестирование и даже смежные функции: поддержка клиентов, продажи, маркетинг, департамент развития бизнеса, клиенты участвующие тестировании в бета-версий, и даже в какой-то форме менеджмент — тестируют все. Несут ответственность за качество, значит тестируют.
2. Смотреть на риски, а не на покрытие
Даже если предположить, что команда сумеет договориться об общем для всех определении понятия «отличный продукт», то чрезмерное стремление к недостижимому идеалу отвлекает внимание команды от самого важного: рисков для бизнеса в случае попадания критического дефекта в продакшен.
Прежде чем бросать все силы на всесторонний охват всех функций, займитесь 3-5 самых важных user flow.
3. Тестируйте то, что важно с точки зрения денег
Каждый отдел и каждая команда имплементируют тот базовый набор функций, который будет приносить прибыли больше, чем все другие вместе взятые.
Вместе с тем, IT-компания должна создать и поддерживать еще и набор второстепенных функций, которые мало влияют на прибыль, но все же необходимы, даже «для галочки».
Сосредоточьте главные усилия на тестировании тех частей продукта, которые непосредственно влияют на доход бизнеса.
Например, в случае магазина приоритет отдается тестированию оформления заказа, а не мелким визуальным погрешностям в профилях клиентов. В финансовой сфере первоочередность — безопасности и обработке платежей, а не визуальному оформлению.
4. Ширина важнее глубины
В принципе, важнее протестировать все области продукта поверхностно, чем глубоко и долго тестировать некоторые из них, особенно неприоритетные.
Частая ошибка: дотошная проверка многовариантных комбинаций бизнес-логики для самых крайних, edge-случаев — при этом риск упустить самые очевидные недостатки в высокоприоритетных областях.
Возникает вопрос: после того как широта охвата достигнута, как глубоко нужно погружаться в функцию, вызывающую сомнения? Смотрим Закон 2: риски.
5. Самый идеальный сигнал — это сигнал от пользователя
Пока ваши пользователи не работают с приложением — все, что вы делаете, носит теоретический характер.
Тесты — это модели, это приближенные модели поведения пользователей, основанные на информации, полученной из прошлого. Сигнал, который мы получаем от теста, может быть искажен окружением, логическими ошибками в самих тестах, неосознаваемой предвзятостью и даже неверными данными из предыдущих моделей.
Единственный надежный способ узнать, что происходит, когда пользователь работает с приложением — наблюдать за пользователем. За его реакцией и его experience. Для оценки эффективности стратегии тестирования необходимо сопоставлять user journeys из аналитики на проде — с тестовым покрытием.
Кроме того, следует учитывать, что user experience включает вещи, которые не являются дефектами и могут не отражаться в аналитике. Ваша работа как тестера не завершается, когда сборка становится «зеленой».
6. Программный код не считается завершенным до тех пор, пока он не тестируемый (и не был протестирован)
Тестируемость (тестабельность) — назовем это так: подготовка кода к тестам. Трудно судить о правильности поведения кода без понимания, как он работает, и без предварительной интерпретации. Это приведет к непропорционально большому объему дополнительной работы, что увеличивает время цикла релиза и отвлекает внимание от работы с клиентами.
7. Один тест = одно действие
Если вы не понимаете точно, что делать, если тест упал (как с точки зрения теста, так и с точки зрения продукта), тест бесполезен.
Чаще всего так происходит потому что в тестах слишком много шагов. Или из-за того, что продукт не дает достаточно информации о причинах некорректного поведения теста (недостаточная тестабельность. См. законы 2 и 6).
8. Тестируйте там, где сигнал от пользователя лучше заметен
Тестирование, как известно, осуществляется по уровням, от юнит-тестов в подножии пирамиды до прода на ее верхушке.
Высокоуровневые тесты критически важны для проверки взаимодействия между компонентами, разработанными разными командами; а мелкие нюансы в edge cases скорее всего можно перенести на низкие уровни. Низкоуровневые тесты имеют меньше зависимостей, позволяют избежать дорогостоящей настройки, и выполняются быстрее.
К примеру, UI-тест по идее должен использоваться только для определения того, способен ли пользовательский интерфейс правильно отображать выводы API. Если вы интенсивно тестируете бизнес-логику через один и тот же UI, лучше перенести большинство таких тестов «вниз», на уровень API.
9. Избегайте взаимосвязанности тестов
Любой тест должен выполняться без учета состояния любого другого теста.
Также, управление тестовыми данными должно осуществляться таким образом, чтобы каждый тест «жил в своем отдельном сценарии» и не мог быть изменен другим тестом.
Тесты должны быть атомарными и автономными.
10. Должна быть короткая петля фидбека
Тесты можно воспринимать как петли фидбека. Они «проходят через продукт», обеспечивая обратную связь с конкретным человеком или командой. Самая лучшая петля фидбека — та из которой удалено как можно больше ненужных деталей проверки конкретной операции/функции.
Тестирование более длинной петли фидбека, чем это необходимо, вводит в процесс переменные, искажающие сигналы, получаемые в результате тестирования.
Дисклеймер
Люди любят поспорить, оспорить что-либо, в том числе можно оспорить правоту этих 10 законов. Согласен: эти законы не являются полными, исчерпывающими, покрывающими все ситуации, и конечно же, существует множество оговорок и уточнений.
Эти пункты сформулированы как законы, но я признаю, что важен контекст, и что полного совершенства формулировок для всех ситуаций достигнуть невозможно. Иногда эти законы будут скорее желательны, чем практичны. Иногда вы нарушите один или два (или все десять) — все ОК, главное стремиться к постоянному совершенствованию, а не к статическому совершенству.»
Автор — Маркус Мерелл, техдиректор Sauce Labs (кроссбраузерное тестирование)
