Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

Постановка мозгов. Факт утверждения спека не означает, что тестировщик и программист объявили спек

Читайте также:
  1. II. ПОСТАНОВКА ЗАДАЧ НА ПЕДАГОГИЧЕСКУЮ ПРАКТИКУ
  2. Глава Х. Мозговые волны и самоорганизующиеся системы
  3. Горящая корзинка для мозгов
  4. Достоинства и недостатки метода мозгового штурма
  5. Интерпретация, анализ, постановка диагноза
  6. Кости мозгового отдела черепа
  7. Марта ( Bellydance классика ) в конкурс добавлена дисциплина - авторская постановка (самостоятельная работа без участия хореографа в номинации соло и дуэт

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

Идем дальше.

Спасский после игры с Фишером неделями ходит и думает: "А вот здесь нужно было бы его конем пришкварить", но, к сожалению, исправить ему уже ничего нельзя, "можно только забыть".

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

Далее.

Обычно спек распечатывается непосредственно перед началом работы по нему. Учитывая, что время начала работы по спеку у каждого индивидуально (я говорю о минутах), если спек будет по-тихому изменяться между распечатываниями, наступит ситуа­ция, когда

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

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



Тестирование Дот Ком. Часть 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, а также код и тест-кейсы к нему должны быть изменены, т.е. минимум трое работников должны


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



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

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

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

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

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

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

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

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

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

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

Если менеджер говорит, что нужно изменить спек, или продюсер "вспомнил" о реально важной вещи для спека и эти "НУЖНО" или "ВСПОМНИЛ" приходятся на самое наинеподходящее время, то никуда не денешься, но все же две очень нехорошие ситуации, связанные с изменением спека, можно превентировать.

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

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

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

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

В любой интернет-компании существует программа контроля за версиями. Во многих случаях это старая добрая CVS ("си-ви-эс" — Concurrent Version System — система по согласованным версиям).

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

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

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



Тестирование Дот Ком. Часть 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 и путем нехитрых манипу­ляций создает веб-страницу с кнопками, полями, картинками и прочими милыми деталями интерфейса.

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

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



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


Пример

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

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

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

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

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

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

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

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

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


Дата добавления: 2015-12-07; просмотров: 117 | Нарушение авторских прав



mybiblioteka.su - 2015-2024 год. (0.011 сек.)