Заблуждение об отсутствии ошибок тестирование

Время прочтения
5 мин

Просмотры 14K

Нам известны 7 принципов тестирования и сейчас мы их подробно разберём.

Итак, приступим:

1. Исчерпывающее тестирование невозможно

2. Тестирование демонстрирует наличие дефектов, а не их отсутствие

3. Заблуждение об отсутствии ошибок

4. Раннее тестирование сохраняет время и деньги

5. Принцип скопления или кластеризация дефектов

6. Тестирование зависит от контекста

7. Парадокс пестицида 

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

В переводе с латинского При́нцип — это основа, начало, первоначало, и можно сказать, что принципы тестирования — это основы тестирования.

1️. Исчерпывающее тестирование невозможно

Давайте начнём так. Допустим, есть некий сайт. На этом сайте присутствует форма с полем для ввода какого-либо значения.

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

И, конечно, ответ будет: ∞

Ну давайте предположим, что максимально в поле мы можем ввести только 3 символа. Даже и в этом случае количество комбинаций, если брать во внимание, что UTF-8 поддерживает 2,164,864 доступных символа, будет равно:

Х = 2,164,864³ =10 145 929 857 329 004 544

Сколько же комбинаций выйдет, если в поле для ввода текста мы можем ввести 100 символов? А 1000 или с N количеством нулей?

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

2️. Тестирование демонстрирует наличие дефектов, а не их отсутствие

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

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

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

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

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

3️. Заблуждение об отсутствии ошибок

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

Надо помнить такую аксиому – не существует какого-либо продукта без багов или ошибок.

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

Дефекты однозначно будут. Но в тестировании и нет такой задачи, чтобы выявить 100% багов, т.к. мы уже знаем, что это невозможно, исходя из первых трёх принципов. Главное здесь – найти наиболее критичные ошибки.

Присутствует в тестировании и такой парадокс – не все ошибки нужно исправлять). Но это отдельная тема.

4. Раннее тестирование сохраняет время и деньги

Это принцип говорит о том, что чем раньше выявится та или иная проблема – тем меньше средств и трудозатрат потребуется для её устранения. Соответственно, если баг попадёт в «прод» или ещё хуже, если его найдёт пользователь – исправление такого дефекта обойдётся немалой кровью для всей команды. Помимо того, что удаление его будет стоить бо́льших денег, нежели на начальной стадии разработки, может получиться так, что этот дефект затронет другой функционал. И тогда проблемы начнут накапливаться как снежный ком. Сколько кода потребуется переписать разработчикам? Сколько времени уйдет на исправление и тестирование? Тут вам и сорванные сроки релизов, рассерженное руководство, потеря нервных клеток и т.д. Сюда же добавим недовольство или даже потерю клиентов, ну и все остальные вытекающие…

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

5. Принцип скопления или кластеризация дефектов

Существует такое определение – наибо́льшее количество дефектов обычно содержится в небольшо́м количестве модулей.

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

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

6. Тестирование зависит от контекста

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

По каким характеристикам различать контекст:

• по типу продукта – web, desktop, мобильное приложение, сервис и др.;

• по цели продукта – обеспечение безопасности, Game, продажа товаров и др.;

• по проектной команде – специализация, количество человек, опыт и т.д.;

• по доступным инструментам – что присутствует на проекте, для успешной реализации;

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

• по ожидаемому уровню качества – чем выше требования, тем тщательнее нужно тестировать.

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

7. Парадокс пестицида

Почему именно так назван этот принцип? Здесь всё просто. Википедия говорит нам, что Пестици́д (лат. pestis «зараза» + caedo «убивать») – ядовитое вещество, используемое для уничтожения вредителей и различных паразитов. Возьмём пример из жизни. Если использовать один и тот же пестицид на протяжении долгого времени, например, для истребления тараканов, то со временем его эффективность упадёт, так как у этих насекомых выработается устойчивость к одному и тому же препарату.

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

Поэтому тест-кейсы должны постоянно обновляться и видоизменяться. Важно пользоваться такими рекомендациями:

