Home

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

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

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

«Мы ищем начинающего тест-аналитика для написания и выполнения тест-кейсов, чтобы убедиться, что клиенты получают качественный продукт…»

«Обязанности: помогать со сбором требований и разработкой тест-кейсов, удовлетворяющих требованиям»

«Для успешной работы в этой роли необходимо следующее: …Уметь писать ручные тест-кейсы и прогонять их… Подтвержденный опыт создания условий тестирования и сценариев тестирования… Выполнение кейсов и отчетность о результатах».

Из объявлений о найме, опубликованных на seek.co.nz 24 января 2014.

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

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

Что такое тест-кейс?

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

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

Вот два простых контрастных примера:

Во-первых, представьте таблицу тест-кейсов, характеризующихся различными условиями. процедура, ассоциирующаяся с этими кейсами, подразумевается или где-либо задокументирована. Следовательно, об этих кейсах можно говорить как о вариациях какой-либо одной тест-идеи. Зачастую содержание каждой ячейки используется для отчета о статусе продукта с точки зрения этого кейса. Отметим, что совершенно неочевидно, как описывать или подсчитывать эти кейсы в данном примере. «Разрешенные Cookies” – отдельная идея и вполне тянет на звание тест-кейса. А может, вся таблица – это один кейс?

Другой пример также часто называется кейсом. Это пошаговая процедура:

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

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

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

Невинные основания

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

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

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

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

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

Культура тест-кейсов и фабричная школа

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

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

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

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

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

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

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

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

Фабричная теория на практике

Что случится, если мы попытаемся управлять сложной когнитивной деятельностью – тестированием – материализуя эту деятельность до поверхностно репрезентативных тест-кейсов?

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

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

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

Тестирование – не фабрика: тестирование – это деятельность

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

Тестирование – это оценка продукта путем его изучения через эксперименты и наблюдения за ним в действии.

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

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

Однако в ряде организаций тестирование управляется именно таким образом.

Конечно, этот случай не претендует на тщательно контролируемый научный труд, но, по крайней мере, подрывает веру в то, что провозглашается массой тест-консультантов и авторов, начиная с «Методов тестирования ПО», первой книги о тестировании, написанной Уильямом Хетцелем в 1973 году – что письменно зафиксированные кейсы – это сильная и стабильная основа тестирования.

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

Существует ли алгоритм, который гарантирует поиск всех важных багов? Увы. На этом базируется компьютерная теория (см. проблема Халтинга) и тот факт, что баги социально конструируются пользователями, а не являются сущностью продукта. Баги не находятся «в» продукте. Баги – это взаимоотношение между продуктом и людьми, которые чего-то от него хотят. Баг можно создать или исправить, просто заменив лицо, мнение которого важно. И помимо всех прочих проблем, алгоритм, полностью идентифицирующий все баги, потребует полной, непротиворечивой, своевременной спецификации, насчет которой все заинтересованные лица пришли к согласию… давно вы видели нечто подобное?

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

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

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

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

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