Как выстроить процесс тестирования с нуля

Процесс управления тестированием: Полное руководство по тестированию проекта

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

Вы становитесь тест-менеджером самого важного проекта в вашей компании. Задача проекта — протестировать банковскую сеть уважаемого «Guru99 Bank».

Кажется, что все отлично. Менеджер вам доверяет и на вас рассчитывает. У вас есть хороший шанс доказать, что вы справитесь со своей задачей. Но правда в том, что:

Управление тестированием — это не просто один вид деятельности. Оно состоит из целого ряда мероприятий.

Фазы управления тестированием

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

Процесс управления тестированием

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

Процесс управления тестированием состоит из двух основных частей:

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

Анализ рисков
Оценка тестирования
Планирование тестирования
Организация тестирования

Выполнение

Мониторинг и контроль тестирования
Решение проблем
Отчет о тестировании и оценка

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

Анализ рисков и их решение

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

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

Более подробно об анализе рисков и их решении вы узнаете здесь.

Оценка теста

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

Преимущества правильной оценки:

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

Планирование тестирования

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

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

При тесте программного обеспечения план предоставляет подробную информацию о предстоящем тестировании, включая:

Стратегия тестирования
Цель тестирования
Критерии выхода/приостановки
Планирование ресурсов
Результаты тестирования

Что такое организация тестов при тестировании программного обеспечения?

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

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

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

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

Выполнение

Мониторинг и контроль тестирования

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

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

Мониторинг

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

Для мониторинга тест-менеджер выполняет следующие действия

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

Контроллинг

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

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

Решение проблем

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

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

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

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

Риск, которого следует избегать при тестировании:

Нарушение дедлайна
Превышение бюджета проекта
Потеря доверия заказчика

Когда возникают эти проблемы, вы должны быть готовы к их решению — или они потенциально способны повлиять на исход проекта.

Отчет о тестировании и оценка

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

Целью отчетов с оценкой результатов тестирования является следующее:

«Отчет с оценкой тестирования» описывает результаты тестирования с точки зрения покрытия теста и критериев выхода. При оценке тестов используются сведения, основанные на данных о результатах тестирования и сводной информации о результате тестирования.

Материал подготовлен в рамках курса «QA Lead». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.

qa lead
test management
управление тестированием

Блог компании OTUS
Тестирование веб-сервисов

Как организовать процесс тестирования с 6 шагов

Всем привет! Меня зовут Елена Поплоухина. Я — один из авторов Youtube‑канала по тестированию «Багаж тестировщика». На канале выходил выпуск про построение процесса ручного тестирования с нуля. Данная статья содержит основную информацию из этого выпуска — 2 общих совета и 6 первых шагов для организации процесса.

Введение

Представим, что вы оказались на новом проекте. Единственным тестировщиком или в команде QA инженеров. Перед вами стоит задача — организовать процесс ручного тестирования. При этом проект находится в одной из стадий:

Проект только стартует, команда формируется, процессы строятся с нуля;
Проект уже развивается, выпускаются публичные релизы. Но присутствуют проблемы с качеством.

Возможно, вы чувствуете себя как ежик в тумане. С чего же начать?

Совет 1 — Начните с выяснения проблем и ожиданий от тестирования

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

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

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

Дополнительно выясните ожидания от тестирования. В отличие от перечня проблем, предложите описать эту информацию в свободной форме. Обычно ожидания тесно связаны с проблемами, выявленными на предыдущем этапе.

Ожидания от тестирования укажут направление, с которого стоит начать строить процесс тестирования. Например, ожидание «Снизить в 2 раза% возврата багов между QA и Dev» говорит о том, что нужно внедрить шаблоны для багов и согласовать регламент работы с багами.

Совет 2 — Внедряйте улучшения постепенно

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

Далее рассмотрим 6 практических рекомендаций для организации процесса тестирования.

Внедрите шаблон бага

Разработайте шаблон бага и описывайте найденные ошибки по нему. Если на проекте используется система вики — заведите в ней отдельный раздел для тестирования и храните в нем шаблоны документов и регламенты.

Наличие шаблонов для багов несет следующие преимущества:

Экономия времени на воспроизведении багов как разработчиками, так и тестировщиками. В случае короткого и неинформативного описания не только разработчик, но и сам автор бага может не вспомнить, о чем шла речь.
Сокращение времени на коммуникации между dev и qa — этот пункт вытекает из предыдущего. Разработчики не будут стучаться к вам в личку со словами — а что имелось в виду в этом баге? А на каком стенде и тестовых данных он воспроизводится?
Единый стиль багов — с багами приятно и привычно работать всем членам команды.

Согласуйте список приоритетов багов

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

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

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

Блокирующий — Blocker
Критический — Critical
Важный — Major
Нормальный — Normal
Минорный — Minor

Или обойтись более простой версией из трех приоритетов:

Высокий — High
Средний — Normal
Низкий — Low

Согласуйте правила установки приоритетов, оформите в виде регламента и положите в wiki.

Внедрите регламент работы с багами

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

ЖЦ бага представляет из себя описание состояний бага и правил перехода по ним в системе управления проектами.

Для составления регламента выполните следующие шаги:

Продумайте набор статусов для багов.
Определите правила перехода между статусами и порядок назначения исполнителей.
Согласуйте регламент с менеджером проекта.

Регламент представляется в виде наглядной схемы или текстового описания. После согласования регламента с командой положите его в wiki и следите первое время за его исполнением.

Согласуйте регламент работы с задачами в системе управления проектами

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

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

Ready for test — задача завершена разработчиками и готова к тестированию;
Testing — задача находится на тестировании у тестировщика;
Done — задача протестирована в рамках итерации;
и т.д.

Пишите тест-кейсы или чек-листы… как можно раньше в процессе обеспечения качества

Один из первых навыков, которым учатся тестировщики — проектирование тест-кейсов. Это база. Тем не менее, тестировщики не всегда создают тестовые сценарии «на бумаге».

Одной из главных причин называется «нет времени». Эта проблема решается путем грамотного планирования итерации и оценки времени на тестирование.

При отсутствии чек‑листов или тест‑кейсов вы рискуете качеством своего продукта.

2 основных совета по стадии проектирования тест-кейсов следующие:

Если нет необходимости в тест-кейсах, пишите чек-листы;
Пишите тест-кейсы или чек-листы как можно раньше в процессе обеспечения качества. В идеале — еще на стадии тестирования требований или до разработки.

Преимущества раннего проектирования тест-кейсов или чек-листов:

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

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

Минусы тестирования без тест-кейсов или чек-листов:

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

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

Установите критерии выпуска релиза в прод

Как определить, когда текущая версия готова к релизу? Ждать до исправления последнего бага или все же нет?

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

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

По всем фичам проведено тестирование;
По фичам исправлены баги всех приоритетов, кроме низкого;
Проведено регрессионное тестирование;
и т.д.

В результате тестирования вы предоставляете менеджеру проекта решение о готовности продукта к релизу. Критерии помогут вам перейти от варианта “вроде все работает” к обоснованному заключению.

Заключение

Мы рассмотрели 2 общих совета и 6 первых практических шагов для построения процесса ручного тестирования на проекте.

Спасибо за внимание и до встречи в следующей статье!

Как организовать тестирование в проекте? Инструкция для самых маленьких

Плохой программист Джон сделал ошибку в коде, из-за которой каждый пользователь программы был вынужден потратить в среднем 15 минут времени на поиск обхода возникшей проблемы. Пользователей было 10 миллионов. Всего впустую потрачено 150 миллионов минут = 2.5 миллиона часов. Если человек спит 8 часов в сутки, то на сознательную деятельность у него остается 16 часов. То есть Джон уничтожил 156250 человеко-дней ≈ 427.8 человеко-лет. Средний мужчина живет 64 года, значит Джон убил примерно 6 целых 68 сотых человека.

Как тебе спится, Джон — серийный программист?

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

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

Я делю тестирование на два этапа: превентивные меры и обратную связь (рефлексию). Сначала мы пытаемся не пустить баги к пользователям, а когда они к ним попадают — разбираемся, что пошло не так и улучшаем превентивные меры.

“No pasaran” или превентивные меры

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

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

