Qa department что это

Кто такой хороший QA?

Начнем с того, что в народе всех quality assurance инженеров (“по-нашенски”, инженеров отдела качества) обзывают тестировщиками. Это не совсем правильно, в реальности тестирование — это только часть задач QA, но кого бы это волновало. Поэтому пойдем в общем тренде и будем использовать привычное всем погоняло.

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

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

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

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

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

Тестирование и не только

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

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

Вы уже понимаете, что история на этом не кончается.

Тестировщик попытался объяснить пользователю, в чем тот не прав, нарвавшись на порцию негатива и негодования. Пользователь усадил его рядом и открыл требования, на основе которых писались спецификации. Одно из этих требований почти дословно гласило следующее: ”Атрибут должен отображаться на каждом экране”. Одно предложение, а сколько смысла! Затем он открыл приложение и начал рандомно навигироваться на разные экраны, приговаривая: “И где же этот атрибут?”. Понятное дело, что пользователь откровенно издевался, но формально он имел на это право. Беда в том, что дальше пошла эскалация, и в процесс обсуждения проблемы вовлекалось все больше народу. Под конец пользователя убеждали, кроме самого тестировщика, несколько ПМов и толпа аналитиков, а тот был непреклонен и требовал уже невозможного.

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

Без фанатизма

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

Заходит однажды тестировщик в бар.
Забегает в бар.
Пролезает в бар.
Танцуя, проникает в бар.
Крадется в бар.
Врывается в бар.
Прыгает в бар.

Заказывает:
кружку пива,
2 кружки пива,
0 кружек пива,
999999999 кружек пива,
ящерицу в стакане,
–1 кружку пива,
qwerty кружек пива.

Первый реальный клиент заходит в бар и спрашивает, где туалет. Бар вспыхивает пламенем, все погибают.

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

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

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

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

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

Язык мой — враг мой

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

Что это все за собой влечет? Тут ответ и ежу понятен, но на примерах, конечно, интереснее.

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

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

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

Личное пространство

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

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

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

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

Организационные моменты

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

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

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

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

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

Заключение

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

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

• Тестирование
• Тестирование ПО
• QA
• QA testing
• QA Engineer
• Тестировщик
• Quality Assurance
• Quality Assurance Engineer
• Хороший тестировщик
• Инженер Отдела Качества

• Блог компании Haulmont
• Тестирование IT-систем
• Карьера в IT-индустрии

Чем занимается Lead QA в IT-компании Just AI?

Елизавета Борщ Lead QA в компании Just AI.

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

Освойте профессию
«Тестировщик-автоматизатор»

Чем занимается QA-инженер в IT-компании

QA-инженер (Quality Assurance) обеспечивает качество на всех этапах разработки, начиная с требований, а тестировщик контролирует это качество. Моя должность в компании — Lead QA. Я занимаюсь как практическими задачами: провожу ручное и автоматизированное тестирование, пишу и делаю ревью документации, — так и организационными, например собеседую кандидатов. Улучшение качества продуктов — это непрерывный процесс, в который вовлечен весь департамент разработки. За этим процессом нужно постоянно следить , поэтому сейчас, например, проводится аудит тестирования, который должен помочь выявить слабые места.

Профессия / 16 месяцев
Тестировщик-автоматизатор
Лучший выбор для быстрого старта в IT
3 790 ₽/мес 6 317 ₽/мес

Департамент разработки состоит из кроссфункциональных команд, в каждой из которых есть backend— и frontend-разработчики, несколько QA-инженеров и DevOps, то есть QA не выделены в обособленную команду, они находятся максимально близко к процессу разработки. Все тесно взаимодействуют друг с другом, это позволяет подстраиваться под нужные скорости, чтобы реализовать новые фичи. Разработка ведется по нескольким направлениям: JAICP, Aimylogic, JAICF. Aimylogic — визуальный конструктор ботов и голосовых ассистентов, JAICP — это платформа корпоративного уровня, на которой можно разрабатывать разговорные решения любой сложности на JavaScript и Kotlin. JAICF — это фреймворк с открытым исходным кодом для разработки ботов на Kotlin. Продукты имеют более 20 различных интеграций: с платформами Яндекс.Алисы, Маруси от VK (ранее Mail.Ru Group), SmartMarket, мессенджерами, соцсетями.

На каких этапах нужно тестирование

