Купив грушу, можно сразу оценить ее качество: размер и форму, спелость, отсутствие видимых помятостей. Но только когда вы откусите первый кусочек, вы сможете увидеть, действительно ли груша так хороша. Даже очень красивая груша может иметь кислый вкус или червячка.
То же самое относится практически к любому продукту, будь то физический объект или часть программного обеспечения. Веб-сайт, который вы найдете в Интернете, поначалу может показаться хорошим, но когда вы прокручиваете страницу вниз, переходите на другую страницу или пытаетесь отправить запрос на контакт, он может начать показывать некоторые недостатки и ошибки дизайна.
Это делает контроль качества столь важным в каждой области, где создается продукт для конечного пользователя. Тем не менее, кислая груша не нанесет столько вреда, как беспилотный автомобиль с некачественным программным обеспечением автопилота. Единственная ошибка в системе EHR может поставить под угрозу жизнь пациента, в то время как веб-сайт электронной коммерции, у которого есть проблемы с производительностью, может стоить владельцу дохода в миллионы долларов.
1. Базовые положения о: Quality Assurance (QA), Quality Control (QC) and Testing.
Хотя человеку свойственно ошибаться, иногда цена ошибки может быть слишком высока. История знает множество примеров ситуаций, когда ошибки в программном обеспечении приводили к потерям в миллиарды долларов или даже к человеческим жертвам: от того, что кофейни Starbucks были вынуждены раздавать бесплатные напитки из-за неисправности регистра, до того, как военный самолет F-35 не мог обнаружить цели правильно из-за отказа радара.
Чтобы убедиться, что выпущенное программное обеспечение безопасно и функционирует должным образом, было введено понятие качества программного обеспечения. Его часто определяют как «степень соответствия явным или неявным требованиям и ожиданиям». Эти так называемые явные и неявные ожидания соответствуют двум основным уровням качества программного обеспечения:
- Функциональность – соответствие продукта функциональным (явным) требованиям и конструктивным особенностям. В этом аспекте основное внимание уделяется практическому использованию программного обеспечения с точки зрения пользователя: его возможностям, производительности, простоте использования, отсутствию дефектов.
- Нефункциональные – внутренние характеристики и архитектура системы, т.е. структурные (неявные) требования. Это включает в себя удобство сопровождения кода, понятность, эффективность и безопасность.
Структурным качеством программного обеспечения обычно трудно управлять., оно в основном зависит от опыта команды инженеров и может быть обеспечено с помощью проверки кода, анализа и рефакторинга. В то же время функциональный аспект может быть обеспечен с помощью набора специальных мероприятий по управлению качеством, которые включают в себя обеспечение качества, контроль качества и тестирование.
Эти три термина, часто используемые взаимозаменяемо, относятся к несколько разным аспектам управления качеством программного обеспечения. Несмотря на общую цель выпуска продукта максимально возможного качества как структурно, так и функционально, они используют разные подходы к этой задаче.
Обеспечение качества (Quality Assurance) — это широкий термин, который объясняется в блоге тестирования Google как «непрерывное и последовательное улучшение и поддержание процесса, который позволяет выполнять работу по контролю качества». Как следует из определения, QA больше фокусируется на организационных аспектах управления качеством, контроле последовательности производственного процесса.
Через Контроль качества (Quality Control) команда проверяет соответствие продукта функциональным требованиям. По определению Investopedia, это «процесс, с помощью которого бизнес стремится обеспечить сохранение или улучшение качества продукции, а также уменьшение или устранение производственных ошибок». Эта деятельность применяется к готовому продукту и выполняется перед выпуском продукта. С точки зрения обрабатывающей промышленности это похоже на извлечение случайного предмета из сборочной линии, чтобы проверить, соответствует ли он техническим спецификациям.
Тестирование (Testing) — это основная деятельность, направленная на обнаружение и решение технических проблем в исходном коде программного обеспечения и оценку общего удобства использования, производительности, безопасности и совместимости продукта. Он имеет очень узкую направленность и выполняется инженерами-испытателями параллельно с процессом разработки или на специальном этапе тестирования (в зависимости от методологического подхода к циклу разработки программного обеспечения).
Применительно к процессу производства автомобилей наличие надлежащего процесса обеспечения качества означает, что каждый член команды понимает требования и выполняет свою работу в соответствии с общепринятыми принципами. А именно, он используется для того, чтобы убедиться, что каждое отдельное действие выполняется в правильном порядке, каждая деталь реализована должным образом, а общие процессы согласованы, чтобы ничто не могло отрицательно повлиять на конечный продукт.
Контроль качества можно сравнить с прибытием старшего менеджера в производственный отдел и выбором случайного автомобиля для осмотра и тест-драйва. Под тестированием в данном случае понимается процесс проверки каждого соединения, каждого механизма в отдельности, а также всего продукта в целом, будь то вручную или автоматически, проведение краш-тестов, тестов производительности, реальных или смоделированных тест-драйвов.
Из-за практического подхода деятельность по тестированию программного обеспечения остается предметом горячих дискуссий. Вот почему в этой статье мы сосредоточимся в первую очередь на этом аспекте управления качеством программного обеспечения. Но прежде чем мы углубимся в детали, давайте определим основные принципы тестирования программного обеспечения.
2. Основные принципы Software Testing.
Семь принципов тестирования программного обеспечения, сформулированные за последние 40 лет, представляют собой основные правила процесса. Это:
- Тестирование показывает наличие ошибок. Тестирование направлено на обнаружение дефектов в части программного обеспечения. Но как бы тщательно ни тестировался продукт, мы никогда не можем быть на 100 процентов уверены в отсутствии дефектов. Мы можем использовать тестирование только для уменьшения количества необнаруженных проблем.
- Исчерпывающее тестирование невозможно. Невозможно протестировать все комбинации входных данных, сценариев и предварительных условий в приложении. Например, если один экран приложения содержит 10 полей ввода с 3 возможными вариантами значений в каждом, это означает, что для охвата всех возможных комбинаций инженерам по тестированию потребуется создать 59 049 (310) тестовых сценариев. А если в приложении 50+ таких экранов? Чтобы не тратить недели на создание миллионов таких маловероятных сценариев, лучше сосредоточиться на потенциально более значимых.
- Раннее тестирование. Как упоминалось выше, стоимость ошибки растет экспоненциально на всех этапах SDLC. Поэтому важно как можно скорее начать тестирование программного обеспечения, чтобы обнаруженные проблемы были решены и не разрастались как снежный ком.
- Кластеризация дефектов. Этот принцип часто называют применением принципа Парето к тестированию программного обеспечения. Это означает, что примерно 80 процентов всех ошибок обычно обнаруживаются только в 20 процентах системных модулей. Поэтому, если дефект обнаружен в конкретном модуле программы, есть вероятность, что могут быть и другие дефекты. Вот почему имеет смысл тщательно протестировать эту область продукта.
- Парадокс пестицидов. Запуск одного и того же набора тестов снова и снова не поможет вам найти больше проблем. Как только обнаруженные ошибки исправлены, эти тестовые сценарии становятся бесполезными. Поэтому важно регулярно просматривать и обновлять тесты, чтобы адаптироваться и потенциально находить больше ошибок.
- Тестирование зависит от контекста. В зависимости от цели или отрасли разные приложения следует тестировать по-разному. В то время как безопасность может иметь первостепенное значение для финтех-продукта, она менее важна для корпоративного веб-сайта. Последний, в свою очередь, делает упор на удобство использования и скорость.
- Ошибка отсутствия ошибок. Полное отсутствие ошибок в вашем продукте не обязательно означает его успех. Независимо от того, сколько времени вы потратили на полировку своего кода или улучшение функциональности, если ваш продукт бесполезен или не соответствует ожиданиям пользователей, он не будет принят целевой аудиторией.
Хотя вышеперечисленные принципы являются бесспорными рекомендациями для каждого специалиста по тестированию программного обеспечения, есть и другие аспекты, которые следует учитывать. В некоторых источниках помимо основных отмечаются и другие принципы:
- Тестирование должно быть независимым процессом, управляемым беспристрастными профессионалами.
- Проверяйте наличие недопустимых и неожиданных входных значений, а также допустимых и ожидаемых.
- Тестирование должно проводиться только на статичном программном продукте (в процессе тестирования не должно производиться никаких изменений).
- Используйте исчерпывающую и всеобъемлющую документацию для определения ожидаемых результатов тестирования.
3. Роль тестирования в цикле разработки программного обеспечения (SDLC).
3.1. Waterfall Model
Представляя традиционный жизненный цикл разработки программного обеспечения, модель Waterfall включает 6 последовательных этапов: планирование, анализ, проектирование, внедрение, тестирование и обслуживание.
На этапе тестирования продукт, уже разработанный и закодированный, тщательно тестируется перед выпуском. Однако практика показывает, что ошибки и дефекты программного обеспечения, обнаруженные на этом этапе, могут быть слишком дорогими для исправления, поскольку стоимость ошибки имеет тенденцию к увеличению на протяжении всего процесса разработки программного обеспечения.
Например, если в спецификациях есть ошибка, обнаружение ее на раннем этапе планирования не приведет к значительным потерям для вашего бизнеса. Однако ущерб экспоненциально растет на протяжении дальнейших стадий процесса. Если такая ошибка будет обнаружена на этапе проектирования, вам потребуется переработать свои проекты, чтобы исправить ее. Но если вы не можете обнаружить ошибку до того, как продукт будет создан, вам может потребоваться внести некоторые серьезные изменения в дизайн, а также в исходный код. Это потребует значительных усилий и вложений.
То же самое относится и к ошибкам, допущенным в процессе реализации. Если функция имеет изъян в своей логике, создание дополнительной функциональности поверх нее может нанести серьезный ущерб в долгосрочной перспективе. Поэтому лучше протестировать каждую функцию, пока продукт еще создается. Именно здесь итерационные Agile-методы оказываются полезными.
3.2. Agile Testing
Будучи неотъемлемой частью процесса разработки программного обеспечения, Agile разбивает процесс разработки на более мелкие части, итерации и спринты. Это позволяет тестировщикам работать параллельно с остальной командой на протяжении всего процесса и исправлять недостатки и ошибки сразу после их возникновения.
Основной целью такого процесса является быстрое и качественное предоставление новых функций программного обеспечения. Следовательно, этот подход менее затратен: исправление ошибок на ранних этапах процесса разработки, до того, как возникнет снежный ком, значительно дешевле и требует меньше усилий. Более того, эффективная коммуникация внутри команды и активное участие заинтересованных сторон ускоряют процесс и позволяют принимать более взвешенные решения. Вы можете узнать больше о ролях и обязанностях в команде тестирования в нашей специальной статье.
Agile-подход к тестированию больше связан с созданием практики QA, а не с командой QA.
3.3. DevOps Testing
Для тех, у кого есть Agile-опыт, DevOps постепенно становится обычной практикой. Эта новая методология разработки программного обеспечения требует высокого уровня координации между различными функциями цепочки поставок, а именно, разработкой, контролем качества и эксплуатацией.
DevOps часто называют расширением Agile, которое устраняет разрыв между разработкой, контролем качества и эксплуатацией. Однако, в отличие от Agile, DevOps включает в себя концепцию непрерывной разработки, при которой код, написанный и переданный для контроля версий, будет создан, развернут, протестирован и установлен в производственной среде, готовой к использованию конечным пользователем. DevOps уделяет большое внимание автоматизации и инструментам непрерывной интеграции, которые обеспечивают высокую скорость доставки приложений и услуг.
Тот факт, что тестирование происходит на каждом этапе модели DevOps, меняет роль тестировщиков и общую идею тестирования. Таким образом, чтобы иметь возможность эффективно проводить тестирование, от тестировщиков теперь требуется наличие технических навыков и даже умение разбираться в коде.
Согласно опросу PractiTest, Agile-тренд — бесспорный лидер, при этом почти 90 процентов респондентов работают хотя бы в каких-то Agile-проектах в своих организациях. При этом треть респондентов по-прежнему применяют модель водопада в некоторых проектах после неуклонного сокращения использования этого метода. DevOps продолжает расти, просто медленнее, чем раньше.
4. Процесс Software Testing на практике.
Организация процесса тестирования программного обеспечения может быть довольно сложной задачей. Мы следуем трем основным этапам процесса тестирования программного обеспечения: планирование, выполнение и отчетность.
4.1. Test Planning: Artifacts and Strategy
Как и любому другому формальному процессу, тестированию обычно предшествуют тщательная подготовка и планирование. Основная цель этого этапа — убедиться, что команда понимает цели клиента, основную цель продукта, возможные риски, которые необходимо устранить, и ожидаемые результаты. Решению этой задачи служит один из документов, создаваемых на этом этапе, задание на проведение испытаний. Это помогает согласовать действия по тестированию с общей целью продукта и координирует усилия по тестированию с остальной работой команды.
Роджер С. Прессман, профессиональный инженер-программист, известный автор и консультант, утверждает: «Стратегия тестирования программного обеспечения представляет собой дорожную карту, в которой описываются шаги, которые должны быть выполнены в рамках тестирования, когда эти шаги планируются и затем выполняются, а также сколько потребуются усилия, время и ресурсы».
Стратегия тестирования, также называемая подходом к тестированию или архитектурой, является еще одним артефактом этапа планирования. Джеймс Бах, гуру тестирования, создавший курс Rapid Software Testing, определяет цель стратегии тестирования как «прояснение основных задач и проблем тестового проекта».
В зависимости от того, когда именно в процессе они используются, стратегии можно классифицировать как превентивные или реактивные. Кроме того, существует несколько типов стратегий, которые можно использовать по отдельности или в комплексе:
В то время как стратегия тестирования является документом высокого уровня, план тестирования имеет более практический подход, подробно описывая, что тестировать, как тестировать, когда тестировать и кто будет проводить тест. В отличие от документа статической стратегии, который относится к проекту в целом, план тестирования охватывает каждую фазу тестирования отдельно и часто обновляется менеджером проекта на протяжении всего процесса.
Согласно стандарту IEEE для документации по тестированию программного обеспечения, документ плана тестирования должен содержать следующую информацию:
- Идентификатор плана тестирования - Test plan identifier
- Введение - Introduction
- Ссылки (ссылки на связанные документы - References
- Тестовые элементы (продукт и его версии) - Test items (the product and its versions)
- Возможности для тестирования - Features to be tested
- Функции, которые нельзя тестировать - Features not to be tested
- Критерии прохождения или отказа элемента - Item pass or fail criteria
- Подход к тестированию (уровни тестирования, типы, методы) - Test approach (testing levels, types, techniques)
- Критерии приостановки - Suspension criteria
- Результаты (План тестирования (сам этот документ), Тестовые сценарии, Журналы дефектов/улучшений, Отчеты о тестировании) - Deliverables (Test Plan (this document itself), Test Cases, Test Scripts, Defect/Enhancement Logs, Test Reports)
- Тестовая среда (аппаратное обеспечение, программное обеспечение, инструменты) - Test environment (hardware, software, tools)
- Оценки - Estimates
- Расписание - Schedule
- Потребности в персонале и обучении - Staffing and training needs
- Обязанности - Responsibilities
- Риски - Risks
- Предположения и зависимости - Assumptions and Dependencies
- Одобрения - Approvals
Написание плана, включающего в себя всю перечисленную информацию, является трудоемкой задачей. В agile-методологиях с их фокусом на продукте, а не на документах такая трата времени кажется недостаточной.
Чтобы решить эту проблему, Джеймс Уиттакер, технический евангелист Microsoft и бывший технический директор Google, представил подход «10-минутный план тестирования». Основная идея этой концепции состоит в том, чтобы сначала сосредоточиться на самом важном, избавляясь от всего лишнего, используя простые списки и таблицы вместо больших абзацев с подробными описаниями. Хотя 10-минутный временной интервал кажется немного нереалистичным (ни одна из команд в первоначальном эксперименте не смогла выполнить это требование), сама идея сокращения и ограничения времени планирования весьма разумна. В результате 80% планирования можно выполнить всего за 30 минут.
4.2. Design and Execution
В качестве отправной точки для выполнения теста нам нужно определить, что подлежит тестированию. Чтобы ответить на этот вопрос, QA-команды разрабатывают тестовые примеры. В двух словах, тестовый пример описывает предварительные условия, желаемые результаты и постусловия конкретного тестового сценария, направленного на проверку того, что функция соответствует основным требованиям.
Следующим шагом в выполнении теста является настройка среды тестирования. Основным критерием для этой части является обеспечение того, чтобы среда тестирования была максимально приближена к фактической среде конечного пользователя (аппаратное и программное обеспечение). Например, типичная тестовая среда для веб-приложения должна включать веб-сервер, базу данных, ОС и браузер.
В процессе тестирования программного обеспечения выделяют две широкие категории: статическое тестирование и динамическое тестирование.
Статическое тестирование изначально исследует исходный код и документы проекта программного обеспечения, чтобы выявить и предотвратить дефекты на ранних этапах жизненного цикла тестирования программного обеспечения. Статическое тестирование, также называемое методом невыполнения или проверочным тестированием, может выполняться в виде инспекций, неофициальных и технических обзоров или обзоров во время ознакомительных совещаний. Неофициальный обзор — это дешевый вариант тестирования, который аналитик QA может проводить в любое время в ходе проекта. Проверка, также называемая формальной проверкой, планируется и контролируется модератором. Во время обзорной встречи ошибки, обнаруженные аналитиками QA, обсуждаются и документируются в обзорном отчете.
Как только основная подготовка завершена, команда приступает к динамическому тестированию, при котором программное обеспечение тестируется во время выполнения. В этом техническом описании основное внимание уделяется процессу динамического тестирования как практичному и наиболее часто используемому способу проверки поведения кода. Динамическое тестирование можно описать методами, уровнями и типами лежащих в его основе действий по обеспечению качества. Давайте подробнее рассмотрим этот сегмент процесса динамического тестирования.
Методы тестирования программного обеспечения — это способы проведения тестов. Они включают тестирование черного ящика, тестирование белого ящика, тестирование серого ящика и специальное тестирование.
Уровни тестирования программного обеспечения описывают этапы разработки программного обеспечения, на которых проводится тестирование. Тем не менее, существует четыре прогрессивных уровня тестирования в зависимости от области, в которой они сосредоточены на процессе разработки программного обеспечения: модульное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование пользователем (UAT).
Типы тестирования программного обеспечения — это подходы и методы, которые применяются на данном уровне с использованием соответствующего метода для наиболее эффективного выполнения требований к тестированию. Их огромное количество, но они служат разным целям.
Подводя итог, вы можете проводить тестирование вариантов использования (тип) во время системного или приемочного тестирования (уровень) с использованием тестирования черного ящика (метод).
4.3. Documentation and Reporting
Поскольку идеального программного обеспечения не существует, тестирование никогда не завершается на 100 процентов. Это непрерывный процесс. Однако существуют так называемые «критерии выхода», которые определяют, было ли проведено «достаточное тестирование» на основе оценки риска проекта.
Есть общие моменты, которые присутствуют в основном в критериях выхода:
- Выполнение тестового примера завершено на 100 процентов.
- В системе нет дефектов с высоким приоритетом.
- Производительность системы стабильна независимо от внедрения новых функций.
- Программное обеспечение поддерживает все необходимые платформы и/или браузеры
- Приемочное тестирование пользователями завершено.
- Как только все эти критерии (или любые пользовательские критерии, которые вы задали в своем проекте) соблюдены, тестирование подходит к концу.
Журналы тестирования и отчеты о состоянии документируются на протяжении всего процесса выполнения теста. О каждой проблеме, обнаруженной в продукте, следует сообщать и обрабатывать соответствующим образом. Сводка по тестированию и отчеты о закрытии теста подготавливаются и предоставляются заинтересованным сторонам. Команда проводит ретроспективную встречу, чтобы определить и задокументировать проблемы, возникшие во время разработки, и улучшить процесс.
Согласно опросу, проведенному компанией PractiTest, комплексным решением для контроля качества и управления тестированием, объем формальной документации по тестированию постоянно сокращается. Эта тенденция сигнализирует о необходимости оптимизации тестирования во всей отрасли.
5. Уровни Software Testing
Программное обеспечение — это больше, чем несколько строк кода. Обычно это многоуровневая, сложная система, включающая в себя десятки отдельных функциональных компонентов и сторонних интеграций. Следовательно, эффективное тестирование программного обеспечения должно выходить далеко за рамки простого поиска ошибок в исходном коде. Как правило, тестирование охватывает следующие уровни программного обеспечения.
- Компонентное/модульное тестирование - Component/Unit Testing.
Наименьшую тестируемую часть программной системы часто называют единицей. Таким образом, этот уровень тестирования направлен на проверку каждой отдельной единицы программной системы, чтобы убедиться, что она соответствует первоначальным требованиям и функционирует должным образом. Модульное тестирование обычно выполняется на ранних этапах разработки самими инженерами, а не командой тестирования.
- Интеграционное тестирование - Integration Testing.
Целью следующего уровня тестирования является проверка того, хорошо ли объединенные устройства работают вместе как группа. Интеграционное тестирование направлено на выявление недостатков во взаимодействии между модулями внутри модуля. Существует два основных подхода к этому тестированию: методы «снизу вверх» и «сверху вниз». Восходящее интеграционное тестирование начинается с модульных тестов, последовательно увеличивая сложность тестируемых программных модулей. Метод «сверху-вниз» использует противоположный подход, сначала фокусируясь на высокоуровневых комбинациях, а затем исследуя простые.
- Системное тестирование - System Testing.
На этом уровне тестируется вся программная система в целом. Этот этап служит для проверки соответствия продукта функциональным и техническим требованиям и общим стандартам качества. Тестирование системы должно выполняться высокопрофессиональной группой тестирования в среде, максимально приближенной к реальному сценарию использования в бизнесе.
- Приемочное тестирование пользователей - User Acceptance Testing.
Это последний этап процесса тестирования, на котором продукт проверяется на соответствие требованиям конечного пользователя и на точность. Этот последний шаг помогает команде решить, готов ли продукт к отправке или нет. В то время как небольшие проблемы должны обнаруживаться и устраняться на ранних этапах процесса, этот уровень тестирования фокусируется на общем качестве системы, от содержимого и пользовательского интерфейса до проблем с производительностью. За этапом приемки может следовать альфа- и бета-тестирование, позволяющее небольшому количеству реальных пользователей опробовать программное обеспечение до его официального выпуска.
В гибкой разработке программного обеспечения тестирование обычно представляет собой итеративный процесс. Хотя уровни обычно относятся ко всему продукту, они также могут применяться к каждой добавленной функции. При этом проверяется каждая маленькая единица нового функционала. Затем инженеры проверяют взаимосвязи между этими устройствами, способ интеграции функции с остальной системой и готовность нового обновления к отправке.
6. Методы Software Testing
- Black Box Testing
Этот метод получил свое название, потому что инженер по контролю качества сосредотачивается на входных данных и ожидаемых выходных данных, не зная, как приложение работает внутри и как эти входные данные обрабатываются. Целью этого метода является проверка функциональности программного обеспечения, чтобы убедиться, что оно работает правильно и соответствует требованиям пользователя. Этот метод может быть применен к любому уровню тестирования, но в основном используется для системного и пользовательского приемочного тестирования.
- White Box Testing
В отличие от тестирования методом «черного ящика», этот метод требует глубоких знаний кода, поскольку предполагает тестирование некоторой структурной части приложения. Поэтому, как правило, за этот тип тестирования отвечают разработчики, непосредственно участвующие в написании кода. Целью тестирования белого ящика является повышение безопасности, потока входных/выходных данных через приложение, а также улучшение дизайна и удобства использования. Этот метод в основном используется на уровне модульного и интеграционного тестирования.
- Grey Box Testing
Этот метод является комбинацией двух предыдущих, так как предполагает тестирование как функциональной, так и структурной части приложения. Используя этот метод, опытный тестировщик имеет частичное представление о внутренней структуре приложения и на основе этих знаний может разрабатывать тестовые примеры, продолжая проводить тестирование с точки зрения черного ящика. Этот метод в основном применим к уровню интеграционного тестирования.
- Ad Hoc Testing
Это неформальный метод тестирования, так как он выполняется без планирования и документации. Проводя тесты неформально и случайным образом без каких-либо формальных, ожидаемых результатов, тестер импровизирует шаги и произвольно их выполняет. Хотя дефекты, обнаруженные с помощью этого метода, труднее воспроизвести из-за отсутствия письменных тестовых примеров, этот подход помогает быстро найти важные дефекты, что невозможно сделать с помощью формальных методов.
7. Типы Software Testing
Исходя из основной цели процесса, тестирование может быть разных видов. Вот самые популярные типы тестирования согласно опросу ISTQB.
Functional Testing - Функциональное тестирование
Набрав 83 процента голосов респондентов, функциональное тестирование является наиболее важным типом тестирования. Этого следовало ожидать, так как без функциональности не было бы использования всех других нефункциональных аспектов системы.
При функциональном тестировании система проверяется на соответствие функциональным требованиям путем подачи входных данных и проверки выходных данных. Этот тип тестирования использует метод черного ящика. Следовательно, он придает значение не самой обработке, а ее результатам. Функциональное тестирование обычно выполняется на уровнях системы и приемки.
Обычно процесс функционального тестирования включает в себя следующий набор действий:
1. Описывает функции, которые должно выполнять программное обеспечение.
2. Формирует входные данные в зависимости от спецификации функции.
3. Определяет выход в зависимости от спецификации функции.
4. Выполняет тестовый пример.
5. Сопоставляет полученные и ожидаемые результаты.
Performance Testing - Тестирование производительности
Тестирование производительности было выбрано 60,7% респондентов как наиболее важный тип нефункционального тестирования. Тестирование производительности направлено на исследование отзывчивости и стабильности работы системы при определенной нагрузке.
В зависимости от рабочей нагрузки поведение системы оценивается различными видами тестирования производительности:
- Нагрузочное тестирование — при постоянно растущей нагрузке.
- Стресс-тестирование — в пределах или за пределами ожидаемой рабочей нагрузки.
- Тестирование на выносливость — при постоянной и значительной рабочей нагрузке.
- Spike Testing — при внезапном и существенном увеличении нагрузки.
Use Case Testing - Тестирование вариантов использования
Это наиболее широко используемый метод тестирования, за которым следует исследовательское тестирование. Вариант использования описывает, как система будет реагировать на заданный сценарий, созданный пользователем. Он ориентирован на пользователя и фокусируется на действиях и актере, не принимая во внимание ввод и вывод системы. Помня о концепциях проекта, разработчики пишут варианты использования, и после их завершения поведение системы тестируется соответствующим образом. Тестировщики, в свою очередь, используют их для создания тестовых случаев.
Тестирование вариантов использования широко применяется при разработке тестов на уровне системы или приемки. Это также помогает выявить дефекты в интеграционном тестировании. Тестирование варианта использования проверяет, работает ли путь, используемый пользователем, как задумано, и гарантирует, что задачи могут быть выполнены успешно. Применяя тестирование вариантов использования, аналитики могут обнаруживать недостатки и модифицировать систему, чтобы она достигла эффективности и точности.
Exploratory Testing - Исследовательское тестирование
Техника исследовательского тестирования была впервые описана Джемом Канером, профессором программной инженерии и защитником прав потребителей, как «стиль тестирования программного обеспечения, который подчеркивает личную свободу и ответственность отдельного тестировщика за постоянную оптимизацию ценности своей работы путем обработки связанных с тестированием вопросов, обучение, разработка тестов, выполнение тестов и интерпретация результатов тестов как взаимодополняющие действия, которые выполняются параллельно на протяжении всего проекта».
Используя метод ad hoc, исследовательское тестирование не полагается на предопределенные и задокументированные тестовые примеры и этапы тестирования, как это делают большинство типов тестирования. Вместо этого это интерактивный процесс в свободной форме, в котором основное внимание уделяется проверке пользовательского опыта, а не кода. Он имеет много общего со специальным или интуитивным тестированием, но более систематичен. Применяя исследовательское тестирование, опытные тестировщики могут предоставить ценные и проверяемые результаты.
Usability Testing - Юзабилити-тестирование
Выбранное 44,1% респондентов тестирование удобства использования проводится с точки зрения конечного пользователя, чтобы убедиться, что система проста в использовании. Этот тип тестирования не следует путать с приемочным тестированием пользователей. Последний проверяет соответствие конечного продукта установленным требованиям, первый гарантирует, что подход к реализации будет работать для пользователя.
8. Test Automation
Чтобы ускорить и улучшить качество тестирования программного обеспечения, важно внедрить передовую автоматизацию.
Автоматизация тестирования имеет решающее значение с точки зрения непрерывного тестирования, поскольку она облегчает управление всеми потребностями тестирования, позволяя тратить больше времени и усилий на создание эффективных тестовых случаев. Тенденция к автоматизации тестирования поддерживается постоянно растущим внедрением гибких методологий, которые продвигают как автоматизацию тестирования, так и практику непрерывной интеграции в качестве краеугольного камня эффективной разработки программного обеспечения.
Подробнее с передовыми инструментами автоматизированного тестирования можно ознакомиться тут.
Процесс автоматизации тестирования обычно проводится в несколько последовательных этапов:
- Предварительный анализ проекта
- Инжиниринг каркаса
- Разработка тестовых случаев
- Реализация тестовых случаев
- Итеративная поддержка фреймворка
Преимущества автоматизации тестирования. Автоматизация может применяться практически к каждому типу тестирования на любом уровне. В результате автоматизация сводит к минимуму человеческие усилия, необходимые для эффективного выполнения тестов, сокращает время выхода на рынок и стоимость ошибок, поскольку тесты выполняются в 10 раз быстрее по сравнению с процессом ручного тестирования. Более того, такой подход к тестированию более эффективен, поскольку фреймворк покрывает более 90 процентов кода, выявляя проблемы, которые могут быть незаметны при ручном тестировании и могут масштабироваться по мере роста продукта.
Автоматизация тестирования в цифрах. Согласно опросу ISTQB®, 64,4 % их респондентов голосуют за деятельность по автоматизации тестирования как за основную область улучшения в тестировании программного обеспечения. При этом 43,4% опрошенных называют автоматизацию тестирования главной задачей Agile-проектов. Вот самые яркие проблемы, с которыми приходится сталкиваться при применении автоматизации тестирования на основе опроса Katalon Studio.
Постепенный рост вклада автоматизации тестирования подтверждает следующий опрос.
Автоматизированные действия по тестированию включают в себя выполнение тестов, проектирование функциональных тестовых случаев, генерацию тестовых данных и тестирование сквозных бизнес-сценариев.
Однако наиболее эффективные подходы к тестированию сочетают ручное и автоматизированное тестирование для достижения наилучших результатов.
9. Regression Testing
Регрессионное тестирование — это практика проверки поведения программного обеспечения после обновлений, чтобы убедиться, что изменения не повлияли на существующие системные функции, стабильность и общую целостность. Регрессионное тестирование может применяться на всех уровнях и со всеми типами процедур тестирования, но наиболее распространенным способом является проведение регрессионного тестирования в соответствии с вариантами использования. Рабочий процесс обеспечения качества регрессии можно автоматизировать, чтобы избежать повторных ручных тестов после каждого обновления.
Существует несколько методов регрессионного тестирования:
- Повторное тестирование всех тестовых случаев
- Выбор конкретных тестовых случаев
- Приоритизация тестовых случаев, чтобы сначала проверить наиболее важные, а затем протестировать остальные
- Гибридные методы
10. The Future of Testing
Являясь частью технического прогресса, тестирование постоянно развивается, чтобы соответствовать постоянно меняющимся потребностям бизнеса, поскольку оно использует новые инструменты, которые позволяют тестировщику расширять границы обеспечения качества.
Новые темы, которые, как ожидается, повлияют на тестирование программного обеспечения в ближайшем будущем, — это безопасность, искусственный интеллект и большие данные.
- Security
Опрос World Quality Report показывает, что безопасность является одним из наиболее важных элементов ИТ-стратегии. Вклад службы безопасности жизненно важен для защиты бизнеса. Уязвимости безопасности могут серьезно подорвать репутацию бренда. По этим причинам тестовая среда и тестовые данные считаются сегодня основными проблемами при тестировании QA.
Законы о защите данных и конфиденциальности также вызывают опасения по поводу безопасности тестовых сред. Если среда содержит личные тестовые данные и имеет место нарушение безопасности, предприятия должны немедленно уведомить власти. В результате для тестовых сред так важно иметь возможность обнаруживать утечки данных.
Тестирование безопасности, наиболее популярное в облачных средах, предназначено для выявления уязвимостей системы и определения того, насколько хорошо она может защитить себя от несанкционированного доступа, взлома, любого повреждения кода и т. д. При работе с кодом приложения тестирование безопасности относится к методу тестирования белого ящика. .
Четыре основных направления тестирования безопасности:
- Сетевая безопасность
- Безопасность системного программного обеспечения
- Безопасность клиентских приложений
- Безопасность приложений на стороне сервера
Настоятельно рекомендуется включать тестирование безопасности в стандартный процесс разработки программного обеспечения.
- Artificial Intelligence
Задачи тестирования растут, и их решения имеют неограниченное количество ситуаций, требующих тщательного тестирования с помощью искусственного интеллекта. Различные реализации ИИ с использованием алгоритмов на основе машинного обучения скоро будут встроены в приложения для выполнения задач, которые когда-то были зарезервированы для людей.
Хотя решения для автоматизации тестирования в области аналитики еще недостаточно хорошо зарекомендовали себя, сдвиг в сторону большей интеллектуальности в тестировании неизбежен. Когнитивная автоматизация, машинное обучение, самовосстановление и прогнозный анализ — многообещающие новые технологии для будущего автоматизации тестирования.
Тем не менее бостонский стартап mabl уже упрощает функциональное тестирование, объединяя его с машинным обучением. «Когда мы встретились с сотнями команд разработчиков программного обеспечения, мы ухватились за идею, что разработка… сейчас идет очень быстро, но есть узкое место в QA», — говорит Иззи Азери, соучредитель mabl. «Каждый раз, когда вы вносите изменения в свой продукт, вы должны протестировать это изменение или создать автоматизацию тестирования».
С mabl нет необходимости писать сложные тесты вручную. Вместо этого вы показываете приложению рабочий процесс, который хотите протестировать, и служба выполняет эти тесты. Mabl может даже автоматически адаптироваться к небольшим изменениям пользовательского интерфейса и предупреждать разработчиков о любых визуальных изменениях, ошибках JavaScript, неработающих ссылках и увеличении времени загрузки.
Внедрение более интеллектуальных решений по автоматизации будет иметь важное значение для тестирования новых интеллектуальных приложений и продуктов в их быстро меняющихся бизнес-средах.
- Big Data
В настоящее время двумя основными проблемами, связанными с управлением тестовыми данными, являются соответствие данных и большие данные.
Во-первых, в связи с появлением множества обременительных законов о защите простое копирование реальных данных сопряжено с риском их нарушения. Например, Общий регламент ЕС по защите данных (GDRP) стал законом в мае 2018 года для всех компаний, работающих в ЕС. Учитывая угрозу значительных штрафов, сегодня большинство ИТ-отделов озабочены соблюдением требований к данным.
Во-вторых, управление огромными объемами данных, которые постоянно загружаются на различные платформы, требует уникального подхода к тестированию, поскольку традиционные методы уже не справляются.
Тестирование больших данных направлено на проверку качества данных и проверку обработки данных. Проверка качества данных включает в себя различные характеристики, такие как соответствие, точность, дублирование, непротиворечивость, достоверность, полнота данных и т. д. Проверка обработки данных включает тестирование производительности и функциональное тестирование. Тестирование больших данных требует высокого уровня навыков тестирования, поскольку обработка выполняется очень быстро.
Заключение
В 2012 году глобальная финансовая компания Knight Capital Americas столкнулась с ошибкой в своей автоматизированной системе маршрутизации заказов на акции — команда развернула непроверенное программное обеспечение в производственной среде. В результате всего за 45 минут компания потеряла более 460 миллионов долларов, что фактически привело к ее банкротству.
История знает еще немало примеров программных инцидентов, повлекших за собой подобный ущерб. Тем не менее, тестирование остается одной из самых спорных тем в разработке программного обеспечения. Многие владельцы продуктов сомневаются в его ценности как отдельного процесса, ставя под угрозу свой бизнес и продукты, пытаясь сэкономить лишнюю копейку.
Несмотря на широко распространенное заблуждение, что единственная задача тестировщика — находить ошибки, тестирование и контроль качества оказывают большее влияние на успех конечного продукта. Обладая глубоким пониманием бизнеса клиента и самого продукта, QA-инженеры повышают ценность программного обеспечения и обеспечивают его отличное качество. Кроме того, применяя свои обширные знания о продукте, тестировщики могут принести пользу клиенту с помощью дополнительных услуг, таких как советы, рекомендации и руководства по использованию продукта. Это приводит к снижению стоимости владения и повышению эффективности бизнеса.
Дополнительные материалы:
- Software Quality – http://softwaretestingfundamentals.com/software-quality/
- The Three Aspects of Software Quality – http://www.davidchappell.com/writing/white_papers/The_Three_Aspects_of_Software_Quality_v1.0-Chappell.pdf
- Foundations of Software Testing: ISTQB Certification – https://www.amazon.com/Foundations-Software-Testing-ISTQB-Certification/dp/1844809897
- Software Engineering: A Practitioner’s Approach – https://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/0073375977/
- Test Strategy – http://www.satisfice.com/presentations/strategy.pdf
- Test Strategy and Test Plan – http://www.testingexcellence.com/test-strategy-and-test-plan/
- IEEE Standard for Software and System Test Documentation 2008 – https://standards.ieee.org/findstds/standard/829-2008.html
- ISTQB Worldwide Software Testing Practices REPORT 2017-18 – https://www.turkishtestingboard.org/en/istqb-worldwide-software-testing-practices-report/
- Defining Exploratory Testing – http://kaner.com/?p=46
- Evaluating Exit Criteria and Reporting – http://www.softwaretestingmentor.com/evaluating-exit-criteria-and-reporting-in-testing-process/
- Myths and realities of iterative testing – http://test.techwell.com/sites/default/files/articles/XUS16337350file1_0.pdf
- Securities Exchange Act of 1934 – https://www.sec.gov/litigation/admin/2013/34-70694.pdf
- World Quality Report 2017-18 | Ninth Edition – https://www.sogeti.com/globalassets/global/downloads/testing/wqr-2017-2018/wqr_2017_v9_secure.pdf
- The most striking problems in test automation: A survey May 2018 – https://d1h3p5fzmizjvp.cloudfront.net/wp-content/uploads/2018/06/05101901/The-Most-Striking-Problemns-in-Test-Automation-A-Survey.pdf
- DevOps Testing Tutorial: How DevOps will Impact QA Testing? – https://www.softwaretestinghelp.com/devops-and-software-testing/