tестирование dot com

Основными источниками ожидаемого результата являются:

1. Спецификация.

2. Спецификация.

3. Спецификация.

4. Спецификация.

5. Жизненный опыт, здравый смысл, общение, устоявшиеся

стандарты, статистические данные, авторитетное мнение и др.

Спецификация на первой—четвертой ролях — это не ошибка, а

ударение на то, что спецификация для тестировщика — это:

• мать родная, а также

• Друг,

• товарищ и

• брат.

Спецификация важна для программиста и тестировщика так же,

как постановление пленума ЦК для коммуниста.

Спецификация — это инструмент, с помощью которого вы смо-

жете выпустить качественный продукт и прикрыть свою спину (в

оригинале звучит как CYA или cover your ass).

Итак, что же это за зверь?

Спецификация (или spec — читается "спек". Далее употребляется

в мужском роде) — это детальное описание того, как должно

работать ПО. Вот так, ни много ни мало.

В большинстве случаев баг — это отклонение от специфика-

ции (я говорю о компаниях, в которых спеки в принципе сущест-

вуют и ими пользуются).

Что такое баг

21

Пример

Пункт 19.а спека #8724 "О регистрации нового пользователя" устанав-

ливает:

«Поле "Имя" должно быть обязательным. Страница с ошибкой должна

быть показана, если пользователь посылает регистрационную форму

без заполнения указанного поля».

В общем все просто:

• тестировщик идет на страничку с регистрационной формой;

• кликаетлинк "Регистрация";

• заполняет все обязательные поля, кроме поля "Имя";

• нажимает на кнопку "Зарегистрироваться".

Если ошибка не показана и регистрация подтверждается, то это есть

момент истины и нужно рапортовать баг (file a bug).

Если ошибка показана, то относительно пункта 19.а на некоторое

время можно успокоиться. Мы поймем, почему можно успокоиться

лишь на некоторое время при разговоре о регрессивном тести-

ровании. ..

Функциональные баги и баги спека

Допустим, что ошибка не была показана и мы имеем классиче-

ский случай функционального бага (functional bug, или баг

обыкновенный), т.е. бага, вскормленного на несоответствии

фактической работы кода и функционального спека.

Если вы внимательно читали пункт 19.а, то не могли не заметить

(шутка), что непонятно, какое должно быть сообщение об ошибке

(error message), т.е. фактически решение отдано на откуп про-

граммисту и он может предусмотреть, что при соответствующей

ситуации код выдаст:

• НЕинформативное сообщение "Ошибка" и оставит пользо

вателя ломать голову над тем, что он сделал неправильно,

либо

• информативное сообщение «Пожалуйста, введите ваше имя

и нажмите кнопку "Регистрация"»

и в любом случае формально будет прав, так как спецификация

не детализирует текста ошибки.

Кстати, несколько лет назад был случай, когда программисты в специ-

альном ПО, разработанном для американских тюрем, оставили "рабо-

чее" название кнопки, причем тюремщикам идея так понравилась, что

они просили ничего не исправлять. Надпись на кнопке была: "Освобо-

дить подонка".

22

Тестирование Дот Ком. Часть 1

В общем сложилась ситуация, когда сама спецификация имеет

проблему, так как мы ожидаем (или по крайней мере должны

ожидать), что в спеке будут подробности о тексте ошибки, а в

реальности их там нет. Так и запишем — "баг в спецификации"

(spec bug).

Кстати, вот варианты развития ситуации с проблемным спеком:

а. Скорее всего программист все же напишет информативное сооб