tестирование dot com
Шрифт:
главное — приобретение автоматизма.
Примеры багов из жизни:
1. Бутерброд падает маслом вниз.
2. Подхалимы и говоруны имеют намного больше шансов на повыше-
ние, чем скромные честные труженики.
3. Несоответствие миловидной внешности и змеиной сущности.
4. Попугай воспроизводит на людях худшее из словарного
зяина.
5. Автомобили российского производства.
6. Кот Бегемот в фильме В. Бортко "Мастер и Маргарита".
Идем дальше.
Что такое тестирование
Любое тестирование — это поиск багов. Испытываем ли мы
новую соковыжималку, наблюдаем ли за поведением подруги
или занимаемся самокопанием — мы ищем баги. Баги находятся
следующим образом:
1. Мы узнаем (или уже знаем) ожидаемый результат;
2. Мы узнаем (или уже знаем) фактический результат;
3. Мы сравниваем пункт 1 и пункт 2.
Как видно, каждый из нас уже является тестировщиком, так как
разного рода осознанные и неосознанные проверки, осуществ-
ляемые нами и в отношении нас, являются неотъемлемой частью
жизни, просто раньше мы непрофессионально качали головой и
выдавали тирады о несправедливости мира, но зато теперь в слу-
чае несовпадения фактического и ожидаемого мы будем с улыб-
кой мудреца смотреть на дилетантов, хлюпающих носами на мо-
сковском ветру, и тихо, но веско (как дон Карлеоне) говорить:
"Та-а-к, еще один баг".
Для иллюстрации правильного подхода приведу в пример одного
моего друга, который выстроил целую систему доказательств тезиса,
что люди и компьютеры созданы по одному образцу. Основой его аргу-
ментации явился тот факт, что и те и другие имеют физическую обо-
лочку (тело/железо) и неосязаемое составляющее, управляющее ею
20
Тестирование Дот Ком. Часть 1
(душа/ПО). Соответственно болезни тела он называл багами в железе,
а проблемы с головой — багами в ПО и очень сожалел, что ПО людей,
управляющих этим миром, состоит в основном из багов...
Теперь вспомним о том, что есть компьютерное ПО и что нам
нужно научиться его тестировать.
С фактическим результатом здесь более или менее понятно: нужно
заставить систему проявить себя и посмотреть, что произойдет.
Сложнее дело обстоит с ожидаемым результатом.
Источники ожидаемого результата
Основными источниками ожидаемого результата являются:
1. Спецификация.
2. Спецификация.
3. Спецификация.
4. Спецификация.
5. Жизненный опыт, здравый смысл, общение, устоявшиеся
стандарты, статистические данные, авторитетное мнение и др.
Спецификация на первой—четвертой ролях — это не ошибка, а
ударение на то, что спецификация для тестировщика — это:
• мать родная, а также
• Друг,
• товарищ и
• брат.
Спецификация важна для программиста и тестировщика так же,
как постановление пленума ЦК для коммуниста.
Спецификация — это инструмент, с помощью которого вы смо-
жете выпустить качественный продукт и прикрыть свою спину (в
оригинале звучит как CYA или cover your ass).
Итак, что же это за зверь?
Спецификация (или spec — читается "спек". Далее употребляется
в мужском роде) — это детальное описание того, как должно
работать ПО. Вот так, ни много ни мало.
В большинстве случаев баг — это отклонение от специфика-
ции (я говорю о компаниях, в которых спеки в принципе сущест-
вуют и ими пользуются).
Что такое баг
21
Пример
Пункт 19.а спека #8724 "О регистрации нового пользователя" устанав-
ливает:
«Поле "Имя" должно быть обязательным. Страница с ошибкой должна
быть показана, если пользователь посылает регистрационную форму
без заполнения указанного поля».
В общем все просто:
• тестировщик идет на страничку с регистрационной формой;
• кликаетлинк "Регистрация";
• заполняет все обязательные поля, кроме поля "Имя";
• нажимает на кнопку "Зарегистрироваться".
Если ошибка не показана и регистрация подтверждается, то это есть
момент истины и нужно рапортовать баг (file a bug).
Если ошибка показана, то относительно пункта 19.а на некоторое
время можно успокоиться. Мы поймем, почему можно успокоиться
лишь на некоторое время при разговоре о регрессивном тести-
ровании. ..