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

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

Количество просмотров 28K

Нам известны 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 от новичка. Однозначно, знание этих основ тестирования помогает формировать грамотную стратегию тестирования, совершать в итоге меньше ошибок в процессе работы с продуктом, сокращать время и упрощать некоторые процессы проводимых проверок.

Принцип 6. Тестирование зависит от контекста
Тестирование выполняется по-разному, в зависимости от контекста. Например, тестирование систем, критических с точки зрения безопасности, проводится иначе, чем тестирование сайта интернет-магазина.
Этот принцип тесно связан с понятием риска. Что такое риск? Риск — это потенциальная проблема. У риска есть вероятность (likelihood) — она всегда выше 0 и ниже 100% — и есть влияние (impact) — те негативные последствия, которых мы опасаемся. Анализируя риски, мы всегда взвешиваем эти два аспекта: вероятность и влияние.
То же можно сказать и о мире ПО: разные системы связаны с различными уровнями риска, влияние того или иного дефекта также сильно варьируется. Одни проблемы довольно тривиальны, другие могут дорого обойтись и привести к большим потерям денег, времени, деловой репутации, а в некоторых случаях даже привести к травмам и смерти.
Уровень риска влияет на выбор методологий, техник и типов тестирования.
Принцип 7. Заблуждение об отсутствии ошибок
Нахождение и исправление дефектов бесполезно, если построенная система неудобна для использования и не соответствует нуждам и ожиданиям пользователей.
Заказчики ПО — люди и организации, которые покупают и используют его, чтобы выполнять свои повседневные задачи — на самом деле совершенно не интересуются дефектами и их количеством, кроме тех случаев, когда они непосредственно сталкиваются с нестабильностью продукта. Им также неинтересно, насколько ПО соответствует формальным требованиям, которые были задокументированы. Пользователи ПО более заинтересованы в том, чтобы оно помогало им эффективно выполнять задачи. ПО должно отвечать их потребностям, и именно с этой точки зрения они его оценивают.
Даже если вы выполнили все тесты и ошибок не обнаружили, это еще не гарантия того, что ПО будет соответствовать нуждам и ожиданиям пользователей.
Иначе говоря, верификация не равна валидации.

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 принципов тестирования в деле

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Бизнес-требования
• Требования к безопасности
• Требования к производительности
• Целевая аудитория
• Технические ограничения

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

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

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

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

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

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

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

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

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

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

Существует 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. Заблуждение об отсутствии ошибок

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

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