Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Я работаю тестировщиком несколько лет, и привыкла к различным типам тестирования – таким, как приемочное, регрессионное, исследовательское, смоук. Но недавно меня познакомили с новым типом, о которым я раньше не задумывалась – с предварительным тестированием.

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

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

Когда имеет смысл предварительно тестировать:

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

Зачем это нужно?

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

Как это делается

1. Проведите исследовательское тестирование старой фичи. Выявите основной пользовательский сценарий.
2. Задокументируйте работу этого сценария, включая необходимые конфигурационные шаги.
3. Продолжайте тестировать, исследуя граничные случаи фичи.
4. Запишите все, что вы нашли – это могут быть и не баги, а просто области функциональности, работающие не так, как кто-либо другой может ожидать.
5. Зарепортите все найденные баги и обсудите с командой, исправлять ли их в новой фиче, или оставить все как есть.
6. Сделайте скриншоты сложных экранов – писем, сообщений, экранов с большим количеством текста, изображений или кнопок. Сохраните их в легкодоступном месте – например, в Wiki.

Когда новая фича готова:

1. Пробегитесь по основному сценарию с новой фичей и убедитесь, что она ведет себя так же, как и старая.
2. Проверьте граничные значения и убедитесь, что все осталось по-старому.
3. Убедитесь, что баги, которые было решено исправить, действительно исправлены.
4. Сравните скриншоты старой фичи со скриншотами новой и удостоверьтесь, что они идентичны (за исключением того, что было решено поменять).
5. Проведите необходимое дополнительное тестирование – например, новой функциональности, которой ранее не было, или интеграции фичи с другими частями приложения.

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

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