фабпждфуквп. Савин Тестирование dot-com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
 Скачать 5.26 Mb.
|
|
б. Технический аспект Каждый из участников цикла разработки ПО должен быть досту- пен для контакта: желательно, чтобы все они работали в одном здании; в локальной сети должны быть доступны служебные, мо- бильные и домашние телефоны; необходимо согласовать часы (хотя бы 4 часа в день), когда все (и тот, кто ушел в 6 часов вече- ра и в 3 утра) находятся в офисе. 3. ИНСПЕКЦИИ КОДА У некоторых программистов есть такая концепция: "Если я пишу код, который могу понять только я, то меня не уволят". Ну, во-первых, при желании можно уволить даже президента "ЮКОСа", во-вторых, такой подход к работе априори неправи- Цикл разработки ПО 91 лен: в интернет-компаниях никто никого силком не держит, и если ты согласился работать на определенных условиях, то будь добр работать профессионально и добросовестно. Если же компания не выполняет взятых на себя обязательств (например, по оплате), то мы просто ищем другую компанию — ведь никто никому не давал клятву верности. Постановка мозгов Компания держит каждого из нас до тех пор, пока мы ей нужны, и если какая-то конкретная позиция перестает быть необходимой для бизне- са, то человеку просто говорят: "Гуд бай" независимо от того, сколько у него детей плачет по лавкам; котов мяукает по печкам. Как поет Тимур Шаов: "Это бизнес, господа..." Вместе с тем, если вы находите компанию с лучшими для себя усло- виями и, работая на старом месте, прошли интервью и получили письменное предложение о работе, то вы просто идете к своему ме- неджеру и говорите, что собрались уходить, но можете подумать о том, чтобы остаться, только если компания сделает для вас то-то и то-то, например повысит заработную плату. Несмотря на то что бизнес есть бизнес, нужно оставаться профессио- налом, даже если предложение о новой работе удивительно выгодно и искушение все бросить велико. Никогда не уходите из компании, не передав дела и не закончив старые проекты. Ведите себя про- фессионально ! После небольшого отступления продолжаем основную тему. В-третьих, чтобы избежать подобных проблем, чреватых багами и трудностью их фиксирования (fix — починка, ремонт), в ком- пании должны проходить инспекции кода (code inspection). Это может быть еженедельное совещание, например, следующего формата: менеджер программистов распечатывает код любого из программистов, и последний в присутствии коллег рассказывает, что, как и почему. Будет ли программист писать код, понятный только ему, если на совещании его обязательно спросят: "Това- рищ, а что это вы здесь написали?" 4. СТАНДАРТЫ ПРОГРАММИРОВАНИЯ С пунктом 3 перекликается идея создания стандартов програм- мирования. 92 Тестирование Дот Ком. Часть 1 Пример Вспомним Вавилонскую башню, а вернее, ТОТ момент строительства, когда все вдруг стали говорить на разных языках (множественность стандартов). Последствия печальны: проект был начисто заброшен, название кинокомедии "Some like it hot" перевели как "В джазе только девушки" и японские фанатки "Тагу" убеждены, что "Мальчигей" — это название места для романтических свиданий нетрадиционных девушек на Красной площади. Такая же катавасия творится в компании, когда программисты вроде бы и используют тот же язык, например C++, но при напи- сании кода каждый руководствуется своими привычками. Пример Допустим, что отсутствуют стандарты названия новых классов C++. S этом случае, если Саня любит называть свои классы в формате "CREDITCARD" (все заглавные и нижнее подчеркивание), а Леха — "CreditCard" (заглавные только первые буквы каждого слова и слитное написание), то, например, Леха, не зная о привычках Сани, но верный своим при- вычкам, помня лишь "Кредиткард" и желая обратиться к функции из CREDITCARD, в своем коде так и запишет: "CreditCard". В итоге код не будет работать, так как C++, ничего не знающий ни о Лехе, ни о Сане, ни о кредитных картах, думает о CREDITCARD и CreditCard как об абсолютно разных классах. Стандарты могут включать: • правила о комментариях; • правила об именах таблиц в базе данных, классов, функций и различных видов переменных; • правила о максимальной длине строки; • прочее. Документ со стандартами должен быть доступен на интранете. Стандарты программирования — это неотъемлемая часть процесса, когда в компании работают два программиста и боль- ше. Они по определению должны быть обязательны для всех. 5. РЕАЛЬНЫЕ СРОКИ В стартапе изначально и по определению сроки на разработку нереальны, и приходится балансировать между • "поспешишь — людей насмешишь" и • необходимостью закончить кодирование в срок. Цикл разработки ПО 93 Несмотря на то что стопроцентно действующих рецептов нет, вот хорошая идея для облегчения нелегкой жизни программистов: после ознакомления со спеками программисты должны предос- тавить менеджменту примерные оценки (сметы) сроков для разработки кода, и исходя из этих смет менеджмент может, если нужно • перераспределить нагрузку и • посмотреть, имеет ли смысл убирать что-то из менее приоритетных функционалъностей ради того, чтобы чисто и тщательно написать остальной код. Единственное утешение состоит в том, что, когда стартап как бизнес становится более зрелым, сроки и рабочие часы стабили- зируются во многом потому, что менеджмент понимает, что луч- ше дать реальный срок (например, перенеся некоторые из спеков в следующие релизы), чем поступиться качеством. 6. ДОСТУПНОСТЬ ДОКУМЕНТАЦИИ ВСЕ документы, относящиеся к разработке ПО, включая спеки, процедуру изменения спека, стандарты программирования, тест- комплекты, и документы, о которых мы будем говорить в даль- нейшем, должны быть доступны в локальной сети, и их располо- жение должно быть максимально оптимизировано для удобства и быстроты поиска. Все должно быть сделано для того, чтобы за- интересованный сотрудник быстро нашел нужный документ, а не тратил свое время и время своих коллег на долгие поиски. Несмотря на кажущуюся очевидность и легковесность этого мо- мента, несоблюдение правила о доступности ВСЕХ документов на практике может принести много проблем. 7. ТРЕБОВАНИЯ К ПРОВЕДЕНИЮ ЮНИТ-ТЕСТИРОВАНИЯ Юнит-тестирование (unit testing) — это тестирование, произ- водимое самим программистом. Здесь нужно подчеркнуть, что неправильный подход к введению юнит-тестирования вызо- вет справедливое раздражение программистов, так как за тес- тирование платят тестировщикам, а отсутствие требований к юнит-тестированию вообще увеличит стоимость багов. 94 Тестирование Дот Ком. Часть 1 Постановка мозгов Стоимость бага — это • расходы компании, чтобы найти баг и исправить его до пе- редачи кода пользователю. Расходы компании поддаются приблизительной оценке; • убытки, которые несет компания, потому что баг не был найден до передачи кода пользователю. Объективная оценка убытков в большинстве случаев невозможна. Подробности: Стоимость бага в первом случае: Если баг был допущен на уровне спека и найден во время тестирования кода, его стоимость вычисляется как стоимость оплаты продюсера в час, помноженная на количество часов, потраченных на разработку "неправильной" части спека (стоимость спека), плюс + стоимость программирования "неправильной" части спека плюс + стоимость тестирования "неправильной" части спека плюс + стоимость фиксирования бага и проблем, из него вытекающих. Как видно, слагаемые поддаются приблизительной оценке. Стоимость бага во втором случае: Если баг был допущен на уровне спека, но не придушен до релиза и найден пользователем, то к стоимости, вычисляемой по формуле предыдущего случая, могут прибавиться десятки других убытков (включая упущенную выгоду), например: • время службы поддержки; • компенсации пользователю потерянных денег; • иски против компании; • навсегда утраченная потенциальная оплата услуг компании ушед- шими пользователями и пользователями, которые по рекомендации ушедших никогда не заглянут на ваш веб-сайт, а также множество других плохих и неприятных вещей. Наиболее важное в концепции стоимости бага — это то, что чем раньше будет найден баг, тем он будет дешевле для компании. Таким образом, баг (а это, как мы знаем, может быть и отклонение от здравого смысла), найденный на уровне идеи, — это самый дешевый баг, соответственно баг, найденный после релиза, — это самый дорогой баг. Причем убытки от последнего, как правило, не поддаются объективной оценке. Как видим, QA и тестирование — это не только обеспечение счастья пользователей, но и путь САМОСОХРАНЕНИЯ любой интернет- компании. Вернемся к юнит-тестированию. Вот две рекомендации: 1. Юнит-тесты должны планироваться в письменной фор- ме ДО написания кода. Цикл разработки ПО 95 В таком случае программист после получения спека не бежит сломя голову писать код, а садится за документацию о дизайне кода с параллельным созданием юнит-тестов. Полезность такого подхода заключается в том, что, во-первых, программист абстрагируется от непосредственного кодирования и, видя "большую картину", может предугадать прин- ципиальные ошибки в алгоритмах и, во-вторых, он сможет заранее представить, КАК он будет тести- ровать код, это "КАК" занозой засядет у него в голове и при на- писании кода будет работать по принципу "предупрежден — зна- чит вооружен". 2. Требования к юнит-тестам должны быть формализованы в стандартах о юнит-тестировании. Например, каждая функция должна иметь по крайней мере один тест-кейс с одним конкретным вводом и одним конкретным вы- водом (ожидаемым результатом). Принципиально, думаю, понятно. А так как написание и испол- нение юнит-тестов — это дело программистов, то мы закончим рассуждения о нем и пойдем дальше, у нас, тестировщиков, своих дел по горло. 8. РЕАЛЬНЫЕ ФИНАНСОВЫЕ РЫЧАГИ СТИМУЛЯЦИИ НАПИСАНИЯ ЭФФЕКТИВНОГО И "ЧИСТОГО" КОДА Здесь все элементарно — менеджмент не должен жмотиться, если люди горбатятся на проект день и ночь, а в итоге не узнают своих подросших детей и называют своих жен Ленами (по имени колле- ги, сидящей за соседним компьютером и ставшей почти родной). • Хорошая заработная плата с возможностью увеличения; • билеты в "Ленком"; • премии за хорошую работу; • неограниченные чипсы и диет-кола; • оплата абонемента в бассейн и гимнастический зал; • месячные проездные; • выезды для игры в пейнтбол; • беспроцентный кредит на машину; • помощь при первоначальном взносе на квартиру — 96 Тестирование Дот Ком. Часть 1 чем больше заботы проявит компания о сотрудниках (и не только программистах), тем добросовестнее они будут работать, тем меньше будут получать втыков от жен — любительниц Louis Vuitton и тем больше будут радеть за свое место и качество кода, включая разработку дополнительных (от себя) юнит-тестов. В общем нужно сделать так, чтобы профессионал не думал о том, как свести концы с концами, а работал, зная, что его труд будет достойно оценен, и видел, что компания заботится о нем. 9. НАЛИЧИЕ ПОНЯТИЙ "КАЧЕСТВО" И "СЧАСТЬЕ ПОЛЬЗОВАТЕЛЯ" КАК ОСНОВНЫХ СОСТАВЛЯЮЩИХ КОРПОРАТИВНОЙ ФИЛОСОФИИ Менеджмент должен сделать так, чтобы персонал понимал, что "качество" и "счастье пользователя" — это не фикция, а путь к финансовому успеху компании и соответственно лучшей жизни каждого, кто работает над проектом. Если менеджеры по- смеиваются над мерами по улучшению качества и отпускают шутки о пользователях (даже в курилке!), то это тлетворно действует на всех сотрудников компании и в конечном счете негативно скажется на пользователях, а следовательно, по принципу бумеранга и на самой компании, включая "юмористов". Пользователи знают, уважают их или нет, уже после одного сообщения об ошибке, одного е-мейла от компании или од- ного звонка в службу поддержки, и если философия компа- нии — это "тупые юзеры", то, поверьте, она проявится, на радость конкурентам, во многих вещах. Теперь поговорим о трех основных занятиях программиста: 1. Написание кода для данного релиза происходит во время стадии "Кодирование". 2. Интеграция кода для данного релиза происходит по за- вершении стадии "Кодирование". 3. Ремонт багов для данного релиза происходит во время стадии "Кодирование" следующего витка цикла разработ- ки ПО (соответственно в пункте 1 программист ремонти- ровал баги для предыдущего релиза). Цикл разработки ПО 97 Техническая версия 1. НАПИСАНИЕ КОДА Один программист написал: parent_value = 1. Другой програм- мист написал: child_value = parent_valu + 3. 2. ИНТЕГРАЦИЯ КОДА а. Пытаемся два куска кода соединить в один: parent_value = 1, child_value = parent_valu + 3. б. Код не компилируется (компайлер выдает ошибку о неоп ределенной переменной), так как второй программист на писал parent valu вместо parent value. в. Код второго программиста фиксируется: child_value —parent_value + 3. г. Пытаемся два куска кода соединить в один: parent_value = 1, child_value = parent_value + 3. д. Код компилируется, но первый программист выполняет юнит-тест, по которому parent_yalue должно быть равно 7. е. Код первого программиста фиксируется: parent_value - 1. ж. Пытаемся два куска кода соединить в один: parent_value = 7, child_value = parent_value + 3. з. Вроде все в порядке, передаем тестировщикам — пусть они тра... маются. 3. РЕМОНТ БАГОВ Согласно спецификации должно быть: child_value - parent_yalue x 3. Тестировщик рапортует баг, и на основании этого бага програм- мист меняет код. 98 Тестирование Дот Ком. Часть 1 Лирическая версия 1. НАПИСАНИЕ КОДА О написании кода мы уже говорили. Один момент: Качество работы программиста не должно оцениваться по коли- честву багов, которые он взрастил, так как помимо таких субъек- тивных вещей, как профессионализм и добросовестность, на на- личие багов влияет множество других объективных факторов, о которых мы упоминали (нехватка времени, плохие спеки и т.д.). 2. ИНТЕГРАЦИЯ КОДА Вариант 1. Неблагодарный После того как код написан на игровой площадке каждого из программистов, происходит интеграция кода, когда тысячи строк кода разных авторов компилируются на одном компьютере, на- езжают друг на друга, спотыкаются, огрызаются и дарят релиз- инженерам, производящим интеграцию, сомнения в принципи- альном наличии вселенской гармонии. Пример Собрали четырех отличных художников, причем каждый должен выпол- нить заказ на куске прозрачной пленки 50x50 см: • задание первому: нарисовать удрученного, стоящего на коленях молодого человека; • задание второму: нарисовать милостиво склонившегося старика; • задание третьему: нарисовать фон, вызывающий сострадание; • задание четвертому: нарисовать группу печальных людей. "В общем, парни, генеральная идея... эта... типа как у этого... О! У Рем- браНа: возвращение загулявшего сына". Неудивительно, что мы прочувствуем всю боль релиз-инженеров, ко- гда соединим четыре рисунка вместе и увидим • удрученного великана, стоящего на коленях над • стариком, • гладящим промокшую болонку • в окружении заспанных курсантов-суворовцев. Остается только редактировать картинки каждого из художников и гру- стить, что их не совмещали по мере написания, используя... Вариант 2. Благодарный Чтобы избежать проблем, когда в один момент происходит мас- сированная интеграция кодов разных авторов, как в Варианте 1, программисты производят интеграцию постоянно по мере напи- Цикл разработки ПО 99 сания нового кода (т.е. стадия 1 и стадия 2 цикла разработки кода сливаются в одну стадию), что дает возможность выявить несты- ковки между кодами разных авторов на раннем этапе. 3. РЕМОНТ БАГОВ... происходит во время стадии "Тестирование и ремонт багов", по- сле того как код для данного релиза был заморожен и програм- мисты работают над кодом для нового релиза. Необходимость в замораживании кода вызвана тем, что продукт (в данном случае код) должен быть в каком-то устойчивом виде, чтобы его проверили. Пример Представьте следующую ситуацию: 1. Программист закончил работу над функциональностью А; 2. Тестировщик проверил, что функциональность А работает, и дал добро на релиз; 3. За час до релиза программист вносит маленькое изменение в код, которое в теории ничего не ломает... а на практике приводит к тому, что функциональность В, связанная с А, абсолютно перестает работать, т.е. получилось так, что тестировщик попросту потерял время (а значит, и деньги компании), тестируя не финальную версию продукта. Из сказанного вытекают две принципиально важные для тести- ровщика вещи. Перед началом тестирования нужно убедиться, что • код заморожен (обычно релиз-инженеры посылают соот- ветствующий е-мейл); • версия продукта на внутреннем сайте, на котором вы будете производить тестирование, является именно той версией, которую вам нужно протестировать. |