Что такое тестирование программ для чего нужно

Любой сайт или приложение нуждаются в тестировании. Сделать это можно вручную или с помощью автотестов. А что лучше для бизнеса? Зависит от ситуации. Меня зовут Ксения, я тимлид команды тестировщиков в Fojin.

Расскажу о разных вариантах с примерами из нашей ежедневной практики.

349 просмотров
Кратко: что такое ручное и автоматизированное тестирование?

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

Тестировщик цифровых продуктов / QA-инженер использует в работе много узконаправленных инструментов. Необходимость в этом не зависит от специализации. Например, у «ручников» может быть Postman, а у автотестировщиков – Selenium.

QA-специалист, особенно мануальный, не может обойтись и без «общеайтишных» сервисов. К примеру, мы в Fojin обычно используем Confluence для создания единой базы знаний и ClickUp для управления задачами по тестированию.

Что такое тестирование программного обеспечения (ПО)

Confluence: тестировщик расписал план и уже выполнил все тесты. А рядом можно найти ссылки на всевозможную документацию по проекту – очень удобно.

Какие проблемы решает тестирование цифрового продукта:

• Ошибки в UX, которые усложняют навигацию по сайту или приложению;
• Некорректное отображение элементов интерфейса при работе с разных устройств (ноутбук, смартфон и т.д.);
• Баги, из-за которых продукт работает не так, как ожидалось;
• Проблемы с производительностью, из-за которых продукт «тормозит» или не выполняет требуемое действие;
• Неуспешная интеграция со сторонним сервисом (например, не работает оплата онлайн на сайте)
• Проблемы с безопасностью данных, и многое другое.

Так какой же тип тестирования лучше для продукта?

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

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

Чтобы проиллюстрировать эту мысль, далее приведем несколько примеров из практики QA-специалистов компании Fojin.

Когда лучше выбрать автоматизированное тестирование?

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

Кейс из нашей практики

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

Тестировщик с нуля / Урок 1 / Что такое тестирование по

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

Кейс из нашей практики

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

Автотесты найдут проблемы, которые может не заметить ручной тестировщик.

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

Кейс из нашей практики

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

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

Кейс из нашей практики

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

Тестирование API с помощью инструмента Postman
Когда стоит использовать ручное тестирование?

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

Кейс из нашей практики

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

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

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

Кейс из нашей практики

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

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

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

Кейс из нашей практики

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

Воспроизвести проблему пользователей – задача как раз для специалиста по ручному тестированию.

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

Кейс из нашей практики

Для сервиса потокового аудио была разработана веб-версия и мобильная версия под Android и iOS. Необходимо было проверить корректность работы с аппаратными средствами. Для полноценного ручного тестирования приходилось настраивать эмуляторы под множество версий операционных систем и моделей устройств. Использование эмулятора помогло избежать проблемы маленького парка устройств для тестирования и позволило всё покрыть тестами.

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

Кейс из нашей практики

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

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

А когда лучший подход – совмещать оба вида тестирования?

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

Кейс из нашей практики

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

Успешное тестирование основано на повторениях и вариациях. С первым отлично справятся автотесты, а второе обеспечит программный тестировщик.

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

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

Источник: vc.ru

Java Unit Testing: методики, понятия, практика

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

Что же, посмотрим, какие вообще есть виды тестирования:

