Тестовые случаи (категории тестов, прмиеняемые к схеме) желательно фиксировать. Вряд ли, не обладая феноменальной памятью, мы сможем воспроизвести все те издевательства над системой, после которых ее отправили на доработку. А повторная прогонка после доработки необходима - проверить всё ли исправлено и корректно ли работают те функции, которые и раньше отрабатывали правильно. Итак, нам нужны краткие описания тестов. В общем случае она выглядит так:
1. ID тестового прмиера (идентификатор, уникальный номер);
2. Элемент схемы тестов (номер в той схеме с требованиями);
3. Предыдущее состоние (состояние системы до теста);
4. Входные данные (что мы, собственно, делаем);
5. Ожидаемые результаты (что должна делать система);
6. Реальные результаты (что в итоге она делает).
Отмечу, что при тестировании сайта (собственный опыт) предыдущее состояние не важно, зато важна последовательностей действий перед входными данными (впрочем, вся последовательность может включатся в "входые данные").
Упрощенный формат документации имеет место быть, однако только при условии, что никому, кроме вас не придется ею пользоваться в полной мере (не привлекаются новые сотрудниик и аудиторы). Упрощать схему можно как удобно тестеру, некоторые примеры рассмотрены в книге, мне же приводить их лень - все равно если мы захотим упростить тесты "под себя" мы их упростим так, как удобно нам самим.
Для фиксации очень удобны электронные таблицы.
Комментариев нет:
Отправить комментарий