tестирование dot com
Шрифт:
ния ни к чему хорошему не приводят, как и попытки заставить
программиста произвести функциональное тестирование.
Вот перевод постинга на одном из форумов по тестированию:
"Программист не должен проводить тестирование, и давать
релизу зеленый свет. Нужно, чтобы кто-то независимый (чело-
век/отдел) был ответствен за поиск багов и уполномочен "дос-
тавать "
Дело в том, что я как программист знаю свой код, и если я сам
провожу тестирование, то обязательно буду делать допущения,
что какие-либо части кода работают по умолчанию и их можно
не проверять. С другой стороны, мои тесты основаны на моем
понимании того, как работает код, и не учитывают реальных и
порой абсолютно нелогичных вещей, которые будут делаться поль-
зователями с моим кодом. С третьей стороны, у меня на тес-
тирование нет времени, и я не понимаю, почему должен проводить
тестирование, если за него платят тестировщикам ".
Реальность — это мир, пропущенный через призму субъективно-
го восприятия. Например, каждый родитель свято верит, что его
ребенок самый умный, талантливый и перспективный. Код — это
дитя программиста, и в своей реальности программист нередко
воспринимает код как априорно непогрешимый.
Вот вам легенда про призму восприятия:
Когда на пути в Индию корабли Колумба остановились перед од-
ним из Карибских островов, индейцы... этих кораблей не увидели,
потому что их призмы восприятия не пропускали образы, абсо-
лютно чуждые тем предметам и явлениям, с которыми они и их
предки существовали бок о бок на протяжении тысячелетий. И
лишь шаман, учуяв что-то неладное, несколько дней пристально
всматривался в горизонт, пока наконец не отделил романтические
силуэты испанских фрегатов от привычных океана и неба и не ска-
зал своей пастве: "Опа! Корабли Колумба " (тут, конечно, все сразу
настроили свои призмы, увидели не замеченные раньше корабли,
деловито погрузили в лодки свиней и поехали менять
Идея, думаю, понятна. Программист пишет, тестировщик тести-
рует, Филипп Филиппыч оперирует, Айседора Дункан танцует, и
никаких разрух.
Классификация видов тестирования
145
Итак, блэк бокс-тестировщику, знающему лишь то, для чего был
написан код (т.е. функциональности), а не как он был написан, легче
смотреть на тестирование с точки зрения пользователя, для удов-
летворения чаяний которого весь софтверный сыр-бор и начался.
С другой стороны,
блэк бокс-тестирование ведется вслепую, так как ни одна из час-
тей виртуального моста неизвестна. Следствием этого может
стать ситуация, когда для вещи, проверяемой одним тест-кейсом,
пишется несколько тест-кейсов.
Итак, в случае с черным ящиком тестировщик не знает, как
устроен виртуальный мост, и это может быть как полезно, так и
вредно для дела.
Разберем второй признак.
2. ИДЕИ ДЛЯ ТЕСТИРОВАНИЯ ИДУТ ОТ ПРЕДПОЛАГАЕМЫХ
ПАТТЕРНОВ (pattern — образец) ПОВЕДЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
То, что мы называли вводом (шагами), на самом деле является
двумя вещами, которые так же неотрывно связаны, как судьбы
Ромео и Джульетты. Речь идет о
сценариях и
данных для сценариев.
Исполнение тестирования может проходить как при наличии, так
и без тест-кейсов. Так вот в обоих случаях сценарий (scenario) —
это последовательность ДЕЙСТВИЙ для достижения фактиче-
ского результата.
Пример сценария
1. Открой www.main.testshop.rs.
2. Кликни линк "contact us".
Если исполнение тестирования идет по тест-кейсам, то можно ска-
зать, что сценарий тест-кейса — это совокупность шагов тест-кейса.
Данные для сценариев, или просто "данные", — это конкрет-
ные ЗНАЧЕНИЯ ВВОДА, используемые для достижения факти-
ческого результата.
Пример данных
1. Открой www.main.testshop.rs.
2. Введи текст "Затоваренная бочкотара" в поле поиска.
3. Нажми кнопку "Искать".
146
Тестирование Дот Ком. Часть 2
В последнем примере шаги 1 —3 (включительно) были сценарием,