• добавлять новые тесты;

• просматривать и изменять существующие;

• применять разные виды и техники тестирования;

• осуществлять тестирование новыми сотрудниками и др.

 В целом посмотреть на продукт под другим углом.

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

Заключение

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

Вместо пролога

Эта статья была начата ещё в апреле текущего (2020) года. И с тех пор я её несколько раз переписывал. Я никак не мог достичь того результата, который бы меня устроил. Я не хотел писать очередную статью про 7 принципов тестирования, куда бы просто скопипастились переводы этих принципов из ISTQB, а потом (как в лучших из статей) сопровождались разъяснениями на тему «Что это всё означает». Получилось бы очередное переписывание «священного писания» с его толкованием. Однако, поистине священное писание в толковании не нуждается.

Моя статья будет не про то, что же это за 7 столпов тестирования. Я специально опущу некоторые детали при объяснении принципов. Легким движением руки по клавиатуре вы сможете нагуглить всё это сами. Мы поговорим сразу о боли.

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

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

Немного о себе, прежде чем начать (эту часть можно пропустить)

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

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

Собственно семь принципов тестирования

Тестирование демонстрирует наличие дефектов

О чём принцип:

Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие.

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

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

Исчерпывающее тестирование невозможно

О чём принцип:

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

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

Некоторые недобросовестные тестировщики используют этот принцип, чтобы оправдывать свою некомпетентность. Ушёл критичный баг в продакшн — «ну что поделать, нельзя предусмотреть всё на свете. Вы вообще знаете, что исчерпывающее тестирование невозможно?». Но они забывают о том, что хотя предусмотреть всё невозможно, это не повод не предусматривать ничего.

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

Раннее тестирование экономит время и деньги

О чём принцип:

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

Это избитая истина, примерно такого же плана, как и «ПО надо тестировать, т.к. писать код без ошибок физически невозможно». Но многим руководителям кажется, что на самом деле тестирование отнимает время релизного цикла, т.к. задерживает доставку фич, а так же тратит время тестировщиков, на то, чтобы они читали «бумажки» вместо того, чтоб тестировать.

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

Кластеризация (или скопление) дефектов

О чём принцип:

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

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

Крайний случай (но справедливости ради замечу, что это не самый распространенный случай) — это «тест до первого бага». Причин тому может быть несколько: ленивый или некомпетентный тестировщик, или же метрики/kpi, которые поджимают тестировщика быстрее перекинуть мяч на сторону разработчиков.

Просто помните, если вы уже нашли несколько багов в каком-то модуле, стоит перелопатить его ещё тщательнее, скорее всего там есть ещё скрытые дефекты.

В то же время, отсутствие дефектов в других модулях не говорит, что дефектов там нет (помните первый принцип?)

Парадокс (эффект) пестицида

О чём принцип:

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

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

Тестирование зависит от контекста

О чём принцип:

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

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

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

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

Заблуждение об отсутствии ошибок

О чём принцип:

Тот факт, что тестирование не обнаружило дефектов, ещё не значит, что программа хорошая.

Ну вот снова! Хочется сорвать с себя шапку-ушанку и крикнуть: «Ай, да катись оно всё пропадом», раз никаких гарантий нет, то нафига вообще тестировать!? Ответ прост: чтобы снизить риски. Протестированный продукт с вероятностью 95% bug free, но не протестированный продукт с вероятностью 95% уйдет в продакшн с багами.

С учетом того, как этот принцип доносят на просторах интернета, легко спутать его с первым принципом. Многие забывают, что суть принципа: отсутствие дефектов — необходимое, но не достаточное условие хорошего ПО. Есть и другие факторы, влияющие на качество продукта. И вот о них-то как раз все забывают, считая, что лишь тестировщики и тестирование ответственны за качество.

Эпилог

