Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи: http://www.developsense.com/blog/2018/12/who-needs-the-testers/
Перевод: Ольга Алифанова

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

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

Почему тестировщики пошли на выход? Они плохо справились с указанием от менеджмента "Нам нужно больше автоматизированного тестирования! Автоматизируйте все тестирование! Автоматизируйте все на свете!" То есть тестировщиков попросили стать разработчиками. Неудивительно, что большая часть тестировщиков с задачей не справилась.

Часть проблемы тут в том, что тестировщики получают в лучшем случае базовые познания о программировании. Еще виновато то, что никто на самом деле не знал (или не знает), что означает фраза "автоматизируйте все" (менеджеры, возможно, думали о видимых аспектах тестирования – нажатии кнопок, передвижении мыши, сравнение ожидаемого с фактическим – то есть о том, что мы называем проверками. Тестирование нельзя автоматизировать, а проверки – можно). И свой вклад внесло то, что программирование занимает время, и это довольно заковыристая задача. Кто бы мог подумать?!

В результате получилась пачка автоматических проверок, которые вышли поверхностными, хрупкими, плохо находили баги и не выдерживали темп разработки. У тестировщиков была масса вопросов к разработчикам, а исследование проблем, найденных автоматическими проверками, занимало время и силы. Многие из этих проблем оказались вовсе не проблемами – они возникли из-за ошибок в коде проверок. Разработчики и менеджеры не без причин решили, что все это мешает разработке.

Вкратце, причина для решения избавиться от тестировщиков была в том, что тестирование замедляет разработку. Выход: выкинуть тестировщиков на мороз. Заставить разработчиков заниматься "тестированием" (то есть автоматизированными проверками), потому что разработчики уже достаточно хорошо разбираются в программировании.

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

В понимании Rapid Software Testing тестирование – это оценка продукта путем его изучения через исследования и эксперименты. Давайте расширим приведенную выше историю – оценка продукта путем его изучения через исследования и эксперименты замедляла разработку.

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

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

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

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

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

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

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

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

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

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

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

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