Программисты и тестировщики хотя и работают над одним проектом, но руководствуются разными редакциями спека.



Причем даже если у программистов и тестировщиков будут рас­печатки одной и той же версии спека, то в случае тихого измене­ния их работа в той или иной части все равно не будет иметь смысла, так как они руководствовались устаревшей редакцией.


78


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


Пример

11 ноября. Спек утвержден Ножовым, Ложкиным и Тарелкиным. Про­дюсер Буханкин.

12 ноября. Спек распечатывает тестировщик Ножов. Работа по спеку началась.

 

14 ноября. У Буханкина новая идея. Спек по-тихому изменен.

15 ноября. Спек распечатывает для себя программист Ложкин. Работа по спеку началась.

16 ноября. У Буханкина новая идея. Спек по-тихому изменен.

17 ноября. Спек распечатывает для себя программистТарелкин. Работа по спеку началась.

18 ноября. У Буханкина новая идея. Спек по-тихому изменен.

19 ноября. Спек распечатывает для себя программист Салфетка, рабо­тающий над кодом по интеграции функциональности кода из этого и своего спека. Работа по спеку началась.

25 декабря. Все выясняется. 30 декабря.

17:00 — начало празднования Нового года в офисе компании.

17:30 — начало избиения Буханкина руками Ножова, Ложкина и Та­релкина.

18:00 — начало избиения Буханкина ногами Ножова, Ложкина и Та-релкина.

18:30 — в офис влетает Салфетка, вернувшийся после разговора с менеджером, разбрасывает в стороны подуставших Ножова, Ложкина и Тарелкина и добивает Буханкина контрольным ударом клавой по голове.

Надо отметить, что во многих случаях спек меняется не по воле продюсера, а по приказу сверху.

Ситуация

Марта.

Менеджер присылает продюсеру е-мейл, что необходимо срочно изменить спек #8337.

За день до этого, т.е. 24марта.

Представьте себя на месте продюсера:

продюсер уже вовсю работает над новым спеком и надеется, что релиз функциональностей согласно спеку #8337 пройдет без сучка без задоринки.

Представьте себя на месте программиста: код для спека #8337 написан, влегкую протестирован самим про­граммистом, частично позабыт и уже кажется частью безвозвратно потерянной юности.

Представьте себя на месте тестировщика:

документация для тестирования спека #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

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

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

с другой — с тем фактом, что многие вещи в этой жизни, для того чтобы быть адекватно понятыми разными людь­ми,нуждаются в многоплановой презентации.

Кстати, именно поэтому на чертеже физического объекта (например, двигателя мотоцикла) последний обычно изображается с трех сторон: вид спереди, вид сверху и вид слева.

Тезис

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

• макетами (mock-up),

• блок-схемами (flow chart),

• примерами (example).

Аргументация

С примерамивсе понятно: написал что-то — придумай пример для иллюстрации, заодно и сам лучше поймешь, о чем пишешь.

Народная мудрость гласит: "Лучше один раз увидеть, чем сто раз услышать". Отличной идеей является разработка продюсером макетовинтерфейса пользователя (User Interface или просто UI — "ю-ай"). Делается это так:

во время (или после) написания спека продюсер берет генератор веб-страниц типа Microsoft FrontPage и путем нехитрых манипу­ляций создает веб-страницу с кнопками, полями, картинками и прочими милыми деталями интерфейса.

Затем эта страничка "подшивается" к спеку и помогает всем за­интересованным лицам увидеть, ЧТО, по замыслу продюсера, должен будет увидеть пользователь.

Кстати, если спецификация предусматривает, что пользователь будет проходить через несколько веб-страниц для совершения какого-либо действия (например, покупки книги), то макеты этих веб-страниц могут не только являться частью спека, но и служить в качестве обоев, если их развесить на стенах офиса в том порядке, в котором их будет видеть пользователь.


82


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


Пример

Вольное изложение опека #1023 "Регистрация нового пользователя": Регистрация пользователя состоит из трех страниц, идущих в следую­щем порядке:

первая страница (1) — поле для индекса места жительства пользователя и кнопка "Продолжить регистрацию";

вторая страница (2) — поля для имени, фамилии, е-мейла и па­роля/подтверждения пароля пользователя, кнопка "Зарегистри­роваться";

третья страница (3) — текст с подтверждением регистрации.

Все поля обязательны для заполнения, и если на странице (1) или (2) вводится недействительное либо пустое значение любого поля, то пользователю показывается та же страница, но с сообщением об ошибке (error message). (В данном случае мы не будем говорить о том, какой ввод действителен (легитимен) для каждого из полей, так как это сейчас неважно.)

Продюсер разрабатывает три страницы, распечатывает их в двух ком­плектах, один из которых подшивает к спеку, а другой развешивает на стене в порядке появления перед пользователем: страница (1), стра­ница (2), страница (3).

Оговорка 1: Макеты могут быть разной степени детализации, и вполне допустимо, когда элементы интерфейса, не имеющие от­ношенияк иллюстрируемому спеку, не включаются в макет, на­пример, в случае с макетами для регистрации нас не интересуют картинки на веб-странице.

Оговорка 2: Понятно, что макеты интерфейса пользователя не создаются, если спек полностью посвящен бэк-энду веб-сайта (например, спек "Автоматизация отчетов по продажам"), так как детали интерфейса пользователя, т.е. фронт-энд, в таком спеке просто не упоминаются.

Проблема макетов (даже развешанных правильно) заключается в том, что они позволяют увидеть в первую очередь интерфейс пользователя,а не логику работы кода позади интерфейса, на­зываемую алгоритмом программы.


Дата добавления: 2018-05-02; просмотров: 644; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!