Роман Савин - тест dot com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
Вопрос: Как конкретно мы превентируем две нехорошие ситуации? Ответ: Мы заморозим спек. В любой интернет-компании существует программа контроля за версиями. Во многих случаях это старая добрая 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: Понятно, что макеты интерфейса пользователя не создаются, если спек полностью посвящен бэк-энду веб-сайта (например, спек "Автоматизация отчетов по продажам"), так как детали интерфейса пользователя, т.е. фронт-энд, в таком спеке просто не упоминаются. Проблема макетов (даже развешанных правильно) заключается в том, что они позволяют увидеть в первую очередь интерфейс пользователя, а не логику работы кода позади интерфейса, на- зываемую алгоритмом программы. Интерфейс — это то, ЧТО видит пользователь, а алгоритм — это то, ПОЧЕМУ пользователь видит то, что он видит. Для графической презентации алгоритмов используются блок- схемы, так горячо любимые всеми выпускниками математиче- ского класса выпуска 1990 г. люберецкой школы № 12. Цикл разработки ПО 83 Пример Представим предыдущую ситуацию с регистрацией, но в форме блок- схемы (такая блок-схема называется process flow chart, так как устроена по схеме ввод->процесс->вывод). Кстати, блок-схемы могут создаваться как продюсером, так и тестировщиком, но независимо от составителя, как правило, прекрасной идеей является включение блок-схемы в секцию тест- комплекта GLOBAL SETUP and ADDITIONAL INFO. Блок-схемы, макеты и примеры (вместе именуемые БМП) помо- гают превентировать появление багов или найти баги на уровне спека следующими путями: 84 Тестирование Дот Ком. Часть 1 • БМП — это описание предмета с разных сторон, что ведет к его адекватному толкованию разными людьми; • создание БМП — это процесс переосмысления написан- ного, что ведет к нахождению багов в написанном, т.е. в спеке; • макеты и блок-схемы наглядны и во многих случаях по- зволяют в буквальном смысле увидеть баги в отличие от ситуации, когда есть только текст. Еще раз: тестировщики должны настаивать, чтобы спеки по максимуму иллюстрировались макетами (тоск-ир), блок-схе- мами (flow chart) и примерами (example). Теперь, после того как вы услышали про макеты и пошли дальше, не увидев их (что было сделано намеренно — с целью дать вам прочувствовать контраст между работой без макетов и с ними), позвольте представить вам макеты "Регистрации": Макет страницы (1) Макет страницы (2) * поле обязательно для заполнения Цикл разработки ПО 85 Макет страницы (3) Регистрация завершена, логина Нажмите сюда для Бонус: Макет страницы (2) в случае ошибки пользователя при заполнении поля "Е-мейл" Ошибка I Проверьте правильность заполнения поля: Е-мейл 2. Заново введите пароль * поле обязательно для заполнения Кстати, макет страницы (2) и бонус-макет страницы (2) противоречат спеку: по спеку поле "Фамилия" является обязательным для заполнения, но на макетах оно не выделено звездочкой. Противоречие внутри спека — это баг, так как любая инструкция теряет смысл, если ее указания не стыкуются друг с другом. Постановка мозгов При обнаружении противоречий внутри спека (а БМП — это части спека!) нужно сделать рапорт о баге против продюсера, чтобы тот настроил в унисон несогласующиеся части. В нашем случае продюсер должен из- менить либо текстовую часть спека ("все поля являются обязательными, кроме поля "Фамилия"), либо соответствующие макеты (добавить звездочку к полю "Фамилия"). Идем дальше. 86 Тестирование Дот Ком. Часть 1 В заключение краткого экскурса о спеках дам еще одну полезную идею. Каждая более или менее уважающая себя компания имеет свой сайт в локальной сети (intranet), который недоступен внешним пользователям. На этом сайте можно прочитать тезисы о корпо- ративной морали, узнать имя любимого лемура президента ком- пании, посмотреть фотографии тех, кто по-тихому правит утвер- жденные спеки, и найти много другой полезной информации. Так вот, все когда-либо утвержденные спеки должны быть выло- жены на этот сайт. При этом они группируются по номеру релиза и доступны для просмотра, поиска по директориям (название директории — номер релиза), ID, ключевым словам в названии и имени продюсера. Если спек ссылается на внешний документ (например, на правила расчетов Центрального банка), то спек должен содержать гиперлинк на адрес такого документа в локаль- ной сети. Постановка мозгов Не стесняйтесь рапортовать баги, которые вы будете находить в спеках. Если продюсеры не понимают, то объясните им без пере- водчика, что баги, посеянные в спеке, могут, как зараза, перенестись в код и тест-кейсы и баг, найденный раньше, стоит компании дешевле (об этом чуть позже), а посему учет таких багов является не правом, а обязанностью тестировщиков. Следующий этап цикла разработки ПО — это кодирование, осу- ществляемое программистами (в то время как тестировщики планируют проверку пишущегося кода). Кодирование Работа программиста заключается в том, чтобы перевести вещи, отраженные в спецификации (или словах босса), на язык про- граммирования. Перевод осуществляется • напрямую, т.е. программист берет спек и напрямую кодирует его предписания (плохая, недальновидная и опасная идея), • или после создания внутреннего дизайна кода, т.е. сугубо технической документации, планирующей, как требова- ния спека будут воплощены в коде (хорошая, дальновидная и благодарная идея). Цикл разработки ПО 87 К документам о внутреннем дизайне кода относятся, например, • документ о дизайне /архитектуре системы (System /Architec- ture Design Document); • документ о дизайне кода (Code Design Document). развитие культуры создания и поддержания документации о внутреннем дизайне кода — это один из признаков, что стар- тап из шарашкиной конторы (пусть даже и с миллионным финансированием) превращается в серьезную софтверную компанию. Идем дальше. В идеальном случае каждый программист имеет личную версию сайта (или playground— игровую площадку), в которую входят: • веб-сервер (web server); • сервер с приложением (application server); • база данных (database). Коротко остановимся на каждом из этих компонентов. Пример 1. Пользователь набирает в браузере: www.testshop.rs. Через Интернет запрос идет на веб-сервер, и в ответ на жесткий диск пользователя сыпятся: • файл index.htm, содержащий HTML (Hyper Text Markup Language)-код с инкорпорированным в нем JavaScript (читается как "джава-скрипт")- кодом; • файлы-картинки (images), на которые ссылается веб-страница index.htm. Эти картинки пользователь должен увидеть в веб-брау- зере на веб-странице index.htm. Кстати, первая страница веб-сайта, которую мы по умолчанию видим в веб-браузере после набора URL веб-сайта (например, www.google.com), называется homepage. Кстати, коммуникация между веб-браузером и веб-сервером осуще- ствляется путем обмена сообщениями, основанными на протоколе, т.е. своде правил, называемом HTTP (Hyper Text Transfer Protocol). Потоки таких сообщений, передающихся по компьютерной сети, называемой Интернетом, являются HTTP-трафиком (HTTP traffic). 2. Пользователь кликаетлинк "Регистрация" (веб-сервер присылает в ответ файл register.htm и слинкованные с ним картинки). 3. На странице register, htm пользователь вводит имя, е-мейл и прочие данные и отправляет форму, нажав кнопку "Зарегистрироваться". 88 Тестирование Дот Ком. Часть 1 4. Через веб-сервер эта форма, т.е. запрос о регистрации, поступает на сервер с приложением, которое • обрабатывает этот запрос; • запрашивает базу данных, есть ли уже эккаунт с таким е-мейлом; • обрабатывает ответ от базы данных; • если е-мейл не найден, посылает запрос к базе данных о созда- нии записи для нового пользователя; • формирует ответ для пользователя; • в виде веб-страницы с подтверждением регистрации или веб-стра- ницы с ошибкой посылает пользователю ответ через веб-сервер. Так вот, программисты разрабатывают код вышеупомянутого приложения, который впоследствии отдается на растерзание тес- тировщикам, в злорадном предвкушении потирающим ручонки и знающим, что причинами возникновения багов в коде явля- ются как возможность программиста полдня бродить по Интер- нету, так и другие объективные вещи: а. Некачественные и/или изменяющиеся спецификации Об этом мы уже говорили. б. Личностные качества программиста Такие, как халатность, невнимательность и лень. в. Отсутствие опыта Программист может просто не знать, как нужно сделать пра- вильно. г. Пренебрежение стандартами кодирования О стандартах чуть позже. д. Сложность системы Современные интернет-проекты отличаются такой сложностью, что мозг простого смертного порой просто не в состоянии про- анализировать все последствия создания/изменения/удаления кода и предугадать появление проблемы. е. Баги в ПО третьих лиц, т.е. баги • в операционных системах; • в компайлерах (compiler — ПО для переведения (напри- мер, C++) кода в машинный язык и создания исполняе- мых файлов); • в веб-серверах; • в базах данных и др. Цикл разработки ПО 89 ж. Отсутствие юнит-тестирования, х.е. тестирования кода самим программистом: "И вообще, почему я должен искать баги в своем коде, когда есть тестировщики?" (Поговорим о юнит-тестировании через минуту.) з. Нереально короткие сроки для разработки Об этом мы тоже скоро поговорим. Возможности оздоровления кода и превентирования багов до передачи кода тестировщикам (иллюстрации последуют не- медленно) включают: 1. Наличие требований к содержанию спеков и следова- ние правилам их изменения; 2. Возможность прямой, быстрой и эффективной комму- никации между программистами и программистами и продюсерами; 3. Инспекции кода; 4. Стандарты программирования; 5. Реальные сроки; 6. Доступность документации; 7. Требования к проведению юнит-тестирования (о кото- ром мы поговорим уже через 30 секунд); 8. Реальные финансовые рычаги стимуляции написания эффективного и "чистого" кода; 9. Наличие понятий "качество" и "счастье пользователя" как основных составляющих корпоративной философии. Подробности. 1. НАЛИЧИЕ ТРЕБОВАНИЙ К СОДЕРЖАНИЮ СПЕКОВ И СЛЕДОВАНИЕ ПРАВИЛАМ ИХ ИЗМЕНЕНИЯ О спеках мы уже говорили. 2. ВОЗМОЖНОСТЬ ПРЯМОЙ, БЫСТРОЙ И ЭФФЕКТИВНОЙ КОММУНИКАЦИИ МЕЖДУ ПРОГРАММИСТАМИ И ПРОГРАММИСТАМИ И ПРОДЮСЕРАМИ Здесь есть следующие аспекты: а. Психологические аспекты Очень важно привить в культуру компании следующее правило: "Если к тебе обратились — помоги". 90 Тестирование Дот Ком. Часть 1 Пример Программист приходит к продюсеру с просьбой объяснить некую часть спека. Продюсер говорит, что он сейчас слишком занят. "Давай завтра, добро?" Очень часто после пары "давай завтра" программист что делает? Пра- вильно! Он пишет код так, как его понимает, — без всякой гарантии, что сей код отразит требуемое. Следующий аспект: программист (как и все остальные участники цикла) никогда не должен стесняться спрашивать (хоть двести раз!) и подтверждать свое понимание е-мейлами типа: "Просто хотел уточнить, что я правильно понял, что пункт 12.2 такого-то спека говорит..." Если же программисту не отвечают, когда он подходит, прекрасно — нужно послать е-мейл и сохранить этот е-мейл, как и е-мейлы "Я хотел уточнить". Если снова не отвечают, программист должен идти к своему менеджеру и просить его принять меры. И это не стукачество, а деловая практика — business is business. Следующий аспект: Менеджмент должен регулярно устраивать так называемые Team Building Activities (мероприятия по сплочению коллектива) с той простой целью, чтобы между членами команды кроме профес- сиональных налаживались и человеческие контакты. Причем, как показывает опыт, совместный выезд для игры в пейнтбол раз в месяц гораздо эффективнее для сплочения коллектива, чем со- вместная проспиртовка мозгов во время пятничных застолий. |