Эта статья была начата ещё в апреле текущего (2020) года. И с тех пор я её несколько раз переписывал. Я никак не мог достичь того результата, который бы меня устроил. Я не хотел писать очередную статью про 7 принципов тестирования, куда бы просто скопипастились переводы этих принципов из ISTQB, а потом (как в лучших из статей) сопровождались разъяснениями на тему «Что это всё означает».
Получилось бы очередное переписывание «священного писания» с его толкованием. Однако, поистине священное писание в толковании не нуждается.
Моя статья будет не про то, что же это за 7 столпов тестирования. Я специально опущу некоторые детали при объяснении принципов. Легким движением руки по клавиатуре вы сможете нагуглить всё это сами. Мы поговорим сразу о боли.
Принципы тестирования — это своеобразная конституция, манифест и договорённости нашей профессии. Но, как и в реальной жизни, как бы чётко ни был написан документ, какими бы благими намерениями не руководствовались авторы, конституцию можно трактовать по-разному, на манифест можно забить, о договорённостях можно забыть.
7 принципов тестирования по за 9 минут. ТОП обзор от Senior QA. Курс по тестированию по бесплатно
Вот об этом я бы хотел поговорить в этой статье. О том, как же мы живём с семью принципами тестирования на самом деле.
Это статья-рассуждение. Тут не будет слишком много полезностей, будьте к этому готовы. Скорее призыв к диалогу и попытка поделиться своим опытом и кое-где даже болью. Так что комментарии приветствуются.
Немного о себе, прежде чем начать (эту часть можно пропустить)
Меня зовут Кирилл, я в ИТ с 2009 года, тестированием занимаюсь уже почти 10 лет. Сейчас я работаю на руководящей должности в QA, а так же помогаю в обучении начинающих тестировщиков и параллельно этому всему веду свой телеграм-канал для джуниоров QA (ссылочка будет в конце статьи)
Я не всегда руководствовался в жизни 7ю принципами тестирования. Более того, я не всегда даже знал о них (как и многие тестировщики, я думаю). Но, чем больше сила, тем больше и ответственность, как говаривал дядя Бен. И со временем до меня начал доходить смысл каждого принципа, а после я начал замечать как эти принципы трактуются, искажаются и видоизменяются под тяжестью корпоративных культур каждой отдельной компании.
Собственно семь принципов тестирования
- Тестирование демонстрирует (только) наличие дефектов (Testing shows presence of defects)
- Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)
- Раннее тестирование (экономит время и деньги) (Early testing saves time and money)
- Принцип скопления дефектов (Defect clustering)
- Парадокс пестицида (Pesticide paradox)
- Тестирование зависит от контекста (Testing is context dependent)
- Заблуждение об отсутствии ошибок (Absence-of-errors fallacy)
Тестирование демонстрирует наличие дефектов
Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие.
На этот принцип довольно часто плюют с высоты бизнеса и проджект менеджмента. Менеджменту иногда кажется, что если багов не нашли на этапе тестирования (не важно сколько у вас степеней фильтрации в жизненном цикле), то багов нет. И когда юзеры находят баги на проде, бизнес искренне удивляется и недоумевает: «Как же вы тестируете? Очевидно вы вообще ничего не делаете, ведь если бы тестировали — баг был бы найден».
7 Принципов тестирования
Но, коллеги, не забывайте, что иногда бизнес спрашивает «почему этот баг попал на продакшн?». На этот вопрос вы обязаны ответить вполне конкретно. У каждого конкретного бага есть причины появления/пропуска. Но давая ответ на вопрос, так же давайте понять бизнесу, что отсутствие найденных дефектов в процессе тестирования не гарантирует отсутствия ошибок в системе.
Исчерпывающее тестирование невозможно
Сколь бы скрупулёзным тестирование не было, нельзя учесть все возможные сценарии, а значит и предвидеть все возможные ошибки.
Запомнили принцип выше? Отсутствие багов не гарантирует отсутствие ошибок, кажется, что второй принцип очевидно вытекает из первого, верно?
Некоторые недобросовестные тестировщики используют этот принцип, чтобы оправдывать свою некомпетентность. Ушёл критичный баг в продакшн — «ну что поделать, нельзя предусмотреть всё на свете. Вы вообще знаете, что исчерпывающее тестирование невозможно?». Но они забывают о том, что хотя предусмотреть всё невозможно, это не повод не предусматривать ничего.
В мире ограниченных ресурсов и возможностей нужно уметь оценивать риски и расставлять приоритеты. Тестируя, мы снижаем риски. Делая правильный тест-дизайн, мы ещё сильнее снижаем риски. Так и живём.
Раннее тестирование экономит время и деньги
Чем раньше начнутся активности тестирования, тем дешевле исправление выявленных ошибок. Грубо говоря, вычитка требований стоит пары часов обсуждений и времени аналитика, в то время, как тот же баг в боевой системе стоит потерянных клиентов, времени разработчиков и всего цикла релиза.
Это избитая истина, примерно такого же плана, как и «ПО надо тестировать, т.к. писать код без ошибок физически невозможно». Но многим руководителям кажется, что на самом деле тестирование отнимает время релизного цикла, т.к. задерживает доставку фич, а так же тратит время тестировщиков, на то, чтобы они читали «бумажки» вместо того, чтоб тестировать.
Я всю свою жизнь сталкиваюсь с этим удивительным противоречием; парадоксом, если угодно. Менеджеры говорят, что качество ПО превыше всего, недовольные клиенты — недопустимо, если надо тестировать, то мы выделим на это время. Но на деле почти всегда оказывается, что рук не хватает, бюджета нет и «давайте вы сейчас проверите, чтобы катнуть побыстрее, а потом уже будете свои тест-кейсы писать».
Кластеризация (или скопление) дефектов
Дефекты не размазаны равномерно по приложению, а сконцентрированы в больших количествах в некоторых модулях системы
Для начала хотелось бы заметить, что об этом принципе вообще не вспоминают. Наоборот, найдя пару ошибок в каком-то блоке функционала некоторые тестировщики успокаиваются, мол «ну мы там баги нашли, отлично, пойдем дальше».
Крайний случай (но справедливости ради замечу, что это не самый распространенный случай) — это «тест до первого бага». Причин тому может быть несколько: ленивый или некомпетентный тестировщик, или же метрики/kpi, которые поджимают тестировщика быстрее перекинуть мяч на сторону разработчиков.
Просто помните, если вы уже нашли несколько багов в каком-то модуле, стоит перелопатить его ещё тщательнее, скорее всего там есть ещё скрытые дефекты.
В то же время, отсутствие дефектов в других модулях не говорит, что дефектов там нет (помните первый принцип?)
Парадокс (эффект) пестицида
Это самый распиаренный принцип тестирования. Суть его в том, что если вы долго проводите одни и те же проверки, скорее всего новых багов вы не найдете. Именно поэтому периодически нужно «встряхивать» вашу тестовую базу, ревьюить её новыми сотрудниками и проводить исследовательское тестирование.
Некоторые коллеги во имя избегания этого эффекта «забивают» на классические подходы к тестированию и всё время проводят только исследовательское тестирование. Часто объясняют это тем, что «раз регрессионные прогоны одних и тех же тестов не помогают выявлять новые дефекты, проще полностью отказаться от этого подхода и каждый раз тестировать как на новенького». К сожалению в этом суждении забывается тот факт, что парадокс пестицида говорит лишь о том, что имеющиеся наборы больше не находят новые баги, а не о том, что формальные повторяющиеся из раза в раз проверки вообще не способны находить ошибки.
Тестирование зависит от контекста
Об этом я уже как-то упоминал в одной из предыдущих статей. Набор методологий и инструментов, а также подходов и ресурсов для тестирования зависит от того, что именно вы тестируете и на сколько объект тестирования важен
Иногда забывают о том, что каждой задаче своё решение и подход. Очень распространённая тактика, везде использовать старую методологию, если она себя показала хорошо. Однако этот принцип как раз напоминает нам о противоположном.
Тем не менее, многие прикрываются этим принципом со словами «Если у других методика работает — не значит, что и у нас будет». Это безусловно верно по-умолчанию. Но дело в том, что «чморение новой идеи» не доказывает, что выбранные сейчас подходы оптимальны для тестирования (так же как и доказательства вредности фаст-фуда не подтверждают полезность овощей).
Зачастую, говоря о контексте, тестировщики рассуждают о внешнем контексте: доменных областях и пользователях (которые не меняются длительное время в рамках одного продукта). Но они забывают внутренний контекст: новые разработчики, больше разработчиков, другие владельцы компании, нагрузка на сотрудников, внутриполитические силы в компании. Этот внутренний контекст и позволяет нам поднимать вопрос о смене методологии и процессов, которые раньше были неуместны.
Заблуждение об отсутствии ошибок
Тот факт, что тестирование не обнаружило дефектов, ещё не значит, что программа хорошая.
Ну вот снова! Хочется сорвать с себя шапку-ушанку и крикнуть: «Ай, да катись оно всё пропадом», раз никаких гарантий нет, то нафига вообще тестировать!? Ответ прост: чтобы снизить риски. Протестированный продукт с вероятностью 95% bug free, но не протестированный продукт с вероятностью 95% уйдет в продакшн с багами.
С учетом того, как этот принцип доносят на просторах интернета, легко спутать его с первым принципом. Многие забывают, что суть принципа: отсутствие дефектов — необходимое, но не достаточное условие хорошего ПО. Есть и другие факторы, влияющие на качество продукта. И вот о них-то как раз все забывают, считая, что лишь тестировщики и тестирование ответственны за качество.
Не могу сказать, что я всю свою сознательную QA жизнь только и вижу, как принципы тестирования нарушаются. Нет, ни в коем случае. Я просто подобрал для каждого принципа распространенные случаи игнорирования или иной трактовки. В том или ином виде, объёме, сознательно или нет, но часть принципов соблюдается почти всеми командами, в которых присутствует процесс тестирования ПО. Мне лишь хотелось подсветить некоторые моменты/признаки, по которым чуть легче пустить факт нарушения принципов в своё сознание.
И напоследок вопрос без ответа, который я задаю сам себе (а теперь задам и вам): можно ли поступиться принципами тестирования во имя каких-то благих целей, или принципы тестирования, как семь смертных грехов (ох, вот это аллюзия. только сейчас это понял), являются нерушимой догмой, нарушение которой есть зло?
На просторах интернета я наткнулся ещё на парочку неофициальных доп.принципов, которые мне кажутся более понятными, приземленными и интуитивно полезными:
- тестирование должно производиться независимыми специалистами;
- тестируйте как позитивные, так и негативные сценарии;
- не допускайте изменений в ПО в процессе тестирования;
- указывайте ожидаемый результат выполнения тестов.
Источник: vc.ru
Семь принципов тестирования программ
Несмотря на то, что всем известны теоретические ограничения тестирования программного обеспечения, на практике мы тратим на решение этой задачи огромные силы и средства, хотя при этом считается, что отказываться от тестирования неразумно и крайне опасно.
Другие технологии верификации, такие как статический анализ, проверка на модели и испытания, обладают огромным потенциалом, но ни одна из них не является столь совершенной, чтобы заменить тесты как доминирующую технологию. Поэтому необходимо понять, какова сфера действия и ограничения тестирования и как правильно его выполнять.
Все изложенные в статье принципы сформулированы на основе практического опыта тестирования программного обеспечения и исследований, предварявших разработку автоматизированных инструментальных средств, таких как AutoTest (se.inf.ethz.ch/research/autotest).
Определение тестирования
Тестирование как метод верификации — это парадокс. Тестирование программы для того, чтобы проверить ее качество, теоретически равносильно втыканию булавок в куклу, причем очень маленьких булавок в очень большую куклу. Разрешить этот парадокс можно, определив реалистичные ожидания.
Слишком часто тестированию в литературе по программной инженерии придается огромное значение, что, собственно, и отражено в определении, данном в Wikipedia: «Тестирование программного обеспечения — это процесс оценки качества компьютерных программ. Тестирование — это практическое техническое изучение, проводимое для того, чтобы предоставить заинтересованным сторонам информацию о качестве продукта или сервиса с учетом контекста, в котором, как предполагается, он будет работать». На самом деле, тестирование программы мало что говорит о ее качестве, поскольку 10 или даже 10 млн тестов — это лишь капля в океане всех возможных случаев.
Безусловно, связь между тестами и качеством программ существует, но она довольно слаба?— успешный тест позволяет оценить качество только в том случае, если прежде он не был пройден. Тогда это свидетельствует об отсутствии неудачи и, как правило, — отсутствии самой ошибки*.
Если систематически отслеживать неудачи и ошибки, то их регистрация может дать представление о том, сколько еще ошибок осталось. Если последние три недели при работе тестов было обнаружено 550, 540 и 530 ошибок, то тенденция обнадеживает, но маловероятно, что при следующем тестировании не будет выявлено ни одной ошибки или всего 100 таковых. (Математические модели надежности позволяют оценить это более точно и достоверно, если реализован эффективный процесс долгосрочной сборки данных.)
Единственная бесспорная связь — это отрицательная связь, или, в терминологии Поппера, «фальсификация». Неудачный тест говорит о недостаточном качестве программы. Кроме того, если раньше тест проходил, а теперь нет, то это свидетельство регрессии, указывающее на возможные проблемы качества в программе и в процессе разработки. Самое известное высказывание о тестировании поразительно точно это описывает.
«Тестирование программ, — отмечал Эдсгер Дейкстра, — можно использовать для того, чтобы показать наличие ошибок и никогда — для того чтобы показать их отсутствие!» Очень немногие (Дейкстра, вероятно, на это и не рассчитывал) понимают, что для тестировщиков это означает наилучшую возможность для саморекламы. Безусловно, любая методика, позволяющая находить ошибки, крайне важна для «заинтересованных лиц», от менеджеров до разработчиков и пользователей. Мы должны воспринимать эту максиму не как некое обвинение, а как определение тестирования. Конечно, это не столь амбициозно звучит, как «предоставление информации о качестве», но зато более реалистично и практично.
Принцип 1. Определение. Для того чтобы протестировать программу, нужно попытаться заставить ее работать неверно.
В силу этого принципа процесс тестирования обретает цель: его единственная задача — найти ошибки, инициируя неудачное выполнение. Любое умозаключение по поводу качества относится к области гарантии качества, но никак не к области тестирования. Это определение также напоминает нам, что тестирование, в отличие от отладки, не связано с исправлением ошибок, — оно связано только лишь с их поиском.
Тестирование и спецификации
При создании программ, опирающемся на тестирование (test-driven) и получившем известность благодаря методам «скорой» (agile) разработки, тесты ставят на первое место, но иногда считают, что они могут заменить спецификации. Не могут. Тесты, даже если их миллион, — это лишь примеры; в них отсутствует абстракция, которую может дать только спецификация.
Принцип 2. Тесты или спецификации. Тесты не заменяют спецификации.
Опасность заблуждения, что тесты могут выступать в роли спецификаций, была продемонстрирована целым рядом программных катастроф, которые произошли только потому, что никто не подумал об исключительном случае. Несмотря на то, что в спецификациях тоже могут быть упущены из виду какие-то случаи, по крайней мере, в них предпринимается попытка некого обобщения. В частности, спецификации могут использоваться для генерации тестов, даже автоматически (как в случае тестирования, опирающегося на модели); но обратное без вмешательства человека невозможно.
Регрессивное тестирование
Особенностью тестирования, если судить по практике создания программного обеспечения, является печальная склонность к появлению уже исправленных ошибок. Старые головы у гидры, как бы глубоко они ни были отсечены, вырастают снова. Это явление известно как регрессия и заставляет использовать регрессивное тестирование, то есть проверку того, что исправленное ранее по-прежнему работает. Как следствие, вы всегда должны помнить об ошибке, которую уже когда-то обнаружили.
Принцип 3. Регрессивное тестирование. Любое неудачное выполнение должно порождать тестовый случай, который навсегда становится частью тестового пакета данного проекта.
Этот принцип касается всех ошибок, возникших во время разработки и тестирования. Отсюда вытекает необходимость в инструментарии, позволяющем превращать неудачное исполнение в воспроизводимый тестовый случай, и недавно такой инструментарий появился: Contract-Driven Development, ReCrash, JCrasher.
Предсказания
Выполнение теста полезно только в том случае, если вы можете однозначно определить, прошел ли он. Критерий называется предсказанием теста. Если у вас есть несколько десятков или даже сотен тестов, то вы в состоянии проверить их результаты по отдельности, однако с увеличением их количества это становится все менее вероятным. Данная задача требует автоматизации.
Принцип 4. Использование предсказаний. Определение успеха или неудачи тестов должно происходить автоматически.
Эта формулировка оставляет открытым вопрос о форме таких предсказаний. Зачастую предсказания специфицируются отдельно. В исследованиях, таких как наше, они встроенные, поскольку анализируемое программное обеспечение уже включает в себя контракты, согласно которым тесты используются как предсказания.
Принцип 4 (вариант). Контракты как предсказания. Предсказания должны быть частью текста программы как контракты. Успех или неудача теста должны определяться автоматически, причем в рамках этого процесса необходимо вести мониторинг выполнения контракта во время работы программы.
Этот принцип детализирует предыдущий, в силу чего те, кто не использует контракты, могут придерживаться более простой его формы.
Тестовые случаи, проверяемые вручную и автоматически
Многие тестовые случаи проверяются вручную. Тестеры продумывают интересные сценарии выполнения и готовят соответствующие тесты. К этой категории можно добавить тесты, полученные в соответствии с принципом 3 как результат некорректного выполнения, их первоначально не предполагалось использовать при тестировании. Сейчас все чаще можно дополнить эти две категории автоматическими тестовыми случаями, полученными из спецификаций с помощью генератора автоматических тестов. Процесс, ограниченный тестами, выполняемыми вручную, не в полной мере использует возможности современных компьютеров.
Все подходы лишь дополняют друг друга.
Принцип 5. Тестовые случаи, проверяемые вручную и автоматически. Эффективный процесс тестирования должен включать в себя тестовые случаи, проверяемые как вручную, так и автоматически.
Достоинством тестов, выполняемых вручную, является их глубина: они отражают понимание разработчиком имеющегося круга проблем и структуры данных. Преимущество автоматических тестов в их широте: они выполняют проверку большого диапазона значений, в том числе экстремальных, которые люди могут пропустить.
Стратегии тестирования
Теперь мы переходим от практики тестирования к исследованиям новых технологий тестирования, которые, однако, уязвимы в смысле рисков мыслительного процесса. Вы придумали идею, которая, как вам кажется, обещает усовершенствования и подтверждается вашей интуицией. Тестирование — это сложный процесс, и после объективного анализа далеко не все разумные идеи оказываются полезными.
Типичный тому пример — случайное тестирование. Интуитивно кажется, что любая стратегия, использующая знания о программе, должна быть лучше случайного ввода. Однако объективные показатели, такие как число найденных ошибок, свидетельствуют о том, что случайное тестирование часто превосходит казавшиеся разумными идеи. В обзоре Ричарда Хемлета, посвященном случайному тестированию (Encyclopedia of Software Engineering, J.J. Marciniak, ed., Wiley, 1994), приводится захватывающее противопоставление человеческого знания и научного анализа.
Ничто не заменяет эмпирические оценки.
Принцип 6. Эмпирические оценки стратегий тестирования. Оценивайте любую стратегию тестирования, однако, какой бы интересной она ни казалась, прибегайте к объективной оценке, используя точные критерии в воспроизводимом процессе тестирования.
Я радовался, как ребенок, читая в книге «Жизнь пчелы» (The Life of the Bee, Fasquelle, 1901) бельгийского драматурга Мориса Метерлинка о том, что происходит, если поместить несколько пчел и мух в бутылку и перевернуть ее донышком к источнику света. Как показано на рис. 1, пчелы, привлеченные светом, будут биться о стекло и умрут от голода и истощения. Мухи же, ничего не понимающие, испробуют все направления и вылетят из бутылки через пару минут. Метерлинк был поэтом, а не профессиональным биологом, и я не знаю, проводил ли он на самом деле этот эксперимент, но это прекрасная метафора для тех случаев, когда, очевидная глупость превосходит очевидный ум, как это часто происходит при тестировании.
Критерий оценки
При применении последнего принципа остается вопрос, какой же критерий использовать. Литература по тестированию предлагает такие показатели, как «число тестов, впервые вызвавших сбой программы». Для практиков данный показатель далеко не самый полезный. Мы хотим найти все ошибки, а не всего лишь одну.
Предположим, что использование критерия «первая неудача» будет корректным, и этот критерий применяется повторно. Но последующие неудачи могут иметь совсем иную природу; а автоматический процесс должен выявлять максимально возможное число ошибок, а не останавливаться на первой.
Число тестов тоже не очень полезно ни для менеджеров (которым нужно помочь принять решение о том, можно ли прекращать тестирование и выпускать продукт), ни для пользователей (которым нужно оценивать плотность ошибок). Более адекватным показателем является время тестирования, требуемое для обнаружения ошибок. С другой стороны, мы рискуем отдать предпочтение стратегиям, которые могут быстро обнаруживать ошибки, но только после длительного процесса продумывания теста, что увеличивает общее время. Вот почему (как и мухи, которые вылетают быстрее пчел) глупая, на первый взгляд, стратегия, такая как случайное тестирование, в целом может оказаться лучше.
Часто используются и другие показатели, в том числе различного рода степень охвата тестов (такие как степень охвата команд, ветвей или путей). Интуитивно они кажутся более полезными, но фактически нет убедительных подтверждений того, что более высокая степень охвата как-то влияет на качество. Фактически несколько последних исследований показали отрицательную корреляцию. Если модуль имеет более высокую степень охвата тестов, то, как правило, это происходит потому, что вы знаете, что с этим модулем связаны определенные сложности, и, действительно, зачастую он будет содержать больше ошибок.
Больше чем любой из этих показателей, имеет значение то, насколько быстро стратегия порождает неудачи, позволяющие выявлять ошибки.
Принцип 7. Критерий оценки. Самое важное свойство стратегии тестирования — это число обнаруженных ошибок как функция времени.
Функция обнаружения, то есть число ошибок в зависимости от времени fc (t), полезна по двум причинам — используя программную базу с известными ошибками, можно оценить стратегию, посмотрев, сколько ошибок база позволит обнаружить за данное время. Менеджеры проектов могут добавить fc (t) в модель надежности для оценки того, сколько еще ошибок осталось, и ответить на старый вопрос «Когда заканчивать тестирование?»
Семь главных принципов тестирования
Собрали 7 базовых принципов тестирования, которые должен знать каждый QA.
- 1. Все протестировать невозможно
- 2. Кластеризация дефектов
- 3. Парадокс пестицида
- 4. Тестирование показывает наличие дефектов
- 5. Отсутствие ошибок может быть обманчивым
- 6. Раннее тестирование
- 7. Тестирование зависит от контекста
Простое объяснение
Как определить, что вы применяете правильную стратегию тестирования? Нужно не отклоняться от базовых принципов тестирования.