Не могу сказать, что я всю свою сознательную QA жизнь только и вижу, как принципы тестирования нарушаются. Нет, ни в коем случае. Я просто подобрал для каждого принципа распространенные случаи игнорирования или иной трактовки. В том или ином виде, объёме, сознательно или нет, но часть принципов соблюдается почти всеми командами, в которых присутствует процесс тестирования ПО. Мне лишь хотелось подсветить некоторые моменты/признаки, по которым чуть легче пустить факт нарушения принципов в своё сознание.

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

Бонус

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

Но вот их я как раз разберу отдельным постом в своём телеграм-канале, так что если кому интересно — присоединяйтесь к @aboutqa

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

1. Исчерпывающее тестирование невозможно

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

Если непонятно, то давайте объясню.

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

Для того чтобы протестировать и перебрать все-все значения и комбинации нам потребуется 27 тестов (3 в 3-ей степени).
Ну, звучит пока реально. А что будет если мы расширим наше меню напитками и салатами тоже по 3 варианта?
Количество тестов превратится в 125 (5 в 3-ей степени). А что если добавить больше вариантов блюд? А что если выбор блюд из какой-то категории сделать необязательным? Количество тестов начнём расти в геометрической прогрессии.

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

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

Мне страшно представить тестировщика, который перебрал все возможные варианты на этой форме и ему сказали сделать это ещё раз 🙂

Поэтому в тестировании мы используем анализ рисков и приоритетов, для того чтобы проверить наиболее показательные варианты значений. Для этого существуют техники тестирования (Test techniques), либо их ещё называют техники тест-дизайна (Test design techniques). О них поговори как-нибудь в другой раз.

2. Принцип скопления дефектов

Этот принцип говорит о том, что в наименьшем количестве мест, находится наибольшее количество дефектов. Это чем-то похоже на правило Парето 80/20, где 80% дефектов находятся в 20% функций.

Почему дефекты любят скапливаться в одном месте?
Очень часто какая-то область кода может быть сложной или плохо написанной. Поэтому в ней и может скапливаться бесчисленное количество дефектов.

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

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

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

3. Эффективность раннего тестирования

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

Ниже мы можем увидеть как меняется цена дефекта в зависимости от фазы на которой он был найден.

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

Да, в этом подходе тестирование будет стоить немного дороже, чем если бы мы совсем не тестировали требования.
Но как говорится «Скупой платит дважды».

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

4. Парадокс пестицида

Если одни и те же тесты проходить снова и снова, то рано или поздно они перестанут находить дефекты.

То есть наш продукт со временем адаптируется к нашим тестам.

Но это не будет означать, что в нем не будет дефектов.

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

• Использовать разные данные при тестировании
• Постоянно пересматривать и улучшать свои тесты
• Добавлять новые тесты
• Использовать разные техники тестирования
• Проводить ротацию кадров

Неформальные техники тестирования основанные на опыте (например, исследовательское (Exploratory testing) и свободное тестирование (Ad-hoc)) очень хорошо помогают бороться с парадоксом пестицида.

5. Заблуждение об отсутствии ошибок

Сколько бы мы не находили ошибок, это не даст нам гарантию того, что мы нашли их все или что продукт будет качественным.

Продуктов без багов (Bug free) не существует!

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

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

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

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

6. Тестирование показывает наличие дефектов

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

Ведь они есть всегда 🙂 см. принцип 5.

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

Не существует единственного верного способа тестировать программное обеспечение. Вряд ли систему контроля жизнеобеспечения мы будем тестировать как интернет-магазин. Даже 2 очень похожих интернет-магазина могут тестироваться совсем по-разному.

Ведь контекст может быть разный.

Что может входить в контекст тестирования:

• Тип продукта — веб, десктоп, мобайл, сервис и тд
• Цель продукта — продажа товаров, игра, обеспечение безопасности
• Проектная команда — количество человек, специализация, опыт и тд
• Сроки — как много времени у нас есть до релиза
• Ожидаемый уровень качества — чем выше показатель, тем тщательнее нужно тестировать
• Риски — существует огромное число рисков, которые нужно учитывать. Например, из-за того, что команда неопытная в разработке продукта с заявленными целями и типом, есть риск, что в продукте может быть много багов. Тем самым, достижение ожидаемого уровня качества может затянуться.
• Доступные инструменты — есть ли у нас возможность пользоваться какими-то инструментами для тестирования или необходимо изобретать самим.
• И другие моменты

