Главная страница

фабпждфуквп. Савин Тестирование dot-com. Пособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин


Скачать 5.26 Mb.
НазваниеПособие по жестокому обращениюсбагам и в интернетстартапах com роман Савин
Анкорфабпждфуквп
Дата06.05.2022
Размер5.26 Mb.
Формат файлаpdf
Имя файлаСавин Тестирование dot-com.pdf
ТипПособие
#515165
страница8 из 24
1   ...   4   5   6   7   8   9   10   11   ...   24
б. Технический аспект
Каждый из участников цикла разработки ПО должен быть досту- пен для контакта: желательно, чтобы все они работали в одном здании; в локальной сети должны быть доступны служебные, мо- бильные и домашние телефоны; необходимо согласовать часы
(хотя бы 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. За час до релиза программист вносит маленькое изменение в код,
которое в теории ничего не ломает...
а на практике приводит к тому, что функциональность В, связанная с А,
абсолютно перестает работать, т.е. получилось так, что тестировщик
попросту потерял время (а значит, и деньги компании), тестируя не
финальную версию продукта.
Из сказанного вытекают две принципиально важные для тести- ровщика вещи. Перед началом тестирования нужно убедиться, что
• код заморожен (обычно релиз-инженеры посылают соот- ветствующий е-мейл);
• версия продукта на внутреннем сайте, на котором вы будете производить тестирование, является именно той версией, которую вам нужно протестировать.
1   ...   4   5   6   7   8   9   10   11   ...   24


написать администратору сайта