Quality assurance что это

Кто такой QA-инженер, чем он занимается и сколько зарабатывает

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

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

АЛЬМИРА НИЗАМОВА

Благодарим Никиту Балясного, senior QA-инженера в М.Видео и эксперта Нетологии, за помощь в подготовке материала.

Кто такой QA-инженер и чем он отличается от тестировщика ПО

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

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

QA-инженеров часто путают с тестировщиками, хотя эти профессии сильно отличаются друг от друга.

Если тестировщик проверяет работу уже готового или почти готового продукта, то QA-инженер обеспечивает качество на протяжении всего жизненного цикла ПО.

С точки зрения функций тестировщик — более узкоспециализированный специалист.

Никита Балясный

Senior QA-инженер в М.Видео

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

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

QA-инженеры бывают ручными и автоматизированными.

Ручные QA не пишут код — все действия они выполняют руками с помощью клавиатуры, мышки и дополнительных инструментов.

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

Где работает и какие задачи решает QA-инженер

QA-инженеры востребованы в самых разных областях: финтех, телекоммуникации, ритейл, медицина, образование, госсектор, логистика и маркетинг.

Вне зависимости от того, в какой компании работает специалист, он выполняет примерно одни и те же задачи:

• Анализирует техническую документацию и требования к продукту на этапе проектирования ПО.
• Разрабатывает сценарии тестирования.
• Тестирует MVP — Minimum Viable Product — самую примитивную версию продукта, которая уже может привлечь первых пользователей.
• Создаёт метрики качества ПО. Их можно разделить на два вида: внутренние и внешние. К первым относят свойства продукта, которые видны только команде проекта: метрики размера, сложности и стиля. Внешние — это свойства, видимые пользователям. Здесь выделяют метрики надёжности, функциональности, применимости и стоимости продукта.
• Фиксирует найденные ошибки.
• Отслеживает процессы исправления багов и ошибок.
• Повторно анализирует качество ПО.
• Проводит мониторинг метрик качества.

За счёт новых гибких методологий разработки ПО QA-инженер работает в тесной связке со всей командой проекта: тестировщиками, разработчиками, аналитиками, менеджерами. Иногда QA взаимодействует и с другими специалистами, например, системными администраторами и DevOps-инженерами.

Никита Балясный

Senior QA-инженер в М.Видео

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

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

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

Какие знания и навыки нужны QA-инженеру

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

Знание языка программирования

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

Понимание основ теории тестирования и тест-дизайна

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

Чеклист — краткое обозначение действий, которые необходимо проверить.

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

Знание методологий разработки Scrum и Kanban

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

Scrum в основном используют при разработке ПО силами небольшой команды. Работа делится на короткие временные отрезки — спринты — и чётко распределяется между участниками проекта.

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

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

Разбираемся в Scrum и Kanban

Понимание устройства компьютера и основ операционной систем Linux, Windows, Mac OS

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

Способность работать с баг-трекингами Jira и YouTrack

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

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

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

Чаще всего QA-специалисты используют именно Jira, но иногда в работе применяют и её аналоги: YouTrack, Redmine, Trello.

Умение работать с фреймворком Selenium Web Driver

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

Среди софт-скиллов QA-инженера можно выделить ↓

Умение мыслить аналитически

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

Грамотный тайм-менеджмент и стрессоустойчивость

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

Умение выстраивать здоровые рабочие отношения и аргументировать свою позицию

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

Усидчивость

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

Самообучаемость

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

Профессия

Инженер по тестированию: с нуля до middle

Узнать больше

• Освоите IT-профессию, для которой не требуется опыт и техническое образование
• Изучите ручное и автоматизированное тестирование, а также языки программирования: Java, JavaScript и Python
• Начнёте работать уже через 2 месяца обучения

Сколько зарабатывает QA-инженер

Работа junior-, middle- и senior-специалистов в области QA оплачивается по-разному. В России специалист с минимальным опытом работы в ручном тестировании может рассчитывать на зарплату в 70 тысяч рублей с полной занятостью:

Профессионалы-автоматизаторы более высоких грейдов — middle и senior — зарабатывают больше:

В свою очередь, QA-инженеры в США получают около 82 тысяч долларов в год, то есть примерно 6,1 тысячи долларов в месяц. Эта цифра актуальна на конец 2021 года.

Никита Балясный

Senior QA-инженер в М.Видео

Судя по вакансиям QA-инженеров в стране, средняя зарплата junior-специалистов в ручном тестировании составляет 50 тысяч рублей, то есть вилка — от 30 до 70 тысяч. У автоматизаторов цифра чуть выше — 60 тысяч.

Что касается middle-инженеров, то они могут рассчитывать на зарплату в районе 100 тысяч рублей, автоматизаторы — 120 тысяч.

Предложения по работе для senior-специалистов начинаются с зарплаты от 180 тысяч, предела может и не быть. Иногда в индустрии выделяют отдельно лидов: это плюс 30–40 тысяч рублей к ежемесячному доходу.

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

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

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

В этом случае стоит обратить внимание на образовательные программы в МГУ, МФТИ, Высшей школе экономики, Санкт-Петербургском государственном университете. Так, в ВШЭ на совместном факультете университета и Яндекса есть бакалавриат «Прикладная математика и информатика», который готовит инженеров-разработчиков и инженеров-исследователей по программному обеспечению. Также хорошую базу можно получить на программе «Фундаментальная информатика и информационные технологии» факультета вычислительной математики и кибернетики МГУ.

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

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

Никита Балясный

Senior QA-инженер в М.Видео

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

В программе курса «Инженер по тестированию: с нуля до middle» Нетологии акцент сделан именно на практику, и все упражнения основаны на реальных задачах QA-инженера.

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

Что такое качество. Разбираемся в иерархии терминов «QA», «QC» и «тестирование»

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

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

Ниже результаты моего небольшого исследования, что же такое качество и как его обеспечить, чтобы не слушать в ответ: «Слушай, да что ты докопался, сходи на www.protesting.ru (далее – ПроТестинг), там специально для таких, как ты все написано». Поскольку про него (ПроТестинг) я слышу постоянно, я буду опираться на него.

Основные понятия и определения

Процитирую определения SQ с ПроТестинга:

Качество программного обеспечения (Software Quality) – это степень, в которой программное обеспечение обладает требуемой комбинацией свойств. [1061-1998 IEEE Standard for Software Quality Metrics Methodology]

Качество программного обеспечения (Software Quality) – это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. [ISO 8402:1994 Quality management and quality assurance]

Хочу обратить внимание на годы, которые я выделил жирным. Стандарты, откуда взяты определения были выпущены больше 20 (!) лет назад. А что есть сейчас?

Ответ: ГОСТ Р ИСО 9000—2015. Тут у многих возникает реакция «Эм, а номера-то стандартов не бьются!». Верно, рекомендую погуглить самостоятельно и потратить время на изучения того, как менялись номера стандартов и один стандарт поглощал другие.

Вернемся к «Качеству». ГОСТ нам говорит следующее:

Качество (Quality) – степень соответствия совокупности присущих характеристик объекта требованиям.

Если сравнить его с предыдущими версиями, то слов стало меньше, а смысл стал более кристаллизованным. Из этого определения вытекает важный вывод: если вы не выдвинули требования, то и разговор про качество не имеет под собой основания. Качество само собой не появляется, оно требует затрат. Об этом развернуто говорится в разделе «2.2.1 Качество».

Приведу абзац из этого раздела:

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

Культура ест стратегию на завтрак? Да, но не только. Она «ест» всё, включая качество. Если вы не будете вкладываться в культуру, поощряющее качество, то можете забыть про него. Качество не может жить в отрыве от организации как системы.

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

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

И еще один абзац. Очень важный абзац:

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

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

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

Пойдем дальше и обсудим, что изменилось в определении: Обеспечение качества (Quality Assurance)

С сайта ПроТестинг:

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

Согласно ГОСТ Р ИСО 9000-2015:

Обеспечение качества (Quality Assurance): Часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.

Что мне нравится в определении ГОСТа: ушли от всей многословности про мероприятия, этапы и прочее, а сфокусировались на сути – на обеспечение уверенности. Если задуматься, то это единственное, что вы можете сделать. Гарантировать на 100% нельзя ничего. А как вы будете обеспечивать эту уверенность – напрямую зависит от корпоративной культуры и политики качества.

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

Quality Control – а вот тут начинается самое интересное! Смотрим и сравниваем, верхнее определение взято с ПроТестинга, нижнее из ГОСТа:

Контроль качества (Quality Control) – это совокупность действий, проводимых над продуктом в процессе разработки, для получения информации о его актуальном состоянии в разрезах: «готовность продукта к выпуску», «соответствие зафиксированным требованиям», «соответствие заявленному уровню качества продукта».

Управление качеством (Quality control) – часть менеджмента качества, направленная на выполнение требований к качеству.

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

Из нового определения также ушла многословность, и остался фокус на выполнение требований, что, на мой субъективный взгляд, сделало его сильно лучше, в старом варианте. В основном потому что в нем присутствовало «…для получения информации…».

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

Например, политика качества предписывает, что тест кейсы должны быть максимально полные – это обеспечение качества. А управление качеством это:

• проверка, что эти тест кейсы полные и достаточные;
• проверка, что тестирование по ним выполняется в полном объеме.

Если соотнести определения с циклом Деминга-Шухарта, то обеспечение качества = планирование, часть выполнения и часть корректировки. А управление качеством – это часть выполнения, проверка и часть корректировки.

Теперь мы поговорим о том, что такое тестирование. Ниже даны два определения, первое взято c ПроТестинга, ниже – из ISO/IEC TR 19759:2015, он же SWEBOK.

Тестирование программного обеспечения (Software Testing) – проверка соответствия между реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов, выбранном определенным образом. [IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004].

В более широком смысле, тестирование – это одна из техник контроля качества, включающая в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Software testing consists of the dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite execution domain».

Официальный перевод отсутствует, поэтому ниже я приведу свой перевод. Альтернативные версии пишите в комменты под постом.

«Тестирование программного обеспечения это проверка того, что программа обеспечивает ожидаемое поведение на конечном наборе тестовых случаев, выбранных определенным образом из бесконечного набора тестовых случаев».

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

А из всего вышесказанного получается вот такая картинка.

Пример

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

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

Знакомьтесь, компания Икс

Компания занимается продажей продуктов, дела у нее все хорошо. Сквозной процесс доставки ценности показан ниже:

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

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

Процесс поставки ценности приобрел следующий вид:

Теперь на выходе два артефакта: дистрибутив и тесты. Но возник вопрос от коллеги из ИБ: что у нас с персональными данными? В дистрибутиве их понятно нет, а в тестах? Как мы соблюдаем 152-ФЗ? А вдруг кто-то использовал свои ФИО или ФИО коллег для тестирования?

Согласно закону фамилия, имя и отчество трактуются как персональные данные. Я понимаю, что юристы тут много что могут сказать, но помните – у нас упрощенный пример.

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

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

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

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

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

Здесь переходим на следующий уровень. Рассматриваем решение нашего кейса уже с точки зрения управления качеством.

Управлением качеством

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

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

• Сотрудник поменял ФИО. Всякое бывает;
• В компанию пришел новый сотрудник.

Сразу возникает вопрос: почему не обновлять и когда информация удаляется из списка? Ответ на них один – никогда. Информация не удаляется и не обновляется, а только добавляется, таким образом мы гарантируем отсутствие ПД. Лучше, как говорится, перебдеть.

Процесс создания ценности становиться вот таким:

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

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

Обеспечение качества

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

Какие плюсы мы получаем от такого подхода:

• Обеспечиваем уверенность, что в созданных для тестирования данных не будет ФИО сотрудников. В самой процедуре реализованы проверки на то, что созданные ФИО отсутствуют в списке ФИО сотрудников;
• Гарантируем, что они не будут похожи на «человеческие». Очень хорошая практика + еще одна ступень уверенности. Например, ФИО могут быть созданы в эльфийском стиле;
• Гарантируем, что в них будут внедрены сигнатуры для быстрой скриптовой идентификации. Например, в начало и в конец вставлять букву «й»;
• Обеспечиваем единую точку поставки тестовых данных;
• Всё есть код! Обеспечивается прозрачный контроль над алгоритмом создания тестовых данных;
• Приятный бонус: мы можем использовать наши процессы для обеспечения качества кода. Например, любые изменения возможно только после одобрения ИБ запроса на изменение.

Все эти меры обеспечивают нам уверенность в том, что требование «В поставляемых тестах отсутствуют персональные данные» будет выполнено. Но важно понимать, что это никак не отменяет тестирования выходных данных на наличие ПД.

Заключение

Определения не отлиты в граните, они меняются. То, что было справедливо в 1999 году, в 2022 может оказаться совершенно устаревшим. Одни стандарты сменяются другими, значения терминов изменяются со временем. Нам остаётся это только принять.

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

• Качество программного обеспечения
• software quality
• гост
• качество по
• обеспечение качества
• quality assurance
• управление качеством
• quality control
• тестирование по
• software testing

• Блог компании Ростелеком
• Тестирование IT-систем
• Терминология IT

QA инженер (QA Engineer) — обязанности и что должен знать

QA – это расшифровывается, как “обеспечение качества” (от англ. Quality Assurance).

QA-инженер (QA-engineer) – это специалист по обеспечению качества разработки ПО (программного обеспечения) и его функционального тестирования.

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

QA — легкий старт для IT карьеры

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

Обязанности QA инженера

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

Если углубиться в профессию, то у QA-инженеров существует несколько ответвлений.

• QA-автоматизатор (Automation QA Engineer) — это специалист, который пишет тесты на основе скриптов для автоматизации тестирования.
• QA-мануальщик (Manual QA Engineer) — специалист, который занимается анализом и улучшением процесса тестирования.
• QC-специалисты (Quality Control specialist) — отвечают за контроль качества продукта. Их задача проводить анализ результатов тестирования и следить за выявлением и устранением дефектов в продукте.

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

• • Test Analyst — проверяет, насколько требования полны и не противоречат друг другу;
  • Test Designer — занимается созданием тестов и их конфигурацией для тестирования;
  • Test Executor — проводит тестирования по написанным сценариям и фиксирует найденные ошибки;
  • Test Manager — занимается планированием работ, связанных с тестированием. В его задачи входит: оценка сроков, контроль выполнения плана и графика работ, контроль полноты выполнения тестов по списку требований, постановка задач членам команды).

  Как это может выглядеть на практике?

  Во время процесса разработки, QA-инженер контактирует со множеством людей, которые работают над проектом и над разрабатываемом ПО.

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

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

  Инструменты для QA-инженеров

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

  • Selenium — Бесплатный инструмент, который используется для автоматизированного тестирования web-приложений. Поддерживает все известные браузеры разных операционных систем: Windows, Linux, Mac, а также позволяет писать сценарии тестирования на основных языках программирования. Однако, selenium имеет ограниченный функционал и предназначен только для тестирования веб-приложений.
  • Katalon Studio — также бесплатный инструмент, который используется для автоматизированного тестирования web и мобильных приложений. Подходит для новичков и для опытных тестировщиков. Поддерживает систему CI — технология непрерывной интеграции. Однако, Katalon Studio не выдает детальных отчетов, поддерживает небольшое кол-во языков программирования и позволяет запускать несколько тестов сразу.
  • UFT — платный инструмент, который применяется для написание тестов, и также используется для автоматизации тестирования программного обеспечения за счет поддержки скриптов. Позволяет тестировать большое кол-во различных приложений. Главное преимущество UFT в том, что здесь поддерживается запись действий пользователя, что позволяет экономить время на написание новых сценариев тестирования.
  • IBM Rational Functional Tester — инструмент для автоматизации процесса тестирования приложений HTML, Java™, Dojo, Ajax, Microsoft Windows, Microsoft .NET, Microsoft Silverlight, Microsoft Visual Basic, Siebel, Flex, GEF и PowerBuilder, которые выполняются в ОС Microsoft Windows и Linux. Здесь, так же, можно записывать и воспроизводить действия пользователей, а также сценарии для тестирования новых компоновок приложения или ПО. Но полноценное функционирование раскрывается только в IBM среде.
  • TestComplete — еще один инструмент для автоматизированных тестирований десктопных, веб и мобильных приложений. Поддерживает большое количество языков программирования такие, как VBScript, JScript, DelphiScript, C++Script, C#Script, и тестируемых приложений .NET, Java, Visual C++, Visual Basic, Delphi, C++Builder. Также позволяет записывать и воспроизводить действия пользователей и выполнять различные виды тестирования.

  Необходимые навыки и что должен знать QA-инженер

  • понимание жизненного цикла и этапов разработки ПО;
  • ориентироваться в кодах программирования;
  • владеть новыми технологиями в области тестирования и знаниями актуальных инструментов для проведения ручного и автоматического тестирования;
  • относительно высокий уровень английского языка;
  • знание систем bug-трэкинга (bug tracking system) таких, как Jira/YouTrack, например;
  • уверенно работать с протоколом HTTP и его кодами ответов сервера;
  • умение работать программный интерфейсом DOM;
  • понимание объектно-ориентированного программирования (ООП);
  • знание языков HTML и данных JSON;
  • умение работать с данными cookie & session;
  • знание SQL;
  • умение вести тестовую документацию;
  • понимание Agile/SCRUM/Lean методов;
  • знание и понимание системы CI&CD: программ GitLab, Docker, Kubernetes или их аналогов;
  • понимание Microservice Arhitecture, HighLoad;
  • умение работать с инструментами и методами обработки BigData;
  • тестирование программных решений на основе технологического стека (GoLang и/или php (symfony), PostgreSQL и/или Clickhouse);
  • навык составления тест-планов и тест-кейсов.

  Преимущества и недостатки профессии QA-инженера

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

  Этапы профессионального роста QA Engineer

  1. Trainee QA Engineer — уровень начинающего QA-инженера с минимальным опытом работы.
  2. Junior QA Engineer — специалист, имеющий опыт работы до 6 месяцев и уже имеющий определенные навыки.
  3. Middle QA Engineer — инженер с опытом работы 1-3 года (средняя степень квалификации). Знает, как выполнять поставленные задачи (составления сценариев тестирования, ведение технической документации) и способен консультировать начинающих сотрудников.
  4. Senior QA Engineer — инженер высшей степени квалификации, умеющий выполнять сложные технические задачи.

  Курсы для QA инженеров на LinuxTrainingCenter

  LinuxTrainingCenter предоставляеют обучение для QA Engineer и предлагает пройти следующие курсы:

  • Курс администрирования linux LPIC-1 и Курс администрирования linux LPIC-2 — это база для дальнейшей работы в любой IT специальности. Практически все программные продукты (особенно их серверные части, с которым возникает большинство проблем у QA инженеров) пишутся для Linux. Как QA инженер, Вы должны уметь поставить, проверить что процесс запущен, убедиться что процесс работает без ошибок, а если ошибки есть — найти их причину и т.д. Из нашего опыта, если QA инженер не обладает минимальными знаниями в Linux, он становиться головной болью для всех команд. Поэтому, без знания и навыков работы в Linux будет крайне затруднительно пройти собеседование. Дополнительный бонус от изучения Linux — вся современная микросервисная архитектура приложений базируется на docker, kubernetes и т.д , но основа каждого контейнера — это Linux с установленными внутрь пакетами и запущенным приложением. Зная Linux, вы всегда сможете зайти внутрь контейнера и найти причину ошибок.
  • Курс GIT для начинающих. Начальный навык работы с GIT даст Вам возможность тестировать различные бранчи и девелоперские фичи и фиксы до их релиза.
  • Курсы Jenkins. Начальный навык работы с Jenkins даст возможность самостоятельно собирать новые билды, автоматизировать тесты, встраивать тесты в релиз, получать логи каждого теста и прочее.

  В совокупности, пройденные у нас курсы, дадут для современного QA специалиста представление и понимание о процессе непрерывной интеграции CI и существенно повысят шансы трудоустройства.

  Различия между контролем качества и обеспечением качества в IT

  

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

  Что такое QA и QC?

  

  В англоязычной IT-среде эти понятия нередко используются в связке — “QC and QA”. На первый взгляд оба процесса похожи, и из-за этого их часто путают между собой как клиенты, так иногда и даже компании-разработчики. На самом же деле эти процессы существенно отличаются, имеют разные цели и задачи, и даже проводятся на разных этапах жизненного цикла ПО. Давайте же выясним, чем отличается QA от QС.

  QA или Quality Assurance в переводе означает обеспечение качества, и на самом деле это определение во многом объясняет само понятие. Quality assurance нацелено на отладку процессов таким образом, чтобы обеспечить максимальное качество разрабатываемого продукта и предотвратить появление ошибок и сбоев.

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

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

  Давайте подробнее рассмотрим каждый из подходов к менеджменту качества программных продуктов.

  QA – Обеспечение качества программного обеспечения

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

  

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

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

  Базовые задачи

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

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

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

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

  QC – Контроль качества программного продукта

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

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

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

  Базовые задачи

  Главная задача QC — это контроль качества, осуществляемый посредством в первую очередь тестирования продукта. Для этого существует отдельная команда, которая создает и проводит ряд тестов для комплексной проверки продукта.

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

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

  Основные отличия QA и QC

  

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

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

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

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

  Фокус и направление процессов также отличаются: quality assurance фокусируется на процессе и направлен на предотвращение отклонений от понятия качества, а quality control фокусируется на результате и направлен на обнаружение и исправление дефектов.

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

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

  Выводы

  Обеспечение и контроль качества, или Quality assurance и quality control — это два подхода к управлению качеством во время разработки программных продуктов. На первый взгляд эти понятия практически неразличимы, но на самом деле они разные:

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

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

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

  Чтобы заказать разработку программного решения в WEZOM , оставьте заявку на сайте и наш менеджер перезвонит вам в ближайшее время.

  Похожие публикации:

  1. Как найти пересечение нескольких множеств питон
  2. Как найти работу проджект менеджеру
  3. Как сделать из файла ссылку
  4. Как удалить миграцию