Распространенные заблуждения начинающих и будущих инженеров по ручному тестированию (manual QA)

Войти в айти сейчас вообще сложно, особенно через manual QA — направление с высокой конкуренцией. Тому доказательство — обилие резюме и сотни, а порой и тысячи откликов на вакансии на хх.ру и других работных сайтах. Выучиться на ручного тестировщика банально быстрее, чем на backend или frontend разработчика — в среднем курсы длятся 4 месяца. Рынок перенасыщен вчерашними студентами, свитчерами и самоучками, что не мешает самым целеустремленным получать офферы после первого же собеседования.

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

Совсем не учиться, кстати, тоже не получится. Manual QA только называется ручным тестированием. На деле вряд ли серьезная компания захочет нанять специалиста на эту должность, который бы не владел JIRA, Postman, Insomnia, SoapUi, основами SQL, а иногда также Perfect Pixel, ADB и прочими специализированными инструментами. На курсах учат работать с упомянутыми выше и другими инструментами на задачах, взятых из реальной практики.

Я считаю, что ИИ не скоро научится писать тест-кейсы так же хорошо, как опытный инженер manual QA. Еще больше времени понадобится для создания модели, способной заниматься так называемым интуитивным тестированием — когда нужно выходить за рамки тест-кейсов и пробовать нестандартные подходы к использованию тестируемого продукта. Иногда попадаются такие непредсказуемые баг-репорты, что представить сложно, как вообще пользователь смог воспроизвести баг. Да, есть инструменты вроде Monkey, но на данный момент времени они не способны удовлетворить все потребности, например, в интуитивном тестировании.

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

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

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

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

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

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

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

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

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

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

Я сторонник того, что работодателя и проект нужно выбирать внимательно. Прежде чем отправлять резюме в «АйТи-Баланс», я внимательно ознакомилась с тем, какие продукты она разрабатывает, с чем в перспективе предстоит работать. Понятно, что всё не узнаешь и заочно влюбиться в продукт редко когда возможно. Но мне кажется странным наобум рассылать резюме в погоне за хотя бы каким-то оффером.

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

По поводу перспективности, вопрос субъективный. Manual QA всегда есть куда расти, чему учиться, а если захочется больше кода — то ничто не мешает свихнуться в fullstack QA и заняться написанием автотестов. На мой взгляд, направление перспективное, востребованное и не такое простое для входа в IT, как пишут на лендингах быстрых курсов.

Резюмируя, manual QA — это работа для терпеливых, любопытных, внимательных. При этом полезно для ее освоения не только изучать теорию и практиковаться в той или иной форме, но развивать софт-скилы — без них в IT однозначно будет непросто. Напоследок совет начинающим и будущим тестировщикам: не бойтесь отправлять резюме и проходить собесы, но обязательно внимательно выбирайте продукт, чтобы каждый день с удовольствием открывать Jira.

Интересные и полезные материалы к прочтению:
«Тестирование Дот Ком» – Роман Савин
«Шпаргалка начинающего тестировщика» – Наталия Матвеева
«Тестирование программного обеспечения: Базовый курс» – Святослав Куликов
6 книг по тестированию ПО
Reddit: r/QualityAssurance
Почему ручное тестирование не умрет
Top 17 Software Testing Blogs