Перевод статьи «Test smart: how to deal with biases around testing?».
🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 17.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
В стремительно меняющемся мире IT крайне важно не потерять ориентир в море возможностей. Хайп вокруг автоматизации и связанных инструментов заставляет нас по-новому взглянуть на роль тестировщиков в разработке цифровых продуктов. Существующие предубеждения о тестировании формируют восприятие специалистов в IT-компаниях, сводя его порой к «поддержке регрессионных тестов» или «поиску багов». Эти же стереотипы влияют на самооценку тестировщиков, создавая чувство недооцененности и, как следствие, недоплаты.
На самом деле в agile-команде тестировщик делает гораздо больше: анализирует пользовательские истории, проверяет прототипы, пишет тест-кейсы, следит за поведением системы, изучает отзывы пользователей, поддерживает инструменты для тестирования и управления тестами и так далее.
Но существующие предубеждения упрощают восприятие роли тестировщика. Я вижу, что в профессиональном сообществе тестировщики активно делятся проблемами, но за его пределами эти разговоры почти не ведутся. Нужно менять эту ситуацию. На мой взгляд, основные проблемы современного тестировщика — культ автоматизации, превознесение инструментов над тестовой стратегией и некорректные профессиональные ярлыки.
Культ автоматизации тестирования
«У вас есть опыт автоматизации?» — первый вопрос от менеджера по найму может создать ощущение, что ищут тестировщика, который «автоматизирует все тесты, до которых никто раньше не дотрагивался». Но прежде чем мчаться в автоматизацию, есть несколько моментов, о которых стоит помнить.
Во-первых, существует нереалистичная идея, что автоматизация повторяющихся (регрессионных) тестов решает все проблемы качества. Допустим, мы автоматизировали большую часть текущих повторяющихся тестов. Отлично! Сделаем глубокий вдох. Но если вы думаете, что теперь есть время на медитацию — забудьте. Как быть с тестами, которые добавятся при появлении новых фич? А с тестами, которые будут меняться по ходу обновления функций? И еще тесты, которые невозможно автоматизировать? Команде потребуется человек (или даже несколько), который будет координировать всё это. Особенно если масштаб продукта внушительный.
Во-вторых, компании часто недооценивают затраты на автоматизацию. Написать скрипт в Cypress или Playwright — это только начало, за этим часы работы. А поддерживать тесты и синхронизировать их с обновлениями продукта — это ещё куча часов на «починку» кода. AI-инструменты могут облегчить жизнь, но не все компании их используют, многие продолжают использовать старые привычные инструменты (привет, Cypress).
В-третьих, когда новые фичи нужно протестировать «на вчера», автоматизация редко становится приоритетом. Новые функции чаще всего тестируются исследовательскими методами, потому что автоматизация требует времени. Даже без срочных дедлайнов исследовательское тестирование нужно делать перед автоматизацией, и это добавляет нагрузку на QA.
Было бы лучше, если бы менталитет компаний, нанимающих специалистов, сместился в сторону более целостного взгляда на роли тестировщиков. Подобные изменения нужны и в IT-сообществе: команды должны учитывать ограничения автоматизации и тщательно анализировать текущее состояние и ресурсы, прежде чем запускать проект по автоматизации. Потому что автоматизация — это всегда полноценный проект!
Когда инструменты важнее тестовой стратегии
Недавние собеседования показали мне, что люди охотно рассказывают об инструментах и фреймворках, с которыми работают. Возможно, нам кажется, что уже само по себе умение использовать тот или иной инструмент — это достижение. Но что насчёт реальной тестовой стратегии? Есть ли у команды стратегия, в рамках которой применяются эти инструменты? Или мы используем техники хаотично либо только по запросу клиента (например, если попросили провести security-тестирование)?
Инструменты хороши, когда они встроены в стратегию. Без неё даже самый трендовый тул остаётся просто игрушкой. Можно подключить всё модное и современное — но понимаем ли мы, зачем? Какие реальные задачи тестирования стоят перед нашей командой?
Целостная тестовая стратегия, включающая набор техник и инструментов, — это важнейший актив любой команды. Это фундамент, на котором строится тестирование. Подобно тому как учебник грамматики задаёт правила для изучающих язык, стратегия тестирования отражает систему методов и инструментов. Но кто должен за неё отвечать?
Чтобы сделать процесс эффективнее, Уэйн Роузберри предлагает назначить ответственного за тестирование: «Ответственный за тестирование описывает подход к тестированию в тестовой стратегии. Команда выполняет этот подход в соответствии с достигнутыми договорённостями». На мой взгляд, это отличная идея — иметь человека, который инициирует обсуждение и следит за актуальностью тестовой стратегии в команде.
Логично, что этим должен заниматься тестировщик. Если его нет — роль стоит отдать тому, кто разбирается в основах тестирования и умеет мыслить стратегически. Хотя это совсем не простая задача.
Иногда полезно притормозить и зафиксировать текущую стратегию — хотя бы в виде схемы. Отличный инструмент для самопроверки — Agile Testing Quadrants (квадранты agile-тестирования) от Лизы Криспин и Джанет Грегори. Обсуждение их в команде позволяет увидеть, движемся ли мы в правильном направлении, и закрыть пробелы в собственной стратегии тестирования.
Ярлыки, которые вредят профессии
Людям свойственно навешивать ярлыки — так проще объяснять окружающий мир. Однако это же упрощение может сужать наше восприятие. Я убеждена, что тестирование сегодня недооценено во многом из-за предубеждений, возникающих из неправильной терминологии.
Когда к должности добавляют «manual» (ручной) или «automated» (автоматизатор), роль резко сужается. Manual QA начинают воспринимать как человека, который просто кликает по чек-листу в конце спринта. В то же время QA-автоматизатора могут воспринимать как гибрид тестировщика и разработчика, и не всегда понятно, занимается ли он только кодированием регрессионных тестов или выполняет более широкий круг задач.
Но такие ярлыки создают ложную картину. Роль тестировщика гораздо шире, чем просто проверки качества.
Майкл Болтон блестяще подметил это. точно подмечает: «Ложная и бесполезная идея о том, что тестирование можно автоматизировать, приводит к разделению на “ручное” и “автоматизированное” тестирование». С этим трудно не согласиться. Мы не можем «избавиться от ручного тестирования с помощью автоматизации», как иногда утверждают в IT-сообществе. Тестирование по своей природе — деятельность, управляемая человеком.
Рудольф Грец приводит отличное сравнение, чтобы проиллюстрировать неактуальность спора о преимуществах ручного и автоматического тестирования: «Скажу сразу: весь спор о «ручном тестировании против автоматизированного тестирования» не имеет смысла. Это как сравнивать молоток и отвёртку — это инструменты для разных задач».
Джефф Найман считает, что само разделение — следствие слабой реакции тестировочного сообщества на корпоративные тренды: «Тестировщики уступили обсуждение границ тестирования другим — в основном разработчикам».
Мы же не делим разработчиков на «ручных» и «автоматизированных». Звучит странно, правда? 🙂
В целом я согласна, что ответственность за корректную терминологию лежит на самих тестировщиках. Делить тестирование на «ручное» и «автоматизированное» бессмысленно, хотя в индустрии это по-прежнему модно. Профили с названиями «Automation Specialist» или «Manual Tester» всё ещё встречаются. Возможно, изменения стоит начать с себя и пересмотреть, как мы сами описываем свою профессию.
В итоге, тестировщикам стоит активнее высказываться, делиться опытом и продвигать идею целостного тестирования без деления на «ручное» и «автоматизированное». Мы защищаем качество продукта и объясняем ценность своей профессии, недооценённой в некоторых компаниях. Командам полезно применять автоматизацию там, где это реально нужно, думать стратегически и осторожно использовать ярлыки. И обнимите своего тестировщика, если он есть в команде — такие люди встречаются нечасто!