Как составить стратегию тестирования: версия настоящих инженеров
Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.
В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.
В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.
0. Разберемся на берегу
Зачем нужна стратегия тестирования?
В первую очередь, конечно же, QA и обязательно менеджер проекта.
Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!
1. Какие типы тестирования будем применять на проекте и почему
В самом начале предлагаем вспомнить все существующие типы тестирования и принять решение по каждому: будем ли его применять и почему. Рассмотрим на некоторых примерах, как можно принять решение о необходимости конкретного типа тестирования.
Тестирование установки версии
В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.
Для веб-приложений полезно обсудить, как мы проверим, что данные после обновления не потерялись. Какого поведения мы ожидаем от активной сессии.
Для десктоп и мобильных приложений надо подумать способ доставки нового дистрибутива до пользователя и процесс обновления, который запускается самим пользователем.
Для всех проектов полезно обсудить такие вещи, как прогрев системы: установка справочников, заведение пользователей и другие данные, которые нужны пользователю, чтобы начать работу с системой.
Тестирование производительности
На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.
| Дано | Решение |
|---|---|
| Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей. | Имеет смысл запланировать volume-тестирование с большими объёмами данных. |
| Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика. | Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду. |
| Приложением пользуется несколько человек в неделю, объём данных минимален. | Тестирования производительности не требуется. |
Регрессионное тестирование
На полную проверку всей системы всегда уходит очень много времени. Поэтому для принятия решения надо оценить целесообразность: сколько времени требуется на полный регресс, и риски, которые могут случиться, если его проводить не будем.
| Дано | Решение |
|---|---|
| Выкатываем первую версию продукта или модуля программы. | Регрессионное тестирование не требуется. |
| Проект очень большой, и на проведение полного регресса перед релизом новых фич требуется время, сопоставимое со сроком разработки. Требуемый темп поставок этого не позволяет. | Решаем, что регрессионное тестирование не проводим, а больше внимания уделяем другим видам тестирования и мониторингу. |
| Взаимодействие между микросервисами покрыто контракт-тестами. | Проведение полного регресса нецелесообразно. В рамках ручного тестирования проводим регресс функциональности по рекомендации разработчика. |
Интеграционное тестирование
Для определения необходимости интеграционного тестирования полезно перечислить все внешние системы, с которыми взаимодействует продукт, и указать, какие именно данные мы получаем и передаём.
| Дано | Решение |
|---|---|
| Данные по продажам из портала передаются в аналитическую систему. | Важно не только проверить, что продажи ушли, ушли в корректном формате, но и то, что пришли в корректном формате — ничего не потерялось по дороге. |
Тестирование локализации
Кроссбраузерность и кроссплатформенность
Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.
| Дано | Решение |
|---|---|
| Пользователями мобильного приложения являются сотрудники по всей стране. | Смотрим существующую статистику использования платформ нашего приложения и принимаем решение, на каких из них будем тестировать. |
| У нашего приложения корпоративные пользователи на стационарных машинах. | Скорее всего, мы сможем порекомендовать использование только одного браузера. И тем самым сократим время на тестирование и поддержку кроссбраузерности. |
2. Приоритеты в тестировании
На всех проектах случаются форс-мажоры, поэтому на такой случай полезно иметь шпаргалку с заранее продуманным планом, а не хвататься за случайные кнопки.
В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).
| Дано | Решение |
|---|---|
| Нашей программой пользуются в аэропортах для продажи услуг пассажирам при посадке в самолет. И если в этот момент случится какая-то ошибка, то у нас не будет времени на хот-фикс. Поэтому ошибок быть не должно! | Проверяем сценарий использования в аэропорту в первую очередь. |
3. Окружения для работы
Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.
| Дано | Решение |
|---|---|
| На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности. | Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA). |
| Регулярно проводятся сессии бета-тестирования. | Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение. |
4. Работы тестировщика на проекте
Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте, потому что они не обязательно одни и те же на всех проектах. Для кого-то в команде может стать сюрпризом, что тестировщик что-то делает или чего-то не делает.
Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.
5. Тестовая документация на проекте
6. Каким образом генерируются тестовые сценарии
7. Порядок работы с трекером
В разных трекерах различаются возможности и типы задач. Исходя из возможностей трекера советуем договориться о том, кто и по какому принципу определяет приоритетность задач, в какой тип задач оформлять баги и таски.
8. Критерии начала и окончания тестирования
Если тестировщик в любой момент будет брать любую задачу — это не порядок, а хаос. Потому что задача может быть не готова. Или готова, но не вдеплоена. Или готова, вдеплоена, но зависит от других задач, которые ещё не готовы. В итоге, тестировщик тратит время и нервы на поиск и оформление ошибок, а на самом деле надо просто подождать. Поэтому договориваемся, в какой момент начинается и заканчивается зона ответственности QA над задачей.
На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.
| Дано | Решение |
|---|---|
| На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования. | Считаем задачу проверенной, если мы прошли все пункты чек-листа. |
| На проекте ведется работа по спринтам. | Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше. |
| На проекте составлен список функциональности по приоритетам. | Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка. |
| На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом. | Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5). |
9. Инструменты для работы
Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.
10. Оценка качества проекта и инструменты мониторинга
В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:
Заключение
Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.
Что такое тест стратегия
Стратегия тестирования представляет собой описание общего подхода к тестированию и целей тестирования. Различают несколько уровней (компонент, интеграция и система в целом) и видов (функции, производительность, нагрузка, отказоустойчивость) тестирования.
В состав стратегии входят:
В некоторых организациях применяются корпоративные стратегии тестирования, и в этих случаях необходимо адаптировать эти стратегии к конкретным проектам.
Важнейшие обстоятельства для планирования тестирования:
Обратите внимание на то, как могут меняться характеристики задач тестирования в зависимости от того, на каком этапе находится тестирование с точки зрения указанных выше параметров. Существует много важных характеристик, например, объем необходимых ресурсов и затраченное время, но в данном случае нужно сконцентрироваться на важнейших факторах с точки зрения разработки стратегии тестирования:
Не существует единого шаблона распределения тестов по циклам тестирования. Типы тестов зависят от количества итераций, размера итерации и типа проекта.
При тестировании центральное внимание уделяется охвату всех требований, подлежащих тестированию, то есть выполнению всех предусмотренных тестов. Это значит, что критерии завершения тестирования обычно привязаны к количественному охвату множества тестов, каждый из которых, в свою очередь, напрямую связан с каким-либо требованием. При тестировании компонентов и интеграции удобнее пользоваться критериями завершения на основе охвата кода. На следующем рисунке проиллюстрировано изменение этих двух критериев охвата на разных этапах итерационного процесса разработки программного обеспечения.
Постарайтесь автоматизировать как можно больше тестов, особенно тех, что выполняются несколько раз (в рамках регрессионного тестирования). Помните о том, что создание и обслуживание автоматизированных тестов требует определенных ресурсов и затрат. В каждом проекте определенный объем тестирования выполняется вручную. На следующем рисунке приведены примеры ситуаций и этапов тестирования, на которых может потребоваться выполнение тестов вручную.
В следующих таблицах показаны различные типы тестов и примеры условий завершения тестирования. В первой таблице показан типичный пример проекта по разработке управленческой информационной системы.
| Итерация | Тест системы | Тест интеграции | Тест компонента |
|---|---|---|---|
| Итерация 1 | Автоматизированное тестирование производительности всех вариантов использования. · Выполнены все запланированные тесты. · Устранены все ошибки серьезности 1. · Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки серьезности 1. | Нет | Неформальное тестирование |
| Итерация 2 | Автоматизированное тестирование производительности и функций всех новых вариантов использования, а также тестирование старых вариантов использования в качестве регрессионного тестирования. · Выполнены все запланированные тесты. · Устранены все ошибки серьезностей 1 и 2. · Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки серьезности 1 или 2. | Нет | Неформальное тестирование |
| Итерация 3 | Автоматическое тестирование функций и негативное тестирование всех новых вариантов использования, а также всех старых вариантов использования в качестве регрессионного тестирования; 95% тестов должны быть выполнены успешно. · Выполнены все запланированные тесты. · Выявлены все ошибки серьезностей 1, 2 и 3. | Автоматизированное тестирование, охват 70% кода. | Неформальное тестирование |
| Итерация 4 | Автоматическое тестирование функций и негативное тестирование всех вариантов использования, тестирование вручную всех неавтоматизированных частей, а также проведение всех прежних тестов в качестве регрессионного тестирования. Должно быть успешно проведено 100% тестов. · Выполнены все запланированные тесты. · Устранены все ошибки серьезностей 1, 2 и 3. · Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки серьезности 1 или 2. | Автоматизированное тестирование, охват 80% кода. | Неформальное тестирование |
Во второй таблице показаны типы тестов и критерии завершения для типичной системы безопасности.
| Итерация | Тест системы | Тест интеграции | Тест компонента |
|---|---|---|---|
| Итерация 1 | Автоматизированное тестирование производительности всех вариантов использования; охват 100% тестов. · Выполнены все запланированные тесты. · Устранены все ошибки серьезности 1. · Все запланированные тесты выполнены повторно и не обнаружено ни одной новой ошибки. | Нет | Нет |
| Итерация 2 | Автоматизированное тестирование производительности и функций, а также негативное тестирование всех вариантов использования; охват 100% тестов. · Выполнены все запланированные тесты. · Устранены все ошибки серьезностей 1 и 2. · Все запланированные тесты выполнены повторно и не обнаружено ни одной новой ошибки. | Автоматизированное тестирование производительности | Неформальное тестирование |
| Итерация 3 | Автоматизированное тестирование производительности и функций, а также негативное тестирование и тестирование документации всех вариантов использования; охват 100% тестов. · Выполнены все запланированные тесты. · Устранены все ошибки серьезностей 1, 2 и 3. · Все запланированные тесты выполнены повторно и не обнаружено ни одной новой ошибки. | Автоматическое тестирование производительности и повтор предыдущих тестов в качестве регрессионного тестирования. | Автоматизированное тестирование, охват 70% кода |
| Итерация 4 | Автоматизированное тестирование производительности и функций, а также негативное тестирование и тестирование документации всех вариантов использования; охват 100% тестов. · Выполнены все запланированные тесты. · Устранены все ошибки серьезностей 1, 2 и 3. · Все запланированные тесты выполнены повторно и не обнаружено ни одной ошибки. | Автоматическое тестирование производительности и повтор предыдущих тестов в качестве регрессионного тестирования. | Автоматизированное тестирование, охват 80% кода. |
© Copyright IBM Corp. 1987, 2006. Все права защищены..
Создать документ по стратегии тестирования
Что такое тестовая стратегия?
Документ «Стратегия тестирования» отвечает на такие вопросы, как то, что вы хотите сделать и как вы собираетесь это сделать. Это самый важный документ для любой команды QA в тестировании программного обеспечения. Написание эффективного Стратегического документа — это навык, который тестер развивает с опытом. План стратегии тестирования должен быть сообщен всей команде, чтобы команда была последовательной в отношении подхода и обязанностей.
План тестирования против стратегии тестирования
План испытаний
Тестовая стратегия
Чтобы было понятнее, если План тестирования — это какой-то пункт назначения, то стратегия QA Test — это карта для достижения этого пункта назначения.
Как подготовить хороший документ по стратегии тестирования
Каждая организация имеет свой уникальный приоритет и набор правил для разработки программного обеспечения, поэтому не копируйте никакую организацию вслепую. Всегда следите за тем, чтобы их документ был совместимым и повышал ценность вашей разработки программного обеспечения, прежде чем следовать шаблону.
Тестовая стратегия в STLC :
Шаг № 1: сфера
Он определяет такие параметры, как
Шаг № 2 Тестовый подход
Шаг № 3 Тестовая среда
Шаг № 4 Инструменты тестирования
Шаг № 5 Управление выпуском
Шаг № 6 Анализ рисков
Шаг # 7 Проверка и одобрения
Скачать шаблон тестовой стратегии
Нажмите ниже, чтобы загрузить образец документа стратегии тестирования
Вывод:
В Software Engineering, версия программного обеспечения периодически просматривает документы Test Strategy, чтобы отобразить ход тестирования в правильном направлении. Когда дата выпуска будет близка, многие из этих действий будут пропущены, желательно обсудить с членами команды, поможет ли сокращение какого-либо конкретного действия для выпуска без какого-либо потенциального риска.
Что такое тест стратегия
Что пишут в блогах
Привет! В блоге появляется мало новостей, потому что все переехало в telegram.
Стоимость в цвете — 2500 рублей самовывозом (доставка еще 500-600 рублей, информация по ней будет чуть позже)
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Онлайн-тренинги
Что пишут в блогах (EN)
Разделы портала
Про инструменты
Автор: Вячеслав Панкратов
Руководителям групп тестирования и ведущим тестировщикам часто приходится разрабатывать кроме необходимой рабочей документации и артефактов, документы более высокого уровня, описывающие общие подходы к тестированию системы и развитие процесса тестирования в проекте. Об одном из таких документов-артефактов и пойдёт речь ниже.
Многие из нас сталкивались с разработкой стратегии тестирования, особенно часто подобные артефакты интересуют заказчиков крупных проектов, срок разработки которых превышает год. Попробуем внести ясность в понятие Стратегии Тестирования и ответить на ряд вопросов разобрав несколько примеров на практике.
Терминология
СТРАТЕГИЯ — искусство руководства; общий план ведения этой работы, исходя из сложившейся действительности на данном этапе развития.
Есть другой вариант, с военным уклоном:
Наука о ведении войны, искусство ведения войны. Общий план ведения войны, боевых операций.
Я привожу оба определения, хотя первое достаточно точно описывает с чём, собственно, мы имеем дело. И хотя наши будни можно рассматривать как ведение войны за качество продукта, как мы увидим ниже ничего «военного» в стратегии тестирования как раз и нет.
Определение
Стратегия тестирования — это план проведения работ по тестированию системы или её модуля, учитывающий специфику функциональности и зависимости с другими компонентами системы и платформы. Стратегия определяет типы тестов, которые нужно выполнять для данного функционала системы, включает описание необходимых подходов с точки зрения целей тестирования и может задавать описания или требования к необходимым для проведения тестирования инструментам и инфраструктуре.
Получается немного страшновато? Попробуем разбить на более детальные части используя, к примеру, разбивку по вопросам, на которые отвечает стратегия тестирования.
Стратегия отвечает на вопросы:
В качестве дополнительной задачи, которая решается в процессе понимания стратегии тестирования, можно рассматривать задачу минимизации затрат на тестирование. Ниже на примере мы разберём более конкретный случай, сейчас же просто ограничимся указанием этого факта.
Как видим, Стратегия тестирования, как артефакт, органично вписывается в План Тестирования. Шаблоны планов тестирования, предлагаемые различными методологиями, зачастую прямо включают одним из разделов описание стратегии тестировании или же включают описание стратегии в пункты плана отвечающие за тестирование конкретных частей функционала. К примеру, шаблон Rational Unified Process определяет стратегию тестирования как самый большой раздел плана тестирования.
Что идеологически более правильно: выделять стратегию для всего проекта, или разрабатывать конкретные подходы для каждой области тестирования, зависит от конкретного проекта. В современных распределённых системах, с несколькими типами рабочих мест и системными агентами, которые также выступают пользователями системы, логичнее выделять стратегию для каждого набора тестируемого функционала: модуля или подсистемы. Для более простых приложений можно предлагать тестирование всего приложение в рамках одной Стратегии.
Заказчик, зачастую, хочет контролировать процесс тестирования и видеть понимание задачи тестирования исполнителями по проекту. Для него стратегия тестирования это менее детальный документ-видение (vision) того, как будет тестироваться система в процессе разработки.
Практика
Для того, чтобы перейти от теории к практическому применению, попробуем разработать стратегию тестирования, для двух различных программных решений: десктоп-приложения, работающего в однопользовательском режиме и клиент-серверную систему средней сложности.
Разбираемые ниже примеры используют упрощённую модель приложений в разрезе взаимодействия компонентов приложения и системы, а также внутренней логики самого приложения.
В качестве простого десктоп-приложения возьмём, к примеру, новый инженерный калькулятор.
Инженерный калькулятор
Весь набор функций этого приложения можно разделить на две логические группы: логика инженерных операций и взаимодействие с операционной системой (выделение и освобождение ресурсов, использование системных компонент, взаимодействие с буфером обмена системы и т.п.).
Из требований к приложению выделим поддержку 5-ти операционных систем с 4 основными языками локализации и выполнение, скажем, 50 инженерных функций, каждая из которых однозначно покрывается одним тестом. Тесты, безусловно, включают проверку на контрольных примерах, проверку на граничные значения и т.п. Кроме того, приложение позволяет выполнять, к примеру, 5 функций по взаимодействию с системой (запуск приложения, выход из приложения, сохранение результатов в файл, работа с буфером и т.п.).
Полное покрытие требований задаёт набор из 5*4*(50+5)=1100 тестовых прогонов. Так как нужно выполнить все доступные операции приложения под всеми поддерживаемыми операционными системами и языковыми локализациями.
Пример, как вы понимаете, подобран не случайно. Попробуем наглядно показать стратегию тестирования в действии.
Вернёмся к разбивке функциональности приложения по логическим группам. Есть набор инженерной функциональности и есть системное взаимодействие.
Очевидно, что работа и правильность результатов вычислений, реализованная внутри приложения и не использующая внешние компоненты не зависит от локализации системы. Более того, если приложение успешно запущено под поддерживаемой операционной системой и основная функциональность по работе с инженерными функциями работает, то имея успешный прогон всех инженерных тестов с анализом контрольных результатов, можно говорить о работоспособности инженерных функций под всеми поддерживаемыми операционными системами и локализациями.
Таким образом, гарантировать работоспособность инженерных операций калькулятора можно прогоном 50 тестов под одним окружением.
Взаимодействие с системой, запуск, остановку приложения, работу с буфером, запись результатов в файл, в нашем примере обеспечивает 5 тестов. Имеем 5 версий операционной системы и 4 локализации, что даёт 20 комбинаций и 20*5=100 тестовых прогонов.
Таким образом, для данного примера, полный охват функциональности определяется 50+100=150 тестовых прогонов, из которых 50 тестов инженерных функций выполняются под одной конфигурацией и 5 тестов системных функций под 20 тестовыми окружениями.
Стратегия тестирования в действии
В данном случае, мы разобрались с тем, что именно нужно тестировать, определили требования к тестам, провели простейший анализ условий тестирования и зависимостей. По сути своей, определили стратегию: «как» и «что» тестировать. Разрабатывать тесты можно в параллель к разработке стратегии, в любом случае дизайн и разработку тестов стратегия не заменяет.
Полное покрытие требований определяет 1100 тестовых прогонов. Разбор функциональности и определение необходимого набора тестирования даёт на выходе из разработки стратегии тестирования 150 тестовых прогонов.
Для данного конкретного примера, разработка стратегии тестирования даёт прямой выигрыш в затратах на тестирование в 1100/150=7,(3) раза. Как видим, имеет смысл. Попробуем рассмотреть шаги разработки стратегии тестирования для более сложного приложения — распределённой клиент-сервер системы.
Распределённая система
Подход в разработке стратегии тестирования для распределённой системы во многом совпадает с разработкой стратегии тестирования для обычного калькулятора. К примеру, аналогично с предыдущим примером, нам нужно выделить основные области, которые могут тестироваться отдельно друг от друга. Для тестирования сложных систем, также полезно выделять не только, так сказать, оперативные шаги по тестированию (то есть что, как и где будет тестироваться), но и проводить анализ тактических шагов по тестированию с учётом развития системы во времени.
Вернёмся к стратегии тестирования сложной распределённой системы. Проведём ориентировочную разбивку функциональности на тестовые области, с тем, чтобы понять как спланировать тестирование и минимизировать затраты.
Пусть система имеет «толстого» клиента, сервер приложения и сервер базы данных, которые могут функционировать на разных физических платформах. Основная логика ввода/вывода, валидации значений и построения печатных форм сосредоточена на клиенте, сервер приложений обеспечивает презентационный уровень и необходимую сервисную логику (автоматическая архивация данных, оповещение пользователей о внештатных ситуациях и т.д.), а база данных обеспечивает кроме непосредственного хранения данных определённую часть обработки данных реализуемую, к примеру, в виде пакетов функций. Ничего особенно сложного выбрано не было и пусть описание не пугает определённой утрированностью — мы всего лишь обрисовали задачу для тестирования.
Для того, чтобы чрезмерно не усложнять задачу, сузим область тестовых окружений за счёт фиксированных конфигураций для сервера БД (зачастую в промышленной эксплуатации используется выделенный сервер или кластерное решение для работы баз данных) и сервера приложений. Клиентское приложение обеспечивает работу под 2-мя операционными системами и жестко фиксированной конфигурацией компонентов ОС (к примеру, на все пользовательские машины регулярно устанавливаются все обновления и service packs + набор ПО на клиентских машинах строго регламентирован внутренней IT политикой).
Объём задач
Попробуем описать задачу на языке тестовых сценариев, то есть будем применять для оценки трудоёмкости задачи или её части количество тестов, необходимых для проверки работоспособности функционала.
Клиент: 50 тестов на работу с данными (ввод форм, расчёт данных на основе данных хранимых в словарях, поиск данных, редактирование словарей и т.п.), 10 тестов на работу с печатными формами (формирование периодов выборок, выбор типов отчётов, печать или экспорт в предопределенный список форматов и т.д.). Пусть для тестирования работы с системой требуется, как и в предыдущем случае, ещё 5 тестов. По аналогии с предыдущим примером можем получить следующую картинку: имея 2 окружения получаем (5+10)*2=30 тестовых прогонов для проверки функциональности связанной с самой операционной системой (включая функционал печати и экспорта во время которого создаются новые файлы в рамках файловой системы). Будем считать, что 50 тестовых прогонов реализующих проверку логики работы с данными, можно выполнять под одним окружением. Итог — 80 тестовых прогонов для тестирования клиента системы.
Объединим в рамках рассматриваемого примера тестирование функциональности сервера приложений и базы данных. Пусть сервер приложения реализует 20 команд по обработке данных и пользовательских сессий (без учёта работы с системными пулами соединений, функций сжатия передаваемого по сети трафика и т.п.). Сервер баз данных реализует 10 системных операций по архивации данных, построению статистики использования отчётов и ещё несколько подобных операций. Общий смысл заключается в том, что мы имеем конечный набор тестируемых операций, и так как конфигурации определены заранее, можем говорить о конечном наборе тестов, которые необходимо выполнить, что бы проверить работоспособность серверного функционала системы. Итог — 30 тестов на серверной стороне. Заметим, что в данном примере мы не затрагиваем нагрузочную составляющую тестирования: речь идёт только о функциональном тестировании.
Зависимости от артефактов проекта
Более интересным с точки зрение разработки стратегии тестирования в данном примере, будет фактор развития системы в целом: создание новых модулей в клиентском приложении или ввод в систему новых серверных агентов.
Что следует учитывать разрабатывая стратегию тестирования для сложных распределённых или клиент-серверных систем. Одним из основных факторов, влияющих на стратегию тестирования (после выделения тестовых областей и понимания тестовых задач в каждой из областей), является анализ план-графика появления новой функциональности в системе, а зачастую и плана разработки дизайнов и спецификаций к модулям и компонентам системы (от этого зависит выполнение задачи дизайна тестов). Чёткий план проекта, разбитый по задачам планирования, проектирования, дизайна и имплементации даёт менеджеру тестирования фундамент, необходимый для решения задачи, которую ставит вопрос «когда», то есть вопрос связанный с планированием тестирования. Хотя временные оценки и оценка трудоёмкости задачи логически выходят за рамки определения стратегии и относятся к непосредственному планированию тестирования, именно понимание приложения/системы в разрезе его развития с течением проекта, является стратегической составляющей плана тестирования.
Таким образом, разработка стратегии тестирования для небольших приложений и достаточно серьёзных систем схожа на стадии выделения тестовых областей и понимания зависимостей функциональности приложения от внешних модулей и компонентов. Различаться же стратегия в зависимости от типа тестируемого приложения, может в части понимания развития системы со временем, так как большие системы зачастую разрабатываются в несколько этапов и характеризуются большим по сравнению с десктоп-приложениями набором функционала, который требует перетестирования в каждой новой версии. Понимание что именно должно тестироваться, как, каким образом конкретный функционал будет тестироваться, что является результатом удовлетворяющим целям тестирования и есть зачастую результатом разработки Стратегии тестирования.
Выводы
Что в общем случае даёт разработка стратегии тестирования? Разбор задачи тестирования на составляющие, выделение тестовых областей и в конечном итоге более полное понимание задачи тестирования в конкретном проекте. Как мы видели на примере тестирования инженерного калькулятора, понимание задачи позволяет разделять функциональность тестируемого приложения или системы на области, которые могут тестироваться автономно, что позволяет снизить (и порой достаточно существенно!) затраты на тестирование.
Вёрнёмся к определению понятия Стратегия: «общий план ведения работы, исходя из сложившейся действительности на данном этапе развития» — применимо к тестированию, стратегия есть понимание «что», «где» (на каком окружении) и «когда» будет тестироваться. Ответ на вопрос «как» нам может дать анализ требований к системе и дизайн тестов. Согласитесь, имея перед собой план развития системы и функционала, можно достаточно уверенно планировать задачи по тестированию, готовить необходимые данные и тестовые окружения. В любой момент времени, руководитель, полагаясь на стратегию, знает где он находится и куда двигается дальше. Планируя тестирование, руководитель отдела или ведущий тестировщик не начинает разбираться с системой, а занимается непосредственно планированием, выделением ресурсов и сроков на конкретные задачи.