Перевод статьи «Test smart: how to stay resilient if you are QA?».
Свежие вакансии для тестировщиков:
Как человек, который сейчас активно ищет новые приключения (то есть работу) в сфере обеспечения качества, я заметила один любопытный феномен. Но сначала задам вам один случайный вопрос. Вы бы пошли к врачу, если бы его должность звучала как «эндокринолог/офтальмолог»? У меня такая формулировка сразу вызвала бы сомнения. Может ли один человек действительно быть достаточно компетентным сразу в нескольких медицинских областях? Честно говоря, я бы от такого врача просто сбежала.
На рынке труда происходит нечто похожее. Тестирование как профессия и роль QA всё ещё недооценены в стремительном мире ИТ. Поэтому если вы видите вакансию вроде «UX-дизайнер/тестировщик», «тестировщик/специалист поддержки» или «разработчик/тестировщик», можно почти сразу понять, что в стратегии компании тестирование занимает далеко не первое место. Причин у этого может быть несколько. Во-первых, компания может просто хотеть сэкономить и нанять одного человека сразу на две роли. Во-вторых, дело может быть в недостаточном понимании роли тестирования и сложности методов обеспечения качества.
Так ли плоха многозадачность?
Если вы легко справляетесь с несколькими задачами одновременно, вакансия с «косой чертой» может показаться интересной. Но стоит понимать, что придётся постоянно переключаться между разными ролями. У меня был небольшой опыт, когда я совмещала работу тестировщика и специалиста поддержки, и могу сказать — это серьёзная ментальная нагрузка. В таких условиях сложно глубоко развиваться хотя бы в одной из областей.
Однако без развития не обойтись. Чтобы расти как специалист, нужно получать новые знания и углублять экспертизу. Это требует времени и сосредоточенного изучения конкретной области. Можно ли эффективно учиться, когда одновременно выполняешь две роли? Скорее всего, это будет непросто. Со временем такой режим может привести и к выгоранию.
Читайте также: Как избежать выгорания, работая в QA
Понимание роли QA
Если посмотреть на ситуацию со стороны компаний, уровень понимания обеспечения качества в ИТ заметно различается. За время своей работы я встречала специалистов из индустрии, которые не до конца представляли, что вообще такое обеспечение качества и в чем заключается роль QA. Кстати, именно это и стало причиной, по которой я начала писать статьи.
Обеспечение качества — это гораздо больше, чем просто тестирование. Эту мысль хорошо сформулировал Бен Бирн:
«Когда специалистов QA называют “тестировщиками”, это сильно сужает представление о том, чем они занимаются. Тестирование — важная, но далеко не единственная часть их работы. Специалисты по качеству участвуют во всём процессе разработки: от анализа требований до проектирования, реализации и дальнейшей поддержки продукта. Называя их только “тестировщиками”, мы игнорируем их вклад на этих этапах и тем самым недооцениваем их роль в разработке».
Следуя старой привычке, я всё же продолжу использовать слово «тестировщик». Однако важно помнить: работа тестировщика — это не только тестирование как таковое. Она включает гораздо больше: анализ пользовательских историй, ревью прототипов, написание тест-кейсов, наблюдение за поведением системы, изучение обратной связи пользователей, поддержку инструментов тестирования и систем управления тестированием и многое другое.
Дженералисты или специалисты
С первых дней Agile лидеры ИТ-индустрии считали, что все члены команды должны быть универсальными специалистами. Предполагалось, что каждый должен уметь и писать код, и тестировать. Однако на практике большинство людей не могут одинаково хорошо выполнять несколько ролей — невозможно качественно освоить всё сразу.
Эту проблему хорошо описали пионеры гибкого тестирования Джанет Грегори и Лиза Криспин:
«Чем сложнее становятся программные системы, тем сильнее растёт потребность в специалистах с глубокой экспертизой. Сегодня существует множество специализированных направлений тестирования — безопасность, производительность, доступность, удобство использования, надёжность. Однако со временем всё больше организаций приходят к выводу, что тестировщики им не нужны. Когда мы наблюдаем команды без специалистов по тестированию, мы видим серьёзные пробелы в тестировании и игнорирование многих характеристик качества».
Инженеры по качеству могут быть универсальными специалистами в плане профессиональных интересов. Например, тестировщик, который изучает автоматизацию повторяющихся сквозных тестов, частично осваивает навыки разработчика. А тестировщики, хорошо разбирающиеся в нагрузочном и производительном тестировании, нередко обладают и хорошим чутьём на проблемы удобства использования. В этом нет ничего плохого. Более того, специалист с Т-образным профилем будет очень полезен любой команде.
Но станет ли хороший QA забирать работу у дизайнеров или разработчиков и совмещать несколько ролей в одной команде? Я в этом сомневаюсь. По крайней мере, большинство сильных специалистов по качеству, которых я знаю, сосредоточены на своей области и помогают командам улучшать качество цифровых продуктов.
Заключение
Если вы Product Owner, вам не стоит брать на себя всю ответственность за качество продукта. Качество — это командная задача. Важно понять, как именно команда работает с качеством: какие функциональные требования и характеристики продукта проверяются и кто за это отвечает. Есть ли человек, который формирует стратегию тестирования и следит за тем, чтобы использовались подходящие методы и инструменты? Если нет, возможно, команде есть куда расти. Иногда команде просто нужен специалист, который станет движущей силой тестирования и поможет объединить всех вокруг общей цели — качественного продукта.
Разработчикам тоже полезно задать себе вопрос: существует ли в команде продуманная стратегия тестирования? Всё ли действительно выстроено правильно? Или времени на тестирование всё меньше, и команда просто полагается на набор автоматических проверок, которые дают зелёный сигнал к релизу? Такая ситуация часто возникает в командах без специалиста по QA. Тогда задачи тестирования распределяются между разработчиками, проверка продукта выполняется поверхностно и воспринимается как дополнительная нагрузка. Возможно, стоит обсудить это внутри команды и подумать, что можно изменить.
UX-дизайнерам тоже важно быть осторожными, когда на них начинают перекладывать задачи QA. Безусловно, дизайнеры способны проводить пользовательские тестирования. Но дизайнер, который сам создавал прототип продукта, вряд ли может полностью объективно оценивать удобство готового решения. Поэтому лучше вовлекать всю команду в оценку пользовательского опыта. При этом наличие отдельного QA-специалиста позволяет быстрее прийти к результату. QA может посмотреть на свежие прототипы глазами пользователя и дать полезную обратную связь. В итоге вы экономите время и избегаете переделки пользовательских сценариев.
Сейчас, когда бурный рост ИТ-рынка немного замедлился, на LinkedIn и других площадках всё чаще появляются вакансии с «косой чертой». Насколько это разумно и действительно экономично? Я бы поспорила.
Самое главное — продолжать говорить о роли QA в быстро меняющемся цифровом мире. Даже самые продвинутые инструменты на базе искусственного интеллекта вряд ли смогут заменить внимательных, наблюдательных и эмпатичных людей, которые посвящают себя обеспечению качества и заботе о конечных пользователях.
А для себя за последние месяцы я сделала вывод: мне хочется продолжать карьеру как независимый специалист по QA. Сохраняйте спокойствие и оставайтесь устойчивыми.