Не тестировщик, а QA: как прокачать в себе специалиста, который нужен бизнесу

Чем отличается QA от тестировщика? Да, мы все помним определение QA по ISTQB: инженер, обеспечивающий соблюдение требований к качеству. Ну, а по сути? По сути, отличие в том, что тестировщик тестирует функционал, а QA — процесс создания полезного продукта. Для QA его subjects under test — это и процесс создания, и полезность, и продукт. Все три по отдельности и вместе — никаких «или»!  

Как QA перестать обижаться на «тестера»? 

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

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

Как это выглядит на практике? 

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

Процесс разработки

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

Граничные значения

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

Допустим, вы выставили граничные значения [0, 3] бага нормального приоритета для среднего размера фичи. Найдено четыре бага с нормальным приоритетом? Sorry!

Классы эквивалентности

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

Оценка может касаться как времени на тестирование, так и рисков, сложности процесса разработки.

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

Что дает такое применение техник к процессу разработки? 

Скорость, точность оценки, предсказание рисков. Не говоря уже о приятном бонусе — качестве конечного продукта.

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

Вы сможете обсуждать проблемы предметно, а не на уровне gut feeling. 

В целом, переход на другой уровень абстракции — это и есть тот самый out-of-the-box thinking. Вопрос не в том, можно ли вставить SQL-код в поисковое поле, а в том, продумана ли логика предотвращения SQL injection на уровне всего продукта и есть ли бекап базы данных на проде.

Фидбек, о котором важно помнить

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

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

Кому и как давать этот самый фидбек? Любому члену команды — будь то коллега QA, разработчик, PM или HR. Да, это нужно уметь делать аккуратно. Поэтому фидбек должен содержать:

• безоценочные факты;
• анализ влияния этих фактов на проект;
Онлайн-курс "Проджект-менеджмент у геймдеві" від Skvot.
Новий левел для тих, хто хоче поєднати менеджерські скіли та любов до ігор.Отримай необхідний скілсет та керуй командою в ігровій індустрії.
Детальніше про курс
• эмоции и ощущения, вызванные этими фактами (важно — безоценочные!);
• предложения по улучшению ситуации. 

Пример, знакомый многим: Business Analyst (BA) поздно отдает требования к фиче, Project Manager (PM), в свою очередь, пушит команду и говорит, что дедлайн — вчера. Команда стонет, но делает. 

Что делает QA? Собирает факты. Вот так может выглядеть его фидбек для РМ:

1. ВА начал сбор требований за две недели до запланированного запуска фичи, но долго не мог получить информацию от двух стейкхолдеров, которые не выходили на связь.
2. Поздний старт работы над фичей привел к тому, что дата релиза сместилась на неделю по отношению к запланированной. Команда овертаймила три дня подряд накануне релиза по четыре-шесть часов. Скоуп тестирования был значительно урезан, в результате мелкие, но неприятные баги были отловлены уже в проде. Шесть пользователей оставили негативные отзывы в сторе. 
3. Команда чувствует себя уставшей и раздраженной. Тяжело сфокусироваться на новых серьезных фичах. 
4. Предложение. Для фичей, которые требуют утверждения более чем одним стейкхолдером, разработать план утверждения заранее (например, за месяц). Если возможно, то в виде шаблона, который можно переиспользовать для других фич.      

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

Вместо выводов

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

Используйте это, чтобы прокачать в себе QA: вам нужны любопытство, смелость, настойчивость и ответственность.

Если вы умудритесь подружить все эти качества между собой, вы рискуете стать классным QA. Никто не говорит, что будет легко, но рекомендую все же попробовать. А вдруг понравится 🙂