Быстрый старт в QA Fullstack: чем вооружиться будущему стажеру в Альфа-Банке

Я очень хотела попасть в тестирование не питая иллюзий, что это «легкий вход в 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):  

• Syllabus 5.2.3 стр.67.

• Статья Definition of Ready — то, о чем нам забыли рассказать.

• Про DoD пост от коллег.

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

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

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

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

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

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

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

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

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

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

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

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

• Как устроена клиент-серверная архитектура. Можно почитать на ресурсах Itelon или IBM.

• Что такое REST и SOAP. Для чтений — Автоматизация Для Самых Маленьких. Заметки. RESTful API и Расширенные возможности SOAP и когда он нужен?

• Что такое HTTP/HTTPS, Основные методы запросов и их особенности, Статусы ответов. На мой взгляд, очень хорошо описана теория API в книге «Идеальный тестировщик» Кристин Джеквони (стр.101-148). Просто. Ёмко. С картинками из Postman. И есть неплохая статья HTTP-запросы от А до Я.

• Идентификация, аутентификация и авторизация: Проверка безопасности передачи данных, виды токенов. По этой теме изучите книгу «Идеальный тестировщик» Кристин Джеквони со 101 по 148 страницы.

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

Конечно. В работе эти знания пригодятся чуть ли ни каждый день. Тестирование 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

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

• начать знакомство с БД со статьи про разные типы базы данных,

• продолжить статьёй Как изучить SQL за ночь или шпаргалка для системного аналитика (коротко и ёмко по SQL),

• и потом перейти к шпаргалке по основным командам.

Попрактиковаться в запросах можно на бесплатном тренажере 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.

• Массивы.

• Конструкторы.

• Основы работы с коллекциями.

• Основы работы с исключениями.

• Основные аннотации тестовых фреймворков JUnit и TestNG.

• Полезная подборка фреймворков и библиотек для QA от коллег из Альфы с линками на документацию.

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

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

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

Заключение 

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

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

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

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

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

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

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