Насколько подробно нужно писать тест-кейсы? Это зависит от того, сколько ресурсов у вас есть и как вы планируете тест-кейсы в дальнейшем использовать. Иногда тест-кейс упрощают до пункта в “списке с галочками” — чеклиста.

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

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

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

Что тестируем?

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

Работает ли функция?
Как только разработчики выпустили функцию — протестируйте ее. Для начала выясните, делает ли она то, что от нее ожидается. Здесь пригодятся тестовые сценарии.

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

Не влияет ли эта функция на другие (или они на нее)?
Функция работает. Настало время понять, не ломается ли она, когда работает вместе с другими. Обычно достаточно полноценно развернуть изменения на отладочном сервере, чтобы увидеть проблемы.

Не забудьте проверить, не сломались ли те функции, которые вы ранее протестировали.

Не сломались ли старые функции?
Перед тем как выпускать новую версию продукта убедитесь, что обновление не ломает то, что сейчас уже работает.

Протестируйте все (или хотя бы основные) функции приложения после применения изменений релиза.

Затраты на тестирование начинают расти очень быстро: каждая новая функция требует тестирования всех предыдущих. На самом деле не обязательно тестировать вообще все.

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

Все ли важные функции тестируются?

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

Важно написать тест-кейсы для наиболее важных с точки зрения бизнеса функций. Так вы будете уверены, что “шоу продолжается”.

Выбор важных функций может быть трудным. В случае сомнений — считайте функцию важной и тестируйте.

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

“Show must go on” или “Есть ли жизнь после бага?”

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

Разберитесь, почему превентивные меры не сработали. Задайте два вопроса:

Тестировали ли мы такой сценарий до релиза?
Есть ли вообще у нас такой тест-кейс?

Другими словами: тест-кейс написан, но его не успели проверить или тестировщик не предусмотрел такой тест-кейс вовсе?

Документирование тестовых прогонов

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

Это полезно не только для рефлексии: данные о том, в каком билде бага еще не было, помогут в его исследовании.

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

Исследование и документирование бага

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

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

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

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

Улучшение тестовых сценариев

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

Как с этим жить?

Баланс

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

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

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

Как построить процесс тестирования в компании (чек-лист для проверки)

Ни для кого не секрет, что QA — это процесс обеспечения качества. Но как можно обеспечить качество продукта, если качество самого процесса тестирования под большим вопросом?

Конечно, когда дело касается микро-стартапов, в команде которых всего пара человек: разработчик, он же и аналитик по совместительству, да и тестировщик, то сильно задумываться над построением процессов не имеет смысла. Но вот в крупном продукте, где команда тестирования состоит из трех и более человек, чтобы эффективно выполнять задачи, приходится налаживать процессы. Когда вокруг царит процессный хаос, сложно сосредоточиться на обеспечении качества, и высока вероятность что-то упустить из виду: где-то — сделать двойную работу, где-то, наоборот, что-то забыть. Вот от этого хаоса постараемся сегодня избавиться, разложив процесс тестирования по полочкам следуя советам Никиты Ткаченко, инженера по тестированию iiii Tech (“Форайз”).

Вспоминаем жизненный цикл ПО

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

Работа с требованиями

