Теория тестирования ПО просто и понятно
Основные термины
Тестирование программного обеспечения — проверка соответствия между реальным и ожидаемым поведением программы, проводится на наборе тестов, который выбирается некоторым образом.
Это одна из техник QC, включающая в себя:
планирование работ (Test Management)
выполнение тестирования (Test Execution)
анализ результатов (Test Analysis)
Основной целью тестирования является предоставление актуальной информации о состоянии продукта на данный момент.
Этапы тестирования:
Разработка стратегии тестирования и планирование QC
Создание тестовой документации
Качество программного обеспечения (Software Quality) — совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности.
Верификация (verification) — процесс оценки системы (её компонентов) с целью понимания, удовлетворяет ли ее работоспособность условиям, сформированным в тест-плане/спецификации. Т.е. выполняются ли цели, сроки, заданные в этих документах.
Валидация (validation) — это оценка соответствия ПО потребностям пользователя.
Верификация (verification)
Валидация (validation)
Соответствие продукта требованиям (спецификации)
Соответствие продукта потребностям пользователей
Требования — это спецификация (описание) того, что должно быть реализовано. Требования описывают то, что необходимо реализовать, без детализации технической стороны решения. Что, а не как.
Требования к требованиям:
Полнота набора требований
Непротиворечивость набора требований
Дефект (баг) — это несоответствие фактического результата выполнения программы ожидаемому результату.
Следует уметь различать, что:
Error — это ошибка пользователя, то есть он пытается использовать программу иным способом (например, вводит буквы в поля, где требуется вводить цифры). В качественной программе предусмотрены такие ситуации и выдаются сообщение об ошибке (error message).
Bug (defect) — это ошибка программиста (или дизайнера или ещё кого, кто принимает участие в разработке), то есть когда в программе, что-то идёт не так, как планировалось. Например, внутри программа построена так, что изначально не соответствует тому, что от неё ожидается.
Failure — это сбой в работе компонента, всей программы или системы (может быть как аппаратным, так и вызванным дефектом).
Жизненный цикл бага
Атрибуты дефекта:
Серьезность (Severity) — характеризует влияние дефекта на работоспособность приложения. Выставляется тестировщиком.
Градация Серьезности дефекта (Severity)
Приоритет (Priority) — указывает на очередность выполнения задачи или устранения дефекта. Чем выше приоритет, тем быстрее нужно исправлять дефект. Выставляется менеджером, тимлидом или заказчиком.
Тест дизайн
Тест дизайн — это этап процесса тестирования ПО, на котором проектируются и создаются тестовые сценарии (тест кейсы), в соответствии с определёнными ранее критериями качества и целями тестирования.
Ответственные за тест дизайн:
Тест аналитик — определяет «ЧТО тестировать?»
Тест дизайнер — определяет «КАК тестировать?»
Техники тест дизайна
Эквивалентное Разделение (Equivalence Partitioning — EP). Как пример, есть диапазон допустимых значений от 1 до 10, выбирается одно верное значение внутри интервала (например, 5) и одно неверное значение вне интервала — 0.
Анализ Граничных Значений (Boundary Value Analysis — BVA). Если брать пример выше, в качестве значений для позитивного тестирования берется минимальная и максимальная границы (1 и 10), и значения больше и меньше границ (0 и 11). BVA может применяться к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
Причина / Следствие (Cause/Effect — CE). Подразумевается ввод условий, для получения ответа от системы (следствие).
Предугадывание ошибки (Error Guessing — EG). Это когда тестировщик использует свои знания системы и способность к интерпретации спецификации на предмет того, чтобы «предугадать» при каких входных условиях система может выдать ошибку.
Исчерпывающее тестирование (Exhaustive Testing — ET) — подразумевается проверка всех возможные комбинации входных значений. На практике не используется.
Попарное тестирование (Pairwise Testing) — это техника формирования наборов тестовых данных. Используется для тестирования сущностей с большими наборами входных данных (например, фильтры, сортировки). Преимущество данной техники в том, что она сокращает общее количество тест-кейсов, тем самым уменьшая время и расходы, затраченные на тестирование. Эта техника заслуживает отдельного внимания и более подробно рассматривается здесь. Также в конце данной статьи есть инструменты для автоматизации этой техники.
Таблица принятия решений (decision table) — инструмент для упорядочения сложных бизнес-требований, которые должны быть реализованы в продукте. В таблицах решений представлен набор условий, одновременное выполнение которых приводит к определенному действию.
Пример таблицы принятия решений
Виды тестирования
Функциональное тестирование рассматривает заранее указанное поведение и основывается на анализе спецификации компонента или системы в целом.
Нефункциональные виды тестирования
Тестирование пользовательского интерфейса (GUI Testing) — функциональная проверка интерфейса на соответствие требованиям (размер, шрифт, цвет, consistent behavior).
Тестирование удобства пользования (Usability Testing) — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. Сюда также входит:
User eXperience (UX) — ощущение, испытываемое пользователем во время использования цифрового продукта, в то время как User interface — это инструмент, позволяющий осуществлять интеракцию «пользователь — веб-ресурс».
Тестирование безопасности — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
Тестирование установки (Installation testing) направленно на проверку успешной инсталляции и настройки, а также обновления или удаления программного обеспечения.
Конфигурационное тестирование (Configuration Testing) — специальный вид тестирования, направленный на проверку работы программного обеспечения при различных конфигурациях системы (заявленных платформах, поддерживаемых драйверах, при различных конфигурациях компьютеров и т.д.)
Тестирование взаимодействия (Interoperability Testing) — это функциональное тестирование, проверяющее способность приложения взаимодействовать с одним и более компонентами или системами и включающее в себя тестирование совместимости (compatibility testing) и интеграционное тестирование
Тестирование на отказ и восстановление (Failover and Recovery Testing) проверяет тестируемый продукт с точки зрения способности противостоять и успешно восстанавливаться после возможных сбоев, возникших в связи с ошибками программного обеспечения, отказами оборудования или проблемами связи (например, отказ сети). Целью данного вида тестирования является проверка систем восстановления (или дублирующих основной функционал систем), которые, в случае возникновения сбоев, обеспечат сохранность и целостность данных тестируемого продукта.
Нагрузочное тестирование — это автоматизированное тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе.
Тестирование стабильности или надежности (Stability / Reliability Testing). Задачей тестирования стабильности (надежности) является проверка работоспособности приложения при длительном (многочасовом) тестировании со средним уровнем нагрузки.
Стрессовое тестирование (Stress Testing) позволяет проверить насколько приложение и система в целом работоспособны в условиях стресса и также оценить способность системы к регенерации, т.е. к возвращению к нормальному состоянию после прекращения воздействия стресса. Стрессом в данном контексте может быть повышение интенсивности выполнения операций до очень высоких значений или аварийное изменение конфигурации сервера. Также одной из задач при стрессовом тестировании может быть оценка деградации производительности, таким образом цели стрессового тестирования могут пересекаться с целями тестирования производительности.
Объемное тестирование (Volume Testing). Задачей объемного тестирования является получение оценки производительности при увеличении объемов данных в базе данных приложения
По виду Тестовых Сценариев:
Позитивный тест кейс использует только корректные данные и проверяет, что приложение правильно выполнило вызываемую функцию.
Негативный тест кейс оперирует как корректными так и некорректными данными (минимум 1 некорректный параметр) и ставит целью проверку исключительных ситуаций (срабатывание валидаторов), а также проверяет, что вызываемая приложением функция не выполняется при срабатывании валидатора.
По Уровню Тестирования:
Интеграционное тестирование (Integration Testing) Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Подходы к интеграционному тестированию
Снизу вверх (Bottom Up Integration) Все низкоуровневые модули, процедуры или функции собираются воедино и затем тестируются. После чего собирается следующий уровень модулей для проведения интеграционного тестирования. Данный подход считается полезным, если все или практически все модули, разрабатываемого уровня, готовы. Также данный подход помогает определить по результатам тестирования уровень готовности приложения.
Сверху вниз (Top Down Integration) Вначале тестируются все высокоуровневые модули, и постепенно один за другим добавляются низкоуровневые. Все модули более низкого уровня симулируются заглушками с аналогичной функциональностью, затем по мере готовности они заменяются реальными активными компонентами.
Большой взрыв («Big Bang» Integration) Все или практически все разработанные модули собираются вместе в виде законченной системы или ее основной части, и затем проводится интеграционное тестирование. Такой подход очень хорош для сохранения времени. Однако если тест кейсы и их результаты записаны не верно, то сам процесс интеграции сильно осложнится, что станет преградой для команды тестирования при достижении основной цели интеграционного тестирования.
Системное тестирование (System Testing) Основной задачей системного тестирования является проверка как функциональных, так и не функциональных требований в системе в целом. При этом выявляются дефекты, такие как неверное использование ресурсов системы, непредусмотренные комбинации данных пользовательского уровня, несовместимость с окружением, непредусмотренные сценарии использования и т.д.
Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема.
Cтатическое и динамическое тестирование
Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестированию относится тестирования спецификации и прочей документации.
Исследовательское / ad-hoc тестирование
Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом.
Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками.
Дымовое (Smoke) тестирование рассматривается как короткий цикл тестов, выполняемый для подтверждения того, что после сборки кода (нового или исправленного) устанавливаемое приложение, стартует и выполняет основные функции.
Тестирование сборки (Build Verification Test) — тестирование направленное на определение соответствия, выпущенной версии, критериям качества для начала тестирования. По своим целям является аналогом Дымового Тестирования, направленного на приемку новой версии в дальнейшее тестирование или эксплуатацию. Вглубь оно может проникать дальше, в зависимости от требований к качеству выпущенной версии.
Повторное тестирование — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок. В чем разница между regression testing и re-testing? Re-testing — проверяется исправление багов Regression testing — проверяется то, что исправление багов, а также любые изменения в коде приложения, не повлияли на другие модули ПО и не вызвало новых багов.
Регрессионное тестирование — это вид тестирования направленный на проверку изменений, сделанных в приложении или окружающей среде (починка дефекта, слияние кода, миграция на другую операционную систему, базу данных, веб сервер или сервер приложения), для подтверждения того факта, что существующая ранее функциональность работает как и прежде. Регрессионными могут быть как функциональные, так и нефункциональные тесты.
Санитарное тестирование — это узконаправленное тестирование достаточное для доказательства того, что конкретная функция работает согласно заявленным в спецификации требованиям. Является подмножеством регрессионного тестирования. Используется для определения работоспособности определенной части приложения после изменений произведенных в ней или окружающей среде. Обычно выполняется вручную.
Документация
Тест план (Test Plan) — документ, описывающий весь объем работ по тестированию ( а также необходимое в процессе работы оборудование, специальные знания, оценки рисков с вариантами их разрешения). Отвечает на вопросы:
Что нужно тестировать?
Как будет тестироваться?
Когда будет тестироваться?
Критерии начала тестирования.
Критерии окончания тестирования.
Основные пункты из которых может состоять тест-план перечислены в стандарте IEEE 829.
Неотъемлемой частью тест-плана является Traceability matrix — Матрица соответствия требований (МСТ) — это таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк — тестовые сценарии. На пересечении — отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. МСТ используется для валидации покрытия продукта тестами.
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Что означает в контексте тестирования ожидаемое поведение программы
Что пишут в блогах
2 декабря выступала в Костроме у Exactpro Systems с темой «Организация обучения джуниоров внутри команды». Уже готово видео! Ссылка на ютуб — https://youtu.be/UR9qZZ6IWBA
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Алексей Лянгузов
Какое-то время назад, я и не подозревал о том, что существует такое понятие как Context-Driven Testing, буду называть его Контекстным Тестированием (или КТ для краткости). Хотя я и сказал, что не подозревал об этом, но как оказалось, на протяжении всей моей карьеры инженера по тестированию, я руководствовался принципами, провозглашенными такими известными специалистами в тестировании ПО как Cem Kaner, James Bach и Bret Pettichord, которые являются авторами и проповедниками КТ.
Я могу назвать себя успешным специалистом в тестировании, и теперь я знаю, что КТ и есть тот базис, который позволил мне добиться успеха. Но я жалею, что не знал об этом раньше, когда был еще молодым специалистом. Пришлось всего достигать самостоятельным путем, а знание принципов КТ позволило бы пойти путь быстрее и проще. Но, как известно, одно дело знать о чем-то, другое дело уметь применять это знание на практике. Таким образом и зародилась идея познакомить людей с КТ и объяснить, как легко данный подход может быть использован в повседневной работе.
Самое интересное, что КТ полезно, не только для инженеров по тестированию, но и для других участников разработки ПО. Тяжело добиться эффективного тестирования без взаимодействия с разработчиками и руководством проекта. А для плодотворного сотрудничества, и разработчики и руководство, в первую очередь, должны понимать что они хотят от команды тестирования, а команда тестирования должна знать об этом.
1. Школы тестирования
Для полного понимания того, что такое КТ, необходимо узнать откуда появилось такое понятие и какие есть альтернативы. Материал этой главы основан на презентации:
Автор вышеуказанной презентации, выделил 5 школ тестирования. Деление на школы тестирования было произведено исходя из:
Школы не базируются ни на каких-либо спицефических методах тестирования, ни на общей теоретической основе или методологии.
Аналитическая школа (Analytic School). Базируется на аналитическом и логико-математическом подходе к тестированию. Пример — оценка покрытия кода тестами (code coverage)
Стандартная школа (Standard School). Базируется на четком планировании, отслеживании прогресса и проверке правильности(validation) разрабатываемого ПО. Пример — матрица прослеживаемости (traceability matrix)
Школа обеспечения качества (Quality School). Базируется на процессах, установленных правилах (policies) и метриках. Пример — критерии окончания тестирования, метрики и аудит исходного кода.
Школа “гибкого” тестирования (Agile School aka Example-driven School). Базируется на проверке пользовательских сценариев (user’s story) и наборе автоматизированных регрессионных тестов. Пример — разработка через тестирование (test driven development).
Школа контекстного тестирования (Context-Driven School). Базируется на текущих нуждах проекта, предметной области и направлено на предоставлении информации о текущем положении дел в проекте. Пример — исследовательское тестирование (exploratory testing).
Среди этих школ нет плохих или хороших. Каждый из подходов имеет право быть использован, и зачастую, применение того или иного подхода обусловлено разрабатываемым ПО или инженером по тестированию. У кого-то лучше получается быть надзирателем, у кого-то лучше аналитические навыки.
С другой стороны, специалисты школы контекстного тестирования наиболее легко могут приспосабливаться к различным условиям, процессам, окружающей обстановке. Данный подход не отрицает ни математического обоснования для тестирования, ни использования метрик, ни следования заведенным процессам. Инженеры, проводящие тестирование в соответствии с принципами КТ, становятся полноправными участниками разработки ПО и играют более значительную роль по сравнению с представителями других школ тестирования.
2. Базовые принципы КТ
Давайте подробнее остановимся на этих принципах и попытаемся понять, чем же они так замечательны. Заодно, для каждого принципа буду давать советы по практическому применению их в вашей работе.
Ценность любых действий зависит от условий, в которых они выполняются. Один из основных принципов КТ. Любое тестирование должно приносить максимальную пользу в данный конкретный момент времени. Ценность результатов тестирования минимальна, если они получены несвоевременно. Например, если по плану вы должны гонять сегодня тест «А», сперва подумайте, а нет ли другого теста «Б», результаты которого сейчас всем нужнее.
Во время работы над проектом случаются непредсказуемые вещи. Будьте готовы к тому, что по ходу проекта будет появляться необходимость в новых тестах (сделайте их), старые тесты могут стать ненужными (забудьте про них). Вполне возможно, потребуется изучение чего-либо, для того чтобы повысить эффективность тестирования (изучите это). Будьте готовы ко всему. Например к тому, что в какой-то момент вам придется сделать более поверхностное тестирование, чем вам бы того хотелось, но, зато, для большего объема функциональности. В противном случае вы ничего не успеете и вывалитесь из контекста.
3. Контекст — что это?
Теперь, когда мы ознакомились с принципами КТ пришло время понять, а что же такое этот контекст, о котором идет речь.
Контекст — это совокупность знаний о разрабатываемом проекте в определенный момент времени.
В первую очередь контекст определяется всеми людьми, задействованными в работу над проектом, а так же сопутствующими документами и базами знаний (спецификациями, требованиями, стандартами, базой дефектов, перепиской и так далее). Третьей составляющей контекста является что-либо, произведенное на основе уже имеющихся данных. Я выделяю три разновидности контекста: истинный, ложный и скрытый.
Истинный контекст. Реальное положение дел в проекте, определенное действиями проводимыми до этого момента. То, что является отправной точкой для дальнейшего развития.
Ложный контекст. Устаревшие данные, неправильно понятая или двусмысленная информация. Что-либо желаемое, выдаваемое за действительное. Истинное положение дел не может быть таким, только потому, что кто-то хочет, что бы оно было таким. Следует избегать любого искажения или сокрытия информации. Не говоря об умышленном искажении фактов. Разоблачить неверные знания — одна из задач тестирования.
Скрытый контекст. Информация, по каким-то причинам, не доступная заинтересованным лицам. Возможно потерянная цепочка логических выводов, незамеченные изменения в спецификациях, расхождение текущей реализации с ее истинными целями. Задача людей работающих в тестировании находить такой скрытый контекст и незамедлительно информировать всех, кому это необходимо знать.
4. КТ и процесс тестирования
Хочу обратить внимание на то, что истинный контекст формируется на основе действий, а не желаний и не на основе процессов по которым эти действия совершаются. Но тем не менее, любая команда тестирования выполняет свою работу, в соответствии с каким-либо внутренним процессом организации труда. С этой точки зрения КТ дает возможность построить максимально гибкий и рациональный процесс.
Во-первых, КТ дает возможность сэкономить ресурсы на планирование и перепланирование. Я не призываю вообще отказаться от планирования или не иметь долгосрочной стратегии тестирования. Можно просто иметь список задач, элементы которого добавляются, удаляются или меняют приоритет перед началом тестирования каждой новой сборки, переданной на тестирование.
Второй момент, который поможет сберечь ресурсы и позволить проводить больше опытов – это тестовая документация. Давно пора перестать описывать тесты так, чтобы их мог прогнать «человек со стороны». Не будет «человек со стороны» тестировать ваш продукт. Никогда не будет. Такие чрезвычайно подробные описания тестов вредны по нескольким причинам – а) их в 99% случаев будут выполнять как есть, не смотря по сторонам; б) любое минимальное изменение в продукте обычно влечет за собой изменение описания теста; в) они требуют больше ресурсов на создание; г) они не дают исполнителю «включить голову».
Третья область где, вероятно, можно выиграть время – отчеты о тестировании. Отчеты должны быть содержательными и полезными. Не стоит писать никому ненужные отчеты, особенно делать это регулярно. Информация содержащаяся в отчете по результатам работы, в первую очередь должна быть полезна сотрудникам отдела тестирования. Ни руководству, ни программистам не нужна очень подробная информация. Таким образом, максимальный уровень детализации отчетов должен регулироваться потребностями самих инженеров, проводящих эксперименты.
В-четвертых, постоянное взаимодействие с командой разработки и с руководством проекта помогут выполнять наиболее важные задачи вовремя.
Последнее, и наверное самое главное, это команда. Процесс должен определяться теми людьми, которые ему следуют. Чем ровнее уровень профессионализма в команде тестирования, тем более эффективно можно организовать процесс тестирования. Наиболее важные качества это самодисциплина и ответственность каждого из участников.
5. КТ и процесс разработки
Команда тестирования — команда, оказывающая услуги другим участникам разработки. При этом все задействованные в разработку (включая тестирование) люди должны преследовать единственную цель — вовремя выпустить качественный продукт, решающий поставленные задачи. Вот несколько советов основным участникам процесса разработки.
Разработчики, воспринимайте людей работающих в тестировании как помощников. Отвечайте на их вопросы, даже если они на первый взгляд кажутся вам глупыми. Ведь проще обсудить возникшее недопонимание прежде чем оно будет сформировано в виде дефектов и окажется на всеобщем обозрении. Прислушивайтесь к тому, что говорят тестеры, объясняйте им почему вы считаете, что они не правы. Знайте — люди работающие в тестировании не глупее вас, они просто делают за вас кое-какую грязную работенку, позволяя вам сосредоточится на других аспектах разработки ПО.
Руководители тестирования, не нагружайте исполнителей бюрократической работой, если ее результаты никому не нужны. Каждый ненужный отчет отнимает драгоценное время от проведения экспериментов. Не требуйте слепого соблюдения планов или процессов, если текущая ситуация диктует поступить иначе. Старайтесь нанимать в тестирование людей, которые умеют думать и знают, зачем они совершают те или иные действия. Откажитесь от набора более дешевых «кликеров», выполняющих, зачастую, никому ненужные действия.
Руководители проектов, определитесь, что вы хотите от тестирования. Придите к соглашению о тех сервисах, которые будет предоставлять команда тестирования. Не гонитесь за большим количеством услуг, лучше меньше, но лучше. Убедите всех участников разработки, что ответственность за качество лежит на каждом, а группа тестирования может только контролировать и информировать о текущем уровне качества продукта. Также помните о том, что нет магического порошка, который выявляет все дефекты — тестирование процесс сложный и ресурсоемкий.
Коллеги по тестированию, думайте, спорьте, не верьте, проверяйте все домыслы на практике, не скрывайте никакие знания или результаты вашей работы. Каждый ваш шаг должен иметь какой-то повод, исходя из контекста. Добивайтесь своего, если вы считаете, что это правильно. Помните, вы одновременно являетесь искателями истины, контролерами качества и первыми пользователями продукта. Знайте, что ожидают от вашей работы коллеги, разработчики и руководители.
6. КТ — стиль жизни думающего инженера по тестированию ПО
Вне зависимости от того, какие процессы разработки и тестирования существуют на вашем текущем месте работы, вы всегда можете руководствоваться принципами, приведенными выше. Сделайте контекстный подход к тестированию вашим жизненным кредо. В этом случае с вашим мнением всегда будут считаться, так как ваше мнение основывается не на количестве тестов, которые надо бы было прогнать, не на закостенелых процессуальных действиях, не на основе вредных метрик. Ваше мнение всегда основывается на текущих нуждах, понимании происходящего и желании принести максимальную помощь. Ваши действия всегда должны быть разумны, резонны и понятны для других членов команды.
7. Как обучиться КТ
Так как я не занимаюсь профессиональным обучением, а сам учился только на практике, то могу привести еще несколько советов для самообучения, которыми я и руководствуюсь:
8. Заключение
Может показаться, что статья не содержит ничего нового и что советы вполне очевидны и тривиальны. Да, да это так и есть. Но как ни странно, почему-то, в повседневной работе очень мало людей руководствуются данными принципами.
Разве ситуация, когда команда тестирования узнает об каких-то изменениях последней является исключительной? Разве не считается, что мнением инженера по тестированию можно, в определенный момент, пренебречь? Разве не общепринятая практика, что лучше набрать побольше низкооплачиваемых и неопытных сотрудников в тестирование, ибо считается что для этой работы ни ума ни опыта много не требуется? Разве нерадивых разработчиков не переводят в «ссылку» в отдел тестирования? Разве руководители не обсуждают ситуации, когда они не понимают, зачем им вообще это тестирование, что они там вообще делают? Можно продолжать список вопросов «разве не. ». Печально, но факт, что все перечисленное довольно часто встречается. А самое печальное в том, что люди работающие в тестировании, зачастую, сами подтверждают сомнения в сложности и важности их работы, просто потому, что делают не то, что от них требуется.
Если, хотя бы, несколько человек задумаются над советами приведенными в статье, если пересмотрят свое отношение к тестированию, если кто-то сможет извлекать больше пользы от тестирования во благо качества разрабатываемого продукта — то я буду считать, что статья написана не зря.