Исходя из данных нашего контекста, мы и будем строить эффективный процесс тестирования.

Существует 7 принципов тестирования:

1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
2. Исчерпывающее тестирование недостижимо
3. Раннее тестирование сохраняет время и деньги
4. Кластеризация дефектов
5. Парадокс пестицида
6. Тестирование зависит от контекста
7. Заблуждение об отсутствии ошибок

Именно принципы тестирования являются основой всех стандартов, книг, методов и техник тестирования.

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

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

Начнем с определения понятия “принцип”.

Принцип или основа, начало, первоначало (лат. principium, греч. αρχή, дословно первейшее) — постулат, утверждение, на основе которого создают научные теории и законы, юридические документы, выбирают нормы поведения в обществе.

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

Принципы тестирования — это основы тестирования

Их нельзя изменить, отменить, понимать “частично” или поверхностно.

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

Давайте разбираться! 🧐

1️⃣ Тестирование демонстрирует наличие дефектов, а не их отсутствие

Дефекты найдены!

Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет.

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

Для лучшего понимания, разобьем первый принцип на 2 части:

1. Тестирование может показать, что дефекты присутствуют
2. Тестирование не может доказать, что дефектов нет

и посмотрим на каждую из них в отдельности.

Тестирование может показать, что дефекты присутствуют

Предположим, у нас есть сайт, который нужно проверить перед передачей заказчику.

Мы проводим тестирование и находим 20 багов.

В этом случае тестирование показало, что в изначальном варианте сайта было 20 дефектов.

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

Повторное тестирования показало, что мы исправили 20 багов и не нашли новых.

Это факт — мы нашли и исправили 20 дефектов в ПО.

Тестирование не может доказать, что дефектов нет

Предположим, что принцип не правильный.

Q: Тестирование МОЖЕТ доказать, что дефектов нет — что для этого необходимо?
A: Как минимум, знать все “места”, где находятся все дефекты, чтоб тестировщик смог их проверить после исправления ошибки.

Q: А можем ли мы каким-то образом узнать о всех “местах”?
A: Короткий ответ — нет!

Для нахождения всех дефектов нужно будет проделать очень большой объем работы:

• проверить каждую строку кода сайта на наличие ошибок (включая ВСЕ сторонние библиотеки)
• проверить сайт на ВСЕХ возможных версиях ВСЕХ возможных браузеров
• проверить сайт на всех возможных устройствах, системах, размерах экранов с шагом 1px
• проверить работу сайта во всех странах мира
• …
• …
• … (думаю, список можно продолжать практически до бесконечности)

И знаете что самое интересное?

Для ДОКАЗАТЕЛЬСТВА, что дефектов нет — эту проверку нужно будет делать КАЖДЫЙ раз после ЛЮБОЙ правки, внесенной в сайт, после ЛЮБОГО обновления ЛЮБОГО браузера, после выхода на рынок ЛЮБОГО телефона, часов, нового экрана и т.д. и т.п.

А учитывая количество и скорость изменений “систем”, окружающих сайт — нужно будет проводить десятки тысяч сложнейших тестов ежедневно, чтоб доказать, что дефектов нет, и надеяться, что вы учли все…

Именно из-за ОГРОМНОЙ сложности и ОБЪЕМА всей системы, в которой создается и работает сайт, мы не можем узнать ОБЩЕЕ КОЛИЧЕСТВО дефектов.

А не зная общего количества дефектов — мы никогда не докажем, что их нет.

2️⃣ Исчерпывающее тестирование недостижимо

Рост количества тестов в процессе анализа задачи

Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо (за исключением тривиальных случаев).

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

Предположим, у нас есть сайт.
На сайте есть форма, в которой есть поле для ввода возраста.

Q: Какое общее количество комбинаций вводов существует для этого поля?
A: ∞

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

