Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

В этом месяце я решила сделать что-то новенькое! Обычно мои статьи нацелены на тестировщиков, которые хотят прокачать свои навыки и лучше размышлять о том, что тестировать. Но в этот раз я хочу обратиться к тем, кто нанимает тестировщиков.

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

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

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

Способность искать баги

Если тестировщик не может найти баги, нет причин его нанимать. Любой разработчик может провести тестирование "счастливого пути" и набросать автотесты, проверяющие созданный код. Тестировщиков отличает их способность думать о проверке того, что разработчики с шансами упустят: негативные тесты, странные граничные случаи, взаимодействие между функциями… Чтобы определить, способен ли кандидат искать баги, дайте ему забагованное приложение и попросите найти и описать баги. Вы удивитесь, как много "опытных" тестировщиков не справится с этим! Эти люди вам в команде не нужны.

Умеет принимать решения о том, что тестировать

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

Понимание API-тестирования

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

Внятная коммуникация

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

Создание хороших автотестов

Согласно Роберту С. Мартину, автору широко признанной книги "Чистый код", тестовый код настолько же важен, насколько и код приложения. Это связано с тем, что тестовый код используется для валидации, что изменения в приложении ничего не сломали. Если код тестов ненадежен, все изменения кода приложения нужно тестировать вручную в дополнение к автотестам, что замедляет весь процесс разработки. Поэтому вам нужен тестировщик, который пишет чистые автотесты: повторяющиеся задачи должны разделяться на методы или классы, и код должен быть хорошо организован. Чтобы проверить, способен ли кандидат писать хорошие автотесты, попросите его написать несколько тестов для простого приложения, а затем – прогнать их и пояснить, почему тесты написаны именно так, и код организован так, а не иначе.

Понимание баз данных

Неважно, пользуетесь ли вы реляционными базами вроде SQL или нереляционными вроде Mongo DB – вам нужен кандидат, способный взаимодействовать с базами данных для получения нужной тестированию информации. Если вы используете реляционные базы, попросите кандидата написать простой запрос или объединение. Для нереляционных баз можно спросить, как планируется получать конкретную запись из базы.

Понимание проблем мобильного тестирования

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

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

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

Понимание важности визуального тестирования и тестирования доступности

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

Способность быть адвокатом качества в команде

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

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

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