Я очень хотела попасть в тестирование не питая иллюзий, что это «легкий вход в IT» — он давно перестал быть таковым! Сейчас я работаю QA Fullstack в клиентском пути «Платежи и Переводы» Альфа-Банка уже 1,5 года. Мечта сбылась, а помогли мне самообучение и курсы от Альфа-Банка.

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

Почему именно Fullstack?

На собеседовании я спросила своего будущего лида о том, кого он ищет: специалиста на ручное тестирование или на автоматизацию? На что получила ответ «Мы все фулстеки и мы QA»

Сейчас разберемся, подождите.

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

Fullstack, в контексте тестирования, подразумевает под собой совмещение ручного и автотестирования. Если брать меня, как пример, то я работаю в команде разработки и являюсь QA Fullstack по продуктам AlfaPay NFC и AlfaPay QR: занимаюсь тест-аналитикой, ручным тестированием функциональности. И, кроме этого, пишу автотесты по AlfaPay NFC в 3 проекта:

  • проект интеграционных автотестов, здесь идут проверки на соответствие API-контрактам;

  • проект UI-автотестов, используем Selenide, здесь преимущественно e2e-сценарии;

  • проект WAS-овых автотестов, здесь проверки сервисов написанных по протоколу SOAP.

А что насчёт приставки «QA»?

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

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

Суммируя получится, что в мои задачи, как QA Fullstack, входит мануальное, автоматизированное тестирование, в полном объеме QC и как у QA есть возможность влиять на процессы.

Так что правду говорил лид: «Мы все фулстеки и мы QA»

У вас может, и скорее всего, возникнет вопрос/негодование/претензия на тему того, что я неправильно описываю термины QA, QC, тестировщика и т.д. Это моё понимание, сформированное обучением, опытом работы, посещением конференций Podlodka, SQA, Heisenbug и прочитанной литературой. Я не сеньор, у меня нет 20 лет опыта, я книги не писала. Следовательно, могу ошибаться. Но я за ясность и понимание и обсуждение.

Но что несомненно, так это то, что до QA Fullstack надо идти через тестирование и QC. Через знания теории, инструментов, через практический опыт.

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

Начнём с теории.

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

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

Для чего это нужно?

Понимание того, что происходит в контексте всего процесса даёт тот самый ответ на те самые вопросы «Для выполнения каких заданий меня наняли? Каких результатов от меня ожидают в команде? В какой форме и в каких артефактах?»

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

Это всё так.

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

Что спрашивали по теории у меня:

  • Что такое тестирование в моем понимании и какие есть виды тестирования?

  • Какие артефакты тестирования существуют и для чего они нужны?

  • Какие техники тест-дизайна знаешь, приведи конкретные примеры?

  • Чем тест-кейс отличается от чек-листа?

  • Приведи пример бага с высоким приоритетом и низкой критичностью.

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

На любом интервью (HR не исключение) огромное значение имеет уверенность и честность. К счастью, вопросы на скрининге очень простые, но если чего-то не знаешь, лучше честно об этом сказать, ещё лучше, зафиксировать вопрос на который ты не знаешь ответ и после интервью заполнить пробел в знаниях. 

Вторым этапом стало техническом интервью с Senior QA и Tech Lead, также с вопросами по теории:

  • Какие техники тест-дизайна знаешь, приведи конкретные примеры?

  • Когда на твой взгляд нужно остановить тестирование?

  • Как понять, что продукт качественный?

Подготовка

Как базовый источник теории я брала силлабус ISTQB на английском: готовилась по версии 3.1.1 (знаю что сейчас вышла версия 4.0, однако есть нюанс). Но кроме него в план, который я составляла для себя, добавила и другие источники, например, статьи на Хабр и Телеграмм-посты от коллег.

Итак, план по пунктам.

№ 1. Разобраться что такое тестирование и зачем оно необходимо. Здесь же миссия тестирования и объекты тестирования:. Смотреть Syllabus 1.1-1.2 (стр 13-16).

№ 2. Принципы тестирования: Syllabus 1.3 (стр 16-17).

№ 3. Пирамида тестирования.

№ 4. Отличие testing/QC/QA и в чём отличия. Мне понравилась статья: Перестань называть себя QA.

№ 5. Что такое Жизненный Цикл Разработки Программного обеспечения SDLC и где здесь работа QA: Syllabus 2.1 (стр 27–29). Наглядная и понятная картинка оттуда.


Идём дальше.

№ 6. Виды и типы и методы тестирования — Syllabus 2.1 (стр 27–29). Плюс другие источники (посты):

№ 7. Shift-left testing и Shift-right testing.

№ 8. Критерии качества. Наглядная картинка.


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

В Syllabus 4 про техники тест-дизайна стр.56-61.

№ 10. Артефакты тестирования: тест-план, стратегия тестирования, баг-репорт, отчёт о тестировании. Пост от коллег из Альфы про Артефаĸты тестирования

№ 11. Что такое Definition of Ready (DoR) и Definition of Done (DoD):  

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

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

Клиент-серверное взаимодействие и тестирование API

Для чего это нужно?

Собеседование?! Да! 

Например, на собеседовании у меня спрашивали: 

  • Опиши своими словами как происходит клиент-серверное взаимодействие?

  • Какие методы HTTP ты знаешь?

  • Чем отличается HTTP от HTTPS?

  • Чем отличается PUT от PATCH?

  • Какой запрос лучше использовать для авторизации GET или POST?

Что нужно знать по теории:

Но теория ведь нужна не только для того, чтобы пройти собеседования, и, как в ВУЗе, сдать «зачет» и забыть? 

Конечно. В работе эти знания пригодятся чуть ли ни каждый день. Тестирование API — это неотъемлемая часть работы QA Fullstack в Альфа-Банке. Наше приложение реализовано с помощью микросервисной архитектуры, у нас больше 400 «апишек». 

Чтобы реализовать ту или иную фичу, нужно создать новую API или доработать старую. Например, из простого и наглядного, недавно передо мной стояла задача протестировать добавление type для эндпоинта (или на IT-сленге «для ручки») #GET /anything-api.

Примерно такую схему работы API-запроса я получила от аналитика.

Видно как запрос должен отработать, что под капотом. 

Но так он работает в теории, с точки зрения документации. А будет ли работать по факту? Для проверки нужен Postman, специальный инструмент для тестирования API. Берём этот запрос и прокидываем его через Postman.

В ответе мы получили код-200 от сервера с JSON-ом в теле ответа. Так отработал API-запрос. 

А на фронте мы видим отрисованный экран по этому JSON.

И так мы плавно подошли к пункту...

Инструменты

Из инструментов я рекомендую только один — Postman — незаменим для тестирования API.

Он довольно простой для входа, но крайне полезный в ежедневной деятельности. При помощи Postman можно делать запросы, быстро копировать и пересылать c URL запроса коллегам. Можно протестировать конкретный запрос, написать цепочку запросов, составить тест-сьюты, автоматизировать многие процессы и т. д. Дифирамбы ему можно петь бесконечно.

Из полезностей по Postman — Большой гайд по тестированию с Postman для начинающих.

Postman хорошо подходит для тестирования как HTTP/HTTPS запросов, так и для SOAP запросов. Многие коллеги для SOAP запросов используют SOAP-UI. Мне больше нравится универсальный для всего Postman. Тут у всех свои предпочтения.

Если вы изучите Postman, у вас будет приличный буст на собеседованиях. 

Базы данных

Для чего это нужно?

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

SELECT count(ID) AS "Count", SourcePort AS "Port" FROM `events` GROUP BY SourcePort ORDER BY Port ASC LIMIT 250

Соотвественно, чтобы решать подобные задачи, рекомендую:

Попрактиковаться в запросах можно на бесплатном тренажере https://sql-ex.ru/.

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

Недавно, мне нужно было тестировать определенные типы карт в определенном статусе: активная дебетовая, замороженная кредитная карта, с пин-кодом, без пин-кода и т.д. Да, я могу сгенерировать карты на тестовом контуре, добиться нужного статуса, но это долго. Куда быстрее взять имеющиеся карты, прокинув SQL-запрос к БД:

select * from TAB_NAME where CARD_TYPE='RA' and LIFE_CIRCLE=03;

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

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

Git

Для чего это нужно? 

На собеседованиях меня про Git не спрашивали, но я считаю, что базовое понимание необходимо для работы.

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

  • git clone [url] — клонирует репозиторий из удаленного хранилища в локальный каталог.

  • git add [file] — добавляет изменения в указанный файл в индекс.

  • git commit -m "commit message" — сохраняет индексированные изменения в новый коммит в локальном репозитории.

  • git status — показывает текущее состояние репозитория, включая неотслеживаемые файлы, изменения в индексе и т. д.

  • git push — отправляет изменения в удаленный репозиторий.

  • git pull — получает последние изменения из удаленного репозитория и объединяет их с локальными изменениями.

  • git checkout [branch] — переключается на указанную ветку.

  • git merge [branch] — объединяет указанную ветку с текущей веткой

Есть матёрые ребята, которые все команды запускают через терминал, а мне нравится UI IntelliJ IDEA — это просто и удобно. По мере необходимости, под определенную задачу, всегда можно за 3 минуты нагуглить необходимую команду

 Отличная статья на эту тему: Работаем с Git: первые шаги в GitHub.

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

Для чего это нужно? 

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

На собеседованиях вопросов тоже на эту тему будет много. Например, у меня на скрининге с HR были вопросы:

  • Какие модификаторы доступа вы знаете?

  • Что такое перегрузка метода?

  • Как в Java реализовано множественное наследование?

  • Что такое сигнатура метода?

На техническом интервью: 

  • Объясни основные принципы ООП просто и с примерами. Как бы ты их объяснила пятилетнему ребенку?

  • Чем абстрактный класс отличается от интерфейса?

  • Какая разница между коллекциями Set и List?

  • Какие паттерны проектирования автотестов ты знаешь?

Был момент на собеседовании, который заставил меня изрядно понервничать: нужно было написать объект класса и конструктор, в итоге создала его прямо в чате Zoom, забыв поставить в конце “;”.

Здесь скорее не про технические знания, а про soft skills — не растеряться и на любой вопрос/задание посмотреть не как на испытание, а как на приключение, пусть и специфическое.

С чего же начать при подготовке к интервью и как планировать обучение?

Первое — выбрать язык.

Для себя я выбрала Java, меня он привлёк своей популярностью и широкой применимостью в автоматизации тестирования. В момент выбора, я сделала исследование вакансий на career.habr и на hh.ru и подавляющая часть вакансий в автоматизации в разделе «требуемые знания» включали в себя слово Java, или инструменты с ней связанные: JUnit, TestNG, Retrofit. 

Также часто встречались мультиплатформенные инструменты: Selenium, Cucumber, Appium, RestAssured, Allure, Maven, Gradle, но везде речь шла о Java.

Поэтому и рекомендации будут связаны именно с Java:

Очень рекомендую книгу по Java, на которую я тоже вышла по рекомендации: Кэти Сиерра, Берт Бейтс, «Изучаем Java» (ориг. «Head-First Java»). Подойдёт она не всем, но точно понравится тем, кто любит простую форму подачи материала, здесь много картинок, читается очень легко. И уровень понимания приходит очень быстро.

Если хорошо заходят ролики Youtube, то рекомендую посмотреть канал Алишева «Java для начинающих»

Звучит скучно, но, советую обратить внимание на официальную документацию Oracle для начинающих — Java Tutorials, и, в целом, на официальную документацию.

Заключение 

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

В одной из статей на habr прочитала мнение про Fullstack QA, что это:

  • или это очень редкий, дорогой специалист;

  • или такой человек во всём разбирается весьма посредственно;

И мне это откликнулось, думаю, так оно и есть.

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

Буду рада, если мои наработки помогут попасть на заветную стажировку или позицию QA junior.

Комментарии (11)


  1. Ruslan964
    29.10.2024 12:42

    интересно, какой опыт был до перехода в it или это первая работа?

    эта информация, как мне кажется, может помочь людям оценить свои силы перед марафоном в смене/освоении профессии)


    1. tatyanagendina Автор
      29.10.2024 12:42

      это моя первая работа в it на инженерной позиции

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


  1. Kaftanova
    29.10.2024 12:42

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


  1. bozhenka99
    29.10.2024 12:42

    @tatyanagendinaКак бы мне помогла ваша статья в своё время. Замечательное полное руководство рабочей минимальной базы для трудоустройства. Думаю у новичков после прочтения будет четкий чек-лист в голове, что сделать и изучить, чтобы пытаться устроиться на работу QA, ещё и сразу со всеми ссылками и примерами!)


  1. tchkEn
    29.10.2024 12:42

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


    1. Didimus
      29.10.2024 12:42

      А что с ним случилось?


    1. tatyanagendina Автор
      29.10.2024 12:42

      спасибо большое за отзыв о статье.
      Пока не слышала про отказ от Postman среди коллег и знакомых.
      Можно побольше подробностей. Интересно)


      1. eusatenko
        29.10.2024 12:42

        Привет, крутая статья!!! (скинул брату) =)
        Нам рекомендуют уйти с постмана из-за того, что запросы через из сервера чтоль идут.

        Я выбрал Bruno - приятный интерфейс, можно импортировать коллекции постмана 1 кнопкой =)


        1. tatyanagendina Автор
          29.10.2024 12:42

          @eusatenkoспасибо )
          *ушла смотреть на Bruno и его возможности


  1. UFO_01
    29.10.2024 12:42

    раньше задачи в спринт брались только с названием, без описания

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


  1. pbezpal
    29.10.2024 12:42

    Если в банк набежит много стажеров, буду знать кто виноват в этом)