Кроме самого очевидного — тестирования самих требований — на ранних этапах стоит подумать что и как будем проверять. В этом нам помогут декомпозиция, тест-план и оценки: 1. Декомпозиция: как гласит народная мудрость, «слона нужно есть по кусочкам», и в нашем случае удобнее всего это сделать в виде майнд-карты — так мы структурируем требования по логическим модулям и создадим себе шпаргалку для будущих проверок. 2. Тест-план: говоря о тест-планах, многие вспоминают нечитабельные «талмуды», изобилующие практически никогда не используемой информацией. Но тест-план должен быть удобен прежде всего для участников процесса и формат его выбираете вы. А потому, возможно, и не стоит расписывать кто заказчик продукта, какова его ценность, критерии начала и окончания тестирования, какие виды тестирования планируете применять и так далее. А вот заранее подсветить возможные риски, оценить зависимости от других продуктов и команд, определить возможное регрессионное влияние — всегда полезно 3. Оценки трудозатрат: прогнозы — это хорошо, а сбывшиеся прогнозы — вдвойне хорошо! Думаю, нет смысла лишний раз говорить насколько важно планирование трудозатрат и сроков для разработки продукта в целом. На первый взгляд кажется, что все вышеописанное — это просто лишняя работа. Но, во-первых, их необходимость для себя команда тестировщиков определяет самостоятельно, а во-вторых, много времени они не занимают, а вот сэкономить при этом могут очень много — проверено не раз. Пожалуй, самым показательным случаем на моей практике оказалась одна небольшая задача: ее релиз был привязан к определенной дате, но работы по ней было буквально на неделю и потому никто особо не переживал за сроки. Однако, все забыли, что получить тестовые данные, необходимые чуть ли не на последнем этапе работы над задачей, нам потребуется от третьей стороны, согласования с которой могут занять длительное время. К счастью, этот риск мною был учтен заранее и этап согласования начался параллельно с работой непосредственно над задачей. И в итоге он занял практически ту же неделю, что и помогло закончить работу прямо к дедлайну. Упусти мы этот момент на этапе планирования, и та самая неделя согласований добавилась бы сверху.

Разработка

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

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

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

Внедрение и эксплуатация

С окончанием тестирования работа QA-инженеров не заканчивается: после внедрения рано или поздно прозвучит нежеланное «баг с прода!». Как бы команда тестирования ни старалась, все досконально проверить невозможно. И здесь просто исправить и забыть нельзя. Баг — это следствие, а команде прежде всего нужно понять причину и «починить» уже ее, чтобы в дальнейшем такое не происходило.

Работа внутри команды

Взаимодействие внутри команды также крайне важно наладить и для этого есть несколько подходов: * Прозрачность: участники команды должны всегда понимать кто чем занимается. Но не контроля ради, а для рационального распределения задач — чтобы не выполнять одну работу вдвоем, а другую полностью оставлять без внимания. Для этого можно использовать как регулярные синки или специальные инструменты, так и просто мессенджеры — удобный способ для себя определяете вы сами. * Нивелирование бас-фактора: сосредоточение знаний в “одной голове” — плохая идея. Уйди сотрудник в отпуск, на больничный или вообще из проекта, и целый пласт знаний в определенной функциональности уйдет вместе с ним. Решить эту проблему заранее поможет постоянный шаринг знаний (в виде встреч или инструкций — как удобно) или распределение компетенций в виде привлечения к задачам нескольких тестировщиков. Как это сделать в условиях ограниченных ресурсов? Очень просто: вместо подхода «один человек на одну задачу» применять «два человека на две задачи». Казалось бы, одно и то же, но во втором случае оба будут в курсе обеих задач, а степень погружения можно варьировать. Но главное, что всегда есть дублирующий.

Единый стиль

Разработчики в своей работе зачастую придерживаются определенного code style — набора правил и подходов при написании кода. Так и в тестировании следует применять подобный подход: определите требования к написанию тест-кейсов, созданию баг-репортов и прочих других артефактов. Условьтесь в их степени детализации, оформлении и придите к некой шаблонизации — так будет обеспечен единый стиль. Паттерны воспринимаются быстрее и проще, чем каждый раз уникальный авторский подход, зависящий от сотрудника.

Долой бюрократию

Документация и артефакты тестирования должны решать проблемы, а не создавать их! На моей практике был случай, когда один из артефактов, потребителем которого была другая команда, создавался вручную в виде docx-файла с оформлением таблиц и копированием туда множества ссылок. Занимало это зачастую не один час, не говоря уж о рутинности такой работы. На мое возражение о нелогичности такой документации коллеги мне ответили что так исторически сложилось и такие требования потребителя. Конечно, так просто я не сдался и пошел выяснять почему так. На мое удивление, потребитель ответил что им по большому счету все равно в каком виде, главное получить нужную информацию. Час работы над новым форматом в confluence, немного автоматизации средствами плагинов и теперь артефакт создается за. 30 секунд. Без документации, конечно, нельзя. Но решите что из нее не используется и может быть упразднено, а что — упрощено и автоматизировано.

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

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

Эволюционируй и строй СВОЙ процесс

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