Мы начинаем с тестирования требований. Чем раньше мы обнаружим проблему, тем дешевле ее исправить. На встрече с продакт-менеджерами мы обсуждаем возможность реализации новых фичей, требования, критерии конечного результата, задаем наводящие вопросы, подсвечиваем трудности. QA-инженер пишет тестовую документацию — это база знаний, набор кейсов, чек-листов, тест-планов, тестовых стратегий, инструкции, по которым QA может пройтись и проверить работоспособность функциональности. Для удобного хранения документации мы пользуемся TestRail — это инструмент для управления тестированием. Если всех устраивают критерии, задача переходит в разработку, команда ее оценивает, декомпозирует и приступает к реализации. Когда требования нужно доработать, мы возвращаем задачу заказчику. QA обязательно принимает участие в этом процессе, так как у него достаточный уровень экспертизы и он может предугадать потенциальную проблему. Когда требования утверждены, их передают на реализацию. После этого задачу тестируют. На этом этапе проводится функциональное тестирование (проверка того, как продукт выполняет свои функции) и тестирование юзабилити (интерфейса); если нужно, проводят еще и нагрузочное (проверка того, выдержит ли система повышенные нагрузки). Тестировщик смотрит негативные кейсы, то, как функциональность встроится в систему, и многое другое. В процессе тестирования заводятся баги в Jira, разработчики их фиксят и отдают на ретест (повторный тест).

Читайте также Кто такой тестировщик и чем он занимается

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

• мануальные проверки. QA вручную сверяются с тестовой документацией, проходят по всем кейсам;
• автоматические проверки. Можно имитировать пользовательские сценарии, прокликивать стандартные действия конечного пользователя — это работа с frontend. Или проверять backend в рамках интеграционного тестирования (взаимодействие нескольких модулей между собой).

После регрессии релиз-кандидаты направляются на стейдж. Это специальное место, которое недоступно пользователям и имитирует продакшн. На этом этапе мы берем копии больших реальных данных и проводим PDV (Post deployment Verification — набор проверок, который позволяет убедиться в работоспособности системы). После этого релиз уходит в боевое окружение/прод.

Какие виды тестирования бывают

Видов тестирования очень много, все зависит от специфики проекта.

Один из основных видов — функциональное тестирование, так как оно учитывает сразу несколько аспектов, например требования и бизнес-кейсы (use-case). Кроме того, проверяем UI (пользовательский интерфейс), тестируем удобство использования. Все это важно, ведь уровень качества интерфейса показывает наше отношение и заботу о пользователе.

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

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

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

Как определять баг

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

Важный инструмент тестирования — логи (файлы, которые содержат в себе информацию работы сервера/компонентов/пользователя); прочитать их можно при помощи различных инструментов, один из них — Graylog (open source инструмент для сбора и анализа событий). Есть разные уровни логирования, но самые опасные, конечно, ERROR.

При тестирования веба нужно владеть еще одним инструментом — консолью DevTools, которую можно вызвать в браузере с помощью F12 или сочетания Ctrl + Shift + J. Там есть несколько полезных вкладок: network, console, где можно, например посмотреть статус ответов на разные запросы. Самые частые группы кодов, которые нужны при оформлении баг-репортов, — это 500 (ошибки сервера) и 400 (ошибка пользователя).

Станьте тестировщиком – это лучший выбор для быстрого старта в IT

Почему для QA-инженера важна коммуникация

Just AI — моя первая работа в IT. До этого я работала инженером-металлургом и проходила курс «Тестирование ПО» в Политехническом университете, но некоторые технические нюансы изучала буквально на ходу. Через пару месяцев работы мне пришла задача на обновление React. Я начала гуглить, что это, спросила у разработчика. Она сказала, что нужно проверить несколько модальных окон, селектов. Показалось, что ничего сложного.

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

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

Совет: Когда появляется проблема, нужно спокойно ее решить подручными средствами, а потом применить правило пяти «А почему?». Задав себе этот вопрос, ты дойдешь до первопричины, а затем сможешь найти решение, чтобы дальше этой ошибки не повторялось.

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

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

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

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

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

Как у нас устроен онбординг новичков

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

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

Конечно, важны и технические навыки: понимание клиент-серверной архитектуры, HTTP-протокола. Нужно уметь работать с командной строкой, знать основы Linux, принципы работы баз данных и писать хотя бы простые SQL-запросы, например на выборку данных с определенными условиями из одной или нескольких таблиц.

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

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

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

Куда расти QA-инженеру

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

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

В нашей команде есть выделенный автоматизатор, который занимается только написанием и поддержкой UI-автотестов на Kotlin. При этом остальные мануальщики как минимум могут поддерживать существующие автотесты. Некоторые, пройдя нашу внутреннюю школу автоматизации, даже пишут свои.

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

Тестировщик-автоматизатор

Как ворваться в IT, даже если вы не умеете программировать? Стать тестировщиком. Для старта достаточно базовых знаний ПК. А начать работать можно уже через 4 месяца обучения.

Кто такой QA engineer и как им стать

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

Кто же такой QA и чем он занимается?

Работа Quality Assurance engineer заключается скорее не в проверке качества (хоть это слово и присутствует в названии профессии), а в контроле за правильностью выполнения всех этапов разработки и правильностью работы итогового продукта. Звучит немного похоже на задачи тестировщика. Но тот занимается только проверкой работы приложения и по результатам (наличию багов и ошибок) принимает его или не принимает. А QA engineer также контролирует соблюдение стандартов при разработке программ, взаимодействует с разработчиками, дизайнерами, заказчиками, предотвращая само появление багов и ошибок в ПО. Правда у нас профессии тестировщика и QA чаще всего воспринимаются как единое целое.

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

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

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

Плюсы и минусы профессии

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

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

Как стать QA?

Фактически для того чтоб ступить на стезю QA не нужно знание языков программирования или строения баз данных. Главное иметь представление о структуре процесса разработки ПО и разбираться в процессе тестирования. Нужно почитать литературу (в основном зарубежную), потренироваться на “кошках” (потренироваться использовать ПК стараясь замечать все недочеты и баги в приложениях/сайтах). Для большей уверенности можно пройти пару обучающих курсов в интернете и/или стажировку в обучающих центрах (в институтах эту специальность, к сожалению, не преподают). Подтянуть английский (при отборе кадров IT компании предпочитают кандидатов со знанием английского).

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

Перспективы

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

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

10 IT-терминов на английском, которые стыдно не знать

Если вы работаете в IT-компании, аутсорсите разработчиков или используете диджитал-продукты /профессиональный софт / онлайн-сервисы, вам будет полезно знать эти 10 терминов.

Многие ошибочно полагают, что production — это производство. На самом деле production (по-русски “прод”) — это боевая среда. То есть та версия продукта, которая выложена онлайн / установлена клиенту.

▫️ When are you going to push it to production? — Когда собираетесь выложить это на прод?

2. Deployment (деплоймент или деплой)

Deployment — это выкатывание на прод. Иными словами — запуск.

▫️When do you plan the next deployment? — Когда планируете следующий релиз (=выкат на прод)?

▫️We should collect customer feedback in 2 weeks after deployment to production. — Нам нужно собрать обратную связь от клиентов через 2 недели после релиза.

3. Staging (стейджинг)

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

▫️The feature is not released yet, but you can check it on staging. — Фича еще не выпущена в продакшн, но ты можешь протестировать ее на стейдже.

4. QA (Quality Assurance) (ку-эй)

Quality Assurance — это контроль качества. Так обозначают подразделение в компании — QA Department (или Отдел тестирования) — или сотрудника-тестировщика (QA manager).

▫️Has this feature passed QA? — Эта фича прошла тестирование QA?

▫️All tests are completed and Quality Assurance signs-off this release. — Все тесты завершены, и QA-специалисты подтвердили возможность релиза.

5. Troubleshooting (траблшутинг)

Troubleshooting — это процесс диагностирования неполадки; установка причины, из-за которой возникла проблема.

Обратите внимание, что глагол troubleshoot пишется в одно слово, а его форма прошедшего времени — troubleshot.

▫️Try to disable these features to troubleshoot the problem. — Попробуйте отключить эти фичи, чтоб диагностировать проблему.

▫️They asked me to troubleshoot the equipment. — Они попросили меня установить причину неполадки в оборудовании.

▫️I’ve successfully troubleshot the problem when it occurred. — Я успешно диагностировал проблему, когда она произошла.

6. Debugging (дебагинг)

Так называют этап разработки, в ходе которого локализуют и исправляют ошибки. Debugging происходит после troubleshooting.

▫️The team found the cause of the problem and already started debugging. — Команда нашла причину проблемы и уже начала ее исправление.

7. Refactoring (рефакторинг)

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

▫️ Why should this task take you so long? — Почему это займет столько времени? — It requires a lot of refactoring. — Тут требуется рефакторинг.

8. Endpoint (эндпойнт)

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

▫️We need to create an endpoint to collect this data. — Нам нужно создать отдельный эндпойт, чтобы собирать эти данные.

9. API (апи)

Аббревиатура API расшифровывается как Application Programming Interface. Так называют вид интеграции или метод общения разных компонентов системы друг с другом.

▫️Could you please send me your API documentation? — Пожалуйста, отправьте мне вашу API-документацию.

10. Backlog (бэклог)

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

▫️ We’ll put this task in the backlog. — Мы добавим эту задачу в бэклог.