Что такое раннее тестирование

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

Раннее тестирование: проблемы и решения

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

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

Три проблемы раннего тестирования

Проблематика тестирования гипотез лежит в трех сферах:

Предвзятость правильности собственных идей

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

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

какие потребности и проблемы не закрыты?

какое ценностное предложение может дать компания клиентам в этом случае?

Формировать ТЗ, а уж тем более, начинать разработку сайта будет намного разумнее именно после такой простейшей аналитики. Дальше — сложнее. Нужно найти пересечение ценностей аудитории с вашим предложением и снять барьеры на пути к покупке.

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

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

Психологические аспекты

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

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

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

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

Что и когда тестировать? Насколько сильно нужно дробить функционал для этого тестирования? Включать ли в него незначительные изменения или нет?

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

Новые идеи и рефлексия

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

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

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

Источник

7 принципов тестирования. Часть 2

В статье использованы материалы книги «Foundations of Software Testing: ISTQB Certification» by Dorothy Graham, Erik van Veenendaal, Isabel Evans & Rex Black.

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

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

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

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

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

Вот почему важно начинать тестирование как можно раньше, со статических техник.

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

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

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

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

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

Также полезно проводить анализ первопричин (root cause analysis), чтобы предотвратить повторное появление дефектов, обнаружить причины возникновения скоплений дефектов и спрогнозировать потенциальные скопления дефектов в будущем.

Источник

Обзор частых вопросов по тестированию ПО на собеседованиях и ответы на них

Главная цель данной статьи – помочь преодолеть страх, который возникает у тестировщиков ПО (как начинающих, так и опытных) к предстоящему интервью в связи с незнанием грядущего.

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

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

Собственно вопросы:

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

Обеспечение качества определено в стандарте ISO 9000:2005 «Системы менеджмента качества. Основные положения и словарь» как «часть менеджмента качества, направленная на создание уверенности в том, что требования к качеству будут выполнены».

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

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

Из этого определения становится понятно, что тестирование ПО включает в себя два различных процесса:
Валидация (validation): доказанное объективными результатами исследования подтверждение того, что требования для конкретного определенного использования приложения были выполнены. [ISO 9000]
Верификация (verification): доказанное объективными результатами исследования подтверждение того, что определенные требования были выполнены. [ISO 9000]

Цель тестирования (test objective, test target) — это причина или цель разработки и выполнения теста.

Следует также понимать что такое big-bang тестирование, тестирование «сверху вниз», восходящие и инкрементное тестирование;

Критерии входа (entry criteria) — это набор общих и специфичных условий для продолжения процесса с определенной задачей, например, фаза тестирования. Цель критериев входа — предотвращение начала задачи, которое может потребовать больше (бесполезных) усилий, чем на устранение не пройденных критериев входа.

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

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

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

Реальный вопрос, на который мы ищем ответ: строим ли мы продукт правильно?

Процесс верификации (verification) выполняется, чтобы убедиться, что каждый этап жизненного цикла разработки ПО (разработка, тестирование и т.д.) строится на основе предопределенных требований (requirements) и спецификаций (specifications) и без каких-либо отклонений от них. (см. № 7)

Реальный вопрос, на который мы ищем ответ: строим ли мы правильный продукт?

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

Помните, валидация охватывает динамическую сторону тестирования, где определенное ПО тестируется и оценивается вопреки заданной SRS документации.

Отладка (debugging) — это процесс поиска, анализа, и устранения причин отказов и ошибок в ПО.

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

Симуляция — это воспроизведение работы программы-оригинала сугубо виртуально, на движке специальной программы (средство разработки курсов, к примеру). Симуляция лишь имитирует выполнение кода, а не копирует его, всё виртуально на 100%, всё «понарошку».

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

Симулятор ПО — это модель оригинального ПО, в которой реализуется логика работы этого ПО (частично или полностью), имитируется поведение ПО, копируется его интерфейс.

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

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

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

Кодирование (coding) — это процесс написания программного кода, скриптов, с целью реализации определённого алгоритма на определённом языке программирования.

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

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

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

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

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

Критичность (severity) — это важность воздействия конкретного дефекта на разработку или функционирование компонента или системы.

Приоритет (priority) — это степень важности, присваиваемая багу. Другими словами определяется, насколько срочно это ошибка должна быть исправлена.

Сборка (build) — подготовленный для использования информационный продукт. Чаще всего это исполняемый файл (двоичный файл, содержащий исполняемый код программы).

Драйвер (driver) — это компонент ПО или средство тестирования, которое заменяет компонент, обеспечивающий управление и/или вызов компонента или системы.

Обвязка (harness) — это тестовое окружение, включающее в себя заглушки и драйверы, необходимые для проведения теста.

Для измерения покрытия требований, необходимо проанализировать требования к продукту и разбить их на пункты. Опционально каждый пункт связывается с тест кейсами, проверяющими его. Совокупность этих связей — и является матрицей трассировки (traceability matrix). Проследив связи, можно понять какие именно требования проверяет тестовый случай.

Тесты не связанные с требованиями не имеют смысла. Требования, не связанные с тестами — это «белые пятна», т.е. выполнив все созданные тест кейсы, нельзя дать ответ реализовано данное требование в продукте или нет.

End-to-end тестирование — это тип тестирования где тестировщик использует ПО (сценарии, которые исследуют весь поток выполнения) в условиях которыми вероятней всего обладает пользователь.

Функциональное тестирование (functional testing) — это тестирование, основанное на анализе спецификации функциональности компонента или системы.

Функциональные тесты базируются на функциях и особенностях, а также взаимодействии с другими системами, и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing) иприемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы.

Белый ящик — это тестирование кода на предмет логики работы программы и корректности её работы с точки зрения компилятора того языка, на котором она писалась.

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

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

Спасибо за внимание и удачи в ваших начинаниях!

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

Призываю к активному и обоснованному холивару!

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник