Сообщений в теме: 5

[EugeneL]

Коллеги, подскажите, пожалуйста, как определить на какие фичи нужны тест-кейсы?

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

А как Вы решаете эту проблему?

[Freiman]

А как Вы решаете эту проблему?

Ну вот примерно так и решаем :)
где достаточно заголовка с кратким комментарием, что требуется, остается только заголовок + небольшой комментарий
где требуется расписывать или считать по формуле — расписываем, указываем формулу и способ ее использования.

[rpwheeler]

Странная какая-то тема.

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

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

[EugeneL]

Странная какая-то тема.

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

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

Эта тема характерна для человека, пришедшего в тестирование недавно, как мне кажется. Я единственный QA. Пока пытаюсь осознать: как должен выглядеть рабочий процесс.
Пока пришел к вывводу, что процесс имеет примерно такой вид Smoke-TRR-Verifification-Critical-Automation. Сейчас пытаюсь вставить куда-то тест-дизайн, т.к. ранее с такой необходимостью не сталкивался. Пока кейсы обновляю "на лету", в процессе их прохождения. Создание новых, думаю, совмещу с процессом приемки новых фич. Так, у меня будет достаточное хорошее покрытие... Запланированной работы с требованиями у меня нет, т.к. этот процесс носит срочность ASAP: как только возникает проблема, мне надо с ней разобраться в минимальный срок....

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

[Drag]

Ок, тогда мое видение. Тесты на фичи нужны, если:
1. фичу кто-то из заказчиков очень сильно ждет (чтобы понимать покроет ли фича цели заказчика),
2. фича слишком громоздкая (без кейсов потом будет сложно вспомнить как оно работает),
3. фича влияет на основной функционал (чтобы потом было откуда плясать дополняя кейс на осн. функционал).

[gamretsky]

Лично я разделаю 3 стадии:

1. Достаточно заголовка
2. Достаточно заголовка + описание кейса (коротко, лаконично, на примере описания Use Case)
3. Детальное пошаговое описание кейса

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