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

Сложность #1 Хорошее качество продукта на протяжении длительного времени

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

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

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

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

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

Возможны некоторые или все из перечисленных ниже результатов:

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

В первую очередь сотрудничество, а не документация!

Сложность #2: Централизация

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

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

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

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

Мы говорили о компетенции, но как насчет обмена опытом?

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

Решение: Поговорим о способах решения проблем.

Есть два правила:

  • Главное — люди, а не процессы
  • В первую очередь сотрудничество, а не документация

Главное — люди, а не процессы!

Пошаговая инструкция рабочего процесса:

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

2) Обсуждение пользовательских историй (описаний требований к разрабатываемой системе). Если новое требование вносит существенные изменения в разрабатывающуюся систему, тогда это, как правило, обсуждается на уровне руководства. Руководители аналитического, девелоперского и тестового отделов проводят обсуждение этих требований. Идея в том, чтобы заблаговременно устранить возможные пробелы и детально все это описать, тем самым сэкономить время для команды тестировщиков.

3) Бизнес-аналитик знакомит команду с требованиями к функционалу. На данном этапе тестировщик получает 90% информации о предстоящей работе. 5-10% — это пока еще неизвестная информация.

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

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

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

6) Тестирование с тест-кейсами. Как только разработчики выполнили определенное требование (user story), тестировщик проводит тестирование программного обеспечения, следуя написанным тест-кейсам и при этом комментируя свои действия. Как только достигнут желаемый уровень качества, пользовательская история отмечается как прошедшая проверку.

7) Дополнительная сессия*. После этого тестировщик проводит дополнительную проверочную сессию для новой функциональной особенности, он объясняет, как все работает. Обязательно присутствие всех тестировщиков, в отличие от брейнсторминга. Таким образом, все участники процесса смогут составить представление о пользовательской истории, узнать, насколько она влияет на их собственную историю, и задать вопросы.

8) Дополнительный тестовый раунд*. Важный, но во многом факультативный шаг, проводится другим сотрудником. Эта сессия обычно длится не более часа.

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

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

  • Дополнительная сессия
  • Дополнительный тестовый раунд
  • Сессия-брейнсторминг

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

Работа может оказаться и очень интересной для сотрудника

Сложность #3: неинтересная работа

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

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

Каждый может поделиться собственными соображениями, идеями относительно процесса работы, достижениями и пр.

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

Если это все еще выглядит как работа, можно попробовать поиграть в игры. Например, в мафию. Обмен информацией может происходить в приложениях Trello или Slack.

Командными усилиями проблемы решаются намного быстрее!

Сложность #4: распределение работы

Еще одна проблема, распространенная среди крупных компаний, — распределение работы в команде.

  • Беспрерывное выполнение одних и тех же заданий не очень способствует личному росту.
  • Тестирование одних и тех же модулей со временем может надоесть.
  • Руководитель естественным образом поручает тестирование определенных модулей специалисту в определенной сфере (проблема централизации, о которой упоминалось ранее).
  • У участников команды возникает ощущение, что они механически выполняют определенную работу и что с их мнением не считаются.

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

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