Размышления о Тестировании

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

Тестирование больше не означает тестирование

Запутаны? Можем себе представить. Раньше цель тестирования была достаточно ясной – “Тестирование - это процесс выполнения программы с целью нахождения ошибок” [Myers79]. Но она меняется при переходе к гибкой и бережливой разработке.

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

Практики работы с кодом, такие как разработка через (модульное) тестирование, размывают границы между тестированием и проектированием, на что явно указывает заявление лидера гибкой разработки Уорд Каннингем:

“Написание тестов сначала - это не практика тестирования”

Разработка через приёмочное тестирование (A-TDD) размывает различия между тестированием и анализом требований. В своей статье “Тесты и Требования, Требования и Тесты: Лента Мёбиуса (Test and Requirements, Requirements and Test: A Möbius strip.)”, опубликованной в журнале IEEE Software, Роберт Мартин и Григорий Мельник утверждают…

… для раннего написания приёмочных тестов, как методики разработки требований. Мы считаем, что конкретные требования сочетаются с приёмочными тестами во многом так же, как две стороны бумажной полосы становятся одной в ленте Мёбиуса. Другими словами, требования и тесты становятся неразличимыми, поэтому вы можете указать поведение системы, написав тесты, а затем проверить это поведение, выполнив эти тесты.

Это размывание границ чревато заблуждениями. Внедрение разработки через (модульное) тестирование в качестве техники тестирования упускает его цель из виду и приводит к поверхностному внедрению. Точно так же мы должны регулярно разъяснять группам тестирования, что они не могут внедрить разработку через приёмочное тестирование без участия других членов команд.

Тестирование больше не тестирование.

Бросьте вызов убеждениями о тестировании

Как уже говорилось выше, дискуссии о тестировании изобилуют убеждениями. Бросьте им вызов! Чтобы стало ясно, мы не говорим, что эти убеждения являются ложными, но не ставя их под сомнения, мы ограничиваем наше мышление и возможность становиться лучше. Глубоко укоренившийся принцип в культуре Тойота является одним из столпов Пути Toyota (Toyota Way): непрерывное улучшение, бросая вызов всему. Тайити Оно (основатель бережливого мышления) сказал:

Если вы собираетесь постоянно следовать философии Кайдзен… Вы должны предположить, что все неидеально. Слишком много людей предполагают, что всё есть так, как оно должно быть… Кайдзен говорит об изменении порядка вещей. Если вы предполагаете, что с текущим положением дел все в порядке, то вы не сможете заниматься Кайдзен. Так что измените что-нибудь!

О каких убеждениях идёт речь? Вот некоторые из тех, с которыми мы сталкиваемся:

тестирование должно быть независимым и поэтому отделённым от разработки
тестирование не может начаться, пока код не написан полностью
тестирование следует в следующем порядке: (1) создание тест-кейса, (2) выполнения тест-кейса, (3) отчёт о прохождении тест-кейса (водопадная модель тестирования)
должно быть отдельное подразделение тестирования
должен быть менеджер по тестированию
тестирование должно быть закончено в конце
тестирование должно быть “хорошо спланировано”
должна быть “стратегия тестирования” и “генеральный план тестирования”
100% покрытие тестами слишком дорого
100% автоматизация тестирования слишком дорога
тестирование требует сложного инструмента для управления тестированием
тестирование должно проводиться ‘тестировщиками’

Не ставя под сомнение эти убеждения, вы поддерживаете узость мышления. Пока вы считаете, что “тестирование может начаться только после завершения разработки”, вы никогда не будете рассматривать инновационные способы выполнения раннего тестирования. Но как только вы осознаете своё убеждение, вы можете усомниться в нём и спросить: “Существует ли способ, следуя которому я мог бы работать по-другому, чтобы тестирование началось до завершения разработки?”

Избегайте использования сложной терминологии в тестировании

Вопрос, который нам нравится задавать крупным продуктовым группам, звучит так: “Что всем вам нужно сделать, чтобы выпустить ваш продукт?”

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

unit-тестирование (unit test)
функциональное тестирование (functional test)
стресс-тестирование (stress test)
тестирование взаимодействия (interoperability test)
нагрузочное тестирование (load test)
тестирование установки (installation test)
свободное/интуитивное тестирование (monkey test)
тестирование документации (documentation test)
модульное тестирование (module test)
системное тестирование (system test)
тестирование стабильности (stability test)
тестирование совместимости (compatibility test)
тестирование под трафиком (traffic test)
тестирование безопасности (security test)
исследовательское тестирование (exploratory test)
приёмочное тестирование (acceptance test)
тестирование разработчиками (developer test)
интеграционное тестирование (integration test)
регрессионное тестирование (regression test)
тестирование надёжности (reliability test)
тестирование производительности (performance test)
тестирование ёмкости (capacity test)
тестирование удобства (usability test)
пользовательское приёмочное тестирование (user-acceptance test)

