Home

Автор: Джеймс Бах (James Bach), Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=30

Перевод: Ольга Алифанова

Почему тестирование нельзя закодировать

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

Идея, что тестирование можно закодировать, не поддерживается ни научной, ни инженерной литературой. Несмотря на годы поисков, авторы так и не нашли исследований, подтверждающих, что тестирование должно быть зафиксировано письменно – они даже не нашли подтверждения, что это в принципе возможно сделать. На самом деле верно ровно обратное. См. «Sciences of the Artificial», написанную нобелевским лауреатом Гербертом Саймоном – он глубоко изучает этот вопрос. Саймон демонстрирует, что идеальная рациональность доступна нам только в простейших ситуациях, и изучает природу процесса дизайна как «ограниченно рациональную», требующую эвристических решений. Прочитать стоит и «Introducton to general systems thinking» Джеральда Вайнберга, который показал, что наблюдение и описание систем требует их упрощения, и что алгоритма, позволяющего, как сделать нечто, ничего не потеряв, не существует.

Также можно взглянуть на книгу «Social life of information» Пола Дугайда и Джона Сили Брауна, рассказывающих, как ремонтники ксероксов учились работать не путем чтения документации, а путем общения друг с другом. Или же книга «Things that make us smart” Дона Нормана, демонстрирующего, как добавление когнитивного артефакта (например, задокументированного тест-кейса) в процесс меняет этот процесс потенциально непредсказуемым образом. Если вы просто бегло пробежитесь по этим работам, вы увидите, как авторы отвергают механистичные, упрощенные, алгоритмичные способы создания и контроля сложных систем, включая социальные.

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

У тестирования множество уровней, каждый из которых вносит свой вклад в успех тестирования, и каждый из которых сложно закодировать:

1. Рождение человека.

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

1. Человек учится тестировать.

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

1. Тестировщик присоединяется к проекту.

Подключение к проекту – это сложный социальный процесс.

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

Чувство контекста и умение реагировать на него можно вкратце набросать, но нельзя полностью закодировать.

1. Тестировщик изучает продукт.

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

Итак, хоть часть нашего обучения и может быть закодирована, большая его половина никогда до этого не дойдет по как минимум двум причинам:

1. Не существует алгоритма или механизма, позволяющего сделать «дамп мозга», точно отражающего состояние наших знаний о чем угодно. Мы не можем быть уверенными, что не существует фактов, о которых мы знаем, но которые еще не добавлены в модель.
2. Даже если бы такой механизм существовал, общий объем обучения огромен. К примеру, чтобы перечислить наши реальные ожидания от поведения браузера, показывающего простенькую страничку – к примеру, домашнюю страницу Google – потребуется предельное время и пространство. И это даже если не брать в расчет еще большую динамику – процесс изучения продукта – это тоже тестирование.

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

Итак, большая часть изучения продукта и тестирования во время изучения не кодируется.

1. Тестировщик приступает к тестированию, вооруженный определенной идеей.

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

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

Представьте процесс тестирования: вы смотрите на проект. Думаете. Пробуете что-то сделать. Видите результат и размышляете уже над ним. У вас появляется вопрос, а затем наблюдение, которое может дать вам ответ. И так далее. Опытные тестировщики выполняют сотни того, что можно назвать раздельными тестами, в течение сессии. Очень небольшая их часть нуждается в повторении. Большинство тестов вытекают из результатов предыдущих тестов. Ценность теста может быть неизвестна до того, как он будет выполнен, а может стать явью намного позже.

Тестирование кажется кодируемым, потому что мы можем выкристаллизовать из всей этой обучающе-думающе-пытающейся каши такие действия, как конфигурация, взаимодействие, наблюдение и оценка. Эти моменты встроены в нашу концепцию риска и статуса продукта. Но человеку со стороны, который не знаком со спецификой работы мозга тестировщика, онимогут показаться отдельными единицами. Джеймс Бах и Майкл Болтон в своей методологии Rapid Testing называют действия, которые может выполнить машина, «проверками». Про проверки полезно поговорить, потому что это задача, которая является частью тестирования, и может быть ускорена или серьезно поддержана автоматизацией. Но следует помнить, что проверки – это только часть тестирования, а не тестирование как таковое – молоток, к примеру, не представляет собой все плотническое дело. Проверку, по определению, можно закодировать. Процесс зарождения идеи, дизайна, внедрения, переоценки или оценки значимости результатов выполнения проверки закодировать невозможно. Тут можно возразить, что мы можем закодировать тестирование, просто записывая движения мыши/нажатия клавиатуры, или снимая процесс на видео. Эти записи могут приносить пользу, но это всего лишь отголоски того, что на самом деле происходит в голове у тестировщика. Они не описывают богатство разума и опыта, требующегося для поиска багов. Ваше проигрывающее нажатия мыши устройство не остановится и не скажет «погодите-ка, по-моему, я копаю не туда».

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

Следовательно, за вычетом факт-чекинга, выполнение тестов не может быть закодировано.

1. Тестировщик отчитывается о работе, разъясняет, защищает, совершенствует свое тестирование.

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

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

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

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

Но почему фальшивое тестирование работает?

Ответ №1:

Тестировщики втихаря тестируют по-настоящему. Брайан Осман называет эту практику «тайным тестированием». Это происходит, когда опытные тестировщики приносят проекту пользу, скрывая это от менеджмента, культура которого требует производительности, вместе с тем вводя процессы, снижающие эту самую производительность.

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

Ответ №2:

Продукт уже достаточно хорош, даже с учетом плохого тестирования.

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

Ответ №3: ответственность за плохое ПО легко спихнуть куда-нибудь еще.

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

К культуре производительности

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

• Концепция тестирования. Тестирование – это деятельность, выполняемая опытными профессионалами. Цель тестирования – выявить важную информацию о статусе продукта, чтобы наши клиенты могли принимать информированные решения о нем.
• Найм. Нанимайте тестировщиков, которые демонстрируют любопытство, любят учиться технологиям, и не боятся путаницы и сложностей.
• Разнообразие. Поддерживайте разнообразие среди тестировщиков в плане талантов, темпераментов, и других потенциально релевантных факторов, с целью увеличить общую производительность команд.
• Обучение. Систематически обучайте тестировщиков, как оффлайн, так и во время работы, путем тренингов и системы наставников.
• Равноправное обучение. Используйте конференции и неформальные встречи для построения внутренних сетей коммуникаций и экспериментов с методами и инструментами. Периодически тестируйте группами («баговечеринки»), чтобы добиться общего понимания тест-практик.
• Открытость. Развивайте способность рассказывать, разъяснять и защищать свою работу. Создайте культуру нормального совместного труда.
• Передача работы. Один тестировщик может подхватить задачу другого – помочь ему, уточнить документацию, обсудить важный вопрос или что-то показать, или просто начать задачу с нуля. Для опытных тестировщиков это не проблема – скорее этого боятся новички.
• Личное превосходство. Тестирование зависит от людей, которые гордятся своей работой и стремятся узнать о ней как можно больше. Культура производительности зачастую не приживается потому, что менеджмент не верит, что тестировщики добьются заявленных результатов.
• Интеграция команд. Развивайте культуру взаимопомощи между тестировщиками и разработчиками. По мере установления доверия производительность обеих команд станет более гладкой и улучшится.
• Подготовка. Детальная и тщательная подготовка редко хорошо отражается на издержках в такой инновационной сфере, как разработка ПО, но это не значит, что от нее нужно вовсе отказаться. Как минимум стоит изучить инструменты и технологии, и разработать четкие тест-идеи.
• Отзывчивость. Мы понимаем, что время – деньги. Мы смотрим на продукт, как только он становится доступным для тестирования, и если кто-то похлопает нас по плечу и спросит, как там тестирование – мы должны предоставить полезную информацию, причем немедленно.
• Цикличный процесс исследования. Производительность подпитывается сама от себя. Когда мы тестируем, мы также открываем для себя новые идеи тестов.
• Гибкость. В культуре производительности гибкости добиться проще, потому что мы не тащим за собой весь багаж документации. Следовательно, мы быстрее и продуктивнее реагируем на изменения контекста.
• Метрики. Метрики можно использовать для разбора полетов, но не используйте их как базис для правил контролирования тестирования – это социальный процесс. Любая метрика, внедренная для контроля, будет использована людьми для контроля менеджмента.
• Документация. Сделайте выбор в пользу краткой документации – списков, ментальных карт. Они дешевле в производстве и поддержке. Разработайте дисциплину личных заметок.
• Менеджмент. Тест-лиды должны наблюдать за работой джуниор-тестировщиков или ставить их в пару с сениорами до момента, когда они не будут способны взять на себя всю полноту ответственности за свою работу. Менеджмент первого уровня должен вовлекаться в тестирование регулярно. Дайте квалифицированным тестировщикам свободу выбора стиля работы. Отмечайте успехи, но также отмечайте и честно заработанные провалы.
• Контроль процесса. Сконцентрируйтесь на эвристиках, а не на алгоритмичном контроле за процессами. Фокусируйтесь на дискуссиях, а не цифрах, на доверии стоящим его людям вместо контроля и наблюдений. Если необходим более формальный контроль, используйте подход, основанный на действиях – например, сессионный тест-менеджмент или тест-менеджмент, основанный на цепочках.
• Регрессия. Можно использовать автотесты для обнаружения очевидных проблем с каждым билдом. Эти инструменты должны быть под контролем тестировщиков, которые берут на себя ответственность за них. В дополнение к проверкам регрессионные риски могут потребовать новых тестов или повторения результатов предыдущих.
• Инструменты. Используйте инструменты так, чтобы они поддерживали и улучшали производительность. Не путайте проверочные инструменты с интеллектом живого человека.
• Конец тестирования. Тестирование завершено, когда клиенты чувствуют, что получили ответы на все важные вопросы о статусе продукта. Это чувство – результат дискуссий о тестировании и его результатах, имеющих место в течение всего проекта.

Тестирование, основанное на контексте (Context-Driven Testing, CDT) годами пропагандирует человечный, ориентированный на производительность взгляд на тестирование. В настоящий момент существует две международные организации и несколько конференций, посвященных CDT. Это движение не возражает против каких-либо практик – оно возражает против методологического шовинизма. Практики, используемые нами, должны хорошо работать и подходить конкретному контексту. Постоянное обучение и скептичная оценка себя помогает освободиться от плохих привычек и неподходящих практик. После сорока лет попыток фабричный подход к тестированию так и не сумел решить проблемы тестирования. Может, хватит уже? Оставьте за плечами перегруженную баржу культуры тест-кейсов. Откройте для себя тестирование как интеллектуальную деятельность. Сложности и риски современного мира этого прямо-таки требуют.

Отдельная благодарность Майклу Болтону и команде Testing Trapeze за ревью и комментарии к тексту.

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