Чем отличается QA от тестировщика? Да, мы все помним определение QA по ISTQB: инженер, обеспечивающий соблюдение требований к качеству. Ну, а по сути? По сути, отличие в том, что тестировщик тестирует функционал, а QA — процесс создания полезного продукта. Для QA его subjects under test — это и процесс создания, и полезность, и продукт. Все три по отдельности и вместе — никаких «или»!
Перестать им быть. Нет, я серьезно. Попотеть придется, конечно, но оно того стоит. Для начала попробуйте изменить угол зрения, под которым вы смотрите на разработку в целом.
При ментальном переходе от тестера к QA вопрос стоит в изменении уровня абстракции. Как только вы начнете рассматривать весь процесс разработки, деливери и поддержки софта как фичу, вы поймете, что к нему применимы все те же техники тестирования.
Вообще, техники тестирования — это мощный инструмент. Его можно применить буквально ко всему, даже к детским каруселькам (но лучше без фанатизма, конечно). Предлагаю разобраться на примерах.
Представьте себе процесс разработки от момента сбора требований до получения фидбека от пользователей как диаграмму состояний и переходов. Вы, как QA, можете описать условия перехода из одного состояния в другое. А также условия, при которых переход зафейлится. В результате у вас появится набор acceptance-критериев на каждом из этапов.
Граничные значения? Легко. Предположим, вам нужно определить критерий, на основании которого вы принимаете решение, идет фича в релиз или нет. Не бывает фич без багов. С каким количеством багов вы можете идти в релиз?
Допустим, вы выставили граничные значения [0, 3] бага нормального приоритета для среднего размера фичи. Найдено четыре бага с нормальным приоритетом? Sorry!
Подумайте о классах эквивалентности для разрабатываемых на вашем проекте фичей. Оценивайте фичи исходя из того, в какой из классов они попадают.
Оценка может касаться как времени на тестирование, так и рисков, сложности процесса разработки.
Например, речь идет о внедрении новой платежной системы. Допустим, одна у вас уже имплементирована. Значит, скорее всего, разработка новой займет не меньше времени, потребует примерно такого же количества усилий и будет иметь не меньший процент рисков.
Скорость, точность оценки, предсказание рисков. Не говоря уже о приятном бонусе — качестве конечного продукта.
Помимо перечисленного выше такой подход позволяет обнаруживать проблемы в процессах. Ваши ретро точно перестанут быть томными.
Вы сможете обсуждать проблемы предметно, а не на уровне gut feeling.
В целом, переход на другой уровень абстракции — это и есть тот самый out-of-the-box thinking. Вопрос не в том, можно ли вставить SQL-код в поисковое поле, а в том, продумана ли логика предотвращения SQL injection на уровне всего продукта и есть ли бекап базы данных на проде.
Возвращаясь к инструментам: в арсенале QA есть еще один, важность которого сложно переоценить. Я говорю о фидбеке. Фидбек о качестве фичи мы оформляем в виде бага. Попробуйте прокачать применение этого инструмента для оценки качества процесса разработки.
Качественно сформированный, обоснованный фидбек с предложением по улучшению — это точка роста для любого проекта. Такой подход способствует и вовлеченности команды, и оптимизации затрат, времени и усилий на разработку — а косты (от англ. cost — затраты — прим.) считают все.
Кому и как давать этот самый фидбек? Любому члену команды — будь то коллега QA, разработчик, PM или HR. Да, это нужно уметь делать аккуратно. Поэтому фидбек должен содержать:
Пример, знакомый многим: Business Analyst (BA) поздно отдает требования к фиче, Project Manager (PM), в свою очередь, пушит команду и говорит, что дедлайн — вчера. Команда стонет, но делает.
Что делает QA? Собирает факты. Вот так может выглядеть его фидбек для РМ:
Для того, чтобы озвучить эту информацию, необязательно ждать следующего ретро. Но нужно обязательно озвучить, что вы ждете действий по реализации предложения или встречного предложения, которое позволит найти оптимальное решение для всех.
К счастью, в нашей профессии инициатива приветствуется, потому что она позволяет бизнесу либо экономить, либо зарабатывать. С высокой долей вероятности вас поблагодарят за нее, а не уволят.
Используйте это, чтобы прокачать в себе QA: вам нужны любопытство, смелость, настойчивость и ответственность.
Если вы умудритесь подружить все эти качества между собой, вы рискуете стать классным QA. Никто не говорит, что будет легко, но рекомендую все же попробовать. А вдруг понравится 🙂
В благословенные офисные времена, когда не было большой войны и коронавируса, люди гораздо больше общались…
Вот две истории из собственного опыта, с тех пор, когда только начинал делать свою карьеру…
«Ты же программист». За свою жизнь я много раз слышал эту фразу. От всех. Кто…
Отличные новости! Если вы пропустили, GitHub Copilot — это уже не отдельный продукт, а набор…
Несколько месяцев назад мы с командой Promodo (агентство инвестировало в продукт более $100 000) запустили…
Пару дней назад прочитал сообщение о том, что хорошие курсы могут стать альтернативой классическому образованию.…