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

документация для тестирования спека #8337 написана. Новые проекты

бьют в паруса, и настоящее наконец-то стало залечивать раны прошлого.

На следующий день, т.е. 26 марта.

Спек #8337, а также код и тест-кейсы к нему должны быть изменены,

т.е. минимум трое работников должны

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

79

• бросить текущие проекты,

• вспомнить спек #8337, понять изменения к нему и

• потратить время на воплощение изменений.

Эта ситуация является идеальной питательной средой для воз-

никновения багов, так как это будет работа (включая продюсера)

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

прошлый проект и понять риск внесения изменений. Мало того,

новые проекты также могут

а) пострадать или

б) даже быть отложенными

из-за того, что

а) на них будет потрачено меньше времени или

б) времени может физически не хватить.

Что же нам делать, чтобы избежать кордебалета с изменяю-

щимися спеками?

Если менеджер говорит, что нужно изменить спек, или продюсер

"вспомнил" о реально важной вещи для спека и эти "НУЖНО"

или "ВСПОМНИЛ" приходятся на самое наинеподходящее время,

то никуда не денешься, но все же две очень нехорошие ситуации,

связанные с изменением спека, можно превентировать.

Две нехорошие ситуации:

1. Спек может быть изменен по-тихому.

2. Изменения к спеку не утверждены программистом и тес-

тировщиком.

Вопрос: Как конкретно мы превентируем две нехорошие ситуации?

Ответ: Мы заморозим спек.

В любой интернет-компании существует программа контроля за

версиями. Во многих случаях это старая добрая CVS ("си-ви-эс" —

Concurrent Version System — система по согласованным версиям).

CVS — вещь многофункциональная, и мы о ней еще поговорим,

но сейчас она нам будет полезна для следующего:

1. С помощью CVS продюсер может сохранять версии спека и

всегда вернуться к старым редакциям.

2. С помощью CVS можно "закрыть" директорию так, чтобы

документы из этой директории могли читаться, но не мог-

ли редактироваться.

80

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

Процессуально все можно сделать так:

1. К определенной дате все спеки должны быть утверждены.

Неутвержденный спек не кодируется, и точка.

2. Директория со всеми утвержденными спеками закрывается,

и никто ничего не может изменить в этой директории...

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

Кстати,

техническую сторону, связанную с заморозкой спеков (spec freeze), обес-

печивают инженеры по релизу.

Процедура включает:

1. Утверждение всех изменений составом лиц, утвердившим

предыдущую редакцию.

2. Посылку е-мейла с перечислением изменений и именами

утвердивших всем департаментам, непосредственно свя-

занным с разработкой ПО (продюсеры, программисты,

тестировщики и инженеры по релизу). Одно из хороших

качеств такого е-мейла — это то, что люди, не участво-

вавшие в пункте 1 и имеющие старую версию спека, тоже

узнают об изменениях.

3. Открытие CVS-директории для закладки файла и ее закрытие.

Конечно, без изменений в спеках не обойтись, но путем

1) замораживания спеков;

2) введения процедуры изменения спека;

3) тщательного рассмотрения необходимости каждого из-

менения спека с участием менеджмента

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

Идем дальше.

Одна из частых причин, по которым в ПО появляются баги кода, —

это неверное толкование спека (misinterpretation) — ситуация,

когда программисты и/или тестировщики, работающие со спе-

ком, понимают по-своему то, что пытался донести до них продю-

сер, и при этом

• на 100% уверены, что на 100% понимают то, что имел в

виду продюсер, и,

• имея уверенность, не уточняют, так как не будешь же бе-

гать за уточнениями того, что тебе и так ясно.

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

81

Причина неверного толкования спека может быть связана

• с одной стороны, с возможностью множественного тол-

кования некой части спека и,

• с другой — с тем фактом, что многие вещи в этой жизни,

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

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

Кстати, именно поэтому на чертеже физического объекта (например,