РАЗОБЛАЧЕНИЕ ВТОРОЙ КОНЦЕПЦИИ

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

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

Идем дальше.

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

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

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

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

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

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

Кстати,

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

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

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

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

Итак,

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

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

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

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

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

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

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

Пример

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

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

• приоритет.

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

При попытке найти "рекордсменов" можно увидеть, что совсем грустная картина сложилась с оплатой (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

Краткое подведение итогов

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

2. Нехватка ресурсов не позволит стопроцентно протестировать сколько-нибудь сложное ПО.

3. Не имеет никакого значения, сколько багов было найдено до релиза.

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

5. QA направлено на превентирование багов, тестирование — на поиск багов.

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

Дата добавления: 2018-05-02; просмотров: 1029; Мы поможем в написании вашей работы!

Поделиться с друзьями:

⇐ Предыдущая 1 2 345 6 7 8 9 10 Следующая ⇒

Мы поможем в написании ваших работ!