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% понимают то, что имел в
виду продюсер, и,
• имея уверенность, не уточняют, так как не будешь же бе-
гать за уточнениями того, что тебе и так ясно.
Цикл разработки ПО