Без продуманной стратегии тестирования наверняка обойтись можно, особенно если в вашей команде представлено большое количество высокоспециализированных сотрудников, денежных средств и времени.
Другими словами, если выпускать веб-продукты исключительно раз в год и то по «большим праздникам.»
В таких идеальных условиях вам не потребуется никакая стратегия, ведь вы можете проверять работоспособность своего ПО месяцами, разными способами, используя доступные техники и стратегии в любом логическом порядке, хоть в несколько кругов, и рано или поздно вы придете к такому желанному качеству сборки — такому, которое можно выпускать.
В реальных же условиях, в процессе работы над проектом всегда возникают определенные трудности, проблемы, нехватка «умов», постоянно растущие требования – и вот без четко определенного плана работ уже никак не обойтись. Как раз решить эти проблемы может грамотно составленная с последующим внедрением стратегия тестирования.
Далее в статье мы постараемся рассмотреть все вопросы, которые так или иначе затрагивают процесс разработки эффективной стратегии тестирования, а также на примерах разберем, как правильно принимать решения касательно инструментов тестирования в той или иной ситуации.
Приступаем к разбору
Зачем вообще требуется какая-то там стратегия тестирования?
Ответ прост:
- Для эффективной организации процесса проверки работоспособности продукта в условиях ограниченных ресурсов. А значит, для начала неплохо было бы узнать, какие именно ресурсы представлены;
- Для того, чтобы каждый член проектной группы прекрасно понимал значение и роль тестирования, чего можно достичь с его помощью, а также, какие именно преимущества можно получить. Другими словами – чтобы каждый из участников проектной группы имел равные ожидания и понимание, что вообще твориться в сфере контроля качества. Ну и, конечно же, для быстрого выявления потенциальных проблем, которые неизбежно появятся в процессе сборки.
Кто должен составлять стратегию?
В первую очередь, конечно же, это работа тестировщика и менеджера конкретного проекта.
Типы тестирования: какие следует применять и зачем
Для начала давайте вспомним, какие вообще типы тестирования существуют и какие идеально подходят для той или иной ситуации. Лучше всего рассмотреть этот вопрос на конкретных примерах, где можно выяснить определенную закономерность использования определенного вида тестирования.
Проверка процесса установки
Несмотря на то, что приложение может быть очень новым и устанавливается впервые, нужно проверить, как оно начало работать: запускается ли, есть ли возможность взаимодействовать с ее запрограммированной логикой. Не имеет значения – мобильное это приложение, веб или десктопное.
Для веб-продукта важно проверить, не потерялись ли обновления после очередного запуска продукта. Какое поведение должно быть у продукта во время активной сессии.
Для мобильных и десктопных приложений необходимо проговорить вариации доставки нового дистрибутива к конечному пользователю, а также процесс обновления, который стартует сразу же после того, как клиент начал работать с инстументом.
Для всех без исключения видов проектов, очень полезно проговорить такие вещи, как прогрев системы: инсталлирование справочников, регистрация пользователей, и другие сведенья, которые необходимы клиенту, чтобы начать спокойно пользоваться продуктом.
Тестирование производительности
На окончательное решение по продукту будут влиять такие факторы: какое количество клиентов в потенциале сможет работать внутри системы, и какой объем данных будет номинально использоваться.
| Дано | Способ решения |
|---|---|
| У нас есть сведенья касательно того, что продуктом будет пользоваться не более 20 человек. Также мы осведомлены о том, что они будут постоянно оперировать таблицами с большим числом записей. | Важно провести объемное тестирование с большим количеством вводных данных. |
| У нас есть сведенья касательно того, что в процессе использования продукта, клиенты будут загружать медиа файлы на сервер. | Нужно определить, на какую максимальную загрузку рассчитан выбранный сервер, и держать эти цифры в уме. |
| Продуктом пользуется не более 3-4 человек в неделю. | Проводить тестирование производительности нет необходимости. |
Регрессионное тестирование
Чтобы проверить работоспособность всей системы, необходимо очень много времени. Значит, крайне важно будет оценить целесообразность: сколько времени уйдет на полный регресс, и какие могут быть риски, если регрессионное тестирование проводиться не будет.
| Дано | Способ решения |
|---|---|
| Запускаем первую версию продукта, или его составной части. | Необходимости в регрессионном тестировании нет. |
| Проект достаточно внушительный, и на проведение полного регрессионного тестирования потребуется такой же временной промежуток, как и на разработку продукта. Оговоренный срок поставок продукта к клиенту этого не предусматривает. | Регрессионное тестирование не проводим, но в обязательном порядке работаем над реализацией других видов контрольных проверок. |
| Вся структура микросервисов покрыта автоматизированными контракт-тестами. | Регрессионное тестирование – нецелесообразно. Лишь вручную проводим регресс функциональности, исключительно по рекомендации команды разработчиков. |
Интеграционное тестирование
Чтобы определить потенциальную необходимость определения интеграционного тестирования, крайне важно перечислить все внешние системы, которые так или иначе взаимодействуют с продуктом, и указать, какими именно данными мы оперируем и что передаем.
| Дано | Способ решения |
|---|---|
| Все данные по заказам передаются из портала внутрь аналитической системы. | Крайне важно проверить не только тот факт, что продажи «ушли» куда нужно, в нужной форме, но и то, что они «дошли» в адекватном виде – ничего не потерялось по дороге. |
Проверка локализации
В данном контексте нужно ответить на такие вопросы:
- Какие языки поддерживаются системой;
- Можно ли подключить вспомогательные локализации во время эксплуатации продукта;
- На какие страны в первую очередь предусмотрен разрабатываемый продукт;
- Есть ли необходимость взаимодействовать с разными часовыми поясами.
| Дано | Способ решения |
|---|---|
| Система веб-продукта предусматривает использование сразу двух языков: французского и русского. | Крайне важно обсудить с проект-менеджером, какой именно интерфейс и на каком языке должен видеть пользователь. |
| Клиент изъявил желание сделать продукт мультиязычным. | Нужно ответить на вопросы: как именно система будет верифицировать текстовые блоки, где взять блоки с арабским языком, под какие разрешения будет отформатирован текст, который традиционно пишется справа налево. |
Проверка кроссбраузерности и кроссплатформенности
У разработчиков в принципе нет реальной возможности проверить работу мобильного приложения на всех без исключения портативных устройствах.
В ситуации с десктопным приложением моментально возникает вопрос: будем ли мы проверять его в IE11?
Перед началом процесса проверки работоспособности приложения, детально анализируем, в каких операционных устройствах и браузерах оно будет чаще всего использоваться.
| Дано | Способ решения |
|---|---|
| Клиентами мобильного приложения в потенциале являются все жители страны. | Анализируем данные использования мобильных платформ для нашего продукта, и принимаем решения, на каких из них мы будем проверять его работоспособность. |
| Клиенты приложения – исключительно корпоративные сотрудники на локальных машинах. | Можно попробовать отрекомендовать использование исключительно одного браузера. Тем самым можно значительно сократить время на проверку инструмента на кроссбраузерность. |
Таким образом, необходимо прорабатывать все прочие виды тестирования:
- Регрессионное (выполнять или нет);
- Приёмочное;
- Критерии отличного интерфейса;
- Модульное тестирование;
- Тестирование производительности и безопасности;
- Отказ работоспобности системы и последующее ее восстановление (как продукт поведет себя при экстренных обстоятельствах).
Приоритеты проверки
Разработка любого продукта сопровождается определенными форс-мажорами, а значит, крайне полезно иметь под рукой «шпаргалку» с заранее продуманным планом, а не хаотично искать решение в технической документации смежных проектов.
В штатном режиме продуманные приоритеты также крайне важны. К примеру, создание группы автотестов необходимо планировать с учетом установленных приоритетов: для начала автоматизации поддается проверка наиболее критичных тестовых сценариев (подобный процесс также называется дымовым тестированием).
| Дано | Способ решения |
|---|---|
| Разрабатываемым продуктом пользуются в аэропортах во время посадки пассажиров на рейс. Если что-то сломается, у команды разработчиков не будет времени на срочное исправление этой ошибки. Значит, багов и критических ошибок быть не должно! | Выполняем проверку сценария использования системы в аэропорту в первую очередь. |
Среда для работы
Важно продумать и согласовать с каждым отделом команды разработчиков, какие окружения необходимы для работы, и кто именно будет ими пользоваться. Традиционно, можно ограничиться всего двумя-тремя окружениями и одним реальным окружением.
| Дано | Способ решения |
|---|---|
| В системе присутствуют CD/CI, созданы дымовые тесты для первоначальной проверки функциональности продукта. | Необходимо окружение для первоначальной сборки программного кода в одной ветке, прогона всего набора дымовых тестов, где все внешние системы закрыты так называемыми «заглушками». |
| Постоянно проводятся сессии бета-тестирования. | Необходимо окружение, которое можно увидеть «снаружи», которое будет более стабильнее, чем QA-среда. |
Задания тестировщика на проекте
Важно заранее обсудить все номинальные активности, которые должны быть выполнены со стороны тестировщика во время его работы на проекте, ведь подобные действия могут значительным образом отличатся друг от друга в зависимости от создаваемых продуктов.
Данный пункт позволит проект-менеджеру понять, какую степень компетенции можно возложить на тестировщика, и сколько времени ему необходимо для выполнения всех поставленных задач.
Так, со стороны команды тестировщиков можно узнать о таком:
- Временная оценка номинальных трудозадач для процесса тестирования;
- Создание группы функциональных автотестов;
- Актуализации стратегий тестирований;
- Выполнение ручного тестирования;
- Процесс проверки сценариев автоматических тестов.
Ведение тестовой документации на проекте
Еще перед началом работы над проектом важно договориться касательно формата документации, а затем, всего лишь пересматривать его:
- Какой именно вид документации будет использоваться на проекте;
- Актуальны ли тест-кейсы;
- Занимается ли команда тестировщиком чек-листами или нет;
- Как часто подобная документация будет обновляться.
| Дано | Способ решения |
|---|---|
| Для уже разработанного продукта создано порядка 300 новых тест-кейсов. Их более не нужно заново прогонять, а также актуализировать. | Откладываем тест-кейсы в сторону, предпочитая взаимодействовать с простыми чек-листами, которые создаются для выполнения определенной задачи. |
Для уже разработанного продукта создано порядка 300 новых тест-кейсов. Их более не нужно заново прогонять, а также актуализировать. Откладываем тест-кейсы в сторону, предпочитая взаимодействовать с простыми чек-листами, которые создаются для выполнения определенной задачи.
Критерии начала и завершения процесса тестирования
Если QA-инженер в любой момент будет переключаться на выполнение новой задачи – это не график, а самый настоящий хаос. Потому как данная задача может быть банально неготовой. Или готова, но еще не развернута. Как итог, тестировщик тратить свое время на поиск ошибок, а на самом деле он мог банально подождать окончательного завершения работ по данному функционалу.
С постоянным ростом многозадачности на проекте, необходимо оперировать четкими критериями того, что данная функция или система уже готова к проверке.
| Дано | Способ решения |
|---|---|
| На проекте соблюдается правило, согласно которому любая доработка или проверка должна находить свое отображение в чек-листе. | Задача считается проверенной только в том случае, когда мы прошлись по всем пунктам чек-листа. |
| Работа на проекте ведется по спринтам. | Спринт выполнен – если все правки и замечания записаны со статусом «Closed.» |
| На проекте есть группа написанных тест-кейсов и проводится процедура регрессионного тестирования. | По итогам выполнения регрессионного тестирования не было найдено никаких ошибок. |
Как итог
К большому сожалению, унифицированной и подходящей для любой ситуации стратегии тестирования нет. Ее необходимо составлять в индивидуальном порядке каждый раз, когда проектная группа начинает работать над созданием нового продукта.
- Крайне важно осознавать тот факт, что стратегия тестирования не должна быть самоцелью – это банальный инструмент, который позволяет достичь определенных результатов;
- Сразу же после написания стратегии становится ясно, где имеются провалы и как с ними бороться;
- Стратегию важно в обязательном порядке актуализировать даже в процессе финального этапа создания продукта, ведь ее актуальность – залог общей производительности всей команды.
Оставить комментарий