Программисты и тестировщики хотя и работают над одним проектом, но руководствуются разными редакциями спека.
Причем даже если у программистов и тестировщиков будут распечатки одной и той же версии спека, то в случае тихого изменения их работа в той или иной части все равно не будет иметь смысла, так как они руководствовались устаревшей редакцией.
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; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!