Кто такой qa automation
Кто такой QA Engineer, QC Engineer и Software Engineer in Test
Я недавно латала дыры в понимании разницы между Quality Assuarance и Quality Control. Статей на эту тему много, я накидала свой вариант, хотелось по существу. Делюсь с вами. Enjoy, если актуально!
Кто такой QС Engineer
Должностные обязанности QC Engineer
Примерный обобщенный список:
Оценка и внедрение программного обеспечения для тестирования.
Проверка продукта на соответствие установленным требованиям и ожиданиям.
Настройка автоматического тестирования.
Поиск дефектов или ошибок, которые могут подорвать доверие покупателей к вашим продуктам.
Проверка, что конечный продукт соответствует стандартам компании, стандартам отрасли, законам.
Составление отчетов об испытаниях и проверках.
Выявление и документирование ошибок и дефектов, которые необходимо исправить перед выпуском продукта.
Выявление и документирование ошибок и дефектов, которые можно исправить после отправки продукта.
Тестирование инструкций, гайдов, документации.
Работа со специалистами по обеспечению качества.
Мониторинг поступления на рынок только высококачественной продукции.
Кто такой QA Engineer
Должностные обязанности QA Engineer
Примерный обобщенный список:
Планирование, разработка и внедрение политики, процессов и процедуры обеспечения качества.
Документирование и обновление типовых инструкций и лучших решений (best practices).
Проверка процессов, процедур и документации на соответствие правилам и стандартам.
Мониторинг текущих процессов с целью их улучшения.
Обучение производственных и инженерных групп соблюдению установленных процессов и процедур.
Анализ первопричин и внедрение решений, направленных на устранение проблем, обнаруженных в текущих процессах и процедурах.
Сбор и оценка отзывы клиентов.
ВАЖНО. Даже если в компании есть четко определенная позиция QA Engineer, обеспечивать качественный процесс, создавать качественный продукт остается обязанностью каждого участника команды.
В общем, QA Engineer, если такой есть на проекте, человек, который прицельно отследит и поможет подтянуть проседающий процесс разработки: направит, надоумит, отправит учиться или подкинет инструментов и идей.
Разница между QA и QC
Кто такой Software Engineer in Test
При ближайшем рассмотрении Software Engineer in Test у меня получилось, что это тоже QC Engineer с одной лишь разницей, что фокус его обязанностей в автоматизации тестирования и включает и разработку собственного фреймворка/инструмента, и написание автотестов:
Создание/расширение фреймворка для тестирования.
Разработка вспомогательных утилит для тестирования сервисов.
Настройка и поддержка тестового окружения.
Настройка автоматизированных тестов для надежного и эффективного выполнения в средах CI / CD.
Обеспечение оптимального покрытия автотестами на всех уровнях.
Обязанности второго плана по сути копируют список QC Engineer.
Подробнее про Software Engineer in Test можно почитать в How Google Tests Software (есть переведенная на русский)
Заключение
Полезно выяснить какой же у вас все-таки список должностных обязанностей и кого в вас видит руководство. Распространено, что руководство не различает некоторые понятия, и чаще всего ожидается, что вы два в одном QA + QC Engineer, либо в вас видят только QC Engineer.
Но кем бы вы ни были совместным итогом поступательных шагов в QA и QC всегда будут:
Кто ты, QA-инженер или тестировщик?
QA и QC — как камыш и рогоз. Конечно, есть ботаники, которые их различают, но большинство людей всё-таки путают. Иногда самим QA и QC легче согласиться с представлением обывателей, чем пускаться в долгие объяснения, в чём же всё-таки разница. Предлагаю сделать усилие над собой, разобраться с терминами и понятиями, увидеть отличия и больше никогда их не путать.
Больше трёх лет я занимаюсь обеспечением качества продуктов. И всё это время наблюдаю за эволюцией процессов тестирования в компании.
От момента зарождения, когда в команду нанимали первых двух человек. Полгода они тестировали продукт руками, а после становились бизнес-аналитиками, а за ними уже стояли следующие два человека.
До текущих процессов с блэкджеком Scrum-Less и автотестами на Selenium.
Накопленный опыт и черты характера типичные для моей профессии привели к размышлениям о том, кто такие тестировщики, QA и QC. Разные это суть сущности или пересекающиеся? В статьях и конференциях я часто сталкиваюсь с какой-то путаницей, мне это не нравится. Поэтому я решил поделиться своими мыслями на этот счёт. Осторожно, данная статья не является истиной в первой инстанции. Данная статья — мысли вслух и желание найти единомышленников.
QA, QC и тестировщики: три большие разницы?
Начнём наши поиски и копания с обращения к Международному стандарту системы менеджмента качества ISO 9000:2015. В каждой статье, в каждом видео на тему отличия этих понятий есть ссылка на этот документ, моя статья не исключение.
В пункте 3.2 стандарта раскрываются два определения:
Отмечу, что в стандарте ISO 9000:2015 вообще нет понятия tester как такового. Я искал.
Так каким же образом взаимосвязаны понятия Quality assurance, Quality control и Тестирование между собой?
Часто можно встретить такого рода иллюстрации со слоёной структурой качества, где тестирование — часть контроля качества, контроль качества — часть обеспечения качества.
Но лично мне кажется, что раз в стандарте нет понятия tester или testing, а QC — это и есть разного рода тестирование, то и иллюстрации должны быть такими:
Однако стандарт есть стандарт, а у нас тут реальная жизнь. И в реальной жизни IT-индустрии встречаются только два названия нашей профессии:
Ищу Тестировщика ПО (QA-инженера)
Я бы не писал эту статью, если бы в индустрии не смешивали эти роли и не называли тестировщиков QA-инженерами и наоборот. По моим наблюдениям, в России не разделяют две профессии. Всех для простоты (а может по незнанию) называют тестировщиками. И ладно бы таким грешили только работодатели, но путаницу поддерживают и сами тестировщики. Например, на Хабре можно встретить статьи, где авторы на протяжении всего текста называют одних и тех же людей тестировщиками, QC-инженерами, QA-специалистами, инженерами по тестированию и тестерами.
Масла в огонь подливают HR-менеджеры: часто для увеличения охвата аудитории они пишут в названии вакансии «Тестировщик ПО (QA инженер)». Шапкой вакансии дело не заканчивается, винегрет продолжается и в самом описании.
Давайте обратимся к вакансиям QA-инженеров:
Все задачи связаны с тестированием и нацелены на поиск багов, хотя компания ищет «QA-инженера».
Или ещё один красочный пример:
По факту многие работодатели ищут тестировщика ПО (если ориентироваться по описанию обязанностей), но в названии обозначают, что находятся в поисках QA-инженера.
Если вы помните, в ISO 9000:2015 есть QA и QC. Что будет, если выполнить запрос на hh.ru по ключевому слову QC? А ничего не будет. Вы не увидите вакансий ни QA, ни тестировщика. По такому запросу появятся вакансии, связанные с производством и контролем качества выпускаемой продукции.
Получается, что в IT-индустрии нет профессий QC, их заменили на тестировщиков ПО, а в других сферах деятельности нет QA-специалистов, зато есть QC. В описании вакансий QA-инженеров не указывают обязанности по улучшению качества продуктов и недопущению багов, наверное, считают это само собой разумеющимся.
Что такое обеспечение качества
Прежде чем продолжить, давайте замутим небольшой интерактив. Перейдите по ссылке и посмотрите на сайт конференции QualityConf. Побродите пару минут по темам выступлений и ответьте для себя на несколько вопросов:
Конференция QualityConf целиком и полностью посвящена качеству, а не тестированию. Однако при подготовке очередной конференции организаторы провели исследование и задали вопрос своим посетителям: «С чем у вас ассоциируется конференция?».
Как вы все уже, наверное, догадались, главные ассоциации были исключительно с тестированием.
Получается, что сегодня, говоря слово «качество», многие слышат «тестирование», и очень часто это функциональное тестирование, хотя понятие качество гораздо шире.
Качество — это определение потребителя, а не определение инженера, не определение маркетинга и не общее определение менеджмента. Оно основано на фактическом опыте клиента в отношении продукта или услуги, измеряется в соответствии с его требованиями — заявленными или неустановленными, осознанными или просто ощущаемыми, технически действующими или полностью субъективными. Качество всегда представляет собой движущуюся цель на конкурентном рынке.
Тестирование — один из способов обеспечить качество продукта. Кроме этого повысить качество продукта можно вводя стандарты кодирования, внедряя новые инженерные практики, дизайн ревью и так далее. Способов обеспечить качество много, но на разных этапах зрелости команд и процессов в компании эти способы дадут разный эффект, об этом необходимо помнить. Но это уже совсем другая история.
QA ≠ QC: как их различить
QC: кто эти люди, какие у них задачи, какие у них ограничения
Кто эти люди? Люди, которых называют тестировщиками, тождественны контролю качества QC. По логике вещей они на последнем этапе разработки проверяют качество продукта (любым видом и типом тестирования — ручным, автоматизированным, нагрузочным, тестированием безопасности и т.д.).
Какая у них задача? Их задача — провести валидацию продукта и предоставить информацию бизнесу и разработчикам о соответствии продукта заявленным требованиям.
Какие у них ограничения? Какие могут быть недостатки, если у вас все сотрудники проверяют продукт на соответствие:
QA: кто эти люди, какие у них задачи, какие у них ограничения
Кто эти люди? Инженеры по обеспечению качества (QA) — это люди, которые помогают командам разработки выпускать качественный продукт, как можно быстрее за как можно меньшие деньги. Ведь все мы знаем, что чем раньше найден баг, тем дешевле его пофиксить. Лучше всего фиксить баги ещё на уровне идеи.
QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это.
Какая у них задача? Задача QA-инженера — не допустить несоответствия продукта предъявляемым требованиям. QA-инженер замеряет качество продукта, знает его актуальное состояние и что нужно сделать, чтобы его поднять не только на этапе тестирования, но и на этапе разработки, дизайна или составления требований.
Какие у них ограничения? Сложно оценить качество работы QA-инженера, потому что если он хорошо выполняет свою работу, то до этапа тестирования будет доходить минимальное количество багов не влияющих на функциональность и запуск продукта в прод.
В отличие от QA, работу QC оценить можно, особенно если отталкиваться от самого простого и оценивать эффективность по количеству багов — сколько багов нашёл и сколько багов пропустил на прод.
Как дальше жить?
Большой штат тестировщиков не сможет существенно улучшить качество продукта. Но сможет улучшить саму проверку качества. Если же вы, коллеги-тестировщики, хотите поднимать именно качество на новый уровень, задумайтесь о переходе в QA-инженеры.
Только не ждите, когда вас позовут на встречу, где обсуждают фичи с разработчиками или дизайнерами, придите на неё сами. Высказывайте своё мнение касательно любого аспекта качества продукта. Не позволяйте сложившимся правилам, должностным инструкциям и прочей фигне мешать вам делать продукт ещё более качественным, чем сейчас.
Я знаю, что большинству из вас не всё равно на то, что вы тестируете. И вы искренне хотите поставлять хороший продукт, которым приятно будет пользоваться.
Путь QA бойца
Небольшой обзор вариантов развития твоей карьеры в сфере контроля и обеспечения качества.
С чего начать?
Итак, предположим, что вы планируете карьеру в IT и впервые услышали о QA. Теперь вы хотите разобраться, что же это такое.
QA — это процесс обеспечения качества программного продукта на всех этапах разработки, но на просторах СНГ часто этот термин применяется относительно тестирования ПО.
Что же потребуется начинающему специалисту чтобы ступить на путь борца за качество? Сейчас разберемся.
Для большинства компаний и проектов будет достаточно:
Хорошо, а куда мы идем?
Дальше поговорим о том, в каких направлениях прокачиваться и каких результатов можно достичь, начав свой путь в IT с обеспечения качества.
Роли в QA
Можно выбрать направление, не меняя сферу деятельности и развиваться, как более узкий специалист. Или объединить в себе несколько ролей. Нужно осваивать стратегии и типы тестирования в разных методологиях разработки, учиться пользоваться инструментами управления тестированием (TestLink, TestRail, Test IT и т.д.) и системами баг-трекинга (Jira, Redmine) – эти знания и навыки являются фундаментальными для всех QA инженеров. Самыми востребованными вариантами специализации являются автоматизированное и нагрузочное тестирования.
Ручное тестирование
Когда ресурсов на разработку автотестов нужно потратить больше, чем на сам продукт — проще/дешевле/быстрее проверить новый функционал руками.
Многие считают, что ручное тестирование это что-то простое и с этим может справиться каждый. На самом деле ручное тестирование требует очень много навыков. Ручные тестировщики решают те задачи, с которыми другие справиться не в силах.
Для ручного тестирования потребуются:
Автоматизация тестирования
Автоматизированные тесты помогают быстрее выпускать новые функциональности, быстрее проводить тестирование, уменьшить количество ручных тестов.
Так что же может понадобиться чтобы начать автоматизировать тесты?
Нагрузочное тестирование
Смысл нагрузочного тестирования в измерении качества системы, которая работает при определенной нагрузке. Выполнив тестирование производительности, можно определить масштабируемость, отказоустойчивость и стабильность программного продукта.
В работу специалистов этого профиля входит сбор данных о производительности приложения, времени отклика и локализацией ошибок при нагрузке, превышающей нормальные сценарии использования системы.
Самые важные навыки для тех, кто хочет заниматься нагрузочным тестированием:
Тест-аналитик
Тест-аналитик- человек, работа которого заключается в создании артефактов тестирования на основании требований. В маленьких командах эти задачи решает рядовой тестировщик, в крупных же функции тестирования и тест-дизайна, зачастую, четко разделены между людьми.
Идеальная цепь взаимодействий выглядела бы так:
Альтернативные пути развития карьеры. Есть ли жизнь после QA?
Системный аналитик
Всю свою карьеру ты боролся с некачественно описанными требованиями? У тебя есть шанс все исправить. Ты будешь общаться с пользователями системы, собирать и анализировать требования, а затем фиксировать их в документации. Плотное взаимодействие с разработчиками и опыт инженера по обеспечению качества помогут в том чтобы требования были полными и проработанными. Помимо этого, возможно участие во внедрении, обучение пользователей и сбор обратной связи об эффективности системы.
Бизнес-аналитик
Основное преимущество, которое тестировщики имеют перед разработчиками, заключается в том, что они получают знания в предметной области, в области бизнеса. Частый вариант продвижения тестировщика по карьерному пути – переход в бизнес аналитики. Как бизнес-аналитик вы будете участвовать в формировании требований к продукту со стороны бизнеса.
Менеджер
Допустим, с людьми вам общаться легче, чем с базами данных — тогда можно примерить на себя роль менеджера. Специалисты по обеспечению качества имеют глубокое понимание того, как сделать программное обеспечение лучше. Если готов принимать сложные решения и нести за них полную ответственность — проблем не будет. Здесь тоже есть свое ветвление, например: проектный менеджер, ресурсный менеджер, тест-менеджер и т.д. Всё зависит от процессов, построенных в компании.
Разработчик
Часто тестировщики уходят с головой в разработку, т.к. находясь бок о бок с программистами, познать их ремесло гораздо проще, чем получать специальное образование. Причем, вам расскажут, подскажут и помогут. Это неплохой способ начать карьеру, познакомиться с процессом разработки изнутри. Особенно, если вы уже знаете языки программирования и занимались автоматизацией тестирования. Главное – желание.
Если что упустил — рад обсудить в комментариях!
Automation QA — это отдельная команда?
«Конечно отдельная!», — ответит большая часть читающих. Такой ответ укладывается в их картину мира, потому что “так работали всегда”.
Так работали всегда
Эта фраза обычно означает наличие продукта, уже работающего на продакшене или только готовящегося зарелизиться, но написанного без модульных и интеграционных тестов. Без страховочной сети из тестов, изменения вносятся долго, дорого и с большим количеством новых багов. Такой проект в мире разработки принято называть “легаси”.
Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:
Прохождение каждого тест-кейса ручное, поэтому процесс тестирования занимает много времени. Количество тест-кейсов в регрессии по естественным причинам постоянно растет, и принимается решение о создании внутри QA-отдела команды автоматизации.
Так как новоиспеченная команда набиралась из-за необходимости ускорить цикл регрессии, который состоит из black-box тестов, то и автоматизация происходит на уровне black-box: через GUI или API. Автоматизация через GUI наиболее болезненная и дорогостоящая из-за хрупкости и низкой скорости тестов, но зачастую начинают именно с нее.
Тем временем, факт создания новой команды никак не влияет на команду разработки: она все также продолжает отдавать в тестирование некачественный продукт, игнорируя написание модульных и интеграционных тестов. Учитывая огромное количество black-box сценариев, находящихся в очереди на автоматизацию, получаем анти-паттерн тестирования Ice-Cream Cone, в котором количество самых медленных и самых дорогостоящих GUI-автотестов намного больше количества дешевых и быстрых модульных и интеграционных тестов.
Нестабильных и медленных по своей природе GUI-автотестов с каждым релизом становится все больше, а значит больше ресурсов уходит на их поддержку, что ведет к расширению команды автоматизации. Департамент обеспечения качества растет, но не обеспечивает должный рост качества выпускаемого продукта. Вы действительно хотите так работать всегда?
В чем проблема?
Одна из главных причин возникновения ситуации, описанной выше, — это отсутствие культуры разработки, в которой каждый разработчик несет ответственность за написанный им код. А даже минимальная ответственность понимает под собой необходимость удостовериться в работоспособности кода прежде чем радостно восклицать: “Моя работа готова!”.
Eye Driven Development является самым простым способом удостовериться в работоспособности кода, но не самым оптимальным. Прост этот способ тем, что не предполагает практически никакой интеллектуальной работы: мы тестируем руками приложение, сервис, класс и т.д. с точки зрения конечного пользователя, не рассматривая граничные значения, классы эквивалентности, негативные сценарии, сценарии с разными уровнями permissions и прочее. Такой способ не дает быстрой обратной связи при разработке, не позволяет проверить сущность на разнообразной выборке данных, занимает много времени и не улучшает качество продукта.
Наиболее оптимальный способ — это написание автотестов на разрабатываемый код. Говоря об ответственности за код, не важно, когда написаны автотесты: до или после самого кода. Главное, что дает такой способ — это уверенность в том, что работа действительно завершена и можно переходить к другой задаче. Учитывая другие преимущества в виде быстрой обратной связи, возможности проверять сущность на большой выборке, а также высокой скорости, автотесты, написанные разработчиками, являются отличным инструментом для улучшения качества продукта.
Работаем не так как всегда
Предлагаю мысленно смоделировать возможное развитие событий в команде, члены которой несут ответственность за написанный код.
У нас имеется продукт, уже работающий на продакшене или только готовящийся зарелизиться, который покрыт модульными и интеграционными тестами. Код постоянно совершенствуется, а новая функциональность добавляется без страха сломать уже имеющуюся. Чтобы убедиться в работоспособности разрабатываемой функциональности больше не нужно “перебрасывать код через стену” в отдел тестирования и терять время, ожидая вердикта, после чего повторять итерацию снова и снова.
QA-отдел уже создан и активно участвует в процессе разработки, занимаясь действительно обеспечением качества выпускаемого продукта. При разговоре об обеспечении качества, как мне кажется, удобно руководствоваться Testing Quadrants:
Используя Testing Quadrants, тестирование можно разбить на 4 категории.
Первая категория — это тестирование реализации продукта, создающее страховочную сеть для команды разработки. Эта категория отвечает за низкоуровневое тестирование с помощью модульных и интеграционных тестов и позволяет понять разработчикам, что с технической точки зрения они делают вещи правильно (Do Things Right). Очевидно, что низкоуровневые тесты являются полностью автоматизированными и пишутся командой разработки, так как лежат в ее сфере интересов.
Вторая категория — это тестирование бизнес-функций продукта, создающее страховочную сеть для команды разработки. Здесь речь идет о таких видах тестирования как Examples, Story Tests и прочих, направленных в первую очередь на создание правильной коммуникации между бизнесом и командой разработки, и позволяющих команде понять, что она делает правильные вещи (Do Right Things), которые действительно нужны бизнесу.
Автоматизирование Examples или Story Tests представляет из себя End-to-End тесты, которые тестируют не сложные сценарии использования интерфейса, а лишь бизнес-логику, но через интерфейс, который доступен конечному пользователю. Так как данная категория тестирования все еще лежит в сфере интересов разработки, то автоматизация ложится на плечи команды разработки.
Третья категория — это тестирование бизнес-функций продукта, которые критичны для восприятия качества продукта конечным пользователем. В эту категорию попадают исследовательское тестирование, тестирование сложных сценариев использования продукта, тестирование юзабилити, альфа- и бета-тестирование. Тесты из этой категории лежат полностью на плечах QA-команды, а их автоматизация невозможна или слишком сложна.
Если говорить непосредственно про исследовательское тестирование и тестирование сложных сценариев, которые могут находить функциональные ошибки, то стоит заметить, что любая найденная ошибка является ошибкой в коде и может быть покрыта соответствующими модульными или интеграционными тестами. Об этом хорошо написал Мартин Фаулер, а я позволил себе вольности в переводе:
I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing or incorrect unit test. Thus I advise that before fixing a bug exposed by a high level test, you should replicate the bug with a unit test. Then the unit test ensures the bug stays dead.
Я утверждаю, что высокоуровневые тесты — всего лишь вторая линия обороны. Упавший высокоуровневый тест означает не только баг в коде продукта, но и отсутствие соответствующего модульного теста или ошибку в уже имеющемся. Мой вам совет: прежде чем фиксить баг, найденный высокоуровневым тестом, воспроизведите его с помощью модульного теста, и вы попрощаетесь с багом навсегда.
Четвертая категория — это тестирование реализации продукта, которая критична для восприятия качества продукта конечным пользователем. Обычно в эту категорию попадают нагрузочное тестирование, тестирование производительности, тестирование безопасности и надежности системы. Такое тестирование проводится с использованием специальных инструментов, зачастую написанных под нужды конкретного проекта. По-хорошему, инфраструктурой для проведения подобных тестов занимается DevOps-отдел, а разработкой соответствующих инструментов —
отдельная команда. Причем инструменты должны позволять проводить тесты по-требованию (Testing as a Service).
Так как созданный QA-отдел теперь отвечает не только за контроль качества продукта, но и за обеспечение качества, то в его обязанности входит:
Бесконечного роста регрессионных ручных black-box тест-кейсов не происходит, потому что большая их часть покрыта в первой и второй категориях командой разработки. В таком случае у нас формируется правильное отношение тестов или, как это принято называть, “пирамида тестирования”:
Рост количества регрессионных ручных тестов минимален, автоматизация на уровне модульных, интеграционных и GUI тестов осуществляется командой разработки. Причем количество GUI-тестов небольшое, они описывают не сложные сценарии использования GUI, а работу бизнес-логики через пользовательский интерфейс, а значит являются менее хрупкими и более дешевыми в поддержке. Отдел QA действительно занимается обеспечением качества, получая и работая с фидбеком от пользователей, проводя исследовательское тестирование, тестирование новой функциональности с помощью сложных сценариев, а также помогая разработчикам общаться с бизнесом. Тестирование в проекте автоматизировано эффективнее чем в первом случае, но команда автоматизации внутри QA-отдела так и не появилась.
И я повторю вопрос: “Automation QA — это отдельная команда?”