2. Основные понятия
Уровни тестирования
Виды тестирования
Этапы тестирования
Документация
Техники, используемые в тестировании
Инструменты, помогающие в тестировании
Риски в тестировании
Автоматизация тестирования
3. Тестирование программного обеспечения С.Канер,
Дж. Фолк, Е.К.Нгуен
Искусство тестирования Г.Майерс, Т.Баджетт,
К.Сандлер
http://www.protesting.ru
http://www.software-testing.ru
http://qaforums.com
http://usqb.org.ua/index.php/ru/
http://www.istqb.org
Software Testing Foundation by A.Spillner, T.Linz,
H.Schaefer
Advanced Software Testing by Rex Black
4. 50е годы – тестирование зародилось как
процесс нахождения и устранения
дефектов (debugging)
70е годы – было предложено разграничить
процессы тестирования (testing) и отладки
(debugging)
В наши дни тестирование все больше
играет превентивную, а не реактивную роль
Дальнейшее развитие в наших руках
5. Тестирование находит
сбои в системе,
вызванные дефектом В процессе отладки
программист находит
причину дефекта, вносит
корректировки и
удостоверяется в их
Повторное тестирование правильности
подтверждает, что после
отладки система работает
без сбоев
Тестировщик Программист
6. Тестирование – это одна из техник контроля
качества, включающая в себя выполнение задач по
планированию работ, проектированию тестов,
выполнению тестирования и анализу полученных
результатов
Тестирование ПО – проверка соответствия между
реальным и ожидаемым поведением программы,
осуществляемая на конечном наборе тестов,
выбранном определенным образом.
7. Ошибка Ошибка (error)– некорректный результат,
который является результатом действий,
выполненных или не выполненных
человеком
Дефект (fault or bug) – изъян в отдельном
компоненте системы или в системе в
Дефект целом, из-за которого данный
компонент или система не могут
корректно выполнять свои функции.
Сбой (failure) – несоответствие работы
системы требованиям к ней.
Сбой Дефект не всегда приводит к сбоям в
системе!
8. Программное
обеспечение – все
увеличивающася
часть нашей с вами
жизни
Ошибки в ПО могут
иметь
серьезные
последствия!
9. Человеческий фактор
Требования к функционалу
Ограниченное время на разработку
Сложность кода
Комплексные системы
11. Качество ПО – степень соответствия
характеристик, присущих программному
обеспечению, указанным требованиям к нему
и/или потребностям и ожиданиям
пользователя (клиента)
12. Тестирование – это не только выполнение
тестов
Задачи тестировщика до выполнения тестов:
◦ Планирование
◦ Проверка документации, кода
◦ Определение условий тестирования
◦ Создание тестовых сценариев
Задачи тестировщика после выполения тестов:
◦ Проверка результатов
◦ Оценка критериев завершения тестирования
◦ Последующий контроль
◦ Документирование тестирования и отчетность
13. Определение соответствия поставляемого
ПО условиям контракта, юридическим
нормам
Предоставление информации о качестве ПО
Предоставление информации о
функциональных и нефункциональных
характеристиках ПО
Оценка соответствия стандартам
(сертификация)
Не забываем учиться на ошибках!
14. Объем тестирования зависит от:
◦ Уровня ожидаемого риска (технического,
проектного, для бизнеса в целом)
◦ Время и бюджета проекта
◦ Наличия и квалификации ресурсов
◦ ...
Тестирование должно предоставить
информацию в объеме достаточном для
принятия взвешенного решения о
завершении этапа в разработке ПО и/или
выпуске новой версии
15. Тестирование демонстрирует наличие
дефектов
Исчерпывающее тестирования невозможно
Раннее тестирование
Дефекты имеют тенденцию скапливаться
группами
«Пестицидный» парадокс
Тест ситуационно зависим
Заблуждение об отсутствии ошибок
16. Тестирование демонстрирует наличие
дефектов
◦ Тестирование обнаруживает дефекты
◦ Тестирование не может гарантировать
отсутствия дефектов
◦ Должное тестирование уменьшает вероятность
наличия дефектов
17. Исчерпывающее тестирование
невозможно
◦ ПО – очень сложный продукт
◦ Слишком много возможных комбинаций
◦ Временные и бюджетные ограничения
◦ Важно правильно сфокусировать усилия
18. Раннее тестирование
◦ Работы, связанные с тестированием, должны
начинаться как можно раньше
◦ Чем раньше обнаружен дефект, тем дешевле
стоит его исправить
19. Дефекты имеют тенденцию скапливаться
группами
◦ Небольшое количество модулей содержит
основную массу дефектов
◦ Основные усилия по тестированию должны
быть нацелены в первую очередь на такие
«проблемные» части ПО
20. Пестицидный парадокс
◦ Тесты «изнашиваются» и становятся
неэффективными («старые» дефекты
устранены)
◦ Необходимо обновлять старые тест-кейсы и
создавать новые, чтобы найти «новые» дефекты
◦ Имеющиеся тесты нуждаются в постоянном
совершенствовании
21. Тест ситуационно зависим
◦ Системы, критичные в вопросах безопасности,
тестируются не так, как обычные бизнес-
системы
◦ В разных ситуациях (сферах) используются
разные подходы, уровни формализации
процесса, строгость в оценке критериев
завершения тестирования
22. Заблуждение об отсутствии ошибок
◦ Обнаружение и исправление дефектов – это
только часть процесса тестирования
◦ Необходимо убедиться, что система отвечает
требованиям и ожиданиям
◦ Отсутствие неисправленных дефектов не
гарантирует их отсутствие в принципе
Editor's Notes
The separation of debugging from testing was initially introduced by Glenford J. Myers in 1979.[13] Although his attention was on breakage testing ("a successful test is one that finds a bug"[13][14]) it illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification. Dave Gelperin and William C. Hetzel classified in 1988 the phases and goals in software testing in the following stagesThe separation of debugging from testing was initially introduced by Glenford J. Myers in 1979.[13] Although his attention was on breakage testing ("a successful test is one that finds a bug"[13][14]) it illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification. Dave Gelperin and William C. Hetzel classified in 1988 the phases and goals in software testing in the following stagesThe origins of software testing can actually be traced back to the fifties, when the primary method of testing anything was debuggingIn the late seventies the approach evolved to one of destruction; basically, the testers woul break down the code to find holes or gaps in itThis method was effective but it was not until the advent of prevention oriented methodologies that we began to enjoy the benefits of more robust software applications
Приходит к вам заказчик и говорит: "Хочу большую красную кнопку, которая будет делать мне хорошо"Аналитики написали требования к кнопке, дизайнеры нарисовали интерфейс, разработчики написали код, вы протестировали, нашли 42 дефекта, их исправили. Подходит РМ и спрашивает: "продукт готов?", а вы отвечаете: "ну, я 42 бага нашёл, других не вижу, но обещать естественно не могу".Продукт выпустили.Развитие событий, вариант №1:У пользователя не работает, оказывается вы многое в тестировании не учли и пропустили критичные баги. Вот он, принцип №1 в действии - то, что вы нашли 42 бага, ещё не значит, что в продукте не спрятались ещё 146.Развитие событий, вариант №2:Софт работает как часы (случилось чудо и вы НЕ пропустили ни одной ошибки), но пользователя красная кнопка счастливым не делает. Чтобы сделать ему хорошо, эта красная кнопка должна быть на самом деле зелёным текстовым полем, он просто неправильно выразился. Вот он, принцип №7 в действии - проверка продукта на соответствие требованием не гарантирует, что пользователь останется доволен
Тестирование демонстрирует присутствие дефектов, а не их отсутствие : Тестирование демонстрирует, что у продукта есть недостатки, т.е. в продукте есть дефекты. Тестирование не может доказать, что программа не содержит дефектов. Должное тестирование сокращает вероятность присутствия скрытых дефектов в тестируемом объекте. Даже если проблемы найдены в процессе тестирование, это не доказывает, что дефектов в продукте нет.
Исчерпывающее тестирование невозможно: Исчерпывающий тест, в котором все возможные входные данные и их комбинации предусмотрены, включая различные предусловия, невозможен. Программное обеспечение, разрабатываемое на практике, требовало бы астрономического числа тест кейсов. Поэтому каждый тест кейс – это всегда лишь образец. Вследствие этого, выполнение тестов должно быть контролируемо с учетом рисков и приоритетов.
Работы, связанные с тестированием, должны начинаться как можно раньше: Тестирование должно начинаться на ранних стадиях жизненном цикла программного обеспечения и должно фокусироваться на заданных целях. Это поспособствует более раннему нахождению дефектов.
Дефекты имеют тенденцию скапливаться группами: Дефекты не распределены равномерно, они имеют свойство «собираться группами». Поэтому, если много дефектов было найдено в одном месте, обычно еще больше дефектов могут быть обнаружены неподалеку. Не нужно критично относиться к данному правилу
“Пестицидный парадокс” (парадокс Бориса Бейзера): Если те же самые тесты выполняются снова и снова, они теряют свою эффективность. Новые, неизвестные до сих пор дефекты не будут найдены. Поэтому, чтобы сохранить эффективность тестов и победить «пестицидный парадокс», должны быть созданы новые тест кейсы, а старые изменены.
Тест ситуационно зависим: Две различные системы не должны быть протестированы одинаковым способом. Для каждой системы критерии завершения тестирования и т.д. должны быть выбраны индивидуально.
Ошибочность предположения, что отсутствие сбоев означает пригодность системы: Поиск сбоев и корректировка дефектов не гарантирует, что система в целом соответствует ожиданиям и потребностям пользователя. Вовлечение пользователей в процесс разработки на ранних стадиях и использование прототипов поспособствует избежанию проблем.
