Вы когда-нибудь задумывались, кто проверяет, хорошо ли работает ваш любимый смартфон, компьютерная игра или интернет-магазин перед тем, как вы начнете ими пользоваться? Есть такая профессия – баги ловить. Мы поговорили с тестировщиками и узнали, что это за профессия, их задачи, инструменты, о том, в каких они отношениях с разработчиками, и даже то, как проходит их обычный день. Об этом и многом другом в нашей статье.
Кто такой тестировщик простыми словами, и какие задачи перед ним стоят?
Тестировщик — это участник проектной команды, который отвечает за качество разработанного продукта. Его работа — проверить каждый уголок и удостовериться, что все работает как часы.
Как проходит стандартный день специалиста? Какие главные инструменты тестировщики используют в своей работе? Можете ли вы описать весь процесс – от разработки до выпуска продукта – где в этом процессе место для тестировщика?
Утро начинается с важного шага – заварить кофе! Потом быстренько проверяем почту, где могут быть новые письма и план встреч на день. Открываем трекер задач и проверяем, нет ли каких-то вопросов по задачам. Далее приступаем к багам, перепроверяем те, что уже отправились на тестирование. В это время мы также общаемся с разработчиками, рассказываем им, что это не фича (все работает так, как и было задумано), а баг (дефект), и как на самом деле все должно работать. После нескольких часов работы с багами мы переходим к тестированию новых фич и поиску новых багов. Не забываем созваниваться с аналитиками, чтобы уточнить требования. Ежедневный созвон с командой тестирования – обязательная часть дня. После созвона распределяем баги и задачи среди тестировщиков проекта. В конце рабочего дня обязательно появляется какой-то срочный вопрос от аналитика или разработчика. И, наконец, можно отдыхать, если, конечно, говорить о стандартном дне. А еще у нас могут быть встречи по проекту, неожиданные задачи от аналитиков и менеджеров, а также работа с отчетами и документацией.
Какие главные инструменты у тестировщика? Ну, во-первых, это его собственная голова на плечах, конечно! Но, помимо этого, есть еще куча инструментов для написания тестовой документации и проведения ручного тестирования, например таких как TestIT, TestRail, Qase. Для автоматизации тестов мы используем инструменты вроде Selenium и Jenkins.
Тестировщик не просто сидит в стороне и ждет, когда ему дадут продукт на проверку. Он включается в процесс уже на самых ранних этапах разработки: анализе, составлении требований, проектировании и тестировании дизайн-макетов. Постепенно он подключается к тестированию нового функционала, проводя тесты по мере разработки, включая регрессионные, нагрузочные и автоматизированные тесты по мере выпуска новых релизов.
Почему разработчики не могут тестировать собственные продукты? Правда ли, что у разработчиков и тестировщиков напряженные отношения? Или это миф?
Разработчики, безусловно, заинтересованы в своих творениях, и, конечно же, оценивают их скорее субъективно. На первый взгляд хочется уверенно заявить, что его продукт – шедевр! Но вот загвоздка: без внешней оценки можно упустить какие-то очевидные «косяки». В данном случае пословица «В чужом глазу соринку видим, а в своем и бревна не замечаем» очень даже кстати. Все потому, что найти ошибки в своей работе куда сложнее, чем в чужой.
Еще один момент: разработчики иногда откладывают в долгий ящик исправление того, что тестировщики «разбили». Почему? Вероятно, потому что тестировщики бывают невероятно дотошными. Они выискивают даже самые мелкие баги. А вот исправлять их – дело не такое увлекательное. Но, знаете, это как с врачом: идти на прием не очень весело, но это важно для здоровья.
Тестировщик смотрит на продукт и как конечный пользователь, и как технический специалиста, это помогает нам находить даже совсем неочевидные ошибки. Напряженные отношения могут складываться, например, если надо срочно выпустить релиз, а тестировщики раз за разом находят новые дефекты, которые препятствуют переходу на следующий этап.
Топ-3 частых ошибок, которые вы находите при тестировании продуктов.
Добиться абсолютного качества программного продукта скорее невозможно, но максимально приблизиться к нему вполне реально. В нашей работе действительно присутствуют типовые ошибки, на которые уже «глаз наметан».
Какой самый главный миф о работе тестировщика? Давайте развеем его.
«Тестировщик только тестирует». На самом деле, это в корне неверно. Потому что подготовка к тестированию занимает гораздо больше времени, чем само тестирование.
Какие продукты нуждаются в тестировании? Существуют ли продукты, для которых тестирование не нужно?
Любая система нуждается в тестировании. Возможно, исключением можно считать «Hello World» – программа, результатом работы которой является вывод на экран или иное устройство фразы «Hello, world». Вопрос в том, кто будет заниматься тестированием. Для небольших, локальных продуктов это могут быть сами пользователи или даже разработчики и аналитики. Иногда нет смысла создавать отдельную команду тестировщиков, особенно если продукт маленький и не очень сложный (это как самому проверить, что новое печенье вкусное, или вы приглашаете в гости эксперта по печеньям?).
Но! Для больших продуктов, особенно тех, которые использует много людей, нужны профессиональные тестировщики. И им необходимо провести различные виды тестирования.
Какие навыки и знания наиболее важны для тестировщика. А что важнее: хард-скиллс или софт-скиллс?
Главные ингредиенты тестировщика: творческий подход, организованность и коммуникабельность. Без творческого подхода и заинтересованности в тестировании он не сможет качественно выполнять свою работу и будет проходить сценарии вслепую, с таким подходом можно упустить множество интересных дефектов.
Без организованности и коммуникабельности, как без компаса в лесу, тестировщик будет как минимум некорректно заводить дефекты, разработчику будет непонятно, что нужно исправить, и тестировщик не сможет донести свою мысль до коллег.
Хард-скиллс или софт-скиллс? Важны оба. Ведь приходится много общаться, а также разбираться в технических вопросах. Так что, как в балете: и грация, и сила!
Роль тестировщиков в разработке огромна. Они не просто находят и фиксируют ошибки, но и обеспечивают стабильность и надежность продуктов. Которые благодаря их усилиям можно использовать без сбоев и быть уверенными в их качестве.
