testirovanie_dot-com

В итогеполучается миллион(1000х 1000) ожидаемыхрезультатов.

Добавим масла в огонь: в большинстве случаев с реальным ПО мы интегрируем одни части кода с другими и в итоге получаем столько вариантов конкретных значений ожидаемых результатов, что на 100%-ю проверку не хватит и пяти жизней. Шести жизней хватить должно, но они будут самыми печальными из всех историй о бессмысленном существовании.

Постановкамозгов

В мире с ограниченными ресурсами (например, время на тестирова-

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

сочившиеся баги — это неизбежное зло, но свести его к минимуму — в наших руках.

ВТОРАЯ КОНЦЕПЦИЯ: критерий эффективности тестирования — это количество багов, найденных до релиза.

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

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

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

ном деле: пользователю все равно (и это правильно), сколько

вы не спали ночей, сколько вы нашли багов и скольких девушек оставили без романтического ужина. Пользователю нужно, чтобы наш онлайн-магазин работал качественно. Точка.

Идем дальше.

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

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

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

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

Кроме того, результаты тех же самых усилий, но приложен-

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

Кстати,

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

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

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

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

Итак,

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

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

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

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

Итак, после каждого релиза данные о багах, найденных после

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

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

Пример

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

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

•приоритет.

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

QA — это забота о качестве в виде превентирования появле-

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

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

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

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

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

Quality Assurance.

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

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

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

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

Пример с батькой и сынкой позволяет нам понять и ощутить со всей болью русской интеллигенции, что тестировщики имеют

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

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

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

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

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

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

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

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

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

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

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

Вопросы и задания для самопроверки

1.У вас есть 5 функциональностей, и отведенного времени не хватит, чтобы тщательно протестировать их все. На основании чего вы расставите приоритеты в тестировании? Подсказка: помните о счастье пользователя.

2.Петров нашел 50 багов до релиза, но пропустил 5 багов, которые были найдены пользователем. Сидоров нашел 12 багов до релиза, не пропустив ни одного. Кому дать премию?

3.Как должен поступить менеджер, чтобы решить вопрос с проблемой оплаты?

4.Придумайте аналогию, демонстрирующую разницу между ОА и тестированием.

4.Стакан граненый.

5.Бутылка "Абсолюта".

6.Огурец соленый.

Затем при деятельном участии жен, детей и котов мы наконец собрались в дорогу и перед выходом взяли список и проверили рюкзак на наличие каждого из 6 предметов.

Таквот.

Каждая из 6 строк списка — это и есть тест-кейс (test case).

Сам список является тест-комплектом (test suite).

Процесс придумывания и написания каждой строки списка называется созданием тест-кейса (test case generation).

Процесс проверки рюкзака на наличие определенного предмета — исполнением тест-кейса (test case execution).

Test case можно перевести как "тестируемая ситуация" и как "оболочка для теста", оба перевода легитимны и представляют собой идеальный союз для понимания места и значения тест-кей- сов в этом жестоком мире.

Главная и неотъемлемая часть тест-кейса — это ожидаемый результат, например "огурец соленый", т.е. тест-кейс может

полностью состоять только из ожидаемого результата.

Структуратест-кейса

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

Пример

Допустим, тестировщику А. Боброву, который только что начал работать в нашем стартапе www.testshop.rs, дали для исполнения следующий тест-кейс:

"Оплата может быть произведена картой VISA". Сразуже

возникает по крайней мере две проблемы:

•для исполнения тест-кейса нужна тестировочная карта VISA, которой у него нет;

•он не знает, как проверить, был ли действительно осуществлен платеж, даже если бы у него была карта.

Единственное, что более или менее понятно, — это процесс покупки в интернет-магазине (найти товар, добавить в корзину и т.д.), что в данной ситуации помогает немного. Естественно, что никакого тестирования не будет, так как пробиться к фактическому результату так же трудно, как доказать инспектору ГАИ, что брать взятки аморально.

Пример

Допустим, тестировщику А. Боброву, который только что начал работать в нашем стартапе www.testshop.rs, дали для исполнения следующий тест-кейс: Шаги:

1.Открой www.main.testshop.rs

2.Введи в поле "Имя пользователя": "testuser1"

3.Введи в поле "Пароль": "pa$$wOrd"

4.Нажми кнопку "Войти"

5.Введи в поле "Поиск": "book117"

6.Нажми кнопку "Найти"

7.Кликни линк "Добавить в корзину"

8.Кликни линк "Корзина"

9.Кликни линк "Оплатить"

10.Выбери из меню "Вид карты": "VISA"

11.Введи в поле "Номер карты": "9999-5148-2222-1277"

12.Введи в поле "Действительна до": "12/07"

13.Введи в поле "CW2": "778"

14.Нажми кнопку "Завершить заказ"

15.Запиши номер заказа __________

16.Запроси базу данных:

select result from cc_transaction where id = <номер заказа >;

Ожидаемый результат: "10"

Очевидно, что тест-кейс из последнего примера вполне может быть исполнен любым, кто знает, как напечатать "pa$$wOrd".

В последнем примере (который мы назовем тест-кейс с картой) к

ожидаемому результату (ОР) добавились шаги (steps), которые должны привести нас к фактическому результату (ФР), необ-

ходимому, чтобы узнать, есть баг или нет. Совокупность шагов называется процедурой (procedure).

Если провести аналогию, то

• шаги — это ступеньки лестницы;