tестирование dot com
Шрифт:
33
Общее в QA и тестировании заключается в том, что они призваны
улучшить ПО, различие между ними — в том, что
• QA призвано улучшить ПО через улучшение процесса
разработки ПО;
• тестирование — через обнаружение
Несмотря на то что большая часть книги посвящена тестирова-
нию, многие вещи будут рассмотрены именно с точки зрения
Quality Assurance.
В реальных компаниях инженер, который занимается улучшени-
ем процесса разработки ПО, должен иметь очень серьезную под-
держку в менеджменте компании, чтобы быть в состоянии про-
вести свои идеи качества в жизнь. Без такой поддержки никакого
прока от инженера по качеству не будет, каким бы гениальным
специалистом он ни был.
Кстати, западные компании часто нанимают аудиторов для проверки
внутренних процессов. Если ваша компания решит нанять аудитора,
который стоит больших денег, то постарайтесь не заключать договор с
крупной аудиторской компанией, которая элементарно может вам
подсунуть ничего не понимающего в деле товарища с кожаным порт-
фелем, а лучше заключите контракт с конкретным специалистом по ка-
честву, проведя ряд интервью и найдя того, кто действительно разби-
рается в своем деле. Запомните, что аудитом кормятся много парази-
тов, которые напишут вам бессмысленные, но солидно презентован-
ные заключения и рекомендации,, которые вам никогда не пригодятся,
и впоследствии вы будете долго ломать голову, пытаясь понять, ЗА ЧТО
же вы все-таки заплатили.
Кстати, хотя инженер по качеству (QA Engineer) и тестировщик (Test
Engineer) — это разные профессии, тестировщиков часто называют
инженерами по качеству.
Пара мыслей вдогонку к сказанному.
Пример с батькой и сынкой позволяет нам понять и ощутить со
всей болью русской интеллигенции, что тестировщики имеют
Дело с ПО, переданным им программистами уже в кривом и
порочном состоянии. С
и полезная идея, что за качество не могут быть ответственны
только тестировщики.
Качество (как и его отсутствие) — это результат
• деяний всех участников процесса разработки ПО, а также
• отлаженности и настроек самого процесса.
34
Тестирование Дот Ком.Часть 1
Краткое подведение итогов
1. Цель тестирования — это нахождение багов до того, как их най
дут пользователи.
2. Нехватка ресурсов не позволит стопроцентно протестировать
сколько-нибудь сложное ПО.
3. Не имеет никакого значения, сколько багов было найдено до
релиза.
4. Статистика багов, найденных после релиза, и ее последующий
анализ могут помочь идентифицировать проблемные участки
процесса разработки ПО. Сопоставление статистики от релиза к
релизу дает, как правило, устойчивый паттерн проблемы, если
таковая существует.
5. QA направлено на превентирование багов, тестирование — на
поиск багов.
6. Тестировщики одни не могут обеспечить качество ПО. Обеспе-
чение качества — это задача всех участников процесса раз-
работки ПО. Важными факторами, влияющими на качество,
являются отлаженность и настройки самого процесса разработки
ПО.
Вопросы и задания для самопроверки
1. У вас есть 5 функциональностей, и отведенного времени не хва-
тит, чтобы тщательно протестировать их все. На основании чего
вы расставите приоритеты в тестировании? Подсказка: помните
о счастье пользователя.
2. Петров нашел 50 багов до релиза, но пропустил 5 багов, которые
были найдены пользователем. Сидоров нашел 12 багов до
релиза, не пропустив ни одного. Кому дать премию?
3. Как должен поступить менеджер, чтобы решить вопрос с про-
блемой оплаты?
4. Придумайте аналогию, демонстрирующую разницу между ОА и
тестированием.
ИСКУССТВО СОЗДАНИЯ
ТЕСТ-КЕЙСОВ
• ЧТО ТАКОЕ ТЕСТ-КЕЙС
• СТРУКТУРА ТЕСТ- КЕЙСА
• ИСХОД ИСПОЛНЕНИЯ ТЕСТ-КЕЙСА •
ПОЛЕЗНЫЕ АТРИБУТЫ ТЕСТ-КЕЙСА
• ТЕСТ-КЕЙСЫ, УПРАВЛЯЕМЫЕ ДАННЫМИ •
ПОДДЕРЖИВАЕМОСТЬ ТЕСТ-КЕЙСА
• СКОЛЬКО ОЖИДАЕМЫХ РЕЗУЛЬТАТОВ МОЖЕТ БЫТЬ
В ОДНОМ ТЕСТ-КЕЙСЕ?
• ПРОБЛЕМНЫЕ ТЕСТ-КЕЙСЫ
• ТЕСТ-КОМПЛЕКТЫ
• СОСТОЯНИЯ ТЕСТ-КЕЙСА
• А НАПОСЛЕДОК Я СКАЖУ