1. Модульное тестирование (unit testing) — тесты, задача которых проверить каждый модуль системы по отдельности. Желательно, чтобы это были минимально делимые кусочки системы, например, модули.
2. Системное тестирование (system testing) — тест высокого уровня для проверки работы большего куска приложения или системы в целом.
3. Регрессионное тестирование (regression testing) — тестирование, которое используется для проверки того, не влияют ли новые фичи или исправленные баги на существующий функционал приложения и не появляются ли старые баги.
4. Функциональное тестирование (functional testing) — проверка соответствия части приложения требованиям, заявленным в спецификациях, юзерсторях и т. д. Виды функционального тестирования:
5. тест «белого ящика» (white box) на соответствие части приложения требованиям со знанием внутренней реализации системы;
6. тест «черного ящика» (black box) на соответствие части приложения требованиям без знания внутренней реализации системы.
7. Тестирование производительности (performance testing) — вид тестов, которые пишутся для определения скорости отработки системы или ее части под определённой нагрузкой.
8. Нагрузочное тестирование (load testing) — тесты, предназначенные для проверки устойчивости системы при стандартных нагрузках и для нахождения максимально возможного пика, при котором приложение работает корректно.
9. Стресс-тестирование (stress testing) — вид тестирования, предназначенный для проверки работоспособности приложения при нестандартных нагрузках и для определения максимально возможного пика, при котором система не упадёт.
10. Тестирование безопасности (security testing) — тесты, используемые для проверки безопасности системы (от атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным и прочих радостей жизни).
11. Тестирование локализации (localization testing) — это тесты локализации для приложения.
12. Юзабилити тестирование (usability testing) — вид тестирования, направленный на проверку удобства использования, понятности, привлекательности и обучаемости для пользователей. Это всё звучит хорошо, но как оно происходит на практике? Все просто: используется пирамида тестирования Майка Кона: Это упрощенный вариант пирамиды: сейчас её делят на более мелкие детали. Но сегодня мы не будем извращаться и рассмотрим самый простой вариант.

1. Unit — модульные тесты, применяемые в различных слоях приложения, тестирующие наименьшую делимую логику приложения: например, класс, но чаще всего — метод. Эти тесты обычно стараются по максимуму изолировать от внешней логики, то есть создать иллюзию того, что остальная часть приложения работает в стандартном режиме. Данных тестов всегда должно быть много (больше, чем остальных видов), так как они тестируют маленькие кусочки и весьма легковесные, не кушающие много ресурсов (под ресурсами я имею виду оперативную память и время).
2. Integration — интеграционное тестирование. Оно проверяет более крупные кусочки системы, то есть это либо объединение нескольких кусочков логики (несколько методов или классов), либо корректность работы с внешним компонентом. Этих тестов как правило меньше, чем Unit, так как они тяжеловеснее. Как пример интеграционных тестов можно рассмотреть соединение с базой данных и проверку правильной отработки методов, работающих с ней.
3. UI — тесты, которые проверяют работу пользовательского интерфейса. Они затрагивают логику на всех уровнях приложения, из-за чего их еще называют сквозными. Их как правило в разы меньше, так они наиболее тяжеловесны и должны проверять самые необходимые (используемые) пути. На рисунке выше мы видим соотношение площадей разных частей треугольника: примерно такая же пропорция сохраняется в количестве этих тестов в реальной работе. Сегодня подробно рассмотрим самые используемые тесты — юнит-тесты, так как уметь ими пользоваться на базовом уровне должны все уважающие себя Java-разработчики.

Ключевые понятия юнит-тестирования

Покрытие тестов (Code Coverage) — одна из главных оценок качества тестирования приложения. Это процент кода, который был покрыт тестами (0-100%). На практике многие гонятся за этим процентом, с чем я не согласен, так как начинается навешивание тестов там, где они не нужны. Например, у нас в сервисе есть стандартные CRUD (create/get/update/delete) операции без дополнительной логики. Эти методы — сугубо посредники, делегирующие работу слою, работающему с репозиторием. В данной ситуации нам нечего тестировать: разве то, что вызывает ли данный метод — метод из дао, но это не серьёзно. Для оценки покрытия тестами обычно используют дополнительные инструменты: JaCoCo, Cobertura, Clover, Emma и т.д. Для более детального изучения данного вопроса держи пару годных статей:

• материал о Code Coverage на JavaRush и на Хабре;
• фундаментальная теория тестирования.

TDD (Test-driven development) — разработка через тестирование. В рамках этого подхода в первую очередь пишется тест, который будет проверять определенный код. Получается тестирование чёрного ящика: мы знаем, что есть на входе и знаем, что должно получиться на выходе. Это позволяет избежать дублирования кода. Разработка через тестирование начинается с проектирования и разработки тестов для каждой небольшой функциональности приложения. В подходе TDD, во-первых, разрабатывается тест, который определяет и проверяет, что будет делать код. Основная цель TDD — сделать код более понятным, простым и без ошибок. Подход состоит из таких составляющих:

1. Пишем наш тест.
2. Запускаем тест, прошел он или нет (видим, что всё красное — не психуем: так и должно быть).
3. Добавляем код, который должен удовлетворить данный тест (запускаем тест).
4. Выполняем рефакторинг кода.

Исходя из того, что модульные тесты являются наименьшими элементами в пирамиде автоматизации тестирования, TDD основан на них. С помощью модульных тестов мы можем проверить бизнес-логику любого класса. BDD (Behavior-driven development) — разработка через поведение. Это подход основан на TDD. Если говорить точнее, он использует написанные понятным языком примеры (как правило на английском), которые иллюстрируют поведение системы для всех, кто участвует в разработке. Не будем углубляться в данный термин, так как он в основном затрагивает тестировщиков и бизнес-аналитиков. Тестовый сценарий (Test Case) — сценарий, описывающий шаги, конкретные условия и параметры, необходимые для проверки реализации тестируемого кода. Фикстуры (Fixture) — состояние среды тестирования, которое необходимо для успешного выполнения испытуемого метода. Это заранее заданный набор объектов и их поведения в используемых условиях.

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

Тест состоит из трёх этапов:

1. Задание тестируемых данных (фикстур).
2. Использование тестируемого кода (вызов тестируемого метода).
3. Проверка результатов и сверка с ожидаемыми.

Чтобы обеспечить модульность теста, нужно нужно изолироваться от других слоев приложения. Сделать это можно помощью заглушек, моков и шпионов. Мок (Mock) — объекты, которые настраиваются (например, специфично для каждого теста) и позволяют задать ожидания вызовы методов в виде ответов, которые мы планируем получить. Проверки соответствия ожиданиям проводятся через вызовы к Mock-объектам. Заглушки (Stub) — обеспечивают жестко зашитый ответ на вызовы во время тестирования. Также они могут сохранять в себе информацию о вызове (например, параметры или количество этих вызовов). Такие иногда называют своим термином — шпион ( Spy ). Иногда эти термины stubs и mock путают: разница в том, что стаб ничего не проверяет, а лишь имитирует заданное состояние. А мок — это объект, у которого есть ожидания. Например, что данный метод класса должен быть вызван определенное число раз. Иными словами, ваш тест никогда не сломается из-за «стаба», а вот из-за мока может.

Среды тестирования

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

А теперь давайте рассмотрим приведенный выше материал на конкретном примере. Будем тестировать метод для сервиса — update. Рассматривать слой дао не будем, так как он у нас дефолтный. Добавим стартер для тестов:

org.springframework.boot spring-boot-starter-test 2.2.2.RELEASE test
Итак, класс сервиса:

8 — вытягиваем обновляемый обьект из БД 9-14 — создаём объект через билдер, если в приходящем объекте есть поле — задаем его, если нет — оставляем то, что есть в БД И смотрим наш тест:

1 — наш Runner 4 — изолируем сервис от слоя дао, подставляя мок 11 — задаем для класса тестовую сущность (ту, которую мы будем юзать в качестве испытуемого хомячка) 22 — задаём объект сервиса, который мы и будем тестить

Здесь мы видим четкое разделение теста на три части: 3-9 — задание фикстур 11 — выполнение тестируемой части 13-17 — проверка результатов Подробнее: 3-4 — задаём поведение для мока дао 5 — задаём экземпляр, который мы будем апдейтить поверх нашего стандартного 11 — используем метод и берём результирующий экземпляр 13 — проверяем, что он не ноль 14 — сверяем айди результата и заданные аргументы метода 15 — проверяем, обновилось ли имя 16 — смотрим результат по cpu 17 – так как в экземпляре для обновления мы не задавали это поле, оно должно остаться прежним, проверяем это. Запускаем: Тест зелёный, можно выдыхать)) Итак, подведём итоги: тестирование улучшает качество кода и делает процесс разработки более гибким и надёжный. Представьте себе, как много сил мы потратим при изменении дизайна программного обеспечения с сотнями файлов классов. Когда у нас есть модульные тесты, написанные для всех этих классов, мы можем уверенно провести рефакторинг. И самое главное — это помогает нам легко находить ошибки во время разработки. Гайз, на этом у меня сегодня всё: сыпем лайки, пишем комменты)))

