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

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

Зачем проводить проверку ПО?

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

Проверка актуальности.

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

• Рынок уже перенасыщен подобными предложениями.

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

• ПО или приложение быстро потеряет актуальность в процессе разработки;

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

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

Обнаружение ошибок.

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

Повышение уровня надежности.

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

Оптимизация.

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

Возрастает уровень удовлетворенности пользователей.

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

Снижение уровня рисков и затрат.

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

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

• Проверка помогает обнаружить дефекты.

• Достичь исчерпывающего тестирования невозможно.

• Раннее своевременное тестирование.

• Группировка дефектов.

• Пестицидный парадокс.

• Полное отсутствие ошибок является мифом.

• Не существует универсальной стратегии тестирования, все зависит от контекста.

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

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

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

Проверка помогает обнаружить дефекты.

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

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

Достичь исчерпывающего тестирования невозможно.

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

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

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

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

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

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

Группировка дефектов.

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

Пестицидный парадокс.

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

В тестировании действует такой же принцип.

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

Полное отсутствие ошибок является мифом.

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

Не существует универсальной стратегии тестирования, все зависит от контекста.

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

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

Определить цели и задачи тестирования.

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

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

Описать объекты тестирования.

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

Среди элементов, которые должны пройти обязательную проверку, могут быть:

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

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

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

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

Выбрать методы тестирования.

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

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

Описать используемые ресурсы и инструменты.

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

Рассчитать и спланировать время работы.

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

Описание процедур контроля.

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