Home

Автор: Майкл Болтон
Оригинал статьи
Перевод: Ольга Алифанова

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

В этой статье, говоря о покрытии, как о «пропорции протестированного продукта», я сказал:

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

И я также сказал:

В терминологии Rapid Software Testing, говоря о покрытии в целом, мы имеем в виду вот что:

Покрытие – это то, насколько тщательно мы исследовали продукт, согласно определенной модели.

У некоторых людей это вызывает вопрос «Как нам измерить покрытие?» Это равнозначно вопросу «Как нам измерить тщательность нашего тестирования?»

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

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

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

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

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

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

Доходчивость – важная идея, с которой связано множество багов и фич. С точки зрения багов вопрос рассматривает Венкатеш Рао в своей статье, а также отличная книга Джеймса С. Скотта Seeing Like a State. Доходчивость – одна из причин, почему глупые инструменты управления кейсами так привлекательны для менеджеров; графики и схемы дают визуальную обнадеживающую иллюзию понимания. «Видите?»

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

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

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

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

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

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

Уровень 0

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

Уровень 1

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

Уровень 2

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

Уровень 3

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

Учитывая все это, вы сможете сказать «мы очень мало знаем об этой области продукта; мы много знаем о той», а также «мы покрыли эту часть продукта тщательнее, чем ту». И да начнется обсуждение.

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