Как написать тестовую стратегию

Как составить стратегию тестирования: версия настоящих инженеров

Без стратегии тестирования можно наверняка обойтись, если есть бесконечное количество квалифицированных сотрудников, времени и денег. Словом, возможность пилить один релиз годами. В таких гипотетических идеальных условиях никакая стратегия не нужна, потому что вы можете тестировать ваш продукт всеми существующими способами как угодно долго, применяя техники в любом порядке, на несколько кругов, и рано или поздно каким-то путем вы придете к production ready качеству.

В реальности же у проекта всегда подгорает дедлайн, трудоспособность/скиллы команды не резиновые, а требования к продукту постоянно эволюционируют – и вот тут без хорошего плана никак нельзя. Поэтому на помощь приходит стратегия тестирования.

В этой статье мы предложим вопросы, которые надо обсудить для составления стратегии тестирования, и покажем на примерах, как принимаются решения об инструментах тестирования в том или ином случае.

0. Разберемся на берегу

Зачем нужна стратегия тестирования?

• Для организации процесса в условиях ограниченных ресурсов. Поэтому для начала неплохо бы осознать, какими ресурсами мы располагаем.
• Для того, чтобы все участники проекта понимали роль тестирования, что оно может дать, какие профиты мы с этого получим. Чтобы у всех были равные ожидания и понимание, что вообще происходит в области контроля качества. А также для выявления возможных проблем, которые неизбежно станут очевидными в процессе обсуждения.

Кто составляет стратегию?

В первую очередь, конечно же, QA и обязательно менеджер проекта.

Итак, берите за руку менеджер проекта тестировщика или тестировщик – менеджера, наливайте кофе, берите бумагу, маркеры, ноуты, и… поехали!

1. Какие типы тестирования будем применять на проекте и почему

В самом начале предлагаем вспомнить все существующие типы тестирования и принять решение по каждому: будем ли его применять и почему. Рассмотрим на некоторых примерах, как можно принять решение о необходимости конкретного типа тестирования.

Тестирование установки версии

В любом случае, даже если приложение совсем новое и ставится (деплоится) впервые, нужно проверить, как оно взлетело: запускается ли, можно ли начать с ним работать. Будь то мобильное приложение, десктопное или веб.

Для веб-приложений полезно обсудить, как мы проверим, что данные после обновления не потерялись. Какого поведения мы ожидаем от активной сессии.

Для десктоп и мобильных приложений надо подумать способ доставки нового дистрибутива до пользователя и процесс обновления, который запускается самим пользователем.

Для всех проектов полезно обсудить такие вещи, как прогрев системы: установка справочников, заведение пользователей и другие данные, которые нужны пользователю, чтобы начать работу с системой.

Тестирование производительности

На решение будут влиять такие факторы: сколько пользователей будет работать в системе, какой объем данных будет обрабатываться.

Дано	Решение
Мы знаем, что продуктом будет пользоваться 10 человек. И знаем, что они будут ворочать таблицами по несколько тысяч записей.	Имеет смысл запланировать volume-тестирование с большими объёмами данных.
Мы знаем, что в процессе использования продукта пользователи будут загружать много медиафайлов на сервер заказчика.	Необходимо выяснить, на какую нагрузку рассчитан этот сервер, и иметь эти данные в виду.
Приложением пользуется несколько человек в неделю, объём данных минимален.	Тестирования производительности не требуется.

Регрессионное тестирование

На полную проверку всей системы всегда уходит очень много времени. Поэтому для принятия решения надо оценить целесообразность: сколько времени требуется на полный регресс, и риски, которые могут случиться, если его проводить не будем.

Дано	Решение
Выкатываем первую версию продукта или модуля программы.	Регрессионное тестирование не требуется.
Проект очень большой, и на проведение полного регресса перед релизом новых фич требуется время, сопоставимое со сроком разработки. Требуемый темп поставок этого не позволяет.	Решаем, что регрессионное тестирование не проводим, а больше внимания уделяем другим видам тестирования и мониторингу.
Взаимодействие между микросервисами покрыто контракт-тестами.	Проведение полного регресса нецелесообразно. В рамках ручного тестирования проводим регресс функциональности по рекомендации разработчика.

Интеграционное тестирование

Для определения необходимости интеграционного тестирования полезно перечислить все внешние системы, с которыми взаимодействует продукт, и указать, какие именно данные мы получаем и передаём.

Дано	Решение
Данные по продажам из портала передаются в аналитическую систему.	Важно не только проверить, что продажи ушли, ушли в корректном формате, но и то, что пришли в корректном формате — ничего не потерялось по дороге.

Тестирование локализации

Здесь важно ответить на вопросы о проекте:

• какие языки должны поддерживаться,
• предусматриваем ли подключение дополнительных локализаций в процессе эксплуатации решения,
• в каких странах будут работать наши пользователи,
• будут ли происходить продажи и в каких валютах,
• требуется ли работа с часовыми поясами.

Дано	Решение
В системе предусмотрено 2 языка: русский и английский.	Имеет смысл обсудить, каким образом мы будем понимать, интерфейс на каком языке показывать пользователю.
Заказчик просит сделать приложение мультиязычным.	Стоит ответить себе на вопросы, каким образом будем верифицировать тексты, откуда мы возьмём тексты на арабском, как будет адаптирован экран для текста, который пишется справа налево.

Кроссбраузерность и кроссплатформенность

Мы не можем проверить корректность работы мобильного приложения на вообще всех девайсах. В случае с веб-приложением сразу возникает вопрос: а IE9 будем поддерживать? Перед тем, как вписать этот вид тестирования в стратегию, анализируем (если решение уже работает) или предполагаем (если еще не работает), на чём им будут пользоваться.

Дано	Решение
Пользователями мобильного приложения являются сотрудники по всей стране.	Смотрим существующую статистику использования платформ нашего приложения и принимаем решение, на каких из них будем тестировать.
У нашего приложения корпоративные пользователи на стационарных машинах.	Скорее всего, мы сможем порекомендовать использование только одного браузера. И тем самым сократим время на тестирование и поддержку кроссбраузерности.

Подобным образом необходимо разобрать все остальные типы тестирования:

• Функциональное (проводим или нет),
• Приёмочное (кто его проводит и каким образом),
• UX/UI (каковы объективные критерии хорошего интерфейса)
• Модульное и юнит (кто пишет контракт-тесты, кто пишет юнит-тесты и пишем ли их вообще),
• Тестирование безопасности (кто гарантирует безопасность данных, и насколько система устойчива ко взлому),
• Отказ и восстановление (как поведет себя система в экстренных обстоятельствах)

и другие.

2. Приоритеты в тестировании

На всех проектах случаются форс-мажоры, поэтому на такой случай полезно иметь шпаргалку с заранее продуманным планом, а не хвататься за случайные кнопки.

В штатном режиме осмысленные приоритеты также важны. Например, разработку автотестов стоит планировать с учетом приоритетов: в первую очередь автоматизируется проверка наиболее критичных сценариев (smoke-тестирование).

Дано	Решение
Нашей программой пользуются в аэропортах для продажи услуг пассажирам при посадке в самолет. И если в этот момент случится какая-то ошибка, то у нас не будет времени на хот-фикс. Поэтому ошибок быть не должно!	Проверяем сценарий использования в аэропорту в первую очередь.

3. Окружения для работы

Необходимо продумать и согласовать с командой, какие окружения требуются для работы, и кто ими будет пользоваться. Как правило, достаточно 2-3 окружений и прода.

Дано	Решение
На проекте CD/CI, написаны smoke-автотесты для первичной проверки функциональности.	Нужно окружение для первичной сборки кода в одной ветке, прогона smoke-тестов, где внешние системы закрыты заглушками. Также нужно окружение для ручного и интеграционного тестирования с сервисами заказчика (QA).
Регулярно проводятся сессии бета-тестирования.	Нужно окружение, которое будет видно «снаружи», более стабильное, чем QA-окружение.

4. Работы тестировщика на проекте

Имеет смысл заранее обсудить все активности, которых мы ждём от тестировщика на проекте, потому что они не обязательно одни и те же на всех проектах. Для кого-то в команде может стать сюрпризом, что тестировщик что-то делает или чего-то не делает.

Этот пункт поможет менеджерам понимать, какая степень компетенции требуется от тестировщика, и какая нагрузка по времени ожидается. Для существующих проектов также важно указать, что мы (QA) умеем, чтобы менеджер понимал, какими средствами он располагает.

Например, это могут быть:

• оценка задач спринта на полноту и непротиворечивость,
• оценка трудозатрат на тестирование,
• подготовка чек-листов для тестирования (или тест-кейсов),
• ревью сценариев автотестов,
• написание функциональных автотестов,
• непосредственно ручное тестирование,
• деплой изменений на окружения,
• актуализации стратегии тестирования и т.д.

5. Тестовая документация на проекте

Нужно договориться на берегу, а возможно, дальше и регулярно пересматривать формат ведения тестовой документации:

• какую тестовую документацию будем вести на проекте,
• будем ли писать тест-кейсы,
• ведем ли чек-листы
• и как часто обновлять эту документацию.

Дано	Решение
Для примерно трети функциональности системы уже написано порядка 300 тест-кейсов. Их надо не только периодически проходить, но и время от времени актуализировать.	В условиях ограниченных ресурсов мы решили не работать с тест-кейсами, а ограничиться чек-листами для каждой конкретной задачи. И в результате экономим время на поддержку документации без потери качества тестирования.

6. Каким образом генерируются тестовые сценарии

Условия и сценарии эксплуатации зависят от конкретного решения, поэтому обязательно нужно обсудить:

• какими техниками тест-дизайна имеет смысл пользоваться. В рамках этого пункта полезно составить список объектов, с которыми работает приложение, и их классы эквивалентности.
• какие эвристики и банальный жизненный опыт помогают придумать сценарии тестирования для конкретного проекта. Для мобильных приложений удобно использовать стандартные эвристики, например, “I SLICED UP FUN”.

Дано	Решение
На страховом проекте пользователь (агент) должен провести осмотр машины, в процессе которого необходимо сделать фотографии и загрузить их на сервер. Здравый смысл подсказывает, что в гаражах вряд ли есть wifi. А порой, там нет и мобильной связи.	Значит, надо проверить приложение не только при работе с 3G, но и при отсутствии связи как таковой.
Любое действие пользователя в мобильном приложении авиакомпании — это часть некоего сценария. Например, нельзя выписать билет, не создав предварительно бронь.	Поэтому логично использовать технику «сценарии использования».

7. Порядок работы с трекером

В разных трекерах различаются возможности и типы задач. Исходя из возможностей трекера советуем договориться о том, кто и по какому принципу определяет приоритетность задач, в какой тип задач оформлять баги и таски.

Проговорите с командой ключевые моменты:

• Как мы будем отличать ошибки, найденные нами, от ошибок, найденными заказчиками (и надо ли нам их различать),
• Как оформлять доработки,
• Надо ли отличать доработки, которые мы придумали сами, от тех, которые попросил сделать заказчик. Каким образом?
• В какой статус ставить ошибку, если она не повторилась,
• Какой статус считать конечным.

Дано	Решение
Тестировщик создаёт bug. Разработчик не может его воспроизвести, переводит в статус rejected.	Тестировщик перепроверяет задачу и ставит статус Closed (конечный), если ошибка и правда ушла, либо уточняет описание и возвращает в New.
Заказчик ставит задачу на доработку. Разработчик понимает, что ему не хватает данных для реализации.	Разработчик переводит задачу в статус Feedback.

(Подробнее о способах описывать баги и userstory мы писали в этой статье).

8. Критерии начала и окончания тестирования

Если тестировщик в любой момент будет брать любую задачу — это не порядок, а хаос. Потому что задача может быть не готова. Или готова, но не вдеплоена. Или готова, вдеплоена, но зависит от других задач, которые ещё не готовы. В итоге, тестировщик тратит время и нервы на поиск и оформление ошибок, а на самом деле надо просто подождать. Поэтому договориваемся, в какой момент начинается и заканчивается зона ответственности QA над задачей.

На ранних этапах развития проекта готовность задачи/версии определяется на глаз.
С ростом самосознания мы понимаем, что нужны четкие критерии того, что задача/версия готова. Чтобы это решение было прозрачным для всех, а не «тестер попой чует, что всё норм». Например, в условиях настроенного CD мы считаем, что задача готова к тестированию, как только она вдеплоена на окружение QA и имеет статус Resolved.

Дано	Решение
На проекте поставлен процесс, что для каждой доработки составляется чек-лист для тестирования.	Считаем задачу проверенной, если мы прошли все пункты чек-листа.
На проекте ведется работа по спринтам.	Спринт считается готовым, если все доработки находятся в статусе Closed и нет ошибок с приоритетом Normal и выше.
На проекте составлен список функциональности по приоритетам.	Считаем, что версия готова к релизу, если успешно работает функциональность из первых пунктов списка.
На проекте написаны тест-кейсы и проводится регресионное тестирование перед релизом.	Версия считается готовой к релизу, если по итогам регресионного тестирования не было найдено ошибок с приоритетом Normal и выше (либо процент неудачных сценариев не выше 5).

9. Инструменты для работы

Раздел полезен затем, чтобы уже на этапе планирования тестирования поставить задачи ответственным (админу и менеджеру) и к началу работ получить все необходимые инструменты.

Стоит обсудить такие вопросы:

• Какие инструменты нам нужны для ведения тестовой документации,
• Какими инструментами можно подготовить тестовые данные,
• Какие инструменты нужны для автоматизации.

Дано	Решение
Для описания реализованной функциональности решили использовать mind-maps.	Ребята в команде работают на разных платформах, поэтому нужно выбрать такой формат файла mind-map, с которым можно работать и в винде, и в линуксе, и на маке.
Мы договорились, что нам нужна автоматизация на проекте.	Значит, нам нужны инструменты, которые позволят подготавливать тестовые данные (например, накатывать скрипты на БД), позволят осуществлять запуск в рамках конвейера (например, newman), позволят создавать заглушки (например, WireMock).

10. Оценка качества проекта и инструменты мониторинга

В этом разделе предлагаем договориться о том, каковы KPI для оценки работоспособности приложения (помимо очевидного подсчета покрытия тестами). Этот показатель должен быть измеримым и достижимым. В частности, понять и ответить на следующем вопросы:

• Каким образом мы будем отслеживать ошибки в проде,
• Каким образом будем собирать обратную связь от пользователей,
• Каким образом будем собирать статистику использования наших фич.

Дано	Решение
После релиза новой фичи системы настраиваются мониторинги использования (например, количество продаж услуги).	Снижение показателей является триггером для расследования. Возможно, фича работает не так, как ожидалось, или мы не реализовали часть сценария.
Мы настроили в программе мониторинг скорости выполнения основных операций.	Критерием качества работы будет то, что при наплыве пользователей скорость выполнения не падает.

Заключение

Единой и универсальной стратегии тестирования, подходящей каждому, не существует. Её составляют индивидуально под каждый проект.

• Важно понимать, что стратегия не должна быть самоцелью — это лишь инструмент, который позволяет достичь наших целей.
• Вполне нормально, что не всегда сразу получается ответить на все поставленные вопросы. Это повод ещё раз поговорить с заказчиком или пользователями продукта.
• Проект растет, и если вчера заморачиваться с производительностью было рановато, то завтра возможно будет уже пора. Поэтому после составления стратегии важно её регулярно актуализировать и пополнять и доводить изменения до команды.
• После написания стратегии обычно становится понятно, где провалы в тестировании и что надо сделать. Это повод поставить задачи, смотреть динамику и… обновить стратегию через какое-то время.

The Test strategy document is a high-level document that outlines the testing technique used in the Software Development Life Cycle and confirms the test kinds or levels that will be performed on the product. One can’t change the test strategy once it’s been written, and it’s been accepted by the Project Manager and development team.

In addition, the test strategy provides the following details, which are required while writing the test document:

• What technique must be used in addition to this?
• Which of the modules will be examined?
• What criteria apply for entry and exit?
• What kind of testing is necessary?

To put it another way, it’s a document that explains the process of product evaluation. And the approaches can be developed using the following factors:

• Whether or not to automate
• From the standpoint of a resource

On the basis of the development design papers, we may write the test strategy.

The following documents are included in the development design document:

• Documents pertaining to the system design: These documents will mostly be used to build the test strategy.
• Design Documents: These are used to outline the software features that will be enabled in a future version.
• Documents relating to conceptual design: These are the documents that we don’t utilize very often.

Here, we will discuss the following points:

1. Components of Test Strategy.
2. Test Strategy vs Test Plan.
3. Types of Test Strategies.
4. Test Strategy Selection.
5. Details Included in Test Strategy Document.
6. Conclusion.

Components of a Test Strategy

The test effort, test domain, test setups, and test tools used to verify and validate a set of functions are all outlined in a Test Strategy. It also includes schedules, resource allocations, and employee utilization information. This data is essential for the test team (Test) to be as structured and efficient as possible. A Test Strategy differs from a Test Plan, which is a document that gathers and organizes test cases by functional areas and/or types of testing in a format that can be presented to other teams and/or customers. Both are critical components of the Quality Assurance process since they aid in communicating the breadth of the test method and ensuring test coverage while increasing the testing effort’s efficiency.

The following are the components of the test strategy:

1. Scope and Overview.
2. Testing Methodology.
3. Testing Environment Specifications.
4. Testing Tools.
5. Release Control.
6. Risk Analysis.
7. Review and Approvals.

Let’s discuss each of these in detail.

1. Scope and Overview: Scope and Overview is the first section of the test strategy paper. Any product’s overview includes information about who should approve, review, and use the document. The testing activities and phases that must be approved were also described in the test strategy paper.

• An overview of the project, as well as information on who should utilize this page. 
• Include information such as who will evaluate and approve the document. 
• Define the testing activities and phases that will be performed, as well as the timetables that will be followed in relation to the overall project timelines stated in the test plan.

2. Testing Methodology: Testing methodology is the next module in the test strategy document, and it is used to specify the degrees of testing, testing procedures, roles, and duties of all team members. The change management process, which includes the modification request submission, pattern to be utilized, and activity to manage the request, is also included in the testing strategy. Above all, if the test plan document is not properly established, it may result in future errors or blunders. This module is used to specify the following information-

• Define the testing process, testing level, roles, and duties of each team member.
• Describe why each test type is defined in the test plan (for example, unit, integration, system, regression, installation/uninstallation, usability, load, performance, and security testing) should be performed, as well as details such as when to begin, test owner, responsibilities, testing approach, and details of automation strategy and tool (if applicable).

3. Testing Environment Specifications: Testing Environment Specification is another section of the test strategy paper. The specification of the test data requirements, as we well know, is quite important. As a result, the testing environment specification in the test strategy document includes clear instructions on how to produce test data. This module contains information on the number of environments and the required setup. The strategies for backup and restoration are equally important.

• The information about the number of environments and the needed configuration for each environment should be included in the test environment setup. 
• For example, the functional test team might have one test environment and the UAT team might have another. 
• Define the number of users supported in each environment, as well as each user’s access roles and software and hardware requirements, such as the operating system, RAM, free disc space, and the number of systems. 
• It’s just as crucial to define the test data needs. 
• Give specific instructions on how to generate test data (either generate data or use production data by masking fields for privacy). 
• Define a backup and restoration strategy for test data. 
• Due to unhandled circumstances in the code, the test environment database may encounter issues. 
• The backup and restoration method should state who will take backups when backups should be taken, what should be included in backups, when the database should be restored, who will restore it, and what data masking procedures should be implemented if the database is restored.

4. Testing Tools: Testing tools are an important part of the test strategy document since it contains all of the information on the test management and automation tools that are required for test execution. The necessary approaches and tools for security, performance, and load testing are dictated by the details of the open-source or commercial tool and the number of users it can support.

• Define the tools for test management and automation that will be utilized to execute the tests. 
• Describe the test approach and tools needed for performance, load, and security testing. 
• Mention whether the product is open-source or commercial, as well as the number of individuals it can accommodate, and make suitable planning.

5. Release Control: Release Control is a crucial component of the test strategy document. It’s used to make sure that test execution and release management strategies are established in a systematic way. It specifies the following information-

• Different software versions in test and UAT environments can occur from unplanned release cycles. 
• All adjustments in that release will be tested using the release management strategy, which includes a proper version history. 
• Set up a build management process that answers questions like where the new build should be made available, where it should be deployed when to receive the new build, where to acquire the production build, who will give the go signal for the production release, and so on.

6. Risk Analysis: Risk Analysis is the next section of the test strategy paper. All potential hazards associated with the project are described in the test strategy document and can become an issue during test execution. Furthermore, a defined strategy is established for inclining these risks in order to ensure that they are carried out appropriately. If the development team is confronted with these hazards in real-time, we establish a contingency plan. Make a list of all the potential dangers. Provide a detailed plan to manage these risks, as well as a backup plan in case the hazards materialize.

7. Review and Approval: Review and Approval is the last section of the Testing strategy paper.

When all of the testing activities are stated in the test strategy document, it is evaluated by the persons that are involved, such as:

• System Administration Team.
• Project Management Team.
• Development Team.
• Business Team.

Starting the document with the right date, approver name, comment, and summary of the reviewed modifications should be followed.

It should also be evaluated and updated on a regular basis as the testing procedure improves.

Test Strategy vs Test Plan

Below are the differences between Test Strategy and Test Plan:

S No.	Test Strategy	Test Plan
1.	It’s developed from a set of software requirements (SRS).	It comes from a Business Requirement paper (BRS).
2.	The test lead or manager is in charge of preparing it.	The project manager or the business analyst creates it.
3.	The test plan’s components include the test plan’s id, features to be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables, responsibilities, and timetable, among others.	The components of a test strategy include objectives and scope, documentation formats, test processes, team reporting structure, client communication strategy, and so on.
4.	After the requirements have been approved, the test plan is written.	The test strategy comes first, followed by the test plan.
5.	The test plan should be simple and straightforward.	The test approach serves as a general guide for the project at hand.

Types of Test Strategies

The following are the different types of test strategies:

1. Analytical strategy: For instance, risk-based testing and requirements-based testing are two types of testing. After examining the test premise, such as risks or requirements, the testing team sets the testing circumstances to be covered. In the instance of requirements-based testing, the requirements are examined to determine the test circumstances. Then tests are created, implemented, and run to ensure that the requirements are met. Even the findings are kept track of in terms of requirements, such as those who were tested and passed, those that were tested but failed, those that were not fully tested, and so on.
2. Model-based strategy: The testing team selects an actual or anticipated circumstance and constructs a model for it, taking into account inputs, outputs, processes, and possible behavior. Models are also created based on existing software, technology, data speeds, infrastructure, and other factors. Let’s look at a case where you’re testing a mobile app. Models to simulate outgoing and receiving traffic on a mobile network, the number of active/inactive users, predicted growth, and other factors may be constructed to conduct performance testing.
3. Methodical strategy: In this case, test teams adhere to a quality standard (such as ISO25000), checklists, or just a set of test circumstances. Specific types of testing (such as security) and application domains may have standard checklists. For example, while performing maintenance testing, a checklist describing relevant functions, their properties, and so on is sufficient.
4. Standards or process compliant strategy: This method is well-exemplified by medical systems that adhere to US Food and Drug Administration (FDA) guidelines. The testers follow the methods or recommendations established by the standards committee or a panel of enterprise specialists to determine test conditions, identify test cases, and assemble the testing team. In the case of an Agile program, testers will create a complete test strategy for each user story, starting with establishing test criteria, developing test cases, conducting tests, reporting status, and so on.
5. Reactive strategy: Only when the real program is released are tests devised and implemented. As a result, testing is based on faults discovered in the real system. Consider the following scenario: you’re conducting exploratory testing. Test charters are created based on the features and functionalities that already exist. The outcomes of the testing by testers are used to update these test charters. Agile development initiatives can also benefit from exploratory testing.
6. Consultative strategy: In the same way, that user-directed testing uses input from key stakeholders to set the scope of test conditions, this testing technique does as well. Let’s consider a scenario in which the browser compatibility of any web-based application is being evaluated. In this section, the app’s owner would provide a list of browsers and their versions in order of preference. They may also include a list of connection types, operating systems, anti-malware software, and other requirements for the program to be tested against. Depending on the priority of the items in the provided lists, the testers can use various strategies such as pairwise or equivalence splitting.
7. Regression averse strategy: In this case, the testing procedures are aimed at lowering the risk of regression for both functional and non-functional product aspects. Using the web application as an example, if the program needs to be tested for regression issues, the testing team can design test automation for both common and unusual use cases. They can also employ GUI-based automation tools to conduct tests every time the application is updated. Any of the strategies outlined above does not have to be used for any testing job. Two or more strategies may be integrated depending on the needs of the product and the organization.

Test Strategy Selection

The following factors may influence the test approach selection:

• The test strategy chosen is determined by the nature and size of the organization.
• One can choose a test strategy based on the project needs; for example, safety and security applications necessitate a more rigorous technique.
• The test strategy can be chosen based on the product development model.
• Is this a short-term or long-term strategy?
• Organization type and size.
• Project requirements — Safety and security applications necessitate a well-thought-out strategy.
• Product development model.

Details Included in Test Strategy Document

The test strategy document includes the following important details:

• Overview and Scope.
• Software and testing work products that can be reused.
• Details about the various test levels, their relationships, and the technique for integrating the various test levels.
• Techniques for testing the environment.
• Level of testing automation.
• Various testing tools.
• Risk Assessment.
• For each level of the test Conditions for both entry and exit.
• Reports on test results.
• Each test’s degree of independence.
• During testing, metrics and measurements will be analyzed.
• Regression and confirmation testing.
• Taking care of discovered flaws.
• Configuring and managing test tools and infrastructure.
• Members of the Test team’s roles and responsibilities.

Conclusion

The test strategy document presents a bright vision of what the test team will do for the entire project. Because the test strategy document will drive the entire team, only individuals with extensive experience in the product area should prepare. Because it is a static document, it cannot be edited or changed throughout the project life cycle. The Test strategy document can be sent to the complete testing team before any testing operations begin. If the test strategy document is properly created, it will result in the development of a high-quality system and the expansion of the entire testing process.

The Test strategy document is a high-level document that outlines the testing technique used in the Software Development Life Cycle and confirms the test kinds or levels that will be performed on the product. One can’t change the test strategy once it’s been written, and it’s been accepted by the Project Manager and development team.

In addition, the test strategy provides the following details, which are required while writing the test document:

• What technique must be used in addition to this?
• Which of the modules will be examined?
• What criteria apply for entry and exit?
• What kind of testing is necessary?

To put it another way, it’s a document that explains the process of product evaluation. And the approaches can be developed using the following factors:

• Whether or not to automate
• From the standpoint of a resource

On the basis of the development design papers, we may write the test strategy.

The following documents are included in the development design document:

• Documents pertaining to the system design: These documents will mostly be used to build the test strategy.
• Design Documents: These are used to outline the software features that will be enabled in a future version.
• Documents relating to conceptual design: These are the documents that we don’t utilize very often.

Here, we will discuss the following points:

1. Components of Test Strategy.
2. Test Strategy vs Test Plan.
3. Types of Test Strategies.
4. Test Strategy Selection.
5. Details Included in Test Strategy Document.
6. Conclusion.

Components of a Test Strategy

The test effort, test domain, test setups, and test tools used to verify and validate a set of functions are all outlined in a Test Strategy. It also includes schedules, resource allocations, and employee utilization information. This data is essential for the test team (Test) to be as structured and efficient as possible. A Test Strategy differs from a Test Plan, which is a document that gathers and organizes test cases by functional areas and/or types of testing in a format that can be presented to other teams and/or customers. Both are critical components of the Quality Assurance process since they aid in communicating the breadth of the test method and ensuring test coverage while increasing the testing effort’s efficiency.

The following are the components of the test strategy:

1. Scope and Overview.
2. Testing Methodology.
3. Testing Environment Specifications.
4. Testing Tools.
5. Release Control.
6. Risk Analysis.
7. Review and Approvals.

Let’s discuss each of these in detail.

1. Scope and Overview: Scope and Overview is the first section of the test strategy paper. Any product’s overview includes information about who should approve, review, and use the document. The testing activities and phases that must be approved were also described in the test strategy paper.

• An overview of the project, as well as information on who should utilize this page. 
• Include information such as who will evaluate and approve the document. 
• Define the testing activities and phases that will be performed, as well as the timetables that will be followed in relation to the overall project timelines stated in the test plan.

2. Testing Methodology: Testing methodology is the next module in the test strategy document, and it is used to specify the degrees of testing, testing procedures, roles, and duties of all team members. The change management process, which includes the modification request submission, pattern to be utilized, and activity to manage the request, is also included in the testing strategy. Above all, if the test plan document is not properly established, it may result in future errors or blunders. This module is used to specify the following information-

• Define the testing process, testing level, roles, and duties of each team member.
• Describe why each test type is defined in the test plan (for example, unit, integration, system, regression, installation/uninstallation, usability, load, performance, and security testing) should be performed, as well as details such as when to begin, test owner, responsibilities, testing approach, and details of automation strategy and tool (if applicable).

3. Testing Environment Specifications: Testing Environment Specification is another section of the test strategy paper. The specification of the test data requirements, as we well know, is quite important. As a result, the testing environment specification in the test strategy document includes clear instructions on how to produce test data. This module contains information on the number of environments and the required setup. The strategies for backup and restoration are equally important.

• The information about the number of environments and the needed configuration for each environment should be included in the test environment setup. 
• For example, the functional test team might have one test environment and the UAT team might have another. 
• Define the number of users supported in each environment, as well as each user’s access roles and software and hardware requirements, such as the operating system, RAM, free disc space, and the number of systems. 
• It’s just as crucial to define the test data needs. 
• Give specific instructions on how to generate test data (either generate data or use production data by masking fields for privacy). 
• Define a backup and restoration strategy for test data. 
• Due to unhandled circumstances in the code, the test environment database may encounter issues. 
• The backup and restoration method should state who will take backups when backups should be taken, what should be included in backups, when the database should be restored, who will restore it, and what data masking procedures should be implemented if the database is restored.

4. Testing Tools: Testing tools are an important part of the test strategy document since it contains all of the information on the test management and automation tools that are required for test execution. The necessary approaches and tools for security, performance, and load testing are dictated by the details of the open-source or commercial tool and the number of users it can support.

• Define the tools for test management and automation that will be utilized to execute the tests. 
• Describe the test approach and tools needed for performance, load, and security testing. 
• Mention whether the product is open-source or commercial, as well as the number of individuals it can accommodate, and make suitable planning.

5. Release Control: Release Control is a crucial component of the test strategy document. It’s used to make sure that test execution and release management strategies are established in a systematic way. It specifies the following information-

• Different software versions in test and UAT environments can occur from unplanned release cycles. 
• All adjustments in that release will be tested using the release management strategy, which includes a proper version history. 
• Set up a build management process that answers questions like where the new build should be made available, where it should be deployed when to receive the new build, where to acquire the production build, who will give the go signal for the production release, and so on.

6. Risk Analysis: Risk Analysis is the next section of the test strategy paper. All potential hazards associated with the project are described in the test strategy document and can become an issue during test execution. Furthermore, a defined strategy is established for inclining these risks in order to ensure that they are carried out appropriately. If the development team is confronted with these hazards in real-time, we establish a contingency plan. Make a list of all the potential dangers. Provide a detailed plan to manage these risks, as well as a backup plan in case the hazards materialize.

7. Review and Approval: Review and Approval is the last section of the Testing strategy paper.

When all of the testing activities are stated in the test strategy document, it is evaluated by the persons that are involved, such as:

• System Administration Team.
• Project Management Team.
• Development Team.
• Business Team.

Starting the document with the right date, approver name, comment, and summary of the reviewed modifications should be followed.

It should also be evaluated and updated on a regular basis as the testing procedure improves.

Test Strategy vs Test Plan

Below are the differences between Test Strategy and Test Plan:

S No.	Test Strategy	Test Plan
1.	It’s developed from a set of software requirements (SRS).	It comes from a Business Requirement paper (BRS).
2.	The test lead or manager is in charge of preparing it.	The project manager or the business analyst creates it.
3.	The test plan’s components include the test plan’s id, features to be tested, test techniques, testing tasks, features pass or fail criteria, test deliverables, responsibilities, and timetable, among others.	The components of a test strategy include objectives and scope, documentation formats, test processes, team reporting structure, client communication strategy, and so on.
4.	After the requirements have been approved, the test plan is written.	The test strategy comes first, followed by the test plan.
5.	The test plan should be simple and straightforward.	The test approach serves as a general guide for the project at hand.

Types of Test Strategies

The following are the different types of test strategies:

1. Analytical strategy: For instance, risk-based testing and requirements-based testing are two types of testing. After examining the test premise, such as risks or requirements, the testing team sets the testing circumstances to be covered. In the instance of requirements-based testing, the requirements are examined to determine the test circumstances. Then tests are created, implemented, and run to ensure that the requirements are met. Even the findings are kept track of in terms of requirements, such as those who were tested and passed, those that were tested but failed, those that were not fully tested, and so on.
2. Model-based strategy: The testing team selects an actual or anticipated circumstance and constructs a model for it, taking into account inputs, outputs, processes, and possible behavior. Models are also created based on existing software, technology, data speeds, infrastructure, and other factors. Let’s look at a case where you’re testing a mobile app. Models to simulate outgoing and receiving traffic on a mobile network, the number of active/inactive users, predicted growth, and other factors may be constructed to conduct performance testing.
3. Methodical strategy: In this case, test teams adhere to a quality standard (such as ISO25000), checklists, or just a set of test circumstances. Specific types of testing (such as security) and application domains may have standard checklists. For example, while performing maintenance testing, a checklist describing relevant functions, their properties, and so on is sufficient.
4. Standards or process compliant strategy: This method is well-exemplified by medical systems that adhere to US Food and Drug Administration (FDA) guidelines. The testers follow the methods or recommendations established by the standards committee or a panel of enterprise specialists to determine test conditions, identify test cases, and assemble the testing team. In the case of an Agile program, testers will create a complete test strategy for each user story, starting with establishing test criteria, developing test cases, conducting tests, reporting status, and so on.
5. Reactive strategy: Only when the real program is released are tests devised and implemented. As a result, testing is based on faults discovered in the real system. Consider the following scenario: you’re conducting exploratory testing. Test charters are created based on the features and functionalities that already exist. The outcomes of the testing by testers are used to update these test charters. Agile development initiatives can also benefit from exploratory testing.
6. Consultative strategy: In the same way, that user-directed testing uses input from key stakeholders to set the scope of test conditions, this testing technique does as well. Let’s consider a scenario in which the browser compatibility of any web-based application is being evaluated. In this section, the app’s owner would provide a list of browsers and their versions in order of preference. They may also include a list of connection types, operating systems, anti-malware software, and other requirements for the program to be tested against. Depending on the priority of the items in the provided lists, the testers can use various strategies such as pairwise or equivalence splitting.
7. Regression averse strategy: In this case, the testing procedures are aimed at lowering the risk of regression for both functional and non-functional product aspects. Using the web application as an example, if the program needs to be tested for regression issues, the testing team can design test automation for both common and unusual use cases. They can also employ GUI-based automation tools to conduct tests every time the application is updated. Any of the strategies outlined above does not have to be used for any testing job. Two or more strategies may be integrated depending on the needs of the product and the organization.

Test Strategy Selection

The following factors may influence the test approach selection:

• The test strategy chosen is determined by the nature and size of the organization.
• One can choose a test strategy based on the project needs; for example, safety and security applications necessitate a more rigorous technique.
• The test strategy can be chosen based on the product development model.
• Is this a short-term or long-term strategy?
• Organization type and size.
• Project requirements — Safety and security applications necessitate a well-thought-out strategy.
• Product development model.

Details Included in Test Strategy Document

The test strategy document includes the following important details:

• Overview and Scope.
• Software and testing work products that can be reused.
• Details about the various test levels, their relationships, and the technique for integrating the various test levels.
• Techniques for testing the environment.
• Level of testing automation.
• Various testing tools.
• Risk Assessment.
• For each level of the test Conditions for both entry and exit.
• Reports on test results.
• Each test’s degree of independence.
• During testing, metrics and measurements will be analyzed.
• Regression and confirmation testing.
• Taking care of discovered flaws.
• Configuring and managing test tools and infrastructure.
• Members of the Test team’s roles and responsibilities.

Conclusion

The test strategy document presents a bright vision of what the test team will do for the entire project. Because the test strategy document will drive the entire team, only individuals with extensive experience in the product area should prepare. Because it is a static document, it cannot be edited or changed throughout the project life cycle. The Test strategy document can be sent to the complete testing team before any testing operations begin. If the test strategy document is properly created, it will result in the development of a high-quality system and the expansion of the entire testing process.

Всем привет! Меня зовут Иван Чечиков, я QA-инженер в МТС Digital, работаю над проектом WASD.TV. В этой статье я моделирую стратегию тестирования для Agile/Scrum-проекта. Она может быть полезна небольшим командам, работающим по такой методологии. Стратегия проста, но не универсальна, вы можете дополнить ее на свое усмотрение.

Что же такое стратегия тестирования?

В моем понимании, стратегия тестирования – это набор практик и целей тестирования, применяемых на проекте. Стратегия помогает понять, где и как лучше использовать тестирование в жизненном цикле разработки ПО.

Почему Agile? На мой взгляд, эта методология востребована в компаниях разного размера за счет своей гибкости и архитектуры процессов: она позволяет качественно и быстро выпускать продукты на рынок. Это – заметный плюс Agile.

Жизненный цикл разработки ПО

Я покажу стратегию тестирования на примере гибкой модели разработки ПО (Agile). Вы можете использовать ее элементы для своей модели.

Этапы жизненного цикла разработки ПО

Гибкая модель разработки обычно состоит из 5 позиций (Планирование-> Разработка-> Тестирование-> Демонстрация-> Внедрение). Пункт Демонстрация я опущу в этой статье, поэтому рассмотрим такой цикл:

Планирование-> Разработка-> Тестирование-> Внедрение

Итак, пойдем по порядку:

Планирование

Представим, что команда работает n-недельными спринтами, каждый спринт ориентирован на конкретные пользовательские истории. В рамках планирования спринта происходят следующие процессы: заведение, проработка задач и историй, определение приоритетов и серьезности задач, их оценка. В итоге задачи формируют релизы, которые добавляются в спринт и определяют его цель.

QA-инженер после этого этапа уже может начинать создавать тест-кейсы/чек-листы к задачам. В процессе необходимо опираться на функциональные требования, это станет хорошей практикой. Инструменты в этом случае – баг-трекер и система для создания тестов. Критерии успеха – верно сформулированные требования к задаче и созданная тестовая документация. Если у команды есть QA Automation-инженер, то на этапе планирования спринта он может заводить задачи для покрытия автотестами нового критически важного функционала.

Разработка

Получив задачу в работу, разработчик пишет код, коммитит изменения и пушит ветку в систему управления версиями. Согласно одному из семи принципов тестирования, тестирование должно начинаться как можно раньше (раннее тестирование экономит время и деньги). В этом случае хорошей практикой тестирования станет использования юнит- и интеграционных тестов.

Юнит-тесты – это модульные или компонентные тесты, направленные на проверку отдельных модулей системы. Модульные тесты пишут разработчики.

• Разработчик во время работы над задачей должен покрывать новый код юнит-тестами.

• Перед отправкой задачи на ревью ветка разработчика должна проверяться юнит-тестами с запуском их в CI/CD-инструменте.

• В случае успешного прохождения тестов, merge request одобряется для ревью.

• Для контроля этого этапа в системе управления версиями кнопка merge должна быть disabled в случае отсутствия запуска юнит-тестов или же их неудачного прохождения.

Интеграционные тесты – это тестирование всех объединенных модулей (компонентов) системы, в результате которого они собираются вместе. После этого модули проверяются на отсутствие ошибок в коде. Интеграционное тестирование должно выполняться после модульного c помощью CI/CD-инструмента.

• Разработчик пушит ветку в систему управления версиями.

• Разработчик запускает модульные тесты.

• Ветка билдится в компилируемый код, содержащий все модули.

• Запускаются интеграционные тесты.

• В результате создан pipeline с результатом выполнения тестов.

Тестирование

Нужно определить уровни тестирования, которые могут использоваться в проекте. Обычно это:

• Модульное или компонентное тестирование.

• Интеграционное тестирование.

• Системное тестирование.

Виды тестирования, которые могут использоваться в проекте:

• Функциональное.

• Нефункциональное.

• Тестирование по доступу к коду (белый/черный ящик).

• Тестирование с изменениями.

• Исследовательское тестирование.

Следовательно, мы должны построить пирамиду тестирования, где первым и вторым этапами будут тесты разработчиков (модульные и интеграционные), а завершающим – ручное тестирование и автоматизированные end-to-end-тесты (тестирование с изменениями) в рамках системного тестирования, запускаемые QA-инженерами. 

Ручное тестирование

Когда задача попала на тестирование, QA-инженер берет ее на выполнение в зависимости от приоритета и создает тест-кейс/чек-лист, если тестовой документации к задаче нет. В зависимости от описания в задаче применяется функциональное/нефункциональное тестирование, тестирование по доступу к коду. При составлении тестовой документации QA-инженер должен использовать подходящие техники тест-дизайна. QA-инженер проверяет задачу и, в случае отсутствия ошибок, подготавливает релиз к регрессионному тестированию. Или же возвращает разработчику на доработку, заведя соответствующий баг.

Исследовательское тестирование

Исследовательское или ad-hoc тестирование – это тестирование в свободной форме, направленное на поиск багов, когда QA-инженер применяет интуитивный подход или накопленные знания о продукте.

Когда QA-инженер не загружен задачами, он может проводить исследовательское тестирование системы. Успех здесь – нахождение багов с последующим заведением задач в баг-трекере.

Нагрузочное тестирование

Нагрузочное тестирование обычно делится на:

• тестирование производительности, то есть времени откликов запросов системы.

• тестирование стабильности – проверка системы при оптимальной нагрузке длительное время.

• стресс-тестирование – испытание системы под максимальной нагрузкой с достижением падения/отказа.

Такое тестирование нужно выполнять при релизе нового/измененного компонента системы, требующего проверки на производительность, масштабируемость, отказоустойчивость, наличие узких мест в коде, утечек памяти, уязвимостей конфигурационной настройки железа. Нагрузочное тестирование необходимо проводить на удаленной машине в тестовой инфраструктуре, с использованием сценариев в соответствующей программе (Jmeter, Яндекс.Танк).

End-To-End тесты (регрессионное тестирование)

E2E-тесты – автоматизируемые тесты, проверяющие тестовый сценарий от начала до конца. Могут быть как и API, так и UI-тесты.

В команде E2E-тесты должен писать QA Automation-инженер. Приступать к работе лучше сразу после планирования, а релизить задачи – вместе или после релизов продукта.

QA Automation-инженер берет задачу в работу в зависимости от ее приоритета. Написав автотест, QA Automation-инженер должен прогнать свой код с помощью CI/CD-инструмента вместе с остальными тестами затронутого модуля. Далее инженер отправляет задачу на ревью. В случае наличия замечаний код исправляют, тесты повторно прогоняются с помощью CI/CD, код еще раз проверяется и мерджится в мастер ответственным лицом.

E2E-тесты или регресс запускаются на завершающей стадии тестирования, перед выпуском релиза в прод, когда ручное тестирование уже было проведено. Регрессионные тесты лучше проводить через CI/CD-инструмент. Критерий успеха – прохождение всех тестовых сценариев.

Внедрение

Внедрение или деплой – завершающая стадия жизненного цикла ПО, обычно выполняется ответственными лицами. Схема такая – ветка в системе управления версиями, содержащая задачи релиза, мерджится в ветку прода, QA-инженер проверяет логи после деплоя, по возможности проводит функциональное тестирование на проде, а заинтересованные лица получают итоговый результат. В случае успеха релиз и все входящие в него задачи переводятся в статус «готово». Если обнаружены блокирующие или критические задачи – релиз откатывается через систему управления версиями. Внедрение завершено.

Вот и все! Таким образом можно составить стратегию тестирования для Agile/Scrum-проекта. Она, конечно же, не универсальна и не объемна, ее можно дополнить процессами и практиками. Они могут уже быть в вашем проекте или появиться там со временем, но базово я вижу стратегию такой. 

Спасибо за уделенное время, если у вас есть вопросы – буду рад на них ответить в комментариях.

Стратегия тестирования — это статический документ высокого уровня, обычно разрабатываемый менеджером проекта. Это документ, который отражает подход к тестированию продукта и достижению целей, и дает четкое представление о том, что команда тестирования будет делать для всего проекта. Обычно он выводится из Спецификации бизнес-требований (BRS). Как только стратегия тестирования готова, группа тестирования начинает писать подробный план тестирования и продолжает дальнейшие этапы тестирования. В мире Agile некоторые компании не тратят время на подготовку плана тестирования из-за минимального времени для каждого выпуска, но они поддерживают документ стратегии тестирования. Это один из важных документов в test deliverables, которым команда тестирования делится с заинтересованными сторонами для лучшего понимания объема проекта, рисков, подходов к тестированию и других важных аспектов.

Артем Безручко — QA Engineer в Depositphotos. В тестировании он уже 5 лет, занимается как автоматизацией, так и ручным тестированием. Как Артем пишет в своей статье на DOU.UA, ему давно хотелось вынести тему тестовой стратегии на суд широкой публики. В основу его текста легли методы и активности, используемые тестировщиками его команды. Материал будет полезен для представителей всех технических направлений, особенно для лидов и тех, кто пока лишь задумывается о том, как построить процесс тестирования в продуктовой компании.

Мы живем в такое время, когда об автоматизации как инструменте упоминается настолько часто, что все остальные темы кажутся недосказанными. Очень много говорится о технологиях и новшествах, но очень мало о том, как их применять, грамотно решая возникающие проблемы.

Мне очень нравится подход Майкла Болтона. Он утверждает, что есть проверки, а есть тестирование. Автоматизация выполняет проверки и получает бинарный результат, а тестирование — это процесс, позволяющий получить развёрнутую информацию о продукте. Многие инженеры пытаются завести у себя на проектах автотесты, не совсем понимая, зачем они им. Большинство тестировщиков стремятся уйти в автоматизацию не из-за пользы для текущего проекта, а просто потому, что модно. И это проблема. Рассмотрим же, что такое тестовая стратегия и как такой подход поможет проекту.

Cтатья основана на моём докладе на online-конференции QA fwdays’20.

Стратегия тестирования: что это и чем она отличается от тест-плана

О тест-плане слышали все, многие даже писали его. Документ отвечает на основные вопросы: что, кто, когда и как тестирует? Он хорош и достаточно практичен, но только для проектов, имеющих конкретные объемы разработки, поскольку количество реализуемого функционала остается более или менее понятным до окончания построения финальной системы.

Но реальность иная. Большинство из нас работает в компаниях, поддерживающих и развивающих долгоиграющие проекты, и никто не в состоянии досконально описать все процессы. Даже если приблизиться к необходимой документальной базе, тут же возникнет сложность ее актуализации и поддержки так, чтобы она оставалась полезной для команды.

Тестовая стратегия как раз и описывает план подхода к тестированию в цикле разработки ПО. (Медленно и вдумчиво перечитайте предыдущее предложение). Разработка по гибкой методологии Scrum циклична. На основе этого принципа и будет строиться наша стратегия. Если провести аналогии с реальной жизнью, то тест-план — это подробная карта маршрута через территорию, а тестовая стратегия — компас, указывающий направление.

С терминами разобрались. Осталось понять, в чем беда скрама.

Waterfall никто не отменял, или Как мы докатились до Scrum

Все знают: вначале был Waterfall. Громоздкий, неповоротливый, длинный. С кучей документации и огромной инерционностью. И вот на смену ему пришел Scrum — легкий, гибкий и простой — в паре с Agile-манифестом, обещавшим разработке и бизнесу стратегию win-win. Берем спринты, нарезаем фичи и реализуем их за короткий промежуток времени. Потом следуют демо, ретро — и все по новой. На первый взгляд, гениально и просто. Но давайте остановимся на минутку и подумаем.

По Waterfall построено большинство вещей, кардинально изменивших нашу жизнь. Например, впервые отправили человека в космос и на Луну, используя именно каскадную модель разработки. Более того, серьезные медицинские проекты до сих пор применяют Waterfall. Может, он не так уж и плох?

Разберемся в предпосылках появления нового подхода в создании ПО. Agile был сформулирован людьми, которые занимались в основном коммерческой разработкой для компаний, выходящих на рынок, и предлагали свои решения широкому кругу пользователей.

Гибкие методологии были призваны устранить проблемы каскадной модели, такие как неповоротливость и инерционность. Была цель ускорить предоставление готовой продукции конечному потребителю.

Однако задача отказаться от документации и сохранения знаний не стояла. Именно с этой проблемой сталкиваются сейчас в большинстве случаев практически все молодые проекты, использующие гибкие подходы к разработке. Через полгода после запуска там уже черт ногу сломит в логике бизнеса и технической части. А если вдобавок сменится поколение инженеров, то у продукта возникнут дополнительные проблемы, которые новой команде невозможно предвидеть из-за образовавшегося информационного вакуума.

Теперь главный вопрос: как отдел тестирования помогает решать эти проблемы с помощью тестовой стратегии?

Рассмотрим лепестковую диаграмму, которая наглядно иллюстрирует, как наша команда чередует основные активности. Эту диаграмму я называю «шестеренкой тестирования»:

На окружности изображены шесть двухнедельных спринтов (приблизительно 3 месяца), каждый из которых условно разбит на 3 сектора: начало (1S — 1MS), середину (1MS — 1ME) и конец (1ME — 1E). Обозначены также уровни QA, QC, Testing и переходы между ними в разных временных рамках.

Из диаграммы следует, что основные задачи лежат в плоскости тестирования и контроля качества. И только один раз за все время отдел взлетает на уровень обеспечения качества, с вершины анализирует пройденный путь и пытается заглянуть за горизонт событий, в будущее.

Ремарка. В Украине границы между должностями и обязанностями QA, QC и Tester бессовестно размыты. Это вносит дополнительный хаос в и без того сложные процессы разработки. Если повезет, я напишу на эту тему отдельную статью.

У большинства команд бывают критические периоды, когда проблемы начинают сыпаться со всех сторон: баги пролазят на прод, тестовые окружения перестают быть стабильными и консистентными, количество flaky-тестов растет, спринты не закрываются. И ты вроде делаешь все, что надо, но результата не видно. В таком случае приходится принимать решение, как быть дальше: поменять компанию или проявить характер и вырваться из порочного круга. Мы остановились на последнем варианте. Наша команда на тот момент состояла из 11 человек: 2 Node.js разработчика, 1 Front-end, 5 PHP Back-end и 3 тестировщика.

Рассмотрим подробно, что именно мы делали для повышения вероятности успешного закрытия спринта и решения проблем.

Начало спринта

Типичная ситуация: после планирования разработчики перегружены задачами, а у тестировщиков, наоборот, дефицит работы. Самоевремя заложить фундамент качественного и эффективного тестирования на весь спринт. Вариантов несколько.

Пойти в разведку

Выбрать средние и большие задачи. Нацелиться на их анализ и тестирование требований. Что это значит? Для начала основательно вчитаться в описание. Сформировать личные тезисы и мнение по тикету. После этого пойти к разработчикам, которые реализуют задачи, (или написать им) и получить от них ответы на следующие вопросы:

1. Что будет реализовано в тикете?

Описание в таск-трекере могло остаться неизменным, но вектор задачи при этом мог измениться из-за нового видения ситуации или пожеланий бизнеса. Этот пункт позволяет нащупать единую точку отсчета и понимания — как для отдела разработки, так и для тестирования.

Пример: «Добавить на главную страницу новый баннер с недорогим платежным планом за $X,XX» — изначально поставленная задача. Но с момента ее создания изменилось видение, и Product Owner написал разработчику — в обход таск-трекера и всей команды, — что баннер нужно отображать только для Украины. Для девелопера это мелочь, всего одна строка в конфиге, а для остальной команды — неочевидные требования.

2. Зачем это делается? Какова бизнес-цель?

На характер и специфику дальнейшего тестирования очень сильно влияет истинная цель, ради которой и реализуется задача. Важно отметить, кто будет потребителем этой фичи: все пользователи, определенные группы пользователей, внутренние отделы компании, третий сервис или что-то другое.

3. Что будет задето этой задачей?

На первый взгляд, простой вопрос. Но ответ на него иногда вскрывает настолько неочевидные связи, что задавать его стоит в протокольном порядке. У нас был случай, когда при добавлении нового типа подписки переставала приходить рассылка, будучи соотнесенной с другими платежными планами. А в случае с баннером (см. пункт 1) была нарушена логика трекинга поведения пользователя.

Именно стандартизированный подход к подготовке тестирования помог обнаружить критическую проблему.

4. С какими сложностями есть вероятность столкнуться при тестировании и эмуляции?

Разработчик проанализирует сотни строк кода, прежде чем написать свои. А если он хороший инженер, то задумается еще и над тем, чтобы его творение было пригодно для тестирования. Задав подобный вопрос, вы сможете избавить себя от часов бессмысленных исследований.

Пример. Когда мы внедряли оплаты и подписки для мобильных приложений через Apple, было достаточно сложно тестировать граничные значения и интеграцию с основным проектом. Разработка сделала приятную схему на API с хорошо конфигурируемыми мок-объектами, что значительно облегчило жизнь тестировщикам.

5. Согласовать критерий качества приемки задачи

Один из удивительных законов Мерфи применительно к разработке ПО формулируется так: «Все, что может быть понято двояко, будет понято двояко». Именно поэтому у нас инженеры проговаривают основные пункты приемки фичи, чтобы исключить возможные разночтения. Очень важно, чтобы сотрудники находились в одном контексте и имели единую систему координат и точку отсчета при работе над задачей.

6. Есть ли у разработчика пожелания и советы по тестированию задачи?

Провокационный вопрос, призванный поднять в памяти коллеги весь проговоренный материал, чтобы случайно ничего не упустить.

7. Подготовить альфа-версию чек-листа.

Очень полезная активность. Все скрытые нюансы, граничные значения и сущности после основательной беседы с разработчиком находятся в оперативной памяти нашего мозга. Самое время освободить ее и запечатлеть в виде первой версии чек-листа. В нем необходимо отметить основные модули, связи и специфические условия — одним словом, все, что поможет любому инженеру моментально найти точки входа для быстрого развертывания процесса тестирования.

8. Проверить описание задачи в Jira и исправить или дополнить на основе полученной информации в вышеперечисленных пунктах

Задачи в таск-трекерах сделали людям огромное одолжение, освободив их от бумажной работы. Запомните: таск в Jira — это документ, значит, он должен быть полным и оформлен согласно стандартам. Никогда не пропускайте этот пункт и обновляйте описание тикетов, как только получаете новую информацию.

Закрыть долги

Если удастся полностью выполнить предыдущий пункт и еще остается свободное время, то мы переключаемся на документальные и организационные задачи.

1. Кейсы, не записанные в TestLink или другой тест-трекер

Всегда найдется сьют, который следовало бы проапдейтить, или функционал, для которого не созданы тест-кейсы.

2. Несозданные тикеты на автотесты

Мы пишем автотесты вдогонку выпускаемому функционалу. И если уж выдалась свободная минута, выгодно потратить ее на ревью кейсов, которые будут автоматизироваться, а также на анализ выпущенных фичей. Возможно, были пропущены важные сценарии или давно напрашивается рефакторинг.

3. Пропущенные статьи в Wiki

Документация условно делится на исполнительную и повествующую. Тест-кейсы относятся к первому типу, а создание страниц во внутренней Wiki — ко второму. Это полезная процедура, она помогает закрепить комплексные понятия о разделе, а в случае необходимости провести ликбез или быстро напомнить об упущенных деталях. Поэтому не стоит упускать возможность поработать с внутренней библиотекой.

4. R&D

Новые инструменты появляются постоянно, и сообщество предлагает большой выбор методов и подходов к работе. Где, как не в боевом окружении, их тестировать?

Середина спринта (тикеты непосредственно берутся в тестирование)

Рабочие дни идут, и вот таски планомерно заполняют столбик «Тестирование». Следующие действия качественно влияют на процесс, поэтому я настоятельно рекомендую именно такой порядок активностей.

Перед началом любых действий по задаче, которая требует тестирования, нужно перечитать описание и повторно переговорить с разработчиком (кратко). Цель — уточнить, одинаково ли все участники понимают задачу, а также убедиться, что ничего не изменилось, не встретились «подводные камни», которые внесли поправки.

Затем следует провести тест-дизайн, углубив анализ задачи на основе альфа-версии чек-листа, написанного ранее.

Бросаться на задачу с шашкой наголо и кромсать ее исследовательским тестированием — это похвально, но только после детальной проработки общего плана работ. Основные его пункты:

• разбить объект на модули и логические составляющие;
• обозначить связи с другими модулями системы;
• выделить smoke-набор для TestLink/Wiki.

Только получив сформированный обозримый объем для тестирования, можно приступать к работе. Если есть сомнения, попросите коллег по цеху сделать ревью чек-листа.

Любая деятельность ценна тем, что она что-то производит. Продукт тестирования => обратная связь по тикету. И чем быстрее она возвращается к разработчику, тем лучше. Но не стоит жертвовать полнотой информации, необходимо соблюдать баланс.

На техниках и подходах к ручному тестированию я останавливаться не буду. Надеюсь, все читатели прекрасно ими владеют.

Заведение отчетов об ошибках

Хочу обозначить два полезных момента:

1. Пред заведением бага стоит проверить его наличие в трекере, чтобы не плодить дублей.
2. После оформления саба надо сообщить разработчику. Не стоит рассчитывать, что он читает почту или правильно настроил нотификации.

Наконец все найденные баги исправлены и запланированные проверки пройдены. Тикет получил резолюцию тест-инженера. Но на этом процесс тестирования не заканчивается. Дальше идут рутинные, но очень полезные активности.

По завершении тестирования тикета остается выделить кейсы для автотестов, оформить кейсы в TestLink и завести статью в Wiki.

Конец спринта

Благодаря четкому выполнению всего вышеописанного в последние день-два нагрузка на отдел тестирования снижается, высвобождая время для анализа проделанной работы.

Назначенный человек оценивает работу в спринте по следующим пунктам:

1. С какими проблемами столкнулись, как их решали?
2. Что нового узнали о работе системы? Нужно ли это документировать?
3. Какие новые фичи зарелизены? Нужно ли закрывать их автотестами?
4. Формирование задач для отдела тестирования на основе предыдущих пунктов.

Активности над спринтами

В описанном выше режиме проходит неделя (спринт, месяц — подставим сюда любой временной отрезок). Гладкая и выверенная схема начинает сбоить. И это нормально, ибо нет ничего вечного. Самое время примерить роль QA в широком смысле этого слова.

На следующем планировании один человек из отдела тестирования берет на себя задачу под названием «Пересмотр тестовой стратегии».

Таск включает следующие разделы:

1. Анализ проделанной работы за квартал/полгода

Просматриваются задачи, анализируются их характер, специфика и направление. Какие фичи релизились, какие заморозились, какие проблемы были наиболее распространены? Что автоматизировано, какую документацию создавали, какая не пригодилась? Также уточняется вектор будущего развития продукта, возможно, перечень технологий, которые планируется внедрить. Основные цели:

1. Увидеть целостную картину работы команды и обозначить роль тестирования в ней.
2. Быть готовым к преобразованию проектов и команды, а также к другим изменениям.

2. А не глупости ли мы делаем?

Этот вопрос я задаю себе каждый раз, когда тестирую новый подход, инструмент или технику в работе и организации команды. Но на этот раз вопрос стоит глобально. Цель — найти активности, на которые тратится больше времени, чем они принесут пользы. У нас такими оказались тест-отчеты. Мы составляли их еженедельно, тезисно описывая неочевидные связи и возникшие проблемы. Времярасходовалось, а польза стремилась к нулю.

3. Сбор метрик по команде и проблемам

В этом пункте источником информации выступает таск-трекер. Собираем численные показатели:

1. Баги от пользователей, относящиеся к нашей команде.
2. Баги от пользователей, относящиеся ко всей компании.
3. Баги, найденные тестировщиками нашей команды.
4. Задачи, назначенные на отдел тестирования.
5. Задачи, выполненные отделом тестирования.

4. Укрепление положительных активностей

Этот пункт призван укоренить действия, которые нетипичны для специалистов нашей области, но оказались нам по силам и принесли ощутимый результат.

В нашем случае экстраполезной активностью оказалось ревью тикетов и баг-репортов. Было время, когда у нас менялись участники команды, и в конце концов оказалось, что у каждого свое понимание предметной области. Из-за этого возникало недопонимание и множество конфликтов. Наконец было принято решение проводить ревью задач и отчетов об ошибках сразу после их создания. За несколько недель это привело всю команду к единому стилю технического описания и единой базе дефиниций.

Вторая такая активность — создание расширения для Google Chrome, которое в пару кликов приводит тестового пользователя в состояние готовности к тестированию.

Обычно для создания предусловий требуется от 1 до 5 минут, а благодаря приложению это делается в 3-4 клика за 10 секунд. Вроде не так уж и много, но в течение дня это экономит от 30 минут до часа. При масштабировании на всех тестировщиков профит заметно ощутим.

5. Анализ сохраненных знаний, систематизация

Проводится вычитка созданных статей и тест-сьютов. Цель — выбросить ненужное и устаревшее, организовать полезное, создать задачи на документирование и исправление нужного.

6. Чего не хватает отделу тестирования в целом?

Этот пункт требует анализа грубых ошибок, допущенных сотрудниками. Зачастую они связаны с незнанием предметной области или неумением пользоваться выделенными инструментами.

Пример. Depositphotos использует много платежных систем для удобства пользователей по всему миру. Естественно, для Бразилии нужны одни провайдеры платежей, а для Канады — совсем другие. Налоги, которые платят пользователи в той или иной стране, записываются в отдельный налоговый сервис, а уже по нему компания предоставляет отчеты в соответствующие органы.

Так вот, при добавлении нового провайдера в Канаду после введения специального налога в провинции Квебек транзакции перестали попадать в сервис. Итог — приличный штраф для компании.

А оказалось, что тестировщик, проверявший эту функциональность, банально не знал нюансов налогообложения. Небольшого ликбеза было достаточно для предотвращения подобных ошибок в будущем.

7. Пересмотр тестовой стратегии

На основе полученных данных необходимо внести коррективы в изначальный процесс тестирования.

8. Проверка знаний команды, выделение личных векторов развития

Это небольшой опрос, который проводится среди сотрудников по основным технологиям и навыкам, необходимым для выполнения задач. Благодаря такой проверке легко понять уровень команды, а также определить, по каким ключевым параметрам в случае необходимости подбирать новый персонал или на какие курсы (воркшопы) направить действующих участников.

Результат применения тестовой стратегии

Что решает такой подход?

1. Теряется минимум знаний о работе системы.
2. Формализуются процессы и подходы. Снижается шанс любого сотрудника допустить ошибку.
3. Понижается порог входа для нового сотрудника.
4. Уменьшается bus-фактор.

Хочу привести графики, на которых показан период в один год. Все это время мы следовали описанной стратегии. Графики, быть может, не суперпрорывные и выглядят не слишком впечатляюще, но каждая цифра в них реальная.

Каждый 13-й баг находит пользователь (показатель >10 — хороший). Количество оформленных багов показывает тенденцию к уменьшению, а количество проблем пользователей стабильно. На основе этого можно предположить, что кастомеры находят проблемы спустя длительное время после релиза фичи. Уменьшение количества найденных багов говорит о том, что больше проблем выявляется на этапе анализа требований и более плотного взаимодействия разработки с тестированием. Ну, или это признак ухудшения работы команды тестирования.

Задачи, выполненные инженерами тестирования и назначенные на отдел

Тестировщики на одну задачу для себя дополнительно ставят еще две. Наблюдается тенденция к увеличению количества задач, выполняемых непосредственно инженерами. На основе этого предполагаю, что процесс тестирования эволюционирует, поскольку механизмы и решения создаются «под проект».

Все проблемы пользователей и баги, пропущенные в области ответственности команды

Каждый восьмой кастомер-баг относится к нашей команде. Общее число кастомер-проблем демонстрирует тенденцию к уменьшению, а проблемы, решение которых поручено команде, имеют постоянную характеристику. Это подтверждает, что кастомеры находят баги спустя длительный промежуток времени (ориентировочно полгода-год).

Выводы

Тестовая стратегия помогает в том случае, если вы имеете конкретную цель. В нашем кейсе целью было успешное закрытие спринтов, уменьшение количества багов, с которыми сталкиваются пользователи в продакшене, эффективное накопление и расшаривание знаний среди сотрудников. По каждому из этих пунктов мы достигли хороших результатов. Поэтому считаю, что затраты сил на разработку и внедрение стратегии того стоили.

Хочу дать несколько небольших советов тем, кто решит делать что-то подобное в своей команде.

Будьте последовательными

Каждую активность проверяйте, анализируйте и аргументируйте. Не нужно бездумно копировать сторонние подходы. Вы не знаете и никогда не узнаете всех нюансов, которые привели другие команды к их результатам.

Будьте системными

Системный подход — это отличная страховка в очень переменчивом мире. И когда совсем непонятно, что делать, следование изначальному плану помогает сориентироваться и выработать необходимое решение.

Будьте профессиональными

Все хотят работать с людьми, у которых есть чему поучиться, и очень ценят коллег, четко выполняющих свои обязанности. Зарабатывайте авторитет, и тогда вам будет легче вносить изменения в устоявшиеся процессы в своем окружении.