вторник, 24 мая 2011 г.

Как бы я писал тестовые сценарии

Хочу вкратце осветить подход как я люблю писать тесты. Хотя между делом я это не очень люблю и потом постарался максимально удобный для себя подход подобрать.

Итак, что важно:
Создавать сценарии, а не отдельные тесты. Это может быть набор из тестов связаных друг с другом. Это экономит время. Например,
Выделять в большом сценарии отдельные точки проверки (verification points) с ожидаемыми результаами и отмечать их по мере прохождения. А  не ставить большую кучу в конце. Как-то в процессе вы должны были ожидать вот это. Видел такое, и не в полугодовом наколеночном проекте. А в зрелой большой успешной компании
В отчетах учитывать каждую точку проверки. Она влияет прошел сценарий/сьют/модуль/набор или нет
Но для общей статистики избегать дублирующий учет точек проверки. Учитывать vp только где это необходимо. Например, если в каждом сценарии вы проходите логин, то не надо считать, что это каждый раз отдельная точка проверки. Либо исключите его как точку проверки: уберите оттуда ожидаемый результат и не ставьте резолюцию. либо при отчетности не учитывать его кроме как только один раз во время проверки самого логина: оставьте ожидаемый результат (жалко копипаста?), но не ставьте резолюцию. Но обязательно оставьте коментарий и пометьте, что в данном случае тест провалился на логине, если только в этом тесте свалился логин. Или только он запускается сейчас.

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

1 комментарий:

  1. Да, очень часто такое бывает, когда поначалу пишутся стандартные "правильные" кейсы, а в конце включается все творчество. И низ тестового набора получается зафейлиным, или нет - в по ситуации. :)

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

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

    ОтветитьУдалить