Что такое исчерпывающее тестирование

Тестирование. Ошибки при сертификации или ISTQB мне очень нужен

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

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

Мне бы хотелось написать о ISTQB, т.н. International Software Testing Qualifications Board. Это признанная во всём мире сертификация для тестировщика. Если ты такое получил, то по идее владеешь базовыми знаниями и теорией, то есть и плюсик тебе на собеседованиях добыть можешь, и в общем самоутверждаешься.

В статье я бы поговорила об ошибках. О глупых и не очень. О тех, которые я лично совершила в таком тесте или могла. И не хотела бы, чтобы кто-то тоже так попался.

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

Хотелось бы для начала, чтобы запомнили следующее, “исчерпывающее тестирование невозможно, независимо от того, сколько усилий затрачено на тестирование (т.н. Принцип # 2)”. Этот принцип запомнить придется. Много ссылок на материалы для подготовки кидать не буду, одну приведу в конце статьи. Пункт, в котором засомневалась я, был “При достаточных усилиях и инструментальной поддержке исчерпывающее тестирование возможно для любого программного обеспечения». Первые мысли были о том, что терпение и труд всё перетрут. Это верно только для тривиальных ситуаций, в любой реальной системе предусмотреть все ситуации не сможем, остается только свести к минимуму количество проблем.

Стадии и задачи

Информация для запоминания. Основной процесс тестирования можно поделить на этапы, направления деятельности:

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

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

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

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

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

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

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

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

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

Тестирование в период сопровождения

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

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

Системное и компонентное тестирование

Главное помнить, что компонентное тестирование обычно является ответственностью разработчиков, в то время как системное тестирование — типичная ответственность тестировщиков.

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

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

Формальное рецензирование и его шаги

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

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

Заключение

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

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

Источник

Принципы тестирования — применение, искажения и иллюзии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Русские Блоги

Все, что вам нужно знать о тщательном тестировании

Что такое исчерпывающий тест?

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

Исчерпывающая стратегия тестирования

Мы знаем,Тестирование программного обеспеченияизОдин из 7 принципов тестированияУказывает, что детальное тестирование невозможно. Теперь возникает вопрос: поскольку исчерпывающее тестирование невозможно, как нам получить достаточное покрытие, чтобы определить, не имеет ли тестируемое приложение дефектов?

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

Почему исчерпывающее тестирование нецелесообразно и невозможно

Невозможно выполнить полный или исчерпывающий тест. Для большинства систем это практически невозможно по следующим причинам:

Подробные примеры испытаний

Пример 1:

вИнструменты IE> Дополнительные параметрыокно:

53 Двоичные условия

1 условие имеет 3 варианта

4 варианта на 1 условие

2 ^ 53 = 9,007,199,254,740,992 x 12 = 108,086,391,056,891,904 возможных комбинаций условий

Каждый тест выполняется за одну секунду:

108 086 391 056 891 904/360 = 300 239 975 158 033,067 часов (12 509 998 964 918,04 дня или 34 273 969 766,9 года) для проверки всех возможных комбинаций.

Пример 2:

Давайте посмотрим на сайт электронной коммерции со следующими функциями:

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

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

Давайте создадим матрицу для приведенного выше примера:

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

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

Согласно вышеописанному методу, области с оценкой выше 25 следует рассматривать как области с чрезвычайно высоким риском, и требуется почти тщательное тестирование. Следовательно, в приведенном выше примере «добавить в корзину» следует провести всестороннее тестирование для всех типов тестов, и следует провести детальное тестирование.

Источник

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

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

Для чего проводится тестирование ПО?

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

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

К задачам обеспечения качества относятся:

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

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:

Этапы тестирования:

Программный продукт проходит следующие стадии:

Требования

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

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

Градация Приоритета дефекта (Priority):

Тестовые среды

Основные фазы тестирования

Основные виды тестирования ПО

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

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

Методы тестирования

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

Согласно ISTQB, тестирование белого ящика — это:

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

Согласно ISTQB, тестирование черного ящика — это:

Тестовая документация

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

Тест план должен отвечать на следующие вопросы:

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

Источник