Что такое мануал тестировщик

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

Тестировщик – это кто

Тестировщик программного обеспечения – специалист в сфере IT. Человек, который занимается планированием и выполнением процесса под названием «тестирование». Это проверка написанной утилиты.

Тестировщик:

• проверяет работоспособность контента;
• занимается отладкой программного кода;
• отвечает за улучшение юзабилити.

Это не developer, хотя разработчик может стать тестером.

Иногда к «тестер» добавляют английские буквы Q и A. Это quality assurance. Расшифровывается как «контроль качества».

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

Ответвление QC

Рассматриваемые сотрудники в широком смысле занимаются еще одним важным делом – QC или quality control. Переводится как «контроль качестве». Такие тестировщики должны контролировать проект во время его разработки и поддержки. Тестирование ПО помогает выяснять, насколько утилита совершенна. Тестировщик будет проверять софт во время организации мероприятий по контролю качества (QC), включенные в комплекс обеспечения качества (QA).

Спектр обязанностей

QA инженеры должны выполнять немало должностных обязанностей. На практике они занимаются такими делами как:

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

На этапе разработки приложения привлечение QA инженеров (тестировщиков) для работы дает компании огромное преимущество. Он поможет оптимизировать весь процесс, чтобы в конечном итоге выпустить на рынок действительно качественный продукт. Приложение не придется переписывать по несколько раз.

Преимущества и недостатки

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

В чем плюсы

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

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

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

О недостатках

Среди основных недостатков профессии можно выделить такие моменты:

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

А еще для того, чтобы добиться больших результатов в карьере, предстоит долго практиковаться. Развитие здесь медленное, а уметь нужно многое. Чем больше у тестировщика навыков, тем лучше. Некоторые разработчики со временем могут самостоятельно проводить тестирование ПО.

Краткий гайд по навыкам

QA инженеры должны много чего уметь. Главное определиться с направлением, в котором проходит тестирование. Для каждого варианта тестер должен обладать определенными навыками:

1. Функциональное тестирование. Так называют проверку отдельных настроек и возможностей системы. В рамках компетенции тестировщику приходится учить функциональные требования к ПО, а также хорошо владеть спецификациями и стандартами качества.
2. Нагрузочное тестирование – testing предназначается для того, чтобы проверить работоспособность программного обеспечения при высокой нагрузке. Позволяет посмотреть, как утилита ведет себя после ошибок и сбоев. QA инженеры должны справляться с определением скоростей выполнения команд, количеством юзеров на платформе, возможности функционирования утилиты при высокой нагрузке.
3. Автоматизированное тестирование. Здесь тест отрабатывает самостоятельно. Среди всех остальных видов проверки является одним из самых быстрых. Тестировщики определяют инструментарий и сферы ПО для проверки подобным образом.
4. Юзабилити – analyst удобства интерфейса контента. Тестировщик тут должен разбираться в бизнес-процессах, маркетинге, особенностях интерфейсов. Желательно знать ЦА и ее потребности. Здесь для тестирования начинают привлекать «обычных пользователей».
5. Конфигурационный тестинг – проверка того, как софт функционирует в разных операционных системах.
6. Тестирование безопасности – процесс проверки защищенности проекта от угроз и взлома. Здесь необходимо умение обнаружения уязвимых частей софта. Также QA Engineer должен знать, как их исправлять.
7. Игровой тестинг – проверка игр на наличие ошибок. Предстоит тестировать развлекательный контент. Технические навыки здесь не слишком важны – достаточно проходить игры на разных устройствах в различных версиях.

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

Личностные качества

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

Для QA Engineer важны следующие качества:

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

Данные качества в тестировании помогут достаточно быстро продвигаться по карьерной лестнице. Но их отсутствие не значит, что не стоит пробовать себя в выбранном направлении.

Знания

В QA тестировании analyst должен обладать определенными знаниями. Без них никакие личностные качества не помогут:

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

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

Зарплата

При QA тестировании людей нередко интересует такой вопрос, как зарплата. Данный мануал поможет окончательно понять, насколько востребована изучаемая профессия.

В России новые сотрудники получают около 40-80 тысяч рублей. Многое зависит от опыта работы и профессионализма кадра. В Москве продвинутый QA инженер (тестировщик) может в месяц зарабатывать порядка 400-450 тысяч рублей.

В Америке соответствующая вакансия оценивается лучше. По данным 2021 года средний заработок (месячный) такого специалиста составляет 12 тысяч долларов (примерно 700 000 рублей).

Образование

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

1. ВУЗ. Тестировщик может выучиться в университете. Это долгий и дорогой подход. Отнимает 5-8 лет. В результате у выпускника будет опыт работы, а также диплом государственного образца. В России на тестировщика не учат, только на разработчиков. Тоже неплохой вариант для старта.
2. Техникумы. Отличное решение для тех, кто планирует в будущем поступление в ВУЗ. Можно отдать предпочтение не QA тестированию (данного направления нет), а программированию или информатике. Результат – диплом о среднем профессиональном образовании, который поможет поступить на 2-3 курс ВУЗа.
3. Самообразование. Никаких документов, указывающих на наличие знаний и навыков в тестировании не будет. Зато человек полностью контролирует образовательный процесс. Можно сконцентрироваться лишь на том, что действительно интересует.

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

Почему стоит выбирать курсы

Преимущества подобного обучения:

• доступные цены;
• период учебы – от нескольких месяцев до года;
• возможность собрать портфолио;
• практика;
• кураторство опытными сотрудниками;
• круглосуточная поддержка;
• возможность учиться по индивидуальному графику;
• для работы с курсами достаточно иметь выход в интернет.

Курсы – отличное решение для всех возрастов. При желании можно сконцентрироваться на одном или сразу нескольких направлениях. Это – отличный способ попробовать себя в самых разных сферах IT без серьезных временных затрат.

Важно: данный вариант способен вызвать некие затруднения у людей с плохим самоконтролем.

P. S. Большой выбор курсов по тестированию есть и в Otus. Среди них широко представлено и направление автоматизации. Есть варианты как для продвинутых, так и для начинающих пользователей.

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

Что такое ручное тестирование

Разработка любого приложения или отдельной его функции состоит из следующих этапов:

1. Аналитика и постановка задачи
2. Проектирование и дизайн
3. Разработка — программирование и кодирование
4. Тестирование и исправление ошибок
5. Выкатка в продакшн, публикация
6. Поддержка и обслуживание

Ручное тестирование — один из финальных этапов. Его задача: измерить качество продукта, то есть убедиться, что то, что было сделано на этапе разработки, соответствует тому, что было описано при постановке задачи.

Разберемся на примере. У нас есть сайт интернет-магазина, и аналитики решили, что продаж будет больше, если разместить кнопку добавления в корзину под описание товара, покрасить ее в красный цвет и написать на ней «Хочу». Дизайнеры спроектировали макет, а программисты написали код. После этого продукт с обновлением размещается на тестовом стенде — там его и проверяет тестировщик.

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

Часть проверок может быть автоматизирована, но полная автоматизация трудно достижима, поэтому ручное тестирование является обязательным этапом разработки.

Изучите ручное тестирование на Хекслете
На Хекслете есть профессия «Инженер по тестированию». Освойте ее и познакомьтесь с этапами разработки и жизненным циклом ПО, техниками тест-дизайна, системами управления тестированием и системами баг-трекинга.

Что входит в задачи тестировщика

Рассмотрим подробнее, как выглядит рабочий процесс специалиста по тестированию.

Тестировщик получает задание: проверить приложение или фичу на наличие ошибок.

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

Тестировщик продумывает стратегию тестирования, пишет тест-кейсы и по ним проводит тестирование. Хороший тестировщик постоянно задает себе вопрос: «А что если?» и придумывает новые способы взаимодействия с продуктом.

Пример тест-кейса:

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

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

Какие навыки нужны ручному тестировщику

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

• Техники тест-дизайна
• Все этапы разработки и жизненный цикл ПО
• Системы управления тестированием, например, Allure Testops, TestLink, TestRail
• Системы таск-трекинга / баг-трекинга. Jira, Redmine, Asana и многие другие
• Умение работать с API и базами данных.

Иногда говорят: «Тестировщик — это тот, кто ломает». Это неправильный подход. Задача тестировщика — не сломать, а выявить ошибку и выяснить, откуда она взялась. К тому же тестировщик часто является второй линией поддержки пользователей, работает с обратной связью, получает репорты о найденных пользователями багах и проверяет их.

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

Поэтому тестировщику в работе пригодятся следующие личные качества:

• Здоровый перфекционизм и педантичность
• Аналитическое и критическое мышление
• Внимание к деталям и умение работать с большим количеством документации
• Коммуникационные и менеджерские качества.

Важно не бояться выглядеть глупо, быть готовым разговаривать, спрашивать, уметь отстаивать свою позицию.

Тестировщик и QA – одно и то же?

Существует некоторая путаница с наименованиями профессии тестировщика. Многие приравнивают тестирование к Quality Assurance (QA) и Quality Control (QC), а тестировщиков часто называют QA-инженерами. Однако эти понятия находятся в разных плоскостях, а роли тестировщика и QA-специалиста сильно различаются.

Попробуем разобраться.

Задача тестировщика — убедиться, что сделано именно то, что было запланировано. Это работа по результату: результат уже есть, его нужно измерить.

Quality Assurance (QA) — это обеспечение качества. Задача QA-инженера сделать, так, чтобы при разработке совершалось как можно меньше ошибок. Это работа в первую очередь с процессом.

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

К понятию QC (Quality Control) тестирование уже ближе. В QС входят мероприятия по созданию тест-кейсов, тест-планов, стратегии тестирования — всего, что касается процесса измерения качества уже готового продукта.

Соответственно:

• QA присутствует с самого начала разработки и обеспечивает ее качество.
• QC контролирует качество, в том числе, за счет создания эффективной методологии его измерения.
• Тестирование измеряет качество уже разработанного продукта, прежде чем он отправится в продакшн.

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

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

Карьерный трек тестировщика

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

Можно стать крутым специалистом по ручному тестированию в узкой сфере, например, в медицине, банковской сфере, безопасности. Таких специалистов мало, поэтому они востребованы. Можно сделать смещение влево (shift left) – и углубиться в обеспечение качества (QA), стать QA-инженером.

И, конечно, стандартный вариант карьерного роста — прокачать менеджерские навыки и стать тимлидом/руководителем отдела.

Также из тестирования часто уходят в программирование или аналитику.

Инфографика на портале payscale

Рынок труда

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

Как и в остальных специализациях, существует несколько уровней тестировщиков: джуны, миддлы и сеньоры. Зарплаты на каждом уровне отличаются от предыдущего примерно в 1,5 раза. В конкретном случае все может сильно зависеть от специализации: миддл-тестировщик, выросший в QA, вполне может получать зарплату на уровне сеньор-тестировщика. Та же ситуация может возникнуть и с уклоном в автоматизацию.

В октябре 2022 года на сайте hh.ru по запросу «тестировщик» есть 3700 вакансий. Максимальная зарплата составляет 200 000 руб. в месяц, однако по факту в крупных компаниях сеньор-специалисты получают 300 000 и больше. Сотрудников ищут такие компании, как «Сбербанк», «Билайн», МТС, «Магнит» и другие. Минимальная указанная зарплата — 40 000 руб. в месяц.

Медианная зарплата в России — 109 000 руб. (по результатам исследования Хабр Карьеры). Большая часть вакансий открыта в Москве и Санкт-Петербурге, но такие специалисты требуются и в других регионах.

Если смотреть на зарубежный рынок, то больше всего вакансий открыто в США, где медианная зарплата тестировщика ПО — $4700 в месяц.

Где и как учиться на тестировщика

В IT не так важна корочка, как реальные навыки и знания. Поэтому вы можете учиться самостоятельно. Есть множество материалов в открытом доступе, YouTube-блогов, статей и книг.

Практические навыки тоже можно отрабатывать самостоятельно. Существуют сайты-тренажеры, например, такой: http://automationpractice.com/index.php – на них намеренно оставляют ошибки. Можно тренироваться и на любом реальном сайте или приложении: протестировать, составить тест-кейс, отчеты об ошибках и общий отчет. Есть порталы, на которых компании создают задания, на них можно откликнуться – за это даже платят деньги (правда, очень небольшие). Но на таких сервисах большая конкуренция. Нужно постоянно быть онлайн, мониторить новые задания и успевать первым на них откликаться. Сложно, но можно попробовать.

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

На Хекслете есть профессия — Инженер по тестированию. Обучение проходит в формате вебинаров с домашними заданиями с проверкой от наставника.

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

Профессия глазами профессионалов: комментарии экспертов о работе тестировщиков, перспективах и обучении

Дмитрий Субботин, QA Lead и автор образовательных программ по автоматизированному тестированию:

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

QA-специалист — это инженер, который созидает, помогает делать продукт лучше. Плюс тестировщики – это еще и аналитики. Им важны менеджерские качества, умение разговаривать и не бояться спросить, если что-то непонятно. «Вот у нас там такая связка. А что это?» Многие люди начинают стесняться, закрываться, если в тестирование идут. Нет, тестировщик должен уметь разговаривать и доказывать свою позицию.

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

Если планируете искать работу в России, всегда можно рассмотреть государственные проекты: много чего появляется в сфере медицины, «Умный город», «Госуслуги» и т. д.

Евгений Сабиров, QA Guild Lead в Точка:

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

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

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

Заключение

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

Чтобы получить первую работу, учиться и отрабатывать навыки можно самостоятельно. А можно пройти курсы, на которых вы не только погрузитесь в теорию, но и сможете на практике отработать навыки.

Например, на Хекслете. С нуля до тестировщика за 4 месяца: узнайте больше о профессии «Инженер по тестированию» и программе обучения на сайте.

Дополнительные материалы:

• Статья: Тестирование приложений: описание и чек-лист
• Статья: Как проверить качество кода: функциональное и нефункциональное тестирование
• Статья: Чек-лист по тестированию веб-форм
• Статья: Как пройти собеседование на тестировщика: все этапы и вопросы
• Статья на Хабре: Каких ответов я жду на собеседовании по тестированию
• Портал https://software-testing.ru/
• Книга: «Как тестируют в Google», Джеймс Уиттакер, Джейсон Арбон и Джефф Каролло

Изучите ручное тестирование на Хекслете
На Хекслете есть профессия «Инженер по тестированию». Освойте ее и познакомьтесь с этапами разработки и жизненным циклом ПО, техниками тест-дизайна, системами управления тестированием и системами баг-трекинга.

Стать инженером по тестированию

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

Рассказываем о том, что ждет тестировщика на работе, какие основные этапы, методы и виды тестирования нужно понимать, а также стоит ли бояться автотестов.

Чем занимается мануальный тестировщик?

Ручное тестирование — это процесс поиска ошибок в программе без использования специальных ПО, силами человека. Тестировщик имитирует реальные действия пользователя и старается охватить максимум функций продукта и найти ошибки (на языке QA — «баги»). Специалист по QA ищет недоработки в визуале, функционале, логике ПО, проверяет его надежность и удобство. Все найденные ошибки QA фиксирует в баг-репорте — отчете о тестировании, по которому разработчики будут исправлять недочеты. 

Из каких шагов состоит ручное тестирование? 

