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

Савин Роман

хватить должно, но они будут самыми печальными из всех исто-

рий о бессмысленном существовании.

Постановка мозгов

В мире с ограниченными ресурсами (например, время на тестирова-

ние) 100%-е тестирование ПО — это фикция (я говорю о реальном

ПО,

а не о программах из наших примеров) и единственное, что мы

можем сделать как тестировщики, — это профессионально, творчески

и добросовестно спланировать и провести наше тестирование. Про-

сочившиеся баги — это неизбежное зло, но свести его к мини-

муму — в наших руках.

ВТОРАЯ КОНЦЕПЦИЯ: критерий эффективности тестирования —

это количество багов, найденных до релиза.

РАЗОБЛАЧЕНИЕ ВТОРОЙ КОНЦЕПЦИИ

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

чтобы все развитые личности ходили в лаковых ботинках.

Скажите, имеет ли значение для развитой личности, сколько де-

нег и сил было потрачено на покупку и ремонт помещения? От-

вет отрицательный: единственное, что ее интересует, — это

сходная цена и качество обуви. Так и в нашем интернет-магазин-

ном деле: пользователю все равно (и это правильно), сколько

вы не спали ночей, сколько вы нашли багов и скольких деву-

шек оставили без романтического ужина. Пользователю нуж-

но, чтобы наш онлайн-магазин работал качественно. Точка.

Идем дальше.

Идея о статистике для пострелизных багов

Итогом разработки ПО является передача этого ПО пользовате-

лю, называемая "релиз" (release).

Допустим, что перед первым релизом нашли 50 багов, а перед

вторым — 200. Казалось бы, во втором случае тестирование про-

шло более успешно. Но в реальности вполне может быть, что по-

сле первого релиза пользователи найдут 2 бага, а после второго —

30

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

22 бага. Тестирование какого релиза было более эффективным?

Очевидно, что первого, так как первый релиз дал возможность

пользователям познакомиться только с двумя багами в отличие

от второго релиза — с 22 багами.

Кроме того, результаты тех же самых усилий, но приложен-

ных для

тестирования разных функциональностей могут

серьезно различаться. Это происходит потому, что предмет тес-

тирования, т.е. некая часть нашего ПО, подвергнутая тестирова-

нию, каждый раз уникален. Уникален качеством кода, сложно-

стью и трудоемкостью тестирования и прочими вещами.

Кстати,

один из критериев качества кода — это количество багов на

1000 строк кода.

Почему же так популярно представление количества багов ДО

релиза в качестве цели и критерия эффективности тестирования?

Поставьте себя на место менеджера отдела тестирования. Ему

нужны просто количественные данные, чтобы показать своим

менеджерам, что в коде данного релиза под его чутким руковод-

ством тестировщики нашли столько-то багов.

Еще одной причиной любви к количеству багов, найденных до

релиза, может быть элементарное незнание основ тестирования

(в которые мы, кстати, незаметно, но верно вгрызаемся).

Итак,

количество багов, найденных до релиза, ничего не говорит об

эффективности тестирования.

Баги, найденные после релиза, — вот что нас угнетает и

преследует в бессонные лунные ночи.

Кстати, если уж мы заговорили о статистике и цифрах, давайте

скажем пару слов о том, как мы используем данные о таких вот

пострелизных багах.

Сначала определимся с тем, что баги бывают разных приори-

тетов, которые отражают важность бага. Скажем, если у

машины на дороге отваливается колесо, это Ш (баг высшего

приоритета). Таких приоритетов обычно 4. Соответственно к

П4 относятся самые незначительные баги (как небольшая цара-

пина на боку автомобиля).

Цель тестирования Decoded

31

Итак, после каждого релиза данные о багах, найденных после

релиза, классифицируются по заданным критериям и анали-

зируются на предмет нахождения слабого звена в процессе

разработки ПО.

Критериями могут быть приоритет, функциональность, имя тес-