С чего начать написание тест кейсов и чек-листов?
Этот вопрос беспокоит многих начинающих тест дизайнеров. Большой продукт, много требований, как ничего не упустить и с чего начать?
Вот несколько советов по тому, как лучше и удобнее проводить тест дизайн. Это только рекомендации, в ходе работы вы уже сами выработаете алгоритм действий.
1. Поймите структуру
Определите, какие разделы / страницы / экраны есть у приложения или сайта.
В этом помогут требования. Скорее всего аналитик структурировал требования по этим самым разделам. Не пытайтесь сразу прочесть все 150 листов требований и уснуть уже на третьей странице. Бегло ознакомьтесь с ТЗ по заголовкам, чтобы понять из чего состоит наше приложение.
2. Приоритизируйте
Расставьте приоритеты, какие разделы нужно покрыть тестами в первую очередь.
Это может зависеть, например, от сроков разработки. Допустим экран 1 уже готов к тестированию, а экран 2 и 3 будет готов послезавтра. Конечно в таком случае нужно начать с экрана 1. Если все экраны будут разработаны в одно время, то покрывай тестами последовательно все экраны, начиная с того, который встретится пользователю первым.
3. Изучите требования
Для выбранного экрана / раздела / страницы изучите требования и макеты, какие элементы должны присутствовать согласно ТЗ, есть ли они на макетах.
Все ли логично написано в требованиях и нет ли у вас вопросов к аналитику. Тут своего рода проводится тестирование требований.
4. Напишите функциональные позитивные проверки
Берите первое требование и напишите для него функциональные позитивные проверки.
Если вы пишете тест кейсы, то сначала лучше накидать идеи тестов или их заголовки, а потом уже расписывать детально шаги. Важно записать все проверки и ничего не пропустить, а написание шагов может отвлечь от генерации идей тестов. Хотя кому как удобно конечно.
5. Напишите негативные проверки
После того, как позитивные сценарии написаны, разработайте для этого требования негативные тесты.
Конечно нужно учитывать, что не для каждого сценария можно придумать негативный тест.
Аналитики часто забывают указывать в требованиях ожидаемое поведение для негативного использования системы. Что будет если ввести неверный логин, что будет, если попытаться загрузить слишком большой файл и т.д. Требуйте от аналитиков добавить в ТЗ эту информацию
6. И так для каждого требования
Переходите к следующему требованию и пишите для него позитивные и негативные проверки.
7. Убедитесь, что все требования покрыты проверками
Перечитайте ТЗ, отметьте строки, для которых написаны тест кейсы. И напишите тест кейсы для тех требований, которые остались непокрытыми.
Вот такой алгоритм!