Тестирование окружено множеством мифов. Одни вырастают из стереотипов от коллег из смежных областей, другие — от невежества и поверхностного взгляда на работу тестировщика. Но и те, и другие часто представляют тестирование в искаженном свете — от идей манки-тестинга до «скоро всех тестировщиков заменит ИИ».
Так ли это? В этой статье поделимся самыми распространенными мифами о тестировании.
«Тестирование — это скучно»
Одна из сторон тестирования — выполнение множества рутинных задач. Как следствие — в QA вакансиях нередко «усидчивость» идет впереди «креативности». Может сложиться мнение, что тестирование — скучная, монотонная работа, а QA-инженеры — все равно, что бухгалтеры от мира IT.
Но есть и другая сторона в работе тестировщиков. Эта сторона — творческая и изобретательская: QA-специалист должен работать не только с очевидным, «запланированным» функционалом продукта, но и находить его уязвимости, скрытые от глаз. Для этого нужно идти нехоженными тропами: кликать туда, куда никто не кликал, делать то, что ни рядовому пользователю, ни остальной команде разработки не придет на ум.
Задачей тестировщика является найти неочевидные пути, описать их, проверить всеми доступными способами, а затем заметки о «путешествии» принести команде. Очевидно, что скучать тут точно не придется :) А способность нетривиально мыслить и смотреть на продукт глазами пользователя — точно будут плюсом в этой профессии.
Миф о монотонности работы тестировщика развеивается, стоит только поближе взглянуть на описание рабочих процессов.
В QA есть понятия «ad-hoc тестирование» и «исследовательское тестирование», где второе является упорядоченной версией первого. Любой пользователь, впервые взаимодействуя с продуктом, выполняет своего рода ad-hoc тестирование, знакомясь с функционалом и вникая в то, как он работает. QA-инженер при этом должен еще составить чек-лист проверок и собственноручно провести их, чтобы убедиться в корректности работы функционала. А учитывая, что новые фичи (и новые баги!) появляются почти в каждом спринте, становится ясно, что работу тестировщика скучной точно назвать нельзя.
Если же хочется больше разнообразия, можно выбрать место работы, где проекты будут поставлены на поток — например, тестирование на аутсорсе. Для тестировщиков из агентства каждый новый проект становится выходом из зоны комфорта: всегда есть, чему поучиться. О том, как на практике устроено тестирование на аутсорсе, мы рассказывали тут.
«Ручное тестирование вытесняется автоматическим»
Страх перед тотальной роботизацией интеллектуального труда — миф, который вышел далеко за пределы тестирования. Рады сообщить: на сегодняшний день прогнозы (по крайней мере, для тестировщиков) оптимистичны. Это все еще миф! «Идущие в айти» отметают вариант профессии ручного тестировщика под страхом остаться в скором времени без работы. Немудрено: нейросети успели напугать представителей творческих профессий, рисуя картины, сочиняя музыку, выдумывая сюжеты книг — почему бы не начать тестировать продукты?
Здесь проходит тонкая грань соприкосновения мифа с реальностью. Тестировщиков частично коснулась «эпидемия ИИ». ChatGPT может писать SQL-запросы, простой код на JavaScript или выдать подробную инструкцию тестирования фронта и бэка.
Многие склонны считать, что платформы с нейросетями могут стать стандартом low-code-тестирования. Сам ИИ отмечает, что для идеальной работы ему не хватает человеческой внимательности, креативности и интуиции. QA-инженеры могут пока выдохнуть: машина все еще уважает их и даже делает комплименты :)
Ручному тестированию иногда противопоставляют автоматическое. Ведь его можно делать быстро и часто, снижая роль человеческого фактора и соответственно, количество ошибок, дошедших до пользователя.
Но на самом деле ручное и автоматическое тестирование выполняют разные задачи, и в равной степени нужны для быстрого и качественного тестирования, особенно когда речь идет о крупном проекте с разнообразным функционалом.
Почему полный отказ от ручного тестирования не предвидится?
Судите сами:
Судите сами:
- Автоматическим тестированием сложно оценить удобство — всегда имеет место субъективный пользовательский опыт.
- Для автоматизации нового функционала нужно участие живого тестировщика, который разработает проверки, спроектирует тест-кейсы и решит, какие из них в первую очередь следует автоматизировать.
- Сценарии тестирования могут изменяться в связи с развитием продукта, а написанные автотесты — содержать ошибки. Без тестировщика это некому оперативно подметить и исправить.
- Для относительно молодых и нестабильных проектов внедрение автотестов является нецелесообразным, так как функционал постоянно меняется, а значит, нужно будет постоянно вносить изменения в автотесты.
Поэтому ручное тестирование не умрёт как минимум в ближайшие двадцать лет — а может, и никогда. Ведь продукты создаются для людей и включают в себя компонент субъективного восприятия, которое не сможет тестировать ни одна машина.
Несмотря на это, в определенных задачах автоматизация существенно увеличивает эффективность сотрудника. Мы учли это в нашем курсе по ручному тестированию — наши ученики осваивают и базу по автоматизации.
«У тестировщиков с разработчиками сложные взаимоотношения»
Любой желающий «войти в IT» рано или поздно сталкивается с мифом о напряженных отношениях между разработчиками и тестировщиками в дикой среде обитания.
Именно позиция разработчиков по-человечески более понятна: они создают код, а тестировщики — постоянно критикуют и придираются. Так ли это?
В реальности разработчики и тестировщики делают общее дело: создают продукт, который будет корректно работать и удовлетворять потребности пользователя. В здоровом варианте коллектива, тестировщик не «атакует» детище разработчика, а наблюдает симптомы и дает рекомендации по его «оздоровлению». Разработчик же в этом сценарии баг-репорты с благодарностью принимает, а советам охотно следует. Ведь одна голова хорошо, а две — лучше.
Но если бы так было везде, не было бы самого мифа.
Перекосы случаются с обеих сторон. Разработчик может критиковать тестировщика за излишнюю придирчивость, тестировщик же может отвечать раздражением на обилие найденных багов и нежелание их исправлять.
Создается ситуация противостояния, которая действует отравляюще не только на рабочую атмосферу, но и на конечный результат. Тестирование становится словесным фехтованием.
Как сохранить хорошие отношения с командой, подробно мы рассказывали в этой статье. Рецепт прост: критика тестировщика должна быть объективной, нейтральной и доступной. Еще коллеги ожидают похвалы, внимания к своей работе и инициативы по улучшению процессов и взаимодействия.
Даже с учетом того, что тестировщику часто приходится критиковать, нужно помнить, что цель его работы — помочь в создании действительно качественного продукта и достижении целей бизнеса.
«Тестировщики отвечают за все ошибки»
Еще один миф о тестировщиках — им достаются все «шишки». Программисты пишут код, дизайнеры создают макеты, СММ запускают рекламу, а тестировщики… Отвечают за все ошибки, которые дошли до пользователя? Давайте разбираться.
На самом деле, тестировщик — не пиньята, которую команда лупит, пока из бедняги не посыплются баг-репорты. Суть работы QA-специалиста — проверить, что фактическое качество продукта соответствует характеристикам, заявленным в требованиях. И если несостыковки обнаружены, то подробно их описать и передать для исправления команде разработке.
При этом, если какой-то баг обнаружат на проде, первым делом пойдут с вопросами именно к тестировщику — отсюда и вытекает этот миф. Но это не означает, что ответственность за все баги лежит на нём. Если ошибка дошла до пользователя, то в первую очередь стараются понять её природу.
Например, это могут быть проблемы с железом — какой-то контейнер с микросервисом неожиданно исчерпал всю память. А может быть документация была неактуальной/неполной и не описывала новое поведение системы. Бывает, что время на тестирование вместо трех дней неожиданно сократили до пяти часов — тоже есть шанс, что часть функционала останется не покрыта проверками.
Если же это человеческий фактор и тестировщик действительно пропустил баг — это обсуждают на ретро (или инцидент-встрече), где решают, какие шаги стоит предпринять, чтобы избежать такого в дальнейшем: может быть добавить новый тест-кейс в регресс или автоматизировать его.
В экологичных командах действует негласное правило, что вина за ошибки общая, поэтому скорее попробуют улучшить процессы, чтобы такого не возникало впредь. Например, расширить команду, наняв ещё одного тестировщика :)
Куда пойти учиться на тестировщика?
Без лишней скромности: в QA Studio. Сейчас расскажем, почему у нас круто, и это уже никакой не миф.
Наши процессы заточены под обучение тестированию. Мы даем ученикам все знания, которые необходимы для устройства на работу, и поддерживаем на протяжении всего пути.
По ходу обучения мы не будем предлагать вам пройти партнерские курсы по английскому языку, веб-дизайну и правильному питанию. Научим именно тому, ради чего вы пришли.
Наши менторы — тестировщики middle и senior в крупных российских компаниях. Они не только с готовностью расскажут про внутреннюю кухню работы в QA, но и поделятся лайфхаками о том, как сделать свою жизнь проще и интереснее, занимаясь отловом багов. Почитать интервью с ними можно в нашем журнале.
Мы придерживаемся индивидуального подхода — каждый ученик обучается в группе до 12 человек. Так ментор сможет каждому уделить достаточно внимания, проверить и объяснить все, что необходимо.
Чтобы наши ученики как можно быстрее вышли на работу по новой специальности, мы организуем QA-стажировки. Для этого у нас есть проект Джуны, где ребята получают первый опыт в тестировании на реальном проекте и попробуют себя в командной работе.
Еще мы помогаем составить резюме и прокачаться в прохождении тестовых собеседований. И это не считая поддержки от дружного комьюнити учеников!
Заглядывайте в наш телеграм, если хотите узнать больше.
Еще увидимся! :)
