Разоблачение второй концепции

Допустим, открывается новый обувной магазин на Кузнецком, чтобы все развитые личности ходили в лаковых ботинках.

Скажите, имеет ли значение для развитой личности, сколько де­нег и сил было потрачено на покупку и ремонт помещения? От­вет отрицательный: единственное, что ее интересует, — это сходная цена и качество обуви. Так и в нашем интернет-магазин­ном деле: пользователю все равно (и это правильно), сколько вы не спали ночей, сколько вы нашли багов и скольких деву­шек оставили без романтического ужина. Пользователю нуж­но, чтобы наш онлайн-магазин работал качественно. Точка.

Идем дальше.

Идея о статистике для пострелизных багов

Итогом разработки ПО является передача этого ПО пользовате­лю, называемая "релиз" (release).

Допустим, что перед первым релизом нашли 50 багов, а перед вторым — 200. Казалось бы, во втором случае тестирование про­шло более успешно. Но в реальности вполне может быть, что по­сле первого релиза пользователи найдут 2 бага, а после второго —

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

22 бага. Тестирование какого релиза было более эффективным? Очевидно, что первого, так как первый релиз дал возможность пользователям познакомиться только с двумя багами в отличие от второго релиза — с 22 багами.

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

Кстати,

один из критериев качества кода — это количество багов на 1000 строк кода.

Почему же так популярно представление количества багов ДО релиза в качестве цели и критерия эффективности тестирования?

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

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

Итак,

Количество багов, найденных до релиза, ничего не говорит об эффективности тестирования.

Баги, найденные после релиза, — вот что нас угнетает и преследует в бессонные лунные ночи.

Кстати, если уж мы заговорили о статистике и цифрах, давайте скажем пару слов о том, как мы используем данные о таких вот пострелизных багах.

Сначала определимся с тем, что баги бывают разных приори­тетов, которые отражают важность бага. Скажем, если у машины на дороге отваливается колесо, это П1Ш (баг высшего приоритета). Таких приоритетов обычно 4. Соответственно к П4 относятся самые незначительные баги (как небольшая цара­пина на боку автомобиля).

Цель тестирования Decoded

Итак, после каждого релиза данные о багах, найденных после релиза, классифицируются по заданным критериям и анали­зируются на предмет нахождения слабого звена в процессе разработки ПО.

Критериями могут быть приоритет, функциональность, имя тес-ти_тИровщика и др.

Пример

После очередного релиза мы совместили статистику по критериям

• функциональность и

• приоритет.

Функциональность Приоритет   Приоритет	Регистрация	Поиск	Корзина	Оплата
П1
П2
ПЗ
П4

При попытке найти "рекордсменов" можно увидеть, что совсем груст­ная картина сложилась с оплатой (7 П1).

Еще один пример, чтобы показать, какова польза от сопоставле­ния статистики от релиза к релизу и что нужно делать с теми, кто эту статистику портит.

Пример

Допустим, что у нас постоянно возникают проблемы с "Оплатой". После каждого из релизов в ней находят по несколько П1 и П2, т.е. появился устойчивый паттерн (pattern — шаблон, тенденция) проблемы. Все спе­ки по оплате составлены продюсером, весь проблемный код написан программистом и проверен тестировщиком. Первое, что приходит в голову, — во всем виноват тестировщик. Но если проявить человеко­любие и талант руководителя, то может всплыть:

• продюсер пишет совершенно мерзопакостные спеки;

• тестировщик в свое время женился на невесте программиста, всячески избегает его;

• оба они ненавидят продюсера, так как тот является зятем прези­дента компании.

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

Дальнейшее расследование показывает, что

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

• программист и тестировщик зарекомендовали себя как блестя­щие профессионалы на всех проектах, когда их пути не пересе­кались.

А вы говорите "Элементарно, Ватсон"! Вот оно, истинное рас­следование! А то обидели бы бедного тестировщика, а в следую­щий раз все повторилось бы.

Заметьте, что ко всему этому мы пришли, начав с анализа стати­стики, а это уже не тестирование, a QA (Quality Assurance — бук­вально "обеспечение качества", произносится "кью-эй").

Тестирование и QA (Quality Assurance)

Рассмотрим базовую концепцию QA и то, как оно соотносится с тестированием.

Пример

Лежит дома на диване некий член правления некого крупного банка. Весь такой благообразный, вальяжный и циничный, как будто он всегда был и будет членом правления. Тишину разрывает звонок телефона, холеные пальцы снимают трубку, и в сознание проникает голос быв­шей жены, которую он бросил 11 лет назад, сразу после своей первой сделки с продажей вагона ворованных противогазов. Бывшая жена го­ворит, мол, твой сын прогуливает уроки математики и рисования, це­луется в подъезде с соседской Дашкой, которая на два года старше него, перестал гулять с собакой и начал курить. В общем, дела плохие. Так вот,

QА-подход — это изначально остаться с женой и воспитывать сына.

Тестирование — это когда после звонка оставленной жены экс-хузбенд запирает сынишку в своей загородной резиденции, ограничи­вает его духовную и половую жизнь полным собранием произведений Ги Де Мопассана, выписывает из Англии учителей, устраивает педсо­вет и говорит, что у них есть 3 года, чтобы неуч, тунеядец, курильщик и сексоман стал образованным, трудолюбивым и здоровым членом ци­вилизованного общества.

Таким образом,

QA — это забота о качестве в виде превентирования появле­ния багов, тестирование — это забота о качестве в виде обна­ружения багов до того, как их найдут пользователи.

Цель тестирования Decoded 33

Общее в QA и тестировании заключается в том, что они призваны улучшить ПО, различие между ними — в том, что

• QA призвано улучшить ПО через улучшение процесса разработки ПО;

• тестирование — через обнаружение багов.

Несмотря на то что большая часть книги посвящена тестирова­нию, многие вещи будут рассмотрены именно с точки зрения Quality Assurance.

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

Кстати, западные компании часто нанимают аудиторов для проверки внутренних процессов. Если ваша компания решит нанять аудитора, который стоит больших денег, то постарайтесь не заключать договор с крупной аудиторской компанией, которая элементарно может вам подсунуть ничего не понимающего в деле товарища с кожаным порт­фелем, а лучше заключите контракт с конкретным специалистом по ка­честву, проведя ряд интервью и найдя того, кто действительно разби­рается в своем деле. Запомните, что аудитом кормятся много парази­тов, которые напишут вам бессмысленные, но солидно презентован­ные заключения и рекомендации,, которые вам никогда не пригодятся, и впоследствии вы будете долго ломать голову, пытаясь понять, ЗА ЧТО же вы все-таки заплатили.

Кстати, хотя инженер по качеству (QA Engineer) и тестировщик (Test Engineer) — это разные профессии, тестировщиков часто называют инженерами по качеству.

Пара мыслей вдогонку к сказанному.

Пример с батькой и сынкой позволяет нам понять и ощутить со всей болью русской интеллигенции, что тестировщики имеют Дело с ПО, переданным им программистами уже в кривом и порочном состоянии. С этим соприкасается правильная, сладкая и полезная идея, что за качество не могут быть ответственны только тестировщики.

Качество (как и его отсутствие) — это результат

• деяний всех участников процесса разработки ПО, а также

• отлаженности и настроек самого процесса.

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

Дата добавления: 2015-12-07