Тестирование в массы. Часть I

1. Тестирование является непрерывным процессом, являющимся частью всех этапов жизненного цикла разработки продукта: от планирования работ до поддержки и мониторинга внедренной системы. 
2. Тестирование может быть динамическим и статическим. Динамическое тестирование подразумевает запуск кода и проверку его работоспособности, статическое же – проверку и анализ кода (без его выполнения), спецификаций, документации и т.д.
3. Процесс тестирования включает в себя планирование и подготовку, проверку и оценку тестируемого компонента или системы, а также анализ результатов.
4. Тестирование помогает убедиться, что система или ее компонент работает именно так, как ожидается, и выполняет все необходимые функции. Иными словами, продукт должен пройти верификацию.
5. Тестирование помогает проверить, что программа может эффективно использоваться в реальных условиях и соответствует потребностям пользователя. Иначе говоря, продукт должен пройти валидацию.
6. Тестирование направлено на выявление дефектов и недостатков разработанного продукта.

Мы в Акелоне любим всё, что связано с качеством. С особенной любовью создаём и масштабируем системы для комплексной цифровизации фармацевтической системы качества. Поэтому вот на этом утверждении ISTQB хотим сделать акцент: тестирование является основным видом контроля качества (QC), который, в свою очередь, является частью обеспечения качества (QA).

 

Контроль качества (QC) — это корректирующий подход, ориентированный на продукт, который сосредотачивается на действиях, поддерживающих достижение надлежащего уровня качества.

Обеспечение качества (QA) — это превентивный подход, ориентированный на процесс, который сосредотачивается на внедрении и улучшении процессов.

В контроле качества (QC) результаты тестов используются для исправления дефектов, а в рамках обеспечения качества (QA) они обеспечивают обратную связь – насколько хорошо выполняются процессы разработки и тестирования.

Ниже мы обязательно познакомим вас с международным стандартом целей, но говоря человеческим языком, представьте, что большая команда из РП, аналитиков, разработчиков создала продукт, выкатила на прод, а пользователь выявляет баг, - причем он может вообще не иметь отношения к разработке, а, например, касаться соответствия юридическим требованиям (знакомо тем, кто работает с госкомпаниями). Как следствие: баг напрягает команду и часто портит репутацию продукта и компании. Цель – минимизировать ошибки. Проще подключить тестировщика, который заранее их выявит. А вот так звучат типичные, но далеко не исчерпывающие цели его работы на языке международных стандартов ISTQB:

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

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

5. Проверка выполнения зафиксированных требований.  А именно, проверка того, что разработанное ПО соответствует зафиксированным в документации функциональным и нефункциональным требования, которые были определены на этапе проектирования и согласованы с заказчиком.
6. Проверка соответствия контрактным, юридическим и нормативным требованиям. В некоторых отраслях существуют строгие нормативные и юридические требования, которым должно соответствовать используемое ПО. Тестирование помогает удостовериться, что продукт соответствует этим требованиям, что особенно важно в таких областях, как финансы или здравоохранение.
7. Предоставление информации о результатах тестирования заинтересованным сторонам для принятия обоснованных решений относительно дальнейшего развития продукта, внесения в него изменений.
8. Создание уверенности в качестве объекта тестирования. То есть в том, что продукт соответствует ожиданиям по качеству, надежности и производительности. Это аспект, важный для всех заинтересованных сторон, включая разработчиков, менеджеров и пользователей.
9. Проверка завершенности объекта тестирования и его соответствия ожиданиям заинтересованных сторон. Проверка того, что все запланированные функции реализованы и работают правильно, а также что продукт готов к передаче конечным пользователям.

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

• тип тестируемого рабочего продукта (например, мобильное приложение или веб-клиент);
• уровень тестирования (например, модульное, интеграционное, системное или приемочное тестирование);
• степень риска, связанного с продуктом (например, критические системы требуют более тщательного тестирования);
• жизненный цикл разработки программного обеспечения (SDLC), используемый командой (например, Agile или Waterfall);
• факторы бизнес-контекста, такие как корпоративная структура или конкуренция на рынке.

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

Принципы тестирования или подсудимый всегда НЕ прав

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Классификация тестирования

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

По уровню тестирования

Уровни тестирования – это группы активностей тестирования, которые организованы и управляются как единое целое. Запомнить их проще всего аббревиатурно - ПСИК .

 

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

Уровни тестирования обычно визуализируются в виде пирамиды, в которой виды тестирования расположены снизу вверх: от более мелких частей системы к самым объемным.

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

Интеграционное тестирование включает в себя два подвида: интеграционное компонентное тестирование и системное интеграционное тестирование.

 

Компонентное интеграционное тестирование (тестирование интеграции модулей) – проверка интерфейсов и взаимодействия между компонентами одной системы. 

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

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

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

По целям тестирования

• Функциональное – оценивает функции, которые компонент или система должны выполнять. Основная цель этого вида тестирования – проверить функциональную полноту продукта, его соответствие требованиям. Отвечает на вопрос «Что делает система?»
• Нефункциональное – оценивает признаки компонента или системы, отличные от функциональных характеристик. Цель – проверить, как и насколько хорошо работает система. В рамках этого вида тестирования могут оценивать, например, следующие характеристики: производительность, совместимость, удобство пользования, надежность, безопасность и т.д.

По знанию кода

• Белый ящик – тестирование, основанное на анализе внутренней структуры компонента или системы. Метод подразумевает полный доступ к тестируемой программе, ее структуре и реализации.
• Черный ящик – тестирование, основанное на анализе спецификации компонента или системы. Такой метод не предполагает доступа к коду и опирается только на внешний интерфейс тестируемой системы.
• Серый ящик – тестирование, предполагающее частичный доступ к коду (комбинация белого и черного ящиков).

Планирование тестирования

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

Обычно содержание плана тестирования включает:

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

Критерии входа и выхода

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

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

Критерии выхода определяют, что должно быть достигнуто для того, чтобы объявить запланированные работы завершенными, и состоят из:

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

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

Определение приоритетов тестовых сценариев

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

Наиболее часто используемые следующие стратегии определения приоритетов тестовых сценариев:

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

Что такое дефект?

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

Роман Савин в своей книге «Тестирование дот ком, или пособие по жесткому обращению с багами в интернет стартапах» отметил: «Дефект — это отклонение фактического результата от ожидаемого результата».

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

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

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

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

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

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

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

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

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

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

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

Все эти явления объединяет то, что они являются аномалиями – отклонениями от ожидаемого поведения системы.

_______________________________________________________

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

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

В следующих статьях цикла аналитики и тестировщики Акелона расскажут о техниках тест-дизайна и тестовой документации.

Материал для вас подготовила

Полина Пахомова, консультант "Акелона".

 

 

 

 

---