1. Читаем документацию и работаем с требованиями. Тестировщики узнают, как должно работать ПО, чего от него ждут разработчики и бизнес. На этом этапе QA-инженер может добавить требования, если они неполные, и сократить, если они невыполнимы.
2. Планируем тестирование. Определяем объем работы, бюджет, выбираем методы, типы и инструменты. 
3. Разрабатываем тестовые сценарии. Специалисты создают тест-кейсы — алгоритм проверки ПО, а также чек-листы и готовят среду для выполнения тестов. 
4. Проводим первое тестирование. Команда выполняет тесты и сообщает разработчикам об ошибках. 
5. Делаем повторное тестирование. Когда программисты исправили ошибки, тестирование повторяют, чтобы проверить, что после изменений все работает.
6. Готовим отчет о результатах. В итоговом документе описывают все тесты, выполненные во время разработки программы.

Какие есть виды ручного тестирования?

Модульное тестирование (Unit-тесты) предполагает проверку отдельных компонентов ПО или частей кода. Это эффективный способ тестирования, если готовое приложение обновляют или дополняют функционалом. Если добавить новые модули, ошибки в них могут повлиять на работу других, уже налаженных и протестированных частей программы. Вместо того чтобы ломать сервис таким образом, можно сначала протестировать модуль отдельно, а потом добавить его в систему.

Интеграционное тестирование (Integration Testing) проверяет, как отдельные части приложения работают вместе. Часто бывает, что страницу авторизации и личный кабинет приложения программируют разные специалисты. Их инструменты и подходы могут отличаться, из-за этого конечный сервис может работать с ошибками. На этом этапе уже не нужно проверять отдельные элементы, например страницу авторизации, — вы уже сделали это unit-тестом. Здесь важно запустить разные элементы в группе и проверить, что они работают корректно. Например, что авторизация запускает процесс создания личного кабинета и все данные пользователя в нем отражаются правильно. 

Системное тестирование (System Testing) нужно, чтобы понять, соответствует ли ПО исходным техническим требованиям. Это этап, когда модульные и интеграционные тесты уже прошли. Теперь время смотреть на готовый продукт, кликать по кнопкам, проверять, что все работает как задумано, сервисом удобно и приятно пользоваться. 

Приемочное тестирование (Acceptance Testing) проверяет, подходит ли приложение под требования бизнеса. На этом этапе тестировщики исследуют поведение пользователей и производительность системы. 

Что такое черный, белый и серый ящики?

Так называются методы тестирования. Они отражают то, сколько знает тестировщик о продукте на старте работы. Разберем каждый подход подробнее. 

Тестирование «черного ящика» (Black Box Testing) — метод, в котором тестировщик ничего не знает о коде или структуре продукта. QA работает с программой как конечный пользователь. Этим методом проверяют функциональность: делает ли приложение то, что должно? 

Например, в интернет магазине важно проверить поиск товаров, фильтрацию результатов выдачи, возможность добавить продукты в корзину, ввести промокоды и оформить заказ. Иногда функции сервиса выглядят идеально в коде, но не работают на практике. В этом случае тестирование «черного ящика» помогает выявить баги, незаметные при проверке только кодовой части ПО. 

Тестирование «белого ящика» (White Box Testing), также известное как glass box или прозрачное тестирование, — это, по сути, проверка исходного кода. Тестировщик анализирует блоки системы по отдельности и ищет проблемы. 

Например, прозрачным тестированием можно проверить формы ввода контактов пользователя в интернет-магазине. Со стороны пользователя это выглядит так: вы нажали кнопку, email-адрес отправился в базу подписчиков магазина, вам на почту пришло письмо с промокодом на скидку. Если тестировать эту часть «черным ящиком», вы можете нажать на кнопку и не получить никакого письма. Зафиксировали баг, тест заканчивается. Методом «белого ящика» можно выявить, почему это происходит. QA-специалист смотрит, чтобы на уровне кода форма была надежно защищена от взлома и данные пользователей не утекли в руки мошенников. Также он следит, чтобы адрес почты отправился в базу данных, а дальше запустился процесс автоматической рассылки новостей об акциях и промокодах. 

Тестирование «серого ящика» (Grey Box Testing) объединяет методы тестирования «белого» и «черного ящика». Цель этого подхода — найти любые ошибки в пользовательском интерфейсе или в разработке. У тестировщика нет доступа к коду приложения, но он знает общую структуру сервиса и его ограничения.