Источник: javarush.com

Пользовательское приемочное тестирование: руководство по успешному запуску новых продуктов

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

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

Именно здесь вам может пригодиться пользовательское приемочное тестирование (User Acceptance Testing, UAT). В сегодняшней статье мы расскажем вам, что это такое, когда и как вам следует использовать данный метод и почему он играет столь важную роль при выводе продукта на рынок.

Что такое пользовательское приемочное тестирование?

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

Известное также как бета-тестирование, UAT служит трем основным целям:

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

Далее в статье мы еще поговорим о важности UAT, но сперва давайте быстро разберем разные типы такого тестирования.

5 типов пользовательского приемочного тестирования

1. Первый тип, на котором мы и будем фокусироваться в этом посте, — альфа/бета-тестирование. При альфа-тесте роль пользователей на себя берут штатные сотрудники и члены команды разработчиков. А вот бета-тест проводится с участием реальных, специально отобранных пользователей. Ниже — пример лендинга с предложением зарегистрироваться для бета-тестирования Division 2, анонсированного на E3:

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

2. Контрактное приемочное тестирование (contractual acceptance testing) нацелено на то, чтобы проверить, соответствует ли разработанный продукт контрактным требованиям, согласованным всеми заинтересованными сторонами. Обычно такое тестирование используют, дабы убедиться в том, что сторонняя команда разработчиков выполнила свои договорные обязательства.

3. Законодательное приемочное тестирование (regulation acceptance testing) позволяет убедиться в том, что продукт соответствует всем законам и предписаниям своей отрасли и юрисдикции. Такое тестирование следует проводить в сферах здравоохранения и финансов, кроме того, с внедрением GDPR на нем должны акцентировать внимание все европейские компании.

4. Операционное приемочное тестирование (operational acceptance testing) сосредоточено на определении эффективности закулисных процессов внутри организации, которые гарантируют людям полноценное использование продукта. С помощью этого типа тестирования оцениваются такие процессы, как онбординг, сбор данных и защитные механизмы.

5. Тестирование по стратегии черного ящика (black box testing) ориентировано на анализ причинно-следственной связи между взаимодействием пользователя с продуктом и результатом, полученным за счет этого взаимодействия. Этот тип тестирования связан с UAT тем, что здесь людям говорят, для чего предназначен продукт, но изучать, как именно он работает, они могут самостоятельно.

Почему пользовательское приемочное тестирование играет столь важную роль

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

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

Думайте о конечном пользователе

Ценность вашего продукта определяется только людьми, которые будут с ним работать.

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

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

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

Подтвердите product/market fit

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

Когда продукт готов к проведению UAT?

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

Остановимся на этих критериях более подробно.

Бизнес-требования должны быть готовы

Согласно iSixSigma, главным образом документы по бизнес-требованиям создаются, чтобы:

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

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

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

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

Проблемы должны фиксироваться, исправляться и тестироваться

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

Этот лог-файл должен содержать следующую информацию:

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

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

Команда по тестированию системы должна дать добро

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

Зачем нужно пользовательское тестирование: кейс от Feedly

6 шагов успешного пользовательского приемочного тестирования

Процесс UAT включает в себя следующие этапы:

1. Проанализируйте бизнес-требования

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

• Устав проекта
• Бизнес-кейсы использования продукта
• Диаграммы технологических процессов
• Спецификации к системным требованиям (для SaaS-продуктов)

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

2. Разработайте UAT план

На этой стадии вы определяете такие логистические критерии UAT, как:

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

3. Определите тестовые сценарии и кейсы

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

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

4. Подготовьте тестовые данные

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

5. Проведите тест

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

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

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

6. Подтвердите достижение бизнес-целей

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

Эта документация включает:

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

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

По материалам: fieldboom.com, Источник картинки: deadheading

Источник: lpgenerator.ru