Если предположить, что максимальная длина строки для этого поля должна быть 3 символа (вряд-ли кто-то живет больше 999 лет), то максимальное количество всех возможных комбинаций (учитывая, что UTF-8 поддерживает 2,164,864 доступных символов) будет равно:

Х = 2,164,864³ =10 145 929 857 329 004 544

Можете представить, сколько комбинаций будет у поля для ввода текста с ограничением по длине в 10,000 символов 😅

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

3️⃣ Раннее тестирование сохраняет время и деньги

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

Тестирование на ранних этапах жизненного цикла разработки программного обеспечения помогает сократить или исключить дорогостоящие изменения.

Для простоты примера можно рассмотреть процесс исправления дефекта, найденного в требованиях к ПО и дефекта, найденного клиентом.

Дефект, найденный в требованиях к ПО — исправляется очень быстро.

Например, кнопка “Оплатить” в требованиях называется “Sell” , а должна называться “Pay”. Это дефект. Исправление — замена текста “Sell” на “Pay”, занимает 2 секунды и стоит $0,05.

Теперь посчитаем стоимость исправления этого же дефекта, найденного клиентом.

Тут — сложнее.

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

Пусть это занимает 30 минут времени команды, которая стоит $100 / час (правка в дизайне, в коде, тестирование, создание релиза, заливка…) Итого — $50.

Дальше, мы оцениваем “ущерб” от потерь репутации.

• Сколько клиентов отказались покупать товар из-за недопонимания текста на кнопке?
• Сколько клиентов подумало, что “если наш сервис не может нормально называть кнопки, как он может качественно делать продаваемый товар?” и ушло с формы заказа.
• …

Грубо предположим, и будем сильно надеяться, это еще $50 😔

Таким образом, стоимость исправления ошибки, найденной клиентом — $100. Это в 2000 ❗️ раз больше, чем исправление ошибки в требованиях.

Если очень приблизительно, то стоимость исправления ошибки в зависимости от этапа разработки следующая:

1. Требования — х1
2. Дизайн — х5
3. Разработка — х15
4. Тестирование — х25
5. Production — x100+

4️⃣ Кластеризация дефектов

Баги живут здесь

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

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

Код пишут люди. Люди ошибаются. Одни — ошибаются чаще, чем другие и это не исправить.

То же самое применимо и к системам. Одни — проще, другие — сложнее. Чем сложнее система— тем больше вероятность возникновения ошибки и так будет всегда.

Добавим сюда дедлайны. Чем ближе к дедлайну — тем больше нагрузка. Чем больше нагрузка — тем меньше времени разработчик уделяет “красоте” кода и перепроверке самого себя. Отсюда тоже берутся ошибки.

Все эти факторы приводят к одним и тем же последствиям — дефекты “собираются” в “кучки” в определенных частях системы.

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

Он знает, что за Васей нужно проверять по 2 раза, а Саша — все делает хорошо, в большинстве случаев.

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

5️⃣ Парадокс пестицида

Automation Test Run #428421 — ALL PASSED!

Если одни и те же тесты будут выполняться снова и снова, в конечном счете они перестанут находить новые дефекты.

Для обнаружения новых дефектов может потребоваться изменение существующих тестов / тестовых данных или написание новых.

Предположим, у нас есть набор тестов, которые проверяют некий функционал, в котором есть 3 дефекта.

Пройдя тесты, мы находим 2 дефекта и исправляем их, а один дефект останется “незамеченным”.

Проходя одни и те же тесты снова и снова — мы всегда будем видеть одну и ту же картину: PASS / Пройдено.

Но, по факту, один дефект будет оставаться в системе и текущие тесты НИКАК не смогут его найти.

Для определения дефекта придется:

• либо изменять существующие тесты
• либо изменять тестовые данные, которые “покажут” ошибку

Чаще всего парадокс пестицида проявляется в автоматизированном тестировании изменений (регрессионном тестировании).

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

Именно поэтому ручное тестирование НИКОГДА не исчезнет 🥳😎

