Постановка мозгов Стоимость бага — это
• расходы компании, чтобы найти баг и исправить его до передачи кода пользователю. Расходы компании поддаются приблизительной оценке;
• убытки, которые несет компания, потому что баг не был найден до передачи кода пользователю. Объективная оценка убытков в большинстве случаев невозможна.
Подробности:
Стоимость бага в первом случае:
Если баг был допущен на уровне спека и найден во время тестирования кода, его стоимость вычисляется как
стоимость оплаты продюсера в час, помноженная на количество часов, потраченных на разработку "неправильной" части спека (стоимость спека), плюс + стоимость программирования "неправильной" части спека плюс + стоимость тестирования "неправильной" части спека плюс + стоимость фиксирования бага и проблем, из него вытекающих.
Как видно, слагаемые поддаются приблизительной оценке.
Стоимость бага во втором случае:
Если баг был допущен на уровне спека, но не придушен до релиза и найден пользователем, то к стоимости, вычисляемой по формуле предыдущего случая, могут прибавиться десятки других убытков (включая упущенную выгоду), например:
• время службы поддержки;
• компенсации пользователю потерянных денег;
• иски против компании;
• навсегда утраченная потенциальная оплата услуг компании ушедшими пользователями и пользователями, которые по рекомендации ушедших никогда не заглянут на ваш веб-сайт,
|
|
|
а также множество других плохих и неприятных вещей.
Наиболее важное в концепции стоимости бага — это то, что чем раньше будет найден баг, тем он будет дешевле для компании.
Таким образом, баг (а это, как мы знаем, может быть и отклонение от здравого смысла), найденный на уровне идеи, — это самый дешевый баг, соответственно баг, найденный после релиза, — это самый дорогой баг. Причем убытки от последнего, как правило, не поддаются объективной оценке.
Как видим, 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. За час до релиза программист вносит маленькое изменение в код, которое в теории ничего не ломает...
а на практике приводит к тому, что функциональность В, связанная с А, абсолютно перестает работать, т.е. получилось так, что тестировщик попросту потерял время (а значит, и деньги компании), тестируя не финальную версию продукта.
Из сказанного вытекают две принципиально важные для тести-ровщика вещи. Перед началом тестирования нужно убедиться, что
• код заморожен (обычно релиз-инженеры посылают соответствующий е-мейл);
• версия продукта на внутреннем сайте, на котором вы будете производить тестирование, является именно той версией, которую вам нужно протестировать.
Пример
Допустим, что на интранете у нас есть два внутренних тестировочных веб-сайта, недоступных для пользователей:
• www.everest.testshop.rs и
• www.elbrus.testshop.rs
Допустим также, что сайт
• www.everest.testshop.rs(по-простомуназываемый "Эверест") является версией 1.0 и содержит функциональность А версии 1.0, а
• www.elbrus.testshop.rs(по-простомуназываемый "Эльбрус") является версией 2.0 и содержит функциональность А версии 2.0.
100
Тестирование Дот Ком. Часть 1
Так вот в окне веб-браузера функциональность А может выглядеть абсолютно одинаково и на Эвересте, и на Эльбрусе, но ее бэк-энд будет существенно различаться на этих двух сайтах.
Допустим, тестировщик собирается проверить функциональность А версии 2.0, но ошибочно использует для тестирования Эверест (с версией 1.0), вследствие чего он не только впустую тратит время, но и рискует дать добро на релиз непротестированного кода функциональности А версии 2.0.
Подобные ошибки возникают, как правило, по небрежности или незнанию тестировщика и из-за "нелогичных" названий внутренних веб-сайтов.
Пути предотвращения ситуации, когда тестировщик тестирует не ту версию ПО:
1. Узнайте у релиз-инженера, как определить версию кода, и используйте сие знание перед началом исполнения тестирования;
2. Посоветуйте, чтобы внутренние веб-сайты имели логичные имена. Например, версия кода, переданного пользователю, всегда должна быть на внутреннем сайте по адресу www.old.testshop.rs, а версия для следующего релиза — на www.main.testshop.rs;
3. Попросите релиз-инженеров, чтобы те создали на интра-нете динамически обновляемую страничку с информацией о
• версии и
• подверсии, т.е. билде (об этом позже),
каждого внутреннего тестировочного веб-сайта.
В завершение кодирования поговорим еще о паре вещей.
Хотя и спеки, а иногда даже и сами идеи для спеков — ребятки не без греха, большинство багов зачинается именно при написании кода. При кодировании появляется присущий только этой стадии и одновременно самый простой в нахождении вид бага — синтаксический баг(syntax bug).
Прелесть синтаксических багов заключается в том, что они, являясь ошибками в языке программирования, находятся компай-лером (например, в случае с C++) автоматически. Последний выдает на экран сообщение об ошибке и принципиально не соз-
Цикл разработки ПО
101
дает исполняемый файл, пока проблема не будет зафиксирована (в скриптовых языках, таких, как Python, исполняемым файлом является сам файл с кодом и синтаксические баги находит интерпретатор языка).
Пример
Вот первая программка любого изучающего C++: 1. #include <iostream.h> 2.
3. voidmain()
4. {
5. cout<< "Hello, World!<< endl;
6. }
Текст этой программки находится в файле syntax_error.cpp. Попробуем ее скомпилировать:
~> C++ syntax error, cpp
Дата добавления: 2018-05-02; просмотров: 791; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!