Путь QA бойца

    Небольшой обзор вариантов развития твоей карьеры в сфере контроля и обеспечения качества. 

    С чего начать?


    Итак, предположим, что вы планируете карьеру в IT и впервые услышали о QA. Теперь вы хотите разобраться, что же это такое.





    QA — это процесс обеспечения качества программного продукта на всех этапах разработки, но на просторах СНГ часто этот термин применяется относительно тестирования ПО.

    Что же потребуется начинающему специалисту чтобы ступить на путь борца за качество? Сейчас разберемся.

    Для большинства компаний и проектов будет достаточно:

    • Представление о процессе разработки ПО (плюсом будет техническое образование, близкое к IT-сфере, но как показывает опыт многих коллег- это не обязательное условие);
    • Знание основных принципов работы программных продуктов (мобильных или standalone приложений, сайтов в зависимости от профиля компании);
    • Знакомство с теорией тестирования, базовое представление о тест-дизайне, какая бывает тестовая документация и откуда она берется (это очень легко гуглится при желании);
    • Способность быстро разобраться с TMS-системой;
      habr.com/ru/post/461205
    • Желание учиться новому, быстро разбираться в деталях, как работает ПО сейчас и как оно должно работать.

    Если пункты выше выполнимы, то мы можем отправляться в путь.

    Хорошо, а куда мы идем?

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

    Роли в QA


    Можно выбрать направление, не меняя сферу деятельности и развиваться, как более узкий специалист. Или объединить в себе несколько ролей. Нужно осваивать стратегии и типы тестирования в разных методологиях разработки, учиться пользоваться инструментами управления тестированием (TestLink, TestRail, Test IT и т.д.) и системами баг-трекинга (Jira, Redmine) – эти знания и навыки являются фундаментальными для всех QA инженеров. Самыми востребованными вариантами специализации являются автоматизированное и нагрузочное тестирования.

    Ручное тестирование


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

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

    Для ручного тестирования потребуются:

    • Высокие аналитические навыки. От вас будут ожидать не только указания на ошибки, но и предложений как сделать лучше. Ведь только вручную можно проверить такие вещи как, например, удобство использования;
    • Креативность. В современных реалиях разработки требования не всегда полные и тестировщики сталкиваются с тем, что им нужно продумывать множество вариантов использования систем, которые они тестируют;
    • Ведение тестовой документации. Хороший тестировщик всегда имеет четкий план действий и активностей по тестированию, основанный на требованиях и сроках;
    • Знание и опыт работы с системой управления тестированием;
    • Владение инструментами работы с HTTP-запросами (Postman, curl);
    • Знания баз данных, умение писать SQL-запросы.

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

    Автоматизация тестирования


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

    Так что же может понадобиться чтобы начать автоматизировать тесты?

    • Нужно будет писать код, например, на Java или Python;
    • Овладеть инструментами автоматизации (Selenium, Katalon);
    • Базовые знания HTML, CSS, XPath;
    • Умение работать с системами контроля версий и репозиториями кода;
    • Навыки работы с API;
    • Знания систем CI/CD (Jenkins, TeamCity и т.д.).

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

    Нагрузочное тестирование


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

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

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

    • Знание архитектуры тестируемой системы. Погружение в тестирование производительности потребует от вас изучения языков разработки и фреймворков которые используются при создании продукта;
    • Умение разработать и анализировать профили нагрузки;
    • Опять же программирование. Для скриптов нагрузочного тестирования могут пригодиться такие языки как Java, Python, JavaScript, C++, C# и специальные фреймворки, например, Gatling;
    • Знание аппаратной и сетевой архитектуры. Часто причиной снижения производительности приложения может стать железо, нужно ориентироваться в таких понятиях как пропускная способность памяти, процессора, сети и уметь анализировать данные о них.

    Тест-аналитик


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

    Идеальная цепь взаимодействий выглядела бы так:

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



    Альтернативные пути развития карьеры. Есть ли жизнь после QA?


    Системный аналитик


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

    Бизнес-аналитик


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

    Менеджер


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

    Разработчик


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

    Если что упустил — рад обсудить в комментариях!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      –2
      QA само по себе уныло.
        0
        Мб и уныло но я предпочту работать в проекте с хорошими QA чем без них.
          0
          ты просто никогда в жизни не видел хорошего QA
            0
            От того что оно хорошее, унылым оно быть не перестает.
            Заметье, хороший программист этим на постоянной основе заниматься не станет, а плохому программисту хорошим QA стать не суждено.
            Получается что это профессия изначально даже не для середнячков.
            И опять же рутины несравненно больше при практически полном отсутствии творческой составляющей. Увлекательной эту профессию тоже не назовешь.
            Соответственно перспектив никаких если быстро не сбежать.
              0

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

            0
            Если нет QA, то у тебя 2 варианта:
            1. Либо достаточно много заниматься правкой багов, которые нашли пользователи и которые пришли на Support. Захочешь ли ты этим заниматься, если у тебя на горизонте новая интересная фича или то что делаешь очень увлекательно?
            2. Самому заниматься тщательным тестированием после программирования. При этом не только того участка, где ты копался, но и вообще всего того, что может потенциально затронуть твоя работа
            3. В процессе разработки заниматься не только написанием модульных тестов, но и разработкой компонентных тестов, интеграционных, нагрузочных и др.

            Если п2 и п3 еще можно сделать, то п1 очень часто нет, т.к. пользователь после баги может психануть и потребовать денег обратно и ему до ломпочки, что ты можешь эту багу пофиксить.
              –1
              Я QA с 2013-го. Java, WebDriver, полный фарш. Если бы занимался только тестами, то сошел бы с ума. Поэтому интенсивно развиваюсь в самых разных областях.
              Ну а платформа тестирования получает непрерывный R&D.
              0

              Главный путь бойца QA — не быть бойцом QA!

                0
                На самом деле не уныло. У QA (особенно если он один в команде) есть столько разных задач, которыми он может заниматься. Проводить ручное тестирование, писать автотесты, писать мануальные тесты, намекать разработчикам, что неплохо было бы добавить юнит-тесты в проект, заводить баги в Jira, просто пользоваться продуктом (да, такой тип тестирования тоже есть), планировать сроки выкатки нового релиза в «прод».
                Уныло становится только если писать тестовую документацию целый день, но это большая редкость.
                  0
                  У нас QA максимум на три года задерживается, перепробовав все эти задачи.
                    0
                    А на сколько задерживаются разработчики?
                      0
                      Те что фейс клепают — обычно от трех до пяти лет, остальные уже лет семь-восемь работают и еще не уходили. У нас С++ основной и Java
                      0
                      И если не секрет, то на какие позиции они дальше уходят? Просто если они остаются в QA-сфере, то значит что-то им не нравилось на Вашей работе, они выгорели и решили поменять место.
                        0
                        Мне вообще не попадалось ни одного, у кого бы этот QA хотя бы не вызывал отвращения.
                        Для большинства это либо ступенька перейти в программисты или девопсы.
                        Другой вариант — способ переехать за рубеж и получить вид на жительство для плохонького программиста или не-программиста.
                          0

                          Кто ж тогда все эти люди по 20+ лет опыта в тестировании, пишущие книги и даже немного срущиеся между собой по поводу школ/подхода/принципов...?


                          Может быть дело таки не в отрасли, а в вашей фирме, раз в ней у всех отвращение к тестированию вырабатывается?

                            0
                            Пишущие книги как раз тестированием уже не занимаются.
                            Как и преподающие тестирование. В Долине тестирование — это преимущественно удел жён индусов. Они и по двадцать лет готовы протирать таким образом задницу. Из этого можно сделать вывод что в QA долго может сидеть лишь тот, для кого это реальный потолок. То есть инженером ему не стать, а для управленца недостаточно хитер, подл,…
                  0
                  test-lead /QA-lead / директор по качеству — я бы таки выделил в отдельный шаг / ступеньку:
                  сейчас, выглядит, что это все внутри «Менеджер» — но не любой менеджер справится с задачами вроде: выстраивание процессов тестирования, принятие решений о необходимости внедрения тех или иных практик, внедрений оптимизаций и улучшений процесса обеспечения качества и ответ на вопрос «Сколько нужно тестировщиков на одного разработчика?» [в контексте конкретного предприятия с учетом всех особенностей процессов и ожидаемого уровня качество получаемого продукта]

                  как будто в QA нет возможностей развиваться и из этой специализации нужно бежать в куда-нибудь…
                    0
                    DevOps, Security QA
                      0
                      Снова халивары, дворник это профессия
                        0
                        очередной рассказ о том что черное это черное, а белое это белое. Откройте блог любой серьезной или не очень компании из Qa сектора там этих карьерных путей… Много

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

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