Для примера вернемся к форме в интернет-магазине. Например, при оформлении заказа нужно ввести имя и фамилию, тестировщику нужно проверить работу текстовых полей. QA знает, что у системы есть ограничение по длине фамилии, например, в 100 символов. Задача тестировщика — найти фамилии длиннее 100 символов (самая длинная в книге рекордов Гиннеса состоит из 700). Также он должен проверить, как будет вести себя система, если ввести в поле больше 100 букв. Приложение должно как минимум не ломаться и выдавать уведомление об ошибке.

Заменят ли мануальных QA автотесты?

Несмотря на то, что работодатели заинтересованы в специалистах, которые умеют автоматизировать процессы, от QA-инженеров по-прежнему ждут опыта в ручном тестировании. Почему этот навык так важен?

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

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

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

Кто такой Manual Software QA Engineer? Что он делает в свой рабочий день? Кому подходит такая работа и почему она так популярна?

Software QA Engineer, так же известный как QA Tester, Manual Tester, Blackbox Tester, Functional Tester, UI Tester — под всеми этими профессиями скрывается один человек — тестировщик ПО.

Manual QA Engineer — это не разработчик. Ему не придется создавать ничего самостоятельно, напротив, он имеет дело с уже конечным продуктом и отвечает за его тестирование.

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

Одно из главных преимуществ такой работы — возможность начать ее с нуля, не имея багажа IT-знаний, профильного образования или «технического склада ума», что идеально подходит для начала карьеры на новом месте: после переезда или иных перемен в жизни.

Преимущества профессии:

• В QAхорошо платят. Зарплата от 40 $ в час — реальность в любом городе США, а не только в мегаполисах Силиконовой долины.
• Здесь комфортно и стабильно. Это работа в окружении интересных людей над «живыми» задачами с хорошими условиями работы: мед. страховка, оплачиваемый отпуск, бонусы.‍
• Уровень стресса низок. Это не та работа, после которой вечером хочется забыться. Этому способствуют совместные поездки, приятные и красивые офисы, хорошая атмосфера. Ведь чаще всего софтверные компании завлекают IT-специалистов не только хорошими зарплатами, но и комфортными условиями работы.

Стандартный рабочий день QA тестировщика, как и у большинства других, длится 8 часов при 5-дневной рабочей неделе. В офис приходят как правило к 9 AM. Когда вы научитесь делать свою работу и войдете в ритм, то сможете справляться с ежедневной рутиной за 3–4 часа, а значит иметь больше свободного времени.

Макс Глубочанский, преподаватель и основатель школы Careerist:

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

Мы поможем вам в короткие сроки приобрести ту специальность, которая даст возможность жить стабильно, смело смотреть вперед и не думать о материальных проблемах!

• Запись на курсы QA Manual
• Запись на курсы QA Automation

Гид по ручному тестированию приложений: преимущества, этапы и методологии

Детально разбираем то, как проводить ручное тестирование, когда оно лучше автоматизированного, что нужно уметь тестировщику и как он может построить свою карьеру от джуниора до тест- лида. Гид подготовлен совместно с руководителем отдела тестирования компании Agima Дариной Гордеевой.

Привет! Меня зовут Дарина Гордеева. Работаю в компании AGIMA руководителем отдела почти 3 года. В области тестирования и обеспечения качества более 6 лет. За это время прошла путь от джуниора до руководителя отдела, занимаясь тестированием железа, а также мобильных и веб-приложений, автоматизацией и настройкой процессов QA. Сегодня я расскажу вам про особенности, возможности и скрытые проблемы ручного тестирования.

Напомним, что любой читатель, воспользовавшийся промословом “Хабр” может получить скидку в 10 000 рублей на понравившийся курс, а самые усидчивые и внимательные могут собрать себе скидку в 25 000 рублей, разгадывая ребусы из материалов, подготовленных совместно с агентством Agima:

• Как с первого раза попасть в AppStore: пошаговое руководство;
• 8 этапов процесса разработки интерфейса мобильного приложения;
• А/В-тесты не работают. Проверьте, что вы делаете не так.

Оперативность, гибкость, возможность импровизации и другие плюсы

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

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

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

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

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

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

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

Автотесты не позволяют проверить удобно ли использовать новые возможности приложения — проверка юзабилити всегда осуществляется вручную.

Skillbox рекомендует: онлайн-курс Fullstack-мобильный разработчик.

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

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

Проблемы ручного тестирования и их решения

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

Один и тот же сценарий два тестировщика могут проверить разными способами. Что с этим делать? Важно, чтобы каждый непредусмотренный или отличающийся от ожидаемого результат был зафиксирован в виде кейса. Чтобы любой тестировщик мог проверить его, совершив тот же набор действий. Но и этого может быть мало — если кейс окажется недостаточно подробным, а тестировщик — не разберётся в описании. Гарантировать стопроцентное исключение человеческого фактора, конечно, невозможно — но можно постараться максимально снизить вероятность проблем, которые он вызывает.

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

Усугубляет ситуацию вероятность того, что часть встреченных багов ещё не будет иметь строгого описания потому что причины их возникновения пока не понятны. Как бороться с такими повторными тестированиями? Либо найти уже источник ошибки и устранить его, либо — всё таки автоматизировать прохождение проблемных кейсов — в этом случае переход к программным тестам будет вполне оправдан как с точки зрения времени, так и финансово. (Нет, это не противоречит вышесказанному — потому что такие ситуации возникают уже в ходе активной разработки и к этому времени вы уже в любом случае развернёте процессы автотестирования).

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

При этом нельзя забывать несколько вещей:

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

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

Этапы тестирования: что, когда и как

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

Тестировщик появляется в процессе создания приложения уже на ранних этапах. Вот у клиента появляется некая идея, бизнес-аналитики собирают из этого требования — а тестировщики уже в этот момент приступают к работе, проверяя эти требования.

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

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

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

Skillbox рекомендует: онлайн-курс Дизайн мобильных приложений

С началом разработки QA-специалисты сразу же приступают к написанию тест-кейсов. На разных этапах разработки они могут обладать различным уровнем детализации, но к её окончанию желательно обеспечить максимальное покрытие кейсами всего продукта, чтобы, получив сборку, можно было приступить к тестированию немедленно.

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

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

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

Следующий этап — проведение регресс-тестов. В ручном или автоматическом режиме проводится основной заранее запланированный массив тестов.

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

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

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

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

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

Но на этом работа QA-специалиста не заканчивается — ему предстоит тестировать обновления приложения и их совместимость с более ранними версиями, составлять кейсы для проверки нововведений и, в случае необходимости, автоматизировать прохождение этих сценариев.

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

Время ребуса: отгадайте его и десятипроцентная скидка на любой из курсов Skillbox ждёт вас прямо сейчас или проявите усидчивость и соберите ответы на все ребусы — эти скидки суммируются между собой (но ни с какими другими скидками на курсы Skillbox).

Однако, слишком медлить не стоит — промо работает до 30 августа 2018 года. Напомним, что тематика загадки — мобайл, а английские слова могут мешаться здесь с русскими, так что будьте внимательны! Отправьте заявку на курс, и когда с вами свяжется менеджер — назовите ему промослово, зашифрованное в ребусе (или — несколько!).

Формализация тестирования: тест-план, формат баг-репортов, отчётность

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

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

Финальной отмашкой, свидетельствующей о том, что продукт готов является статус “все требования покрыты кейсами, все кейсы пройдены успешно”.

Кроме того, в тест-плане формализуется формат отчёта по ошибкам. Это может быть баг-лист, список задач в трекере.

Задача тестировщика — предоставить наиболее полную информацию о качестве продукта всем участникам команды.

Что нужно знать и уметь, чтобы стать тестировщиком

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

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

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

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

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

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

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

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

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

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

Skillbox рекомендует:

• Управление digital-проектами;
• Анимация интерфейсов;
• UX- дизайн.