Адаптивность QA-инженера

Меня зовут Андрей Ю, и я расскажу про адаптивность QA-инженеров (quality assurance engineers) – что это такое, зачем она нужна, какие проблемы решает и как к ней прийти. В каком-то смысле я предлагаю план развития QA-тестировщика, который у меня хорошо сработал.

[материал на основе моего видео]

Что такое адаптация

Адаптация – это способность человека подстроиться под изменившиеся условия. В том числе, если он сам меняет свою деятельность. Например, когда специалист по ручному управлению решает перейти в автоматизацию или автоматизатор UI решает перейти на REST.

Мне пришлось адаптироваться, когда от UI- и REST-автоматизации я перешел к автоматизации и тестированию OpenStack в VK Cloud (бывш. MCS). OpenStack – платформа, которая позволяет одним кликом получить виртуалку, кластер Kubernetes, базу данных или даже целый кластер из них. Тема интересная, но сообщества тестирования OpenStack еще нет.

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

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

Что нужно, чтобы научиться адаптироваться

Способность адаптироваться зависит от многих факторов и навыков QA-инженера, но все можно свести к мотивации и гибкости ума.

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

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

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

• общаться с разработчиками;
• изучать новые фреймворки;
• пробовать новые подходы;
• вникать в бизнес-процессы и так далее.

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

Есть и более конкретные вещи, которые необходимы, чтобы научиться адаптироваться.

Поиск паттернов

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

• Backend-разработчиков можно сравнить с фермерами и обработчиками кофе.
• Frontend-разработчики – это обжарщики и баристы, потому что результат их работы можно ощутить прямо у себя в кружке.
• Q-грейдеров (специалистов оценки качества кофе), как и QA-инженеров, обычно никто не видит, но именно они знают процесс лучше всех. Без них появится множество ошибок, а качество продукта упадет.

Знания и условия динамичны, а паттерны остаются неизменными, поэтому при наблюдении за разными сферами нужно обращать внимание именно на них.

Хороший пример – братья Райт. Они в малейших деталях изучали птиц, а потом применяли шаблоны их поведения, что помогло им успешно совершить первый полет.

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

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

Изучение языков программирования

Изучая объектно-ориентированные языки программирования вроде Java и C#, человек начинает мыслить структурно, а языки вроде Erlang или JavaScript учат мыслить событийно. Постоянная смена мышления дает преимущество – мозг становится пластичнее, а новые знания легче усваиваются.

Пробуйте разрабатывать что-то самостоятельно. Например, интерфейс на React, серверную часть Spring Boot на Java или Flask на Python. Обучающих материалов по этим направлениям очень много.

Знание техник продаж

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

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

Fullstack

Хороший специалист должен знать, как устроена каждая часть разработки: начиная с планирования и заканчивая релизом. QA-инженер обязан знать проект даже лучше разработчиков. Если не знаешь, как продукт должен работать, найти в нем дефекты не получится. Также необходимо очень плотное взаимодействие с командой, чтобы понимать, к чему стремиться и на что делать упор.

От чего стоит отказаться

Некоторые вещи могут тормозить не только работу, но и развитие специалиста.

Нудная работа

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

Велосипеды

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

Для OpenStack есть всего лишь один фреймворк – Tempest, написанный на Python. Но он не подходит для нормальной работы, потому что его писал разработчик, а не QA-специалист. Он не смог учесть определенные требования к автотестам.

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

Что в остатке

Если осознанно подойти к собственной адаптации как QA-инженера, в незнакомой ситуации ты сможешь адаптироваться и эффективно работать. Если тебе надоест тестирование, ты всегда ты сможешь уйти в разработку или менеджмент. Яркий пример – Евгений Федоров, CTO (технический директор) фонда «Общественное мнение», который начинал карьеру как специалист  по автоматизации тестирования в HeadHunter. Любой сможет добиться вершины, если будет мотивирован и нацелен на всестороннее изучение своей работы.