Как стать qa-инженером?

Зачем столько тестировщиков

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

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

Не успели оглянуться — и вы уже делаете массовый веб-сервис, у вас несколько сотен тысяч клиентов, а сам сервис состоит из десятков модулей. И часть модулей делают в Москве, другую часть — в Санкт-Петербурге, третью — в Екатеринбурге. У каждого офиса своя атмосфера, куча собственных нюансов и проблем. И вот это всё нужно «причесать», чтобы внутри и на стыках этих модулей не было багов. Над этим работают десятки тестировщиков, несколько QC и один большой важный QA, который управляет тестированием.

Почему тестировщик и QA не одно и то же

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

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

QA — в первую очередь инженер

Для многих это звучит непривычно и вызывает небольшое сопротивление. Не стоит нервничать 🙂 Специалист каждый новый таск воспринимает, как челлендж, рвется его преодолеть с помощью имеющегося тулсета? Поздравляем, Вы нашли идеального QA. Столкнувшись с незнакомой задачей, тестировщик скажет: «Я такого не умею. Найдите того, кто умеет», а инженер ответит: «Дайте я разберусь и объясню, как могу решить эту задачу». В моей команде есть несколько специалистов, которые постепенно начали разделять и поддерживать этот подход. В тот момент, когда они приняли новые правила игры, когда страха неудачи не существует, а очередная задача — это всегда увлекательный и посильный челлендж — они стали получать от работы больше удовольствия и постоянный респект от коллег. Ребятам достаются новые, «непонятные» таски и в них они находят для себя постоянный рост.

Какие активности доступны с описанным выше складом ума? Любые! Ограничений практически нет. За любую задачу можно взяться, почерпнув из нее что-то новое. Например, виды тестирования, помимо простого мануального, это же кладезь интересных задач:

• автоматизация функциональных проверок;

• перформанс;

• секьюрити;

• аксессибилити.

Среди других активностей, могу выделить такие:

• вникание в код приложения для поиска новых вариантов проверок или отсечения дубликатных;

• применение новых техник тест-дизайна к существующим проверкам;

• построение новых пайплайнов тестирования.

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

Часть третья. Зависимость уровня оплаты труда QA-специалистов от уровня владения навыками тестирования

Какими навыками лучше всего владеют QA-специалисты?

Что должен знать каждый QA-специалист?

1. Навык локализации и заведения дефектов — Самый распространённый навык. 4 человека им совсем не владеют, 16 – плохо владеют. А 98% респондентов владеют навыком хорошо и в совершенстве.
2. Владение системами баг-трекинга (Jira, Redmine, YouTrack, Bugzilla) – также, всего 6 человек совсем не знакомы с данным навыком.
3. Клиентское тестирование веб-приложений – им хорошо или в совершенстве владеет 81% респондентов.
4. Владение системами управления знаниями и хранилищами тест-кейсов (wiki, confluence и пр.) – те же 81%, но из них только 27% в совершенстве.
5. Владение техниками тест-анализа, тест-дизайна и тестовой комбинаторики – этим навыком 58% специалистов владеет хорошо и ещё 18% в совершенстве. Стоит ли от них отставать?

Чем можно похвастать перед работодателем/коллегами?

1. Опыт разработки скриптов нагрузочного тестирования в JMeter или аналогичных приложениях – самый редкий навык. 467 человек совсем не владеют этим навыком (46,4%). 197 человек владеют им на достаточном уровне (19,6%). Всего 49 человек владеют им в совершенстве, причем, 36 из них зарабатывают более 1500$.
2. Владение системами отчётности результатов автотестов (Allure, пр.) − на достаточном уровне владеет 204 специалиста.
3. Владение драйверами и надстройками для автоматизации тестирования – 241 специалист.
4. Владение тестовыми фреймворками для автоматизации (TestNG, JUnit и пр.) – 272 специалиста.

Интересно:

Какие навыки оплачиваются лучше всего?

Скромнее всего (до 1410$ в мес.)Недалеко от них (до 1560$ в мес.)Ещё лучше (до 1660$ в мес.)Ну, а в если вам нравится цифра 1770$Интересно:

«Непроактивность»

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

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

Субъективно, я был достаточно неплохо подготовлен для джуна, но не имел большого практического опыта. Это плюс пара ошибок по теории привело к тому, что на первом собесе мне сказали: «Не быть тебе QA!». Но! Я почти сразу попросил дать мне второй шанс. Следующие 2 недели я не только зубрил почти всё что можно, но и активно практиковался в тестировании полей, оплат, покупок, а также составлял тест-кейсы, чек-листы и тому подобное.

Но! Придя второй раз, я столкнулся далеко не с джуниорскими вопросами: спрашивали про пентестинг и всё такое. Кажется, со мной не захотели возиться. Но! Я написал другому тимлиду тестирования и сразу договорился о третьем собеседовании.

Мы просто по-человечески общались: я ответил на все вопросы, кроме одного, и был точно уверен, что меня возьмут! А в итоге «Прости, но взяли человека с опытом». Если до этого момента я не понимал, что такое «мораль ниже плинтуса», то вот тогда вкусил это в полной мере.

Моя проактивность резко упала. Я даже почти перегорел. Однако… Через месяц я попросил о четвёртом собеседовании. И в этот раз решил пойти на отчаянный шаг — попросился работать в QA на парт-тайме, хотя бы бесплатно. И ребята согласились. Теперь моей задачей было совмещать работу в техподдержке (8 часов в день) и параллельно работать Trainee QA на подхвате (4 часа в день). Я начал писать тест-кейсы, майндмэпы, тестировать что-то простое вроде правок в вёрстке, проходить тест-ран из 4000 кейсов. Сказать, что я был счастлив, — ничего не сказать.

Приходилось потеть по 12 часов в день 5 (а иногда и 6) дней в неделю на протяжении месяца, но это того стоило. Когда испытательный срок длиною в месяц подошёл к концу, меня взяли в QA! Я даже был удивлён, потому что успел продолбать один критикал, но ребята сказали, что я не знал продукт, и поэтому они дали мне шанс всё исправить.

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

Из-за моего рвения постоянно улучшать процессы меня перевели в другой отдел, я стал тимлидом команды тестирования. Около года я «лидил» команду ручного тестирования, но параллельно сам проявил инициативу и совершенствовался в автоматизации, в чём мне очень помогал коллега Андрей AndrewQA777 Шальнев. Ну а год спустя я всё-таки решил идти в хард, поэтому перешёл на фуллтайм автоматизацию. Нетрудно догадаться, что в автоматизации мне тоже сиделось крайне неспокойно: в свободное время я начал обучать других ребят автотестам, ревьюить код коллег, советовался с разработчиками, как лучше что-то написать. В какой-то момент оказалось, что я по факту руководил уже 5 проектами в автоматизации. Я вырос из «суетолога» в лида, который может аргументированно проталкивать хорошие процессы и внедрять их. Конечно, не всё сразу получалось, т.к. в начале были проблемы с расфокусом на задачах, но я научился планировать и приоритизировать их. После этого лиды всей гильдии тестирования пришли к выводу, что пора отдать мне все проекты автоматизации, чтобы улучшения происходили повсеместно.

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

Перспективы

Работа QA, как одна из относительно легких точек входа в ИТ, предлагает довольно много вариантов развития. Можно остаться в этой специальности и подняться по лестнице: junior QA, middle QA, senior QA, QA team lead, QA manager, head of QA department. Если вы больше тяготеете к программированию, но не готовы идти в программисты, то можно переключится на QA automation engineer. Тогда вы сможете попробовать свои силы в автоматизации проверки приложений.

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

Принципы тестирования

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

1. Тестирование показывает наличие дефектов

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

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

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

2. Исчерпывающее тестирование невозможно

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

3. Раннее тестирование

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

4. Скопление дефектов

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

5. Парадокс пестицида

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок.

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

И еще несколько важных принципов:

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

Есть ли у тебя какой-нибудь персональный лайфхак, который бы упростил жизнь всем QA-автоматизаторам?

АЛЕКСЕЙ ПОБОЛЬ: Если я нахожу какое-то интересное решение, то сразу документирую это на внутреннем портале, чтобы другие члены команды тратили меньше времени в будущем

ЕКАТЕРИНА ЖУКОВСКАЯ: Сложно назвать это лайфхаком, но могу сказать, что нужно уметь писать не только красивый и правильный по структуре код, но также и уметь создавать, так называемые, “костыли”. Это действительно упростит жизнь и сократит время на решение какой-то нетривиальной проблемы, где красота кода ничем не помогает, ведь это уже будет критическое мышление, основанное на опыте.

А самое главное – не нужно бояться, что ты чего-то не знаешь, главное желание и усердие. Мы учимся всю жизнь –  “Чем больше мы знаем, тем ещё больше нам придётся узнать”.

Основные функции

Автоматизация процедур контроля качества в соответствии с приказами, ОСТ и ГОСТ

• •Контроль качества количественных методов исследований и иммуноферментного анализа
• •Контроль качества по одному или нескольким контрольным материалам, по дубликатам и ежедневным средним
• •Расчет среднего стандартного отклонения, коэффициента вариации
• •Оценка сходимости, воспроизводимости и правильности результатов измерений
• •Построение контрольных карт и графиков кумулятивных сумм (cusum)

Материалы

• •Настраиваемый справочник аналитов и контрольных материалов
• •Настройка уровня материалов
• •Отслеживание срока годности

Профессия QA Engineer: кто такие и что делают

QA-инженером (Quality Assurance Engineer) называют специалиста, который занимается функциональным тестированием программного обеспечения на всех этапах разработки. Чтобы более детально говорить о Quality Assurance, нужно разобраться с терминологией.

Многие ошибочно думают, что термины Quality Assurance, Quality Control и тестирование – это синонимы. Но это неверное суждение.

• Quality Assurance (QA). QA-специалисты подготавливают и устанавливают стандарты, анализируют качество, выбирают инструменты, предотвращают ошибки и совершенствуют программу. 
• Quality Control (QC). Контроль качества продукта отвечает за анализ результатов тестирования, поиск и устранение ошибок. QC-специалисты анализируют код, технические обзоры и проверяют программу.
• Тестирование программного обеспечения (Software Testing). Тестировщики проверяют готовый продукт на соответствия установленным требованиям. 

Что должен уметь QA Engineer: основные навыки и обязанности

Теоретические знания и практические умения:

• Понимание цикла разработки ПО.
• Знание видов и уровней тестирования.
• Умение читать техническую документацию.
• Анализировать требования.
• Составлять тестовую документацию.
• Мониторинг и отслеживание правок.
• Написание и доработка сценариев тестирования.
• Составление ТЗ на устранение найденных, после тестирования недочетов.

Английский язык

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

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

Дополнительные технологии:

• Умение работать с HTML/CSS, JavaScript, jQuery и HTTP для тестирования web-приложений.
• Чтобы было легче тестировать мобильные приложения, нужно уметь работать с Genymotion, VirtualBox и iOS Simulator. 

Владение языками запроса SQL и умение работать с базами данных

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

Важные качества, на которые нужно обратить внимание при собеседовании QA-инженера

1. Аналитический ум и внимательность для обнаружения даже маленьких ошибок.
2. Стратегическое и абстрактное мышление, умение моделировать и абстрагироваться от внешних факторов.
3. Умение работать с командой, аргументированно объяснять свои решения.
4. Перфекционизм, ответственность, усидчивость.
5. Умение расставлять приоритеты, находить компромиссы, настойчивость.

Перспективы

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

Сегодня пока еще отсутствует возможность максимальной эффективной автоматизации процесса тестирование юзабилити программ или их частей. Речь идет в данном случае об игровых продуктах и мобильных приложениях, насыщенных анимацией и другими визуальными эффектами. Поэтому ручной тестировщик в течение следующие 5-10 лет не «умрет», а будет профессионально эволюционировать. Чтобы сохранить собственную востребованность как специалиста, уже сейчас желательно заняться саморазвитием, получением новых знаний и оттачиванием обретенных навыков.

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

Что входит в основной пул обязанностей QA-автоматизатора?

АЛЕКСЕЙ БЕДУНКЕВИЧ: Как ни странно, автоматизация QA процессов:

• Составление плана и стратегии
• Автоматизация тесткейсов
• Настройка CI, репортинг, и нотификация

ЕКАТЕРИНА ЖУКОВСКАЯ: Обязанности разнятся от проекта к проекту. В основном это непосредственно:

• Разработка фреймворка для автоматизации продукта и написание автотестов
• Настройка окружения, создание дополнительных условий для корректного функционирования автотестов
• Интеграция автотестов с порталами баг репортинга для последующего анализа результатов
• Интеграция с системами автозапуска (CI/CD) и с системами отслеживания версий.
• Но самая главная обязанность – любить свою работу.

Зоны ответственности QA лида

QA Lead в Miro отвечает за стратегию качества большой части продукта, реализацию крупных инженерных инициатив и развитие QA-инженеров.

QA lead как стратег

QA лид отвечает за стратегию качества в стриме. Для этого он напрямую работает с Head of Stream Engineering и Head of QA.

Работает с Head of Stream Engineering

Вместе с Head of Stream Engineering QA лид определяет видение процесса разработки в части качества в перспективе минимум на год — что нам нужно сделать, чтобы достичь цели бизнеса. Head of Stream Engineering отвечает за техническую сторону достижения целей бизнеса: масштабируемую архитектуру, предсказуемую разработку, масштабирование команды (найм) и, конечно, качество продукта.

В данном случае обеспечение качества — это не дополнительная работа, которая удлиняет t2m, это, наоборот, история про сокращение издержек. Мы хотим уделять время фичам, но тратим много времени на исправление ошибок — нужно сделать так, чтобы мы не порождали ошибки. Мы хотим, чтобы добавление кнопки заняло один день, а это занимает три недели из-за легаси в коде — нужно устранить сложный код, так как в него невозможно быстро и качественно вносить изменения. То есть при должных ограничениях качества, единственный способ ускорить t2m — это сразу делать качественнее. Этот вопрос и решает QA lead в связке с Head of Stream Engineering.

Работает с Head of QA

Однако есть не только бизнес цели стрима. Есть принципы качества, единые для всех стримов, потому что мы работаем над одним продуктом. Есть эффективные подходы и инструменты, которые можно использовать всеми стримами для экономии ресурсов. Это всё задает видение стратегии обеспечения качества на уровне компании. Head of QA помогает QA лидам совместно определять принципы и подходы.

QA lead как Project manager

Часто для решения технических инициатив в рамках всей компании формируются кросс-функциональные команды, проектным менеджером в которых становится QA лид.

Реальные примеры таких проектов:

• Обеспечить 80% покрытия тестами на разных уровнях;

• Уменьшить втрое стоимость ответа на тикеты для команды поддержки;

• Провести исследование доверия метрикам;

• Улучшить качество релизных веток на Х;

• Внедрение JS test framework для non-Canvas команд.

QA lead как People manager

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

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

Чем ещё занимается QA lead

Он проверяет на прочность всё вокруг.

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

Архитектура. Архитектура может не позволять покрывать код тестами из-за сильной связности. Это не дает гарантий надёжности изменений.

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

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

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

CI/CD в части выполнения тестов всех уровней. Если получение результатов е2е тестов занимает более 10 минут, разработчик переключает контекст на другую задачу, а это порождает издержки.

Тестирование на проде

Важно, чтобы это был действительно полезный эшелон защиты, например, chaos monkey testing. Большая проблема — когда используется тестирование на проде, потому что раньше не получается

А также:

• Нефункциональное тестирование и его автоматизация;

• Канареечные релизы и процесс анализа пропущенных до прода ошибок;

• Релизы и действия на проде;

• Мониторинг вышедших фичей и компонентов;

• Инциденты;

• Health monitoring.

Особенности профессии

Функциональные обязанности QA-инженера:

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

Обязанности QA и тестировщика

Функция QC или тестировщика ПО заключается в проверке качества продукта на последнем этапе разработки. Они могут это делать любым видом и типом тестирования  —  ручным, автоматизированным, нагрузочным, тестированием безопасности и так далее. Их основная задача предоставить полную информацию о соответствии продукта заявленным требованиям.

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

У QA или инженеров по обеспечению качества гораздо выше уровень ответственности и меньше ограничений. Они участвуют во всех этапах разработки и помогают бизнесу выпустить качественный продукт.

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

Как стать тетсировщиком ПО

Статистика зарплат для ‘QA Engineer’ по некоторым регионам

Обзор зарплат для ‘QA Engineer’ по некоторым регионам

Регион	Средняя зарплата, руб.	Медианная зарплата, руб.	Вакансий с зарплатой	Всего вакансий
Новосибирская область	121457.0	91000.0	70	187
Республика Татарстан	93222.0	77000.0	36	143
Свердловская область	89264.0	79000.0	53	138
Самарская область	95706.0	69000.0	34	107
Нижегородская область	126879.0	103000.0	33	106
Ростовская область	81720.0	63000.0	25	95
Краснодарский край	87133.0	79000.0	30	92
Московская область	78238.0	79000.0	21	58
Пермский край	51235.0	51000.0	17	53
Республика Башкортостан	83632.0	79000.0	19	41

Представляем Telegram-канал короткометражных фильмов!

Перейти к Telegram-каналу с короткометражками

Важные личные качества

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

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

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

Как стать QA-тестировщиком

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

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

Вот лучшие образовательные программы по QA-тестированию:

Курс
Школа
Стоимость со скидкой
В рассрочку
Длительность
Ссылка на курс

Профессия ТестировщикПерейти на сайт курса

Skillbox
105 732 ₽
от 5 874 ₽/мес.
12 месяцев
Курс на Skillbox

Тестировщик программного обеспеченияПерейти на сайт курса

SkillFactory
62 400 ₽
от 5 200 ₽/мес.
8 месяцев
Курс на SkillFactory

ТестировщикПерейти на сайт курса

Нетология
46 740 ₽
3895 ₽/мес.
6 месяцев
Курс на Нетология

Факультет тестирования ПОПерейти на сайт курса

GeekBrains
112 500 ₽
от 3 750 ₽/мес.
12 месяцев
Курс на GeekBrains

Автоматизированное тестирование веб-приложений на JavaScriptПерейти на сайт курса

Skillbox
55 300 ₽
4608 ₽/мес.
12 месяцев
Курс на Skillbox

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

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

Какие типы или виды тестирования используются в QA процессе?

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

Функциональные и нефункциональные тесты

Основные категории тестов — это функциональные и нефункциональные тесты.

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

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

Знание исходного кода

Если тестировщики знают исходный код до тестирования, речь идет о тестировании “белого ящика” (white box testing). В противном случае мы имеем дело с тестированием “черного ящика” (black box testing), когда тестировщики оценивают только поведение приложения, не зная его внутреннего устройства. Тестирование “серого ящика” (grey box testing) представляет собой комбинацию этих двух подходов. Тестировщикам предоставляется ограниченная информация о внутренней структуре системы.

Подход к выполнению тестов

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

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

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

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

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

Фаза разработки программного обеспечения

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

Вот еще несколько типов тестов, с которыми вы часто будете сталкиваться в публикациях:

Дымовые тесты (smoke tests) предназначены для проверки базовой функциональности приложения. Это быстро выполнимые тесты, с помощью которых тестировщики следят за тем, чтобы основные функции системы работали правильно.

Регрессионные тесты (regression tests)  помогают проверить, работает ли приложение так, как оно должно работать, после внесения каких-либо изменений, например исправления дефектов.

Нагрузочные тесты (load tests) необходимы для проверки приложения как при средней, так и при пиковой нагрузке.

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

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

Важные качества специалиста

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

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