Принципы тестирования, Agile принципы тестирования
Принципы тестирования, Agile принципы тестирования
Принципы тестирования
1. Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
Тестирование может показать, что дефекты присутствуют, но не может доказать, что дефектов больше нет. Сколько бы успешных тестов вы не провели, вы не можете утверждать, что нет таких тестов, которые не нашли бы ошибку.
2. Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
Для проведения исчерпывающего тестирования придется протестировать все возможные входные значения и все пути выполнения программы, в большинстве случаев число таких вариаций стремится к бесконечности или просто на порядки превосходит отведенное время и бюджет.
Вместо попыток «протестировать все» нам нужен некий подход к тестированию (стратегия), который обеспечит правильный объем тестирования для данного проекта, данных заказчиков (и других заинтересованных лиц) и данного продукта.
При определении, какой объем тестирования достаточен, необходимо учитывать уровень риска, включая технические риски и риски, связанные с бизнесом, и такие ограничения проекта как время и бюджет. Оценка и управление рисками - одна из наиболее важных активностей в любом проекте.
3. Раннее тестирование (Early testing).
Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
Тестовые активности должны начинаться как можно раньше в SDLC, а именно когда сформированы требования.
Этот принцип связан с понятием «цена дефекта» (cost of defect). Цена дефекта существенно растет на протяжении жизненного цикла разработки ПО. Чем раньше обнаружен дефект, тем быстрее, проще и дешевле его исправить. Дефект, найденный в требованиях, обходится дешевле всего.
Еще одно важное преимущество раннего тестирования - экономия времени. Тестовые активности могут начинаться еще до того, как написана первая строчка кода. По мере того, как готовятся требования и спецификации, тестировщики могут приступать к разработке и ревью тест-кейсов. И когда появится первая тестовая версия, можно будет сразу приступать к выполнению тестов.
4. Скопление дефектов (Defects clustering).
Большая часть дефектов находится в ограниченном количестве модулей.
Небольшое количество модулей содержит большинство дефектов, обнаруженных на этапе предрелизного тестирования, или же демонстрируют наибольшее количество отказов на этапе эксплуатации.
Многие тестировщики наблюдали такой эффект - дефекты «кучкуются». Это может происходить потому, что определенная область кода особенно сложна и запутана, или потому, что внесение изменений производит «эффект домино». Это знание часто используется для оценки рисков при планировании тестов - тестировщики фокусируются на известных «проблемных зонах». Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.
5. Парадокс пестицида (Pesticide paradox).
Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
Boris Beizer в своей книге Software Testing Techniques объяснил парадокс пестицида как феномен, согласно которому чем больше вы тестируете ПО, тем более невосприимчивым оно становится к имеющимся тестам, т.е.
- каждый метод и набор тестов, который используется для предотвращения или поиска ошибок, может оставлять часть не найденных ошибок, против которых эти методы и тесты неэффективны;
- имеющиеся тесты устаревают после исправления дефекта и не могут обнаружить новые;
Из чего следует, что набор тестов, тестовых данных и подходов нужно постоянно пересматривать и улучшать для выявления не найденных ошибок, а также необходимо обновлять тесты и тестовые данные после исправления уже найденных дефектов.
6. Тестирование зависит от контекста (Testing is context depending).
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск - это потенциальная проблема. У риска есть вероятность (likelihood) - она всегда выше 0 и ниже 100% - и есть влияние (impact) - те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние.
То же можно сказать и о мире ПО: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьируется. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
7. Заблуждение об отсутствии ошибок (Absence-of-errors fallacy).
Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО - люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи - на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают. Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей. Иначе говоря, верификация не равна валидации.
Гибкое тестирование
Гибкое тестирование (agile testing): Способ тестирования для проектов, использующих гибкие методологии разработки программного обеспечения, включающий такие техники и методы, как экстремальное программирование, и рассматривающий процесс разработки как потребителя процесса тестирования и делающий упор на парадигму раннего тестирования.
Принципы Agile тестирования
по книге E. Hendrickson - Agile Testing Nine Principles and Six Concrete Practies for Testing on Agile Teams
1. Тестирование продвигает проект вперед
В традиционных проектах тестирование обычно рассматривается как контроль качества, а QA/Test группа часто служит привратником качества. Предотвращение выход плохого программного обеспечения в поле, считается обязанностью тестирования. Результат этого подхода долгие, затяжные встречи по поиску ошибок, на которых мы спорим о приоритете ошибок, обнаруженных в ходе тестирования, и достаточно ли они важны и/или серьезные, чтобы задержать релиз.
В Agile-командах мы с самого начала хорошо создаем продукт, используя тестирование для предоставления обратной связи на постоянной основе о том, насколько хорошо новый продукт удовлетворяет потребности бизнеса. Это выглядит как небольшое изменение, но оно имеет глубокие последствия.
Враждебные отношения, которые некоторые организации поддерживают между тестировщиками и разработчиками, должны быть заменен духом сотрудничества. Это совершенно другое мышление.
2. Тестирование — это НЕ один из этапов…
…в Agile-командах тестирование — это образ жизни.
Agile-команды постоянно тестируют. Это единственный способ убедиться, что функции реализованные во время данной итерации или спринта, фактически выполняются. Непрерывное тестирование — единственный способ обеспечить непрерывный прогресс.
3. Все тестируют
В традиционных проектах независимые тестировщики несут ответственность за все действия по тестированию.
В Agile за проведение тестирования отвечает вся команда. Да, тестеры выполняют тесты. Разработчики тоже.
Необходимость провести все тесты за одну итерацию может означать, что команда просто не сможет сделать в каждом спринте столько, сколько они изначально думали. Если это так, то Agile сделал видимым несоответствие импеданса между тестом и разработчиком, которое уже существовал. А это значит, что команда двигалась не так быстро, как они думали.
Им казалось, все идет быстро, потому что разработчики шли быстро. Но если тестирование не сделано, фичи не сделаны, и у команды просто нет той скорости о которой они думают.
Другая точка зрения на эту идею состоит в том, что тестирование — это «травка» в команде. Теория ограничений гласит, что вся команда может только идти так быстро, как идет самая медленная часть. Чтобы работать быстрее, команда должна увеличить пропускную способность самой медленной часть процесса. Устранить узкое место; все тестируют.
4. Сокращение оборотов обратной связи
Как долго команда должна ждать информацию о том, как ведет себя программное обеспечение? Измерьте время между написанием программистом строки кода, и тем, когда кто-то или что-то выполняет этот код и предоставляет информацию о том, как он себя ведет. Это обратная связь.
Если программное обеспечение не протестировано до самого конца длинного релиза, циклы обратной связи будут увеличены и могут измеряться месяцами. Это слишком долго.
Более короткие петли обратной связи повышают гибкость. К счастью, на Agile-проектах программное обеспечение готово к тестированию практически с самого начала. А Agile-команды обычно используют несколько уровней тестирования для выявления разных типов информации.
Автоматизированные модульные тесты проверяют поведение отдельных функций/методов и взаимодействие объектов. Они запускаются часто и предоставляют обратную связь в считанные минуты. Автоматизированные приемочные тесты обычно проверяют поведение системы от начала до конца. (Хотя иногда они обходят графический интерфейс, проверяя лежащую в основе бизнес-логику.) Как правило, они запускаются на зарегистрированном коде на постоянной основе, предоставляя обратную связь примерно через час. Гибкие проекты предпочитают автоматизированные тесты из-за быстрой обратной связи, которую они обеспечивают.
Ручные регрессионные тесты занимают больше времени и, поскольку человек должен быть доступен, могут начаться не сразу. Время обратной связи увеличивается до дней или недель.
Ручное тестирование, особенно ручное исследовательское тестирование, по-прежнему важно. Однако Agile-команды обычно обнаруживают, что быстрая обратная связь, обеспечиваемая автоматической регрессией, является ключом к быстрому обнаружению проблем, что снижает риск и количество доработок.
5. Держите код в чистоте
Этот принцип является примером дисциплины Agile-команд. Требуется огромная внутренняя дисциплина, чтобы исправлять ошибки по мере их обнаружения.
Если это настоящая ошибка, а не новая фича, она исправляется в ходе итерации.
В противном случае это все равно, что готовить на грязной кухне: для приготовления пищи требуется больше времени, чтобы пробраться через беспорядок, и полученная еда может быть съедобной, а может и не быть.
6. Легкая документация
Вместо того, чтобы писать многословную исчерпывающую тестовую документацию, Agile-тестировщики:
- Используют многоразовые чек листы, чтобы предлагать тесты
- Сосредоточиваются на сути теста, а не на второстепенных деталях
- Используют упрощенные стили/инструменты для документации.
- Фиксируют идеи тестирования в чартерах для исследовательского тестирования
- Используют документы для различных целей
7. Использование одного тестового артефакта для ручных и автоматических тестов
Вместо того, чтобы вкладывать средства в обширные, тяжеловесные пошаговые сценарии ручного тестирования в Word или инструмент управления тестированием, мы фиксируем ожидания в формате, поддерживаемом системы автоматизированного тестирования, такие как FIT/Fitnesse.
Тест может быть выполнен вручную, но что более важно, тот же тестовый артефакт становится автоматическим тестом, когда программисты пишут приспособление для подключения теста к тестируемому программному обеспечению.
8. «Сделано Сделано», а не просто Сделано
В традиционных средах со строгим разделением между разработкой и тестированием разработчики обычно говорят, что они «закончили» работу с функцией после ее реализации, но до ее тестирования.
Конечно, функция не «готова», пока она не будет протестирована и не будут исправлены все ошибки. Вот почему в отрасли существует давняя шутка о том, что данный выпуск программного обеспечения обычно «готов на 90%» для 90% проекта. (Или, другими словами, последние 10 % усилий занимают 90 % времени.)
Agile-команды не считают что-то «сделанным» и готовым к принятию владельцем продукта или заказчиком до тех пор, пока оно не будет реализовано и протестировано.
9. Test-Last v. Test-Driven
В традиционных средах тесты создаются на основе артефактов проекта, таких как документы с требованиями.
Требования и дизайн на первом месте, а затем тесты. И выполнение этих тестов происходит в конце проекта. Это подход «testlast».
Тем не менее, тесты предоставляют конкретные примеры того, что означает для нового программного обеспечения соответствие требованиям.
Формирование тестов вместе с требованиями, а не после, и использование этих тестов для управления усилиями по разработке дает нам гораздо более четкие критерии выполнения и общее внимание к цели.
Этот подход, основанный на тестировании, можно увидеть в практиках TDD и ATDD.
Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects) Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.
Принцип 2 — Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible) Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
Принцип 3 — Раннее тестирование (Early testing) Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.
Принцип 4 — Скопление дефектов (Defects clustering) Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.
Принцип 5 — Парадокс пестицида (Pesticide paradox) Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот «парадокс пестицида», тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
Принцип 6 — Тестирование зависит от контекста (Testing is concept depending) Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции. Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy) Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.