company_banner

Кто ты, QA-инженер или тестировщик?

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



    Больше трёх лет я занимаюсь обеспечением качества продуктов. И всё это время наблюдаю за эволюцией процессов тестирования в компании.

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

    До текущих процессов с блэкджеком Scrum-Less и автотестами на Selenium.

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

    QA, QC и тестировщики: три большие разницы?


    Начнём наши поиски и копания с обращения к Международному стандарту системы менеджмента качества ISO 9000:2015. В каждой статье, в каждом видео на тему отличия этих понятий есть ссылка на этот документ, моя статья не исключение.



    В пункте 3.2 стандарта раскрываются два определения:

    1. Обеспечение качества (3.2.10) — часть управления качеством, направленная на обеспечение уверенности в том, что требования к качеству будут выполнены.
      Оригинал
      Quality assurance (3.2.10) — part of quality management focused on providing confidence that quality requirements will be fulfilled.
    2. Контроль качества (3.2.11) — часть управления качеством, ориентированная на выполнение требований к качеству.
      Оригинал
      Quality control (3.2.11) — part of quality management focused on fulfilling quality requirements.

    Из этих определений следует, что мы либо обеспечиваем качественный продукт, либо проверяем продукт на соответствие качеству.
    Отмечу, что в стандарте ISO 9000:2015 вообще нет понятия tester как такового. Я искал.
    Так каким же образом взаимосвязаны понятия Quality assurance, Quality control и Тестирование между собой?

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



    Но лично мне кажется, что раз в стандарте нет понятия tester или testing, а QC — это и есть разного рода тестирование, то и иллюстрации должны быть такими:



    Однако стандарт есть стандарт, а у нас тут реальная жизнь. И в реальной жизни IT-индустрии встречаются только два названия нашей профессии:

    1. QA-инженер.
    2. Тестировщик Программного обеспечения (ПО).

    Причём очень часто эти понятия взаимозаменяются и путаются. Неразбериха начинается ещё на этапе описания вакансий.

    Ищу Тестировщика ПО (QA-инженера)


    Я бы не писал эту статью, если бы в индустрии не смешивали эти роли и не называли тестировщиков QA-инженерами и наоборот. По моим наблюдениям, в России не разделяют две профессии. Всех для простоты (а может по незнанию) называют тестировщиками. И ладно бы таким грешили только работодатели, но путаницу поддерживают и сами тестировщики. Например, на Хабре можно встретить статьи, где авторы на протяжении всего текста называют одних и тех же людей тестировщиками, QC-инженерами, QA-специалистами, инженерами по тестированию и тестерами.

    Масла в огонь подливают HR-менеджеры: часто для увеличения охвата аудитории они пишут в названии вакансии «Тестировщик ПО (QA инженер)». Шапкой вакансии дело не заканчивается, винегрет продолжается и в самом описании.

    Давайте обратимся к вакансиям QA-инженеров:



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

    Или ещё один красочный пример:



    И ещё:



    И на сладкое:



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

    Если вы помните, в ISO 9000:2015 есть QA и QC. Что будет, если выполнить запрос на hh.ru по ключевому слову QC? А ничего не будет. Вы не увидите вакансий ни QA, ни тестировщика. По такому запросу появятся вакансии, связанные с производством и контролем качества выпускаемой продукции.

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

    Что такое обеспечение качества


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

    1. Для кого эта конференция?
    2. С чем она у вас ассоциируется?

    Конференция QualityConf целиком и полностью посвящена качеству, а не тестированию. Однако при подготовке очередной конференции организаторы провели исследование и задали вопрос своим посетителям: «С чем у вас ассоциируется конференция?».

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

    Получается, что сегодня, говоря слово «качество», многие слышат «тестирование», и очень часто это функциональное тестирование, хотя понятие качество гораздо шире.

    Качество — это определение потребителя, а не определение инженера, не определение маркетинга и не общее определение менеджмента. Оно основано на фактическом опыте клиента в отношении продукта или услуги, измеряется в соответствии с его требованиями — заявленными или неустановленными, осознанными или просто ощущаемыми, технически действующими или полностью субъективными. Качество всегда представляет собой движущуюся цель на конкурентном рынке.
    Оригинал
    Quality is a customer determination, not an engineer's determination, not a marketing determination, nor a general management determination. It is based on the customer's actual experience with the product or service, measured against his or her requirements — stated or unstated, conscious or merely sensed, technically operational or entirely subjective — and always representing a moving target in a competitive market (Armand Feigenbaum «Total quality control»).

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

    QA ≠ QC: как их различить


    QC: кто эти люди, какие у них задачи, какие у них ограничения


    Кто эти люди? Люди, которых называют тестировщиками, тождественны контролю качества QC. По логике вещей они на последнем этапе разработки проверяют качество продукта (любым видом и типом тестирования  —  ручным, автоматизированным, нагрузочным, тестированием безопасности и т.д.).

    Какая у них задача? Их задача — провести валидацию продукта и предоставить информацию бизнесу и разработчикам о соответствии продукта заявленным требованиям.

    Какие у них ограничения? Какие могут быть недостатки, если у вас все сотрудники проверяют продукт на соответствие:

    • До взятия фичи в проверку такие сотрудники не влияют на процесс обеспечения качества и разработки, хотя их участие могло бы предотвратить некоторое количество багов и тем самым сократить затраты на тестирование.
    • Зачастую такие сотрудники не могут давать рекомендации, как сделать продукт лучше. Потому что поезд ушёл и уже поздно. Им остаётся лишь сверять соответствие продукта требованиям. FYI: хотя на самом деле тестировщикам есть что сказать по поводу улучшений, которые необходимо сделать.
    • Эти ребята чаще всего не видят полной картины процесса, поэтому искренне не понимают, почему разработчики дают им код, в котором приложение крашится при попытке запуститься. И, согласно п.1, ничего не могут с этим сделать. Даже если хотят. 
    • Они не могут взять на себя полную ответственность за качество продукта.
    • Очень часто между тестировщиками и разработчиками возникают конфликты. Так бывает, когда разработчики считают свой код самым лучшим и работающим, а в тестировщиках видят лишь попытки его сломать и показать, что код не работает. Такое положение дел порождает всем известные мемы «Это не баг, а фича».

    QA: кто эти люди, какие у них задачи, какие у них ограничения


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



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

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

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

    В отличие от QA, работу QC оценить можно, особенно если отталкиваться от самого простого и оценивать эффективность по количеству багов — сколько багов нашёл и сколько багов пропустил на прод.

    Как дальше жить?


    Большой штат тестировщиков не сможет существенно улучшить качество продукта. Но сможет улучшить саму проверку качества. Если же вы, коллеги-тестировщики, хотите поднимать именно качество на новый уровень, задумайтесь о переходе в QA-инженеры.

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

    Я знаю, что большинству из вас не всё равно на то, что вы тестируете. И вы искренне хотите поставлять хороший продукт, которым приятно будет пользоваться.
    Dodo Pizza Engineering
    О том как IT доставляет пиццу

    Комментарии 18

      +4

      Если я сокращу статью до:
      1) многие путают QA и QC
      2) QC видит только ошибки
      3) QA видит весь продукт в масштабе…
      4) и поправляет, когда девелоперы делают что-то не так
      5) QA это хорошо


      что я упущу из статьи?

        +4
        Спасибо, в целом у тебя получился неплохой краткий пересказ моей статьи)
        Действительно, если убрать мои рассуждения и примеры подкрепляющие их то в сухом остатке будут эти тезисы, я бы еще к ним добавил тезис
        6) если видишь в вакансии смесь QA и QC — возможно в компании не различают эти понятия, будь осторожен.
          +1
          Иногда компании специально подменяют понятия в вакансиях, чтобы сыграть на самолюбии кандидата, с одной стороны — это выгодно обеим сторонам, при успешном стечении обстоятельств сотрудник получает запись в резюме и в трудовую с красивым названием QA, а компания сотрудника, который хоть и на короткое время, но закрывает позицию(работа делается), с другой стороны, с точки зрения индустрии получается не очень позитивно, потому что люди перестают разделять эти понятия, так как в большинстве случаев информацию получают во время рабочих процессов и у них складывается восприятие, что так оно на самом деле и есть
          0
          Ничего, можно еще добавить автор не угадал

          e-ivanchenko, смотрим ГОСТ Р ИСО 9000-2015: «Качество — степень соответствия совокупности присущих характеристик объекта требованиям». Все, и не надо фантазировать про потребителя и прочее. Вот как требования выявили, так и получили…

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

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

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

            +2
            Все верно, в стандарте есть такое определение качества. Мое определение из книги “Total quality cintrol”, которое мне запомнилось и как мне кажется отражает суть качества. Как я писал, стандарт отличается от реальной жизни. В стандартах нет тестировщиков, а в жизни есть, так же и тут. Продукта без пользователей не существует. И фактически качество продукта определяют они, а не ТЗ. Другой вопрос кто за это отвечает и что с этим делать.

            Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
            это валидация и верификация?

            Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.

            Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
            1. мы нашли “багу” на PBR или в ТЗ.
            Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
            2. Нашли багу на проде.
            Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
            Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.
              0
              Все верно, в стандарте есть такое определение качества. Мое определение из книги “Total quality cintrol”, которое мне запомнилось и как мне кажется отражает суть качества. Как я писал, стандарт отличается от реальной жизни. В стандартах нет тестировщиков, а в жизни есть, так же и тут. Продукта без пользователей не существует. И фактически качество продукта определяют они, а не ТЗ. Другой вопрос кто за это отвечает и что с этим делать.


              А книги нагло врут про реальную жизнь…
              В стандартах есть тестирование, это так к слову.
              Еще раз, «Качество — степень соответствия совокупности присущих характеристик объекта требованиям».
              С этим мы можем работать, улучшать и прочее. С тем что думают пользователи внезапно нет.
              Мы можем предпринимать набор действий, а вот результат слабо предсказуем.
              Именно поэтому QA специалисты работают с ОБЕСПЕЧЕНИЕМ качества. Их задача убрать преграды на пути других, что бы они сделали продукт качественно, основной инструмент это процессы.

              Можешь раскрыть немного почему ты считаешь что «QA-инженеры участвуют на самых ранних этапах создания продукта/фичи…»
              это валидация и верификация?


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

              Да, все что вы написали входит в задачу QA. У меня нет опыта работы в разных компаниях и если в компаниях есть люди, которые занимаются исключительно процессами обеспечения качества, то это круто (наверное). Но мне кажется это далеко не во всех компаниях, поэтому я и призываю самим становиться QA и улучшать процессы и влиять на качество.


              Эти люди есть везде где активно используют ИСО или CMMI, просто в части компаний придумывают свой альтернативный путь и идут по нему.

              Сопровождаемость это хорошо, но кривая стоимости изменений справедлива и для самого сопровождаемого продукта. Давайте представим продукт с хорошей сопровождаемостью и 2 ситуации:
              1. мы нашли “багу” на PBR или в ТЗ.
              Чтобы ее пофиксить владелец продукта или кто-либо вносит правку в приемочные критерии или доку. Баг пофикшен.
              2. Нашли багу на проде.
              Прилетел тикет на первую линию. Первая линия не разобралась в чем подвох, отдала на вторую. Вторая линия выяснила что это бага и сделала задачу на фикс. Владелец продукта увидел эту задачу, поставил ей приоритет. Разработчик затянул задачу, пошел читать код и править её. Сделал, отдал на тестирование. Тестировщик так же погрузился в контекст, затем протестировал задачу. Дальше отправляем задачу релиз-инженеру, который катит это на прод.
              Вторая ситуация куда более затратная чем первая. Именно эти затраты и отражает эта кривая.


              Посмотрите, что есть сопровождаемость по стандартам.
              Нравиться мне когда сравнивают не сравнимое. Но скажу. Компании которые упираются в том числе и в качество, делают так, что бы стоимость исправления дефекта была одинаково низкой, хоть на проде, хоть в доке. И этим занимаются специалисты по качеству. Так что второй пример, пример именно фиговой работы QA.
          +2
          Реальность такова, что QA — низшее звено пищевой цепочки. Причины вполне объективные. Порог вхождения в профессию ниже плинтуса. Техническая неподготовленность не даёт возможности продуктивно взаимодействовать с разработчиками. Недостаток софт скиллов ограничивает контакт с бизнесом.
          Собственно тут и определяются два пути развития: либо учись программировать и становись матерым SDETом, либо учись увлекательно говорить и становись менеджером. Есть ещё QA аналитик, кстати. В России таких вакансий не встречал, но есть… Что-то среднее между бизнес аналитиком и тестировщиком. Скажем, если нужно нового клиента прикрутить к существующим бизнес процессам. Соответственно нужно понять как адаптировать клиента и софт друг под друга. QA analyst будет одним из участников такой адаптации.
          Тестирование странная пограничная область. Разработчики и бизнес перетягивают тебя на свою сторону, потому что таково положение дел: одни делают вид, что работают, другие делают вид, что управляют. Поэтому матёрый тестировщик всегда переходит на тёмную сторону: становится своим у тех или других. Только евангелисты продукта могут быть по настоящему привержены качеству, но они далеки и от QA и от QC.
            +2

            "QA — низшее звено пищевой цепочки."
            Ну… Ну… Занимаюсь автоматизированным тестированием микросервисов в большом проекте. Умею настраивать docker, mysql, mongo, elasticsearch и кучу сопутствующих фреймворков, сервисов и т.п. + знание бизнес логики. А вот программисты иногда даже не знают продукт который пишут. И часто поменять программиста легче, чем QA. Так кто там "низшее звено"?

              +5

              Кто меньше получает

              0

              Пройдёт ещё время и у тебя перестанет бомбить на эту тему )))
              Может ещё статью написать в чем разница между «Функционалом» и «Функциональностью»?)
              Тоже будет полезно

                +1
                А почему перестанет бомбить? Из-за смирения?
                  +1

                  Из-за мудрости и опыта! )

                  +1
                  Сорян, не сразу понял что я перепутал) Поправлю в статье.
                    0
                    Категорически плюс один к разнице между «Функцией» и «Функциональностью».

                    Для тестировщиков разница капец важнецкая. Остальных это не касается.
                    +3
                    В общем-то все правильно написано. А то, что многие этого не понимают это да… И это печально…
                    0
                    Просто перестаньте натягивать понятие QA на процессы разработки ПО, и всё станет норм.
                      0
                      Рекомендую (нудно, но чоуж) подумать о том, что изначально разные проектные задачи
                      • анализировать требования (не читать их, а анализировать, раскладывая их на сущности, подсущности и свойства всех этих шняг)
                      • придумывать тестовые ситуации
                      • формулировать и записывать тестовые ситуации
                      • выполнять тестовые ситуации


                      тянули за собой и отдельные проектные роли, вроде Тест-Дизайнер, Тест-Аналитик и Тест-ТестерОбыкновенный (Исполнительный, Тупой, Бесперспективный, ну, вы же знаете). И над всеми был нужен Тест-Менеджер или Координатор усилий группы людей. Отдельные роли и (не всегда) отдельные люди.

                      Было хорошо, если весь дизайн и аналитику для тестирования делали аналитики, которые требования формулировали. Чаще нет.

                      Со временем бизнес упростил всё, пусть придёт ОДИН чувак, который и требования осознает, и тесты придумает, и сам их выполнит. И уже давно появились люди, которые не знают, что можно/нужно по-другому, и которых старая терминология не настораживает, а только слегка смущает. А значит, можно всё старьё проигнорировать или обобщить, и ничего плохого не случится. QA, QC… иди ищи баги и обеспечивай качество, едрить.

                      Сегодня бизнес просит всё так же ОДНОГО чувака, который сделает всё сам и потом автоматизирует. «QA» вы его назовёте или «Big-Bang QA Guru» — всем однородно.

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

                      Самое читаемое