Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

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

Самый простой способ – это взять требования, перефразировать каждый пункт, и при желании добавить деталей, используя разбиение на классы эквивалентности. Наилучший способ – это пользоваться множеством источников информации и генерировать достойные прогона идеи тестов, которые с хорошим шансом будут эффективными. Невозможный способ – скомбинировать всю важную информацию всеми доступными путями.

Лучше использовать каждый важный элемент, и каждую, с вашей точки зрения, значимую комбинацию. Вам помогут ревью, реальный подсказывающий тесты продукт, а также скорость тестов – это даст вам наилучшие идеи для вашей конкретной ситуации. Совместная командная работа над ментальной картой не займет много времени.

Я рекомендую записать идеи тестов – как минимум высокоуровневые, - чтобы их можно было легко использовать при обсуждениях и планировании. Если ревью еще не проведено, или ПО уже доступно – гораздо быстрее будет фиксировать полезные тесты после их выполнения, одновременно с результатом.

Не пытайтесь покрыть все, это невозможно. Стремитесь к широте своих тестов, и рассчитывайте на неожиданные открытия, которые помогут вам найти необходимую для успешного продукта информацию. Некоторые идеи тестов будут генерироваться на лету, во время выполнения тестов, когда вы своими глазами увидите, что на самом деле можно сделать с ПО.

Не останавливайтесь, наткнувшись на полезную идею. Подумайте еще, и, возможно, вы найдете способы получше, или же обнаружите новые решения старых проблем.

Тут применяются классические техники: классы эквивалентности, анализ граничных значений, модели состояний, деревья классификаций, поток данных, а также прямые заявления о том, что вы хотите протестировать, и что угодно, что вы считаете полезным.

В целях тренировки могут пригодиться классификации – на основе рисков, на основе спецификации, доменное тестирование. Однако в реальности куда полезнее быстро переключаться между ними и создавать собственные методики для имеющегося разнообразного исходного материала.

Тем не менее, вашему вниманию предлагается альтернативная классификация идей для тестов:

Непрерывные идеи тестов

Непрерывные идеи тестов нельзя взять и завершить – они продолжают жить, пока не получена вся возможная релевантная информация. Хороший пример – это такая характеристика качества, как стабильность: чем больше вы тестируете, тем больше вы узнаете о стабильности продукта. Для важных характеристик вы, возможно, пользуетесь не только непрерывными, идущими в фоновом режиме тестами, но в качестве дополнения они очень полезны и ресурсоемки.

Другой пример – это свободное непрерывное тестирование удобства использования: в ходе тестирования тестировщик держит в уме релевантные качества продукта, и в случае каких-либо нарушений они будут замечены и зафиксированы.

Классические идеи тестов

Классические идеи тестов имеют дело с конкретикой и могут быть записаны в формате "убедиться, что…". Они могут отражать требования или другую известную тестировщикам информацию.

Не поймите меня неправильно, это важные идеи. Классические техники тест-дизайна с явными ожидаемыми результатами могут быть критически важными для покрытия всего необходимого в центральных частях функциональности, и вы должны знать, как ими пользоваться. Для функционального тестирования можно рассматривать отдельные изолированные возможности, или изучать всю систему целиком.

Чтобы не повредить ревью и отчетности, опасайтесь гранулярности: лучше использовать один тест вида "убедиться в правильном обращении с невалидным вводом (пустой ввод, пробелы, строка, с ударениями, Unicode, особые символы ASCII, длинная строка, неверные разделители)", чем дюжину тестов. В некоторых ситуациях вы можете даже использовать фразу "Убедиться, что все явные требования выполнены", и сфокусироваться на более интересных тест-идеях.

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

Комбинаторные идеи тестов

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

Сценарное тестирование – один из способов это сделать, а попарного тестирования может вполне хватить, если нет смысла выяснять самые распространенные, подверженные ошибкам, важные или наилучшие комбинации (тестировщик, знающий продукт, может сходу рассказать вам, где нельзя пренебречь тестированием взаимодействия).

Комбинаторные идеи тестов совместно используют множество тест-элементов, потому что мы полагаем (или, наоборот, не знаем), что эти элементы могут влиять друг на друга.

Необычные идеи тестов

Требования часто пишутся так, чтобы их можно было "протестировать" (обычно это означает "верифицировать"). Это может запросто превратиться в количественные требования в форме контракта, которые не описывают реальные нужды и желания.

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

Необычные тест-идеи открыты, основаны на чем-то интересном, к ним нельзя применить дихотомию "Прошел/Упал", и они по большей части направлены на исследование и изучение с целью найти полезную информацию.

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

Эти тесты особенно важны для получения обратной связи, так как одна необычная идея может привести к двум другим, получше. У вас также есть шанс отбросить их как нерелевантные.

Визуальные идеи тестов

Не все можно выразить словами, а многие вещи гораздо лучше объясняются при помощи изображений. Попробуйте визуально изобразить ваши тесты – это также может помочь при генерации новых идей и осмыслении продукта.

Примеры таких тестов: модели состояний, изображения архитектуры, представление технологии, взаимоотношения между тест-элементами, различные вдохновляющие изображения.

Как и все прочие, визуальные идеи тестов трансформируются в любой другой тип и могут изменяться при надобности.

Что и как?

Большинство тест-идей, скорее всего, будет концентрироваться на том, что тестировать. Некоторые будут также указывать, как тестировать. Это очень выгодно – к примеру, если вы пишете, что собираетесь использовать Xenu’s Link Checker, а кто-то сообщит вам, что есть куда более подходящий инструмент. Иногда переход от идеи теста к реальному тесту долог и труден, и это провоцирует доверие к исполнителю тестов (которым можете быть вы сами) и стремление не упускать возможности.

Держите в голове "что" и "как", но расценивайте их как единое целое – это позволит создавать более эффективные и инновационные тесты, использующие синергию разных областей. Используйте целостный подход: копаясь в деталях, вы должны держать в уме общую картину, систему в целом.

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

Обсудить в форуме