Ведите простую классификацию тестов

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

Две группы:

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

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

Не разделяйте разработку и тестирование

Бил Хетцель (Bill Hetzel), организатор первой конференции по тестированию ПО, определил в книге The Complete Guide to Software Testing шесть принципов тестирования. Шестой принцип, независимость, является общим мотивом на протяжении всей истории тестирования ПО. Гленфорд Майерс (Glenford Myers), автор первой книги о тестировании ПО, подчёркивал независимость тестирования в Software Reliability :

Тестирование всегда должно выполняться внешней стороной, которая несколько отстранена от программы и проекта… Тестирование системы всегда должно выполняться независимой группой, например, такой как обособленным отделом обеспечения качества.

Почему разделение так важно? Некоторые часто приводимые аргументы:

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

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

В этих аргументах независимость тестирования приравнено к отделению тестирования от разработки. Однако, Хетцель проясняет этот принцип:

Требуется, чтобы была достигнута независимость духа, но не обязательно, чтобы тестирование проводилось отдельной группой людей.

Этот момент повторяется в книге Agile Testing, в которой авторы также указывают на локальную субоптимизацию, создаваемую отделением тестирования:

Команды часто путают “независимость” и “раздельность”. Если структура отчётности, бюджеты и процессы находятся в разных функциональных областях, различие между программистами и тестировщиками неизбежно. Тратится время на дублированные совещания: программисты и тестировщики не разделяют общей цели, а обмена информацией вообще не происходит.

Независимость тестирования не означает независимых тестировщиков.

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

Тестировщики и программисты работают вместе

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

В Скрам-команде ‘тестировщики’ уже не тестировщики, а ‘просто’ члены команды, с основной специализацией в тестировании. ‘Программисты’ - это любые члены команды, которые могут писать код. Каждый член команды разделяет общую цель и, как и вся команда, ответственен за достижение этой цели. Члены команды с различными основными специализациями должны сотрудничать для достижения этой цели.

Обучайте и тренируйте навык тестирования

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

Тестировщики, которые не стремятся повышать свою квалификацию и расти профессионально, способствуют восприятию тестирования как низкоквалифицированной работы. [CG09]

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

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

Они (рассказ одного из участников сессии “Конференция внутри конференции” на Agile 2007, [прим. переводчика]) разделили свою организацию тестирования… Однако они включили тестировщиков в подразделения разработчиков без какого-либо тренинга; после этого в течение трёх месяцев все тестировщики уволились, потому что не понимали своей новой роли.[CG09]

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

Создайте сообщество тестировщиков

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

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

Вместо того, чтобы держать тестировщиков отдельно… подумайте о сообществе тестировщиков. Постройте организацию обучения таким образом, чтобы помочь тестировщикам… в обмене идеями и взаимной помощи. Когда менеджер по качеству станет лидером-практиком в организации, он сможет учить тестировщиков навыкам, необходимым чтобы стать сильнее и лучше справляться с постоянно меняющимися условиями. [CG09]

Не создавайте отдельную команду автоматизации тестирования

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

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

Что происходит потом? Новый функционал реализован. Интерфейсы поменялись и автоматические тесты падают. Команды разработчиков расстроены и просят команду автоматизации тестирования исправить тесты. Или команды разработчиков отключают такие тесты, потому что их не понимают. Или тестовое ПО передаётся командам разработчиков, которые обнаруживают, что оно непригодно или непонятно, и игнорируют его. Или… мы испытали дюжину различных сценариев в организациях. Это никогда не срабатывало.

Почему? Предположение заключается в том, что создание тестового инструментария является сложной и самой важной частью. Но другие важные аспекты недооцениваются:

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

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

Автоматизация тестирования должна быть ответственностью кросс-функциональных команд, как и обычное тестирование.

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

Команда автоматизации тестирования в качестве фича-команды

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

Как получить эти преимущества без недостатков?

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

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

Все тесты должны завершаться успешно – остановись и исправь

Тесты падают?

Остановитесь и исправьте это!

“А что у вас с автоматическими тестами?” - спрашиваем мы продуктовые группы во время их посещения. Иногда, они отвечают: “У нас 800 автотестов, 200 из которых сейчас падают.” Это является громадной очередью и создаёт полное отсутствие прозрачности в разработке. Когда автотесты падают, исправьте это немедленно.

Возведите нетерпимость к дефектам в абсолют

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

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

“Абсолютная нетерпимость к дефектам” - это практическое руководство, которым пользуется один из наших клиентов. Если в его команде находят дефекты, они исправляют их как можно скорее. Это предотвращает:

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

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

Заключение

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