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

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

ситуации, когда есть только текст.

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

максимуму иллюстрировались макетами (тоск-ир), блок-схе-

мами (flow chart) и примерами (example).

Теперь, после того как вы услышали про макеты и пошли дальше,

не увидев их (что было сделано намеренно — с целью дать вам

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

позвольте представить вам макеты "Регистрации":

Макет страницы (1)

Макет страницы (2)

* поле обязательно для заполнения

Цикл разработки ПО

85

Макет страницы (3)

Регистрация завершена, Нажмите сюда для

логина

Бонус: Макет страницы (2) в случае ошибки пользователя при

заполнении поля "Е-мейл"

Ошибка

I Проверьте правильность заполнения поля:

Е-мейл

2. Заново введите пароль

* поле обязательно для заполнения

Кстати, макет страницы (2) и бонус-макет страницы (2) противоречат

спеку: по спеку поле "Фамилия" является обязательным для заполнения, но

на макетах оно не выделено звездочкой. Противоречие внутри спека —

это баг, так как любая инструкция теряет смысл, если ее указания не

стыкуются друг с другом.

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

При обнаружении противоречий внутри спека (а БМП — это части спека!)

нужно сделать рапорт о баге против продюсера, чтобы тот настроил в

унисон несогласующиеся части. В нашем случае продюсер должен из-

менить либо текстовую часть спека ("все поля являются обязательными,

кроме поля "Фамилия"), либо соответствующие макеты (добавить

звездочку к полю "Фамилия").

Идем дальше.

86

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

В заключение краткого экскурса о спеках дам еще одну полезную

идею.

Каждая более или менее уважающая себя компания имеет свой

сайт в локальной сети (intranet), который недоступен внешним

пользователям. На этом сайте можно прочитать тезисы о корпо-

ративной морали, узнать имя любимого лемура президента ком-

пании, посмотреть фотографии тех, кто по-тихому правит утвер-

жденные спеки, и найти много другой полезной информации. Так

вот, все когда-либо утвержденные спеки должны быть выло-

жены на этот сайт. При этом они группируются по номеру релиза

и доступны для просмотра, поиска по директориям (название

директории — номер релиза), ID, ключевым словам в названии и

имени продюсера. Если спек ссылается на внешний документ

(например, на правила расчетов Центрального банка), то спек

должен содержать гиперлинк на адрес такого документа в локаль-

ной сети.

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

Не стесняйтесь рапортовать баги, которые вы будете находить в

спеках. Если продюсеры не понимают, то объясните им без пере-

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

в код и тест-кейсы и баг, найденный раньше, стоит компании дешевле

(об этом чуть позже), а посему учет таких багов является не правом,

а обязанностью тестировщиков.

Следующий этап цикла разработки ПО — это кодирование, осу-

ществляемое программистами (в то время как тестировщики

планируют проверку пишущегося кода).

Кодирование

Работа программиста заключается в том, чтобы перевести вещи,

отраженные в спецификации (или словах босса), на язык про-

граммирования.

Перевод осуществляется

• напрямую, т.е. программист берет спек и напрямую кодирует

его предписания (плохая, недальновидная и опасная идея),

• или после создания внутреннего дизайна кода, т.е. сугубо

технической документации, планирующей, как требова-

ния спека будут воплощены в коде (хорошая, дальновидная

и благодарная идея).

Цикл разработки ПО

87

К документам о внутреннем дизайне кода относятся, например,

• документ о дизайне /архитектуре системы (System /Architec-

ture Design Document);

• документ о дизайне кода (Code Design Document).

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

внутреннем дизайне кода — это один из признаков, что стар-

тап из шарашкиной конторы (пусть даже и с миллионным

финансированием) превращается в серьезную софтверную