Цели и задачи тестирования ПО в разрезе задач обеспечения качества ПО и некоторые мысли по автоматизации тестирования ПО.
Источник: Переход к автоматизированнуму тестированию
У тестировщика три основных задачи:
1. выявить как можно больше существующих дефектов и
2. проверить, что они устранены и
3. при устранении известных дефектов не были внесены новые баги (проверка целостности).
Все!
Не согласен с приоритетами в целом, но соглашусь с некоторыми выводами в разрезе задач автоматизации тестирования ПО.
Постараюсь кратко, но не обещаю:
1. Выявление ошибок не есть цель тестирования ПО.
2. Основной задачей тестирования ПО является получение информации о статусе готовности заявленной функциональности системы или приложения.
3. Задача получения статуса готовности обычно реализуется как проверка сценариев использования системы в валидных и невалидных условиях использования, которые формируются наборами входных данных и состояний, операций или пеолучаемых тестируемым функционалом данных и набором выходных данных и состояний системы.
4. Выявленные ошибки это побочный результат отработки задачи тестирования ПО, так как напрямую не являются нужной и полезной Заказчику тестирования информацией.
5. Количество найденных в процессе тестирования ошибок никак не характеризует уровень качества конечного продукта, а может выступать метрикой качества или зрелости самого процесса разработки ПО.
6. Количество найденных в процессе тестирования ошибок никак не характеризует целесообразность затрат ресурсов на проведение тестирования, так как напрямую зависит в основном от состояния продукта на момент начала тестирования и в меньшей степени от степени подготовленности/спланированности тестирования.
Теперь посмотрим на задачи автоматизации тестирования ПО с точки зрения приведённых выше задач тестирования ПО ибо автоматизация не есть вещью в себе, а является просто подходом к выполнению задач тестирования, эффективность которого по сравнению с ручным тестированием зависит от конкретных переменных проектного окружения: длительность проекта, готовность проекта к автоматизации на разных структурынх уровнях и т.д..
Автоматизировать можно и нужно только то, что автоматизации требует, а не те функциональные модули, где автоматизацию можно применить.
Что значит требует?
Занимает много времени при ручном тестировании (повторяется циклически многократно и/или требует множества автоматизируемых операций перед проверкой ключевой функциональности, как например проверка операции закрытия переода в биллинге, тестирование которой требует введения данных о потреблении услуг) и может в перспективе с учётом затрат на приобретение и внедрение инструмента автоматизации окупиться в бюджете проекта. Финансовая окупаемость - это единственный фактор, который определяет целесообразность внедрения автоматизации тестирования ПО в проекте. Зачастую на финансовую окупаемость может положительно влиять внедрение практик и инструментов автоматизированного тестирования на уровне компании, а не отдельно взятого проекта.
Что значит целесообразность внедрения на практике.
Модульное тестирование
Прогон всех модульных тестов на интеграционном окружении во время сборки версии системы является первым этапом автоматизации. Имеет ли смысл вкладывать ресурсы в модульное тестирование?
Если вопрос возник, культура разработки в проекте находится на достаточно низком уровне. Продукт приходит в тестирование стабильно сырым, исправление ошибок вызывает циклическое появление новых ошибок в связанном функционале. Скорее всего поможет внедрение практик модульного тестирования, что приводит к более целосному коду, который выходит из группы разработки. При этом модульные тесты являются первыми же приёмочными тестами и невыполнение полного набора модульных тестов автоматически заворачивает сборку версии/билда. При этом модульное тестирование не есть самоцель, а только инструмент предварительного контроля качества кода на модульном уровне.
Если на этом уровне проблемы не хронические, версии выходят готовые к тестированию, значит группа разработки своими ресурсами обеспечивает целосность кода (обычно в таких проектах за целосность выкатки отвечает тим лид, который строит версию на своей машине и сам проводит начальное тестирование – до тех пор, пока ему это не надоедает и он сам начинает гонять разработчиков на предмет покрытия юнитами). Требовать группой тестирования от разработки вложений ресурсов в модульное тестирование, не имея веских оснований уровня многократых перевыкаток версии после дымового тестирования или возникновения связанных ошибок я бы не стал.
Автоматизация набора регрессионных тестов
Я не совсем понимаю этузадачу как вид тестирования и для себя не выделяю, но формулировки в форумах встречаются именно такие. Для меня структура тестов любого функционала примерно следующая:
1. Полный или основной тестовый набор, покрывающий всю функциональность тестовой области. Ревьювится перед каждым прогоном полного цикла тестирования на предмет изменений в спецификациях и критических исправлений/доработках. Обновляется/актуализируется по результатам ревью.
2. Короткий список (обычно только позитивные тесты основанные на наиболее приоритетных сценариях использования). Включается в цикл дымового тестирования или другими словами в набор тестов приёмочной фазы тестирования. Составляется в процессе создания тестового набора. Ревьювится перед каждым прогоном набора приёмочных тестов, по сути перед каждым раундом тестирования при выкатке новой версии. Обновляется/актуализируется в момент актуализации основного тестового набора. Удобно вести в том же артефакте что и основной тестовый набор с возможностью автоматизированного включения в тестовый набор дымового/приёмочного тестирования.
Регрессионным тестовым набором системы, в моём понимании, является сумма всех наборов тестов всех тестовых областей. Регрессионное тестирование, по сути, является функциональным тестированием с той разницей, что целью такого тестирования проверка отсуствия регрессии системы. Вкладывать ресурсы в регрессионное тестирование как выделенный этап работ как я бы не стал, так как результатаы регресии системы станут очевидны после прогона полного тестового набора функциональных тестов и тестов производительности (система может регрессировать по любому из аспектов качества ПО включая производительность, функциональность и надёжность). Если проведение полного цикла тестирования удобнее или нагляднее выносить в отдельный этап работ и называть его как-то надо :) то можно называть его и регрессионными тестами. Только не надо потом думать над задачами автоматизации в разрезе этой привнесённой выделенности регрессионного тестирования.
Иногда в планы автоматизации может вмешиваться задача автоматизации тестирования какого-то выделенного компонента, например от стороннего разработчика, функционал которого как бы оборачивается прослойкой автоматизированных тестов, для снижения рисков связянных с неполным контролем качества поставляемого этим разработчиком модулей или компонентов. Если таким компонентом является что-то, что используется в системе несколькими модулями системы, скорее всего прийдётся идти по принципу точечной автоматизации именно в разрезе автоматизации тестирования этого выделенного списка функций. Например, уровень работы с базой данных может стать таким узким местом, если кому-то пришлось отказываться от поставляемых в составе СУБД драйверами.
Что попадает в набор тестов для автоматизации определяется всё тем же основным принципом экономической рациональности и в каждом конкретном тестовом наборе.
