QA best practices
1.0.0
Это краткое изложение QA Practices Futurice использует и рекомендует использовать. Это не должно быть подробное описание, а иногда не может быть полностью использовано во всех задачах, но в качестве обзора наиболее важных процессов QA и списка хороших практик, которые следует использовать.
В целях ясности этот документ не описывает ошибку или процесс инцидента (то есть новая ошибка обнаружена из производства).
У каждого в команде Futurice есть обязанности QA, даже если есть названный менеджер QA или специалисты по QA. Футурис QA означает три вещи.
На высоком уровне работы и практики можно разделить на два процесса.
Кроме того, есть другие действия QA.
Futurice использует методы TDD и ATDD (разработка приема на тест), когда это применимо.
Метод заставляет реализацию следовать архитектуре и рассмотреть модули, которые используются. Реализация начинается с написания автоматического теста сначала, а затем реализации функциональности для прохождения теста.
Futurice использует метод парного программирования, когда это применимо. Это очень удобный способ поделиться знаниями и опытом в области проекта и программного обеспечения.
Просмотр кода помогает другим членам команды получить информацию о определенных функциональных возможностях и дает возможность дать отзыв ответственному лицу, а также обеспечивает обмен знаниями между членами команды.
Ручное тестирование в основном выполняется с использованием методологии исследовательского тестирования, и обнаружили, что ошибки либо сразу же зафиксированы, либо приоритеты и записываются на инструмент управления задачей/историей/ошибки. Изучение приложения или услуги может быть запущено сразу после того, как что -то функциональное «готово».
Исследовательское тестирование - очень мощный инструмент в конечном и конечном тестировании, где вся система покрывается тестированием. В методе тестера выходит за рамки того, что можно определить в тестовом примере, применяет пользовательское мышление, а также пытается сломать систему с помощью различных сценариев ошибок и никогда не «выполняется» с тестированием.
Вокруг функциональных требований и тестирования обычно существуют нефункциональные требования, которые можно проверить, применяя локализацию, удобство использования, производительность и тестирование нагрузки. Потребности и инструменты являются специфичными для проектов. Для удобства использования Futurice есть мобильная юридическая лаборатория для использования. Для тестов производительности Futurice использовал веб -сервисы, такие как Browsermob, чтобы назвать один. Для тестирования нагрузки Loadui и J Meter активно используются для проверки возможностей обслуживания в высоком трафике и для поиска возможных узких мест обслуживания.
Полученные проблемы записываются в конкретный инструмент или плату с такой информацией, как приоритет, среда (программное обеспечение и информацию о устройствах), шаги по воспроизведению, ожидаемому результату, времени и дате и скриншоту. Такие инструменты, как Jira, Trello, Pivotaltracker, Tracker, активно используются также для отслеживания ошибок.
Одним из принципов Agile является то, что филиал главного кода всегда должен быть потенциально подготовим. Это означает, что это всегда должно быть качество производства. Это достигается следующим средством:
Каждая пользовательская история (или функция) разрабатывается индивидуально в их собственном филиале. Цель этого состоит в том, чтобы каждое обновление в главную ветвь была в то же время 1) максимально небольшим, а 2) потенциально поддающаяся полной, полной истории.
Перед тем, как филиал функции может быть объединена с главной ветвью, она должна пройти список действий, требований и практики, называемых определением DED (DOD). Это определяется вместе с клиентом PO и командой разработчиков и может быть изменено во время проекта в случае изменения потребностей в проекте.
Следующие элементы в предлагаемом DOD были выделены жирным шрифтом
Процесс развертывания - это процесс того, как новый выпуск (или версия в Master Branch) развертывается для производства. Для этого процесса есть три соответствующие среды.
Сервер непрерывной интеграции (CI) используется для автоматических тестов и развертывания кода в средах. Автоматизированные тесты всегда выполняются, когда какая -либо из этих сред.
Тестовая среда обновляется автоматически с помощью CI, всякий раз, когда мастер -филиал обновляется. Это означает, что автоматические тестовые примеры также автоматически работают при обновлении главной ветви.
Тестовая среда является основным сервером тестирования для Futurice. Ожидается, что любой выпуск, который был протестирован здесь, готов к тому, чтобы его подтолкнули к QA или производству (в зависимости от терминологии и интеграций, используемых в проекте).
При обновлении теста нет необходимости запускать ручные регрессионные тестовые случаи. Довольно часто время, потраченное на предварительное тестирование, является более полезным. Тем не менее, это хорошая практика для проведения этих тестов, по крайней мере, один раз на спринт.
Среда QA должна использоваться в качестве среды для приемочных тестов, демонстраций или любого стороннего тестирования или аудитов (безопасность, локализация, нагрузка, удобство использования и т. Д.). Это не основной сервер тестирования Futurice (тест IS). Обновление в QA всегда согласовано между PMS клиента и Futurice.
Основная причина иметь две среды тестирования (тест и QA) - соответствовать требованиям безопасности и интеграции. Тест позволяет FutUrice разрабатывать сервис, используя гибкие принципы. QA позволяет клиенту и контролировать время для запуска своих текущих процессов QA.
QA не следует обновлять, если выпуск не пройдет тестирование в тестовой среде.
Среда Prod - это среда для живого сайта (производство).
Хорошая практика - развернуть и запустить автоматические тесты, по крайней мере, в QA, прежде чем настаивать на обновлении в PROD. Однако в PROD основные функциональные возможности должны быть проверены после каждого развертывания.
Рекомендуется, чтобы PO также имел право подтолкнуть обновление для Prod, без какого -либо тестирования в QA (если версия передается в тесте). Это актуально, когда обновление очень мало или просто.
В конечном счете, в гибкой разработке, когда услуга находится в постоянном развитии, цель состоит в том, чтобы иметь много небольших обновлений, чтобы продувать. Т.е. важнее, чтобы процесс развертывания был худым и быстрым, чем пуленепробиваемые. Считается более важным для того, чтобы иметь возможность быстро делать исправления, чем иметь услугу без ошибок (очевидно, с DOD и автоматическим тестированием качество также должно быть высоким). Futurice не рекомендует сразу же начинать с этого подхода. Тем не менее, это должно быть направление, куда обе организации хотят идти.
Каждая мобильная платформа имеет свою конкретную SDK, наборы инструментов и лучшие практики Futurice.
Для Android https://github.com/futurice/android-best-practices
Для iOS https://github.com/futurice/ios-good-practices
Для Windows Phone https://github.com/futurice/windows-app-development-best-practices
Мобильные платформы предоставляют эмуляторы в их SDK.
Во время фазы реализации разработчик может использовать моделируемые / эмулированные устройства для проверки изменений, но ничто не может превзойти реальное тестирование устройства, где рассматривается вся система с сенсорного экрана и интегрированной памяти в мобильные процессоры.
Мобильные браузеры также могут быть протестированы с помощью облачных сервисов, таких как BrowserStack.
Futurice имеет хороший выбор различных устройств и версий операционной системы в библиотеке устройств, от основных телефонов до расширенных планшетов.
Для тестирования приложений для приложений и проверки производительности Futurice используется тестовая лаборатория ELISA (ELISA является финским поставщиком мобильных услуг). В лабораторной среде различные нагрузки и скорости могут быть протестированы в контролируемой / изолированной среде без необходимости устроить дорогостоящие и не такие эффективные сеансы полевых испытаний.
Обычно мобильное приложение подключается к бэкэнд -сервису через мобильную сеть. Чтобы получить максимальную отдачу от тестирования, тестер должен иметь полный контроль над бэкэнд, в котором мобильное приложение подключено, чтобы подготовить и выполнить различные сценарии теста на конечную к конеду.
В мобильных устройствах может быть сделана установка тестовой сборки: локально по кабелю, используя разработку инструментов SDK, управляемых беспроводным образом с помощью инструментов распределения сборки, таких как TestFlight или HockeyApp. Выпуск фреймворков обычно поддерживает данные журнала сбоя и данные версий. Dev, Alpha и Beta Lelease также могут быть предоставлены для сбора обратной связи, прежде чем выпустить приложение в магазины. Google Play Store имеет возможность настроить группы Alpha и Beta Test, где конкретное приложение доступно только для участников группы
В современных мобильных приложениях аналитика и сбор данных представляют собой критическую функциональность, которая также требует тестирования. Футурик считает это важной частью функционального тестирования.
В связи с тем, что процесс обновления мобильных приложений отличается от веб -приложений, настройка Analytics должна получить прямо с первой попытки или затем пропущены ценные данные. Процесс обновления проводится с помощью процедур хранилища приложений, но будет ли обновление будет сделано или нет, зависит от настройки пользователя и деятельности. Поэтому, если первая версия пропускает некоторые критические функции аналитики, и некоторые пользователи никогда не обновляют приложение, эти данные будут пропущены. Решение может быть вынуждено обновлять, когда приложение станет непригодным для использования до тех пор, пока пользователь не обновится на новейшую версию, но это может быть слишком поздно.