6️⃣ Тестирование зависит от контекста

Тестирование выполняется по-разному в зависимости от контекста.

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

Предположим, нам нужно проверить простой сайт, который состоит из 5 страниц.

Вы пишете некий простой чек-лист (функционала нет, тест-кейсы не нужны, не тратим время) и проверяете сайт.

Все супер, залили, ничего критического нет, вы молодец! 🥳🥳🥳

Дальше, вам отдают на проверку другой сайт.

Но в этот раз не из 5, а из 45,000 страниц, с сложным функционалом, админками и т.д. и т.п.

1. Как вы думаете, сможете ли вы проверить этот сайт по уже готовому чек-листу?
2. Как на счет “нагуглить” какой-то чек-лист в интернете — и проверить сайт по нему?

Надеюсь, что вы ответили — нет на оба вопроса! 😍

Тестирование всегда зависит от контекста!

• Для сайта из 5 страниц — подход один
• Для сайта из 45,000 — другой
• Для онлайн-магазина — третий
• Для посадочной страницы — четвертый
• Для мобильного приложения todo-list— пятый
• Для мобильного приложения банка — шестой
• …

Поэтому, перед тем как начинать что-то проверять, нужно сделать анализ и продумать стратегию и план тестирования.

И только после этого приступать к написанию тестовой документации и тестированию!

7️⃣ Заблуждение об отсутствии ошибок

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

Кроме того, ошибочно ожидать, что простое нахождение и исправление большого числа дефектов обеспечит успех системе.

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

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

Важно не отсутствие ошибок, а критичность, скорость реакции и исправления!

Более того, не все ошибки нужно исправлять!

Если ошибка встречается на окружении, которым пользуется 0,002% ваших пользователей, которые приносят $5 прибыли в год и на ее исправление нужно будет потратить $50,000 и пол года разработки — вы будете ее исправлять? Сильно сомневаюсь 😏

Резюме

В статье мы подробно рассмотрели 7 принципов тестирования:

1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
2. Исчерпывающее тестирование недостижимо
3. Раннее тестирование сохраняет время и деньги
4. Кластеризация дефектов
5. Парадокс пестицида
6. Тестирование зависит от контекста
7. Заблуждение об отсутствии ошибок

Попробуйте пройти тест и узнайте, насколько хорошо вы разобрались.

Желаю удачи в ваших проектах и начинаниях!

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

1. Тестирование показывает наличие дефектов

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

2. Исчерпывающее тестирование невозможно

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

3. Раннее тестирование

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

4. Скопление дефектов

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

5. Парадокс пестицида

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

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

6. Тестирование зависит от контекста

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

7. Заблуждение об отсутствии ошибок.

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

И еще несколько важных принципов:

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

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

Нажмите здесь, если видео не доступно

Фон

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

Чтобы понять это, рассмотрим сценарий, в котором вы перемещаете файл из папки A в папку B.

Подумайте обо всех возможных способах проверить это.

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

• Попытка переместить файл, когда он открыт
• У вас нет прав безопасности для вставки файла в папку B
• Папка B находится на общем диске, и объем памяти заполнен.
• В папке B уже есть файл с таким же именем, фактически список бесконечен
• Или предположим, что у вас есть 15 полей ввода для проверки, каждое из которых имеет 5 возможных значений, количество проверяемых комбинаций будет 5 ^ 15

Если бы вы протестировали все возможные комбинации, проект EXECUTION TIME & COSTS увеличился бы в геометрической прогрессии. Нам нужны определенные принципы и стратегии для оптимизации усилий по тестированию

Вот 7 принципов:

1) исчерпывающее тестирование невозможно

Да! Исчерпывающее тестирование невозможно. Вместо этого нам необходим оптимальный объем тестирования на основе оценки риска приложения.

И вопрос на миллион долларов, как вы определяете этот риск?

Чтобы ответить на это, давайте сделаем упражнение

По вашему мнению, какая операция наиболее вероятно приведет к сбою вашей операционной системы?

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