Home

Автор: Эми Филлипс (Amy Phillips)

Оригинал статьи: http://www.testingcircus.com/how-a-lone-tester-can-build-an-efficient-test-process-despite-the-challenges/

Перевод: Ольга Алифанова

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

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

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

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

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

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

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

Джеймс Бах называет единственного тестировщика «омега-тестировщиком». Мне нравится идея, что омега-тестировщик может выбирать, действовать ли ему как опасной Омега-6, использующей тестирования для блокирования работы команды, или радушной Омега-3, помогающей разработке. В условиях ограниченного времени и решения компании не расширять тест-команду вам нужно быть безжалостными в оценке тест-деятельности, а также убедиться, что вы распределяете свое время наиболее продуктивным образом.

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

Если вы беседуете с хорошим тестировщиком – скорее всего, он назовет тестирование деятельностью, приносящей радость и удовольствие. Лично я обожаю хорошую охоту на баги, и мой недавний опыт с Weekend Testing подтвердил, что другие тестировщики разделяют это мнение. К сожалению, тестирование заработало себе репутацию однообразной скучной деятельности. Хороший разработчик знает, что тестирование важно и ценно, и зачастую стремится помочь, чтобы убедиться, что его работа сделана на пять. Но очень немногие из них стремятся тестировать. Это первая проблема, которую надо побороть путем презентаций, воркшопов и реального тестирования. Вам нужно научить разработчиков и техникам тестирования, и азарту охотников.

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

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

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

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

Обсудить в форуме