Автор: Филип Рик
Оригинальная публикация

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

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

Тестировщики и разработчики отличаются по навыкам, но цели у них общие (по крайней мере, должны такими быть). Я считаю, что тестирование и разработка – две стороны одной медали. Когда разработчик запускает веб-приложение в браузере, он перестает быть разработчиком? Когда тестировщик проектирует автоматизированный скрипт, он больше не тестировщик?

Конечно, нет.

Я думаю, что этот барьер портит жизнь всем нам. Разработчики создали потрясающие стратегии, как выпустить отличное ПО и командно расти. Тестировщики сделали то же самое. Делясь этими знаниями, мы можем создать нечто большее суммы своих составляющих – и «1 + 1» действительно будет равняться трем.

Эта статья – сборник мыслей и идей, как нам лучше сотрудничать. Наслаждайтесь.

Тестировщики должны научиться хорошо понимать код

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

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

Разработчики должны бороться с нестабильностью тестов

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

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

Тестировщики должны относиться к автоматизации, как к разработке

К коду тест-автоматизации часто относятся, как к существу второго сорта. Многие команды держат его отдельно от основной базы кода. Этому искусственному разделению разработки и тестирования надо положить конец: тест-автоматизация – это тоже разработка. Если вы инженер-автоматизатор, то вы и разработчик, и тестировщик.

Чтобы улучшить свою тест-автоматизацию:

• Используйте инструменты разработчика вроде ESLint, Prettier и TypeScript.
• Создавайте библиотеки и утилиты многократного использования.
• Пишите полную и внятную документацию.
• Внедрите рецензирование разработчиками и тестировщиками.
• Создавайте чеклисты качества.
• Приоритезируйте тестирование в команде.
• Празднуйте победы и демонстрируйте пользу.

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

Разработчики должны сместить акцент на пользователей

В своем замечательном докладе «8 убеждений тестирования» мой друг Энди Найт говорил о концепциях сдвига влево и вправо в тестировании. «Сдвиг вправо» в тестировании акцентирует значимость того, что происходит после релиза. Как тестировщики, мы отслеживаем баги, оцениваем их серьезность и влияние на пользователя. Разработчики тоже должны начать так мыслить.

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

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

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

Тестировщики должны концентрироваться на выполнении тестов

Принцип DRY («Не повторяйся») – крепкая основа любой базы кода, но, как и любой принцип, может доходить до маразма. Старшие разработчики прекрасно принимают решения по проектированию, улучшающие поддерживаемость и читабельность кода. Как ответственные за код тестов, тестировщики должны начать мыслить так же.

Однако DRY в тест-автоматизации куда шире простого сокращения дублирующих функций. Мы должны применять его не только к созданию кода, но и к его запуску.

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

Избегайте повторяющихся UI-взаимодействий в распространенных сценариях вроде авторизации – используйте вызовы API или управление состояниями браузера, Cypress и Playwright позволяют это прямо из коробки. Это может значительно сократить время прогона, сохраняя тест-покрытие неизменным.

Разработчики не должны забывать о тестируемости

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

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

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

Тестировщики и разработчики должны делиться знаниями

Тестировщики и разработчики – не оппоненты. Мы партнеры в поставке качественного ПО, которое служит пользователям. Разрушая искусственно возведенные барьеры, мы можем создавать потрясающие вещи.

Обсудить в форуме