Как проходит тестирование программного обеспечения в нашей компании

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

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

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

Цели и задачи тестировщика

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

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

Скажем, кто-то запустил приложение на стареньком Huawei, и поехала верстка — смотреть страшно. Или его установил пользователь из Саудовской Аравии и ничего не понял, потому что в этой стране текст читается справа налево, а интерфейс под это не адаптирован (вам наверняка вспомнился известный пример треска рекламной кампании Coca-Cola по этой причине, но знайте — это обман. Несколько лет назад этот кейс распространился по всему интернету, многие авторы включали его в самые ужасные провалы рекламных кампаний за всю историю, но это не подтверждается ни одним авторитетным источником).

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

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

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

 
Задачи тестировщика:

  • Выявить баги и ошибки, описать и отправить на доработку. Хотя обычно приоритеты задач на устранение багов расставляет менеджер проекта, в нашей компании это часто делает тестировщик.
     
    Когда время сильно ограничено, заказчик также может принимать участие в процессе, например, определять, что надо исправлять в первую очередь.  
  • Проверить сделанные доработки.
  • Протестировать продукт заново — и так до тех пор, пока не будет получен нужный результат.
  • Проверить продукт на всех требуемых устройствах и разрешениях экрана — для этого формируется список устройств параметров окружения, который позволит покрыть тестами необходимые версии операционной системы, разрешения экрана и т.д.
  • Проверить работоспособность продукта в различных условиях, включая использование основной функциональности системы и проверку различных вариантов ее нестандартного использования.
  • Протестировать соответствие продукта требованиям.
  • Проработать все нетипичные кейсы и проследить, что продукт функционирует как задумывалось.
     
    Проверяются нестандартное использование системы, границы переполнения массивов данных, нелогичное кликанье по кнопкам и набор символов (например, на находящемся в портфеле смартфоне сработал сенсор, открылось приложение и произошел беспорядочный набор огромного числа символов).
  •  
    Может возникнуть впечатление, что тестирование программного обеспечения занимает уйму времени, но это не совсем так. Если процессы разработки и коммуникаций хорошо поставлены и специалисты знают свое дело, задержек быть не должно.

    Чтобы вникнуть в наш процесс тестирования, давайте пройдемся по всему циклу создания продукта в OZiTAG.

    Этапы разработки программного решения в OZiTAG

    • Начало работы — прием и обработка заявки от клиента, сбор и изучение требований.
    • Анализ и утверждение требований — участвуют бизнес-аналитик, менеджер проекта, лид-разработчик и лид-тестировщик. Цель данного шага — вникнуть в задачи заказчика, изучить требования к продукту, выявить в них ошибки и недочеты, предложить альтернативные решения. 
       
      Для этого QA-специалист проводит тестирование требований, которое представляет собой их обработку, формулирование списка вопросов заказчику, внесение правок и рекомендаций.
       
      Затем менеджер проекта согласует конечный вариант с заказчиком. Также 
      в данный этап работы входит составление мокапов и варфреймов для наглядной фиксации требований и визуализации будущего решения. Они же служат подспорьем при отрисовке дизайна.
    • Планирование работы — оценка объема работы и времени, разделение на итерации, формирование списка задач для команды. 
       
      От планирования зависит дальнейший ход и успех проекта, т.к. именно на этом этапе мы ищем лучшие пути достижения целей клиента, продумываем, что и как надо сделать и фиксируем это в списке задач. Впоследствии по этому списку мы контролируем достижение целей, выполнение задач, укладывание в установленные сроки.

    • Дизайн — отрисовка, тестирование, утверждение с заказчиком. В рамках тестирования изучаем удобство (юзабилити) интерфейса программного решения, проверяем дизайн на соответствие требований.
    • Разработка продукта реализация программного решения согласно функциональным и нефункциональным требованиям.
    • Тестирование и отладка — проверка разработанного продукта, исправление багов, подготовка к релизу.
    • Запуск проекта — публикация приложения в магазинах / запуск сайта / интеграция продукта с системами компании заказчика.

    software testing process

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

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

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

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

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

    Пока разработчики пишут код, тестировщики составляют тестовую стратегию, пишут чек-листы и тест-кейсы — так называемые артефакты тестирования, и определяют, для каких “зон” функциональности необходимы тест-кейсы, для каких чек-листы, а где достаточно исследовательского тестирования (exploratory testing).

    Исследовательское тестирование — подготовка и выполнение тестов в одно и то же время. Данный вид тестирования не требует написания тест-кейсов и применяется для проверки критических участков системы в маленьких и небольших проектах или когда мало времени на прохождение тестов.  

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

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

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

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

    Процесс тестирования ПО в нашей компании

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

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

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

     
    При создании программных решений используются как минимум 3 различных окружения:

    • Dev — предназначен для разработки и тестирования новой функциональности, используется только разработчиками ПО.
    • Test (stage) — используется для проведения тестирования силами QA-специалистов и другими лицами (в том числе и заказчиками).
    • Release — служит для непосредственной эксплуатации программного решения — это то, с чем работает клиент после выхода продукта.

    environments

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

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

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

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

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

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

    Test (stage) — в работу вступают QA-инженеры. Собирается тестовый билд, настраивается тестовое окружение. Чтобы работа команд разработчиков и тестировщиков не конфликтовала, работа QA выносится на тестовое окружение, он же тестовый сервер.

    Далее проводится общая проверка билда — инсталляционное тестирование. На данном этапе проверяется корректная установка и деинсталляция билда.

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

    А теперь взгляните, как проходит тестирование каждой отдельной фичи!

     
    Жизненный цикл тестирования фичи выглядит следующим образом:

    • Разработчик поставляет реализованную фичу на тестирование.
    • QA инженер тестирует разработанную фичу.
    • На каждый обнаруженный баг тестировщик заводит баг-репорт. Также он может написать рекомендацию к фиче, которая утверждается клиентом и менеджером проекта.
    • Расставляются приоритеты багов и фич. Определяется, что идет в следующую итерацию разработки и что требует исправления в текущем спринте.
    • Отладка продукта — команда разработки фиксит баги и собирает билд.
    • Тестирование фичи. Если выявлены баги, процесс тестирования и отладки повторяется. Когда все отлично работает, фича помечается, как реализованная.
    • Когда готовы все фичи, релизная сборка проходит регрессионное тестирование.

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

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

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

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

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

     
    Функциональные тесты могут быть представлены на всех уровнях тестирования:

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

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

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

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

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

    Для их проверки проводится нефункциональное тестирование, при котором оценивается качество продукта в целом.

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

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

    Еще один вид тестирования, без которого не обойтись — альфа-тестирование. Главная цель — выявить наиболее критические ошибки в коде.

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

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

    Далее приложение/сайт/система переходят в release окружение. На данном этапе проводится бета-тестирование — проверка бета-версии, т.е. продукта, фактически готового к релизу.

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

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

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

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

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

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

    Даже ранее лояльный Google Play постоянно ужесточает правила публикации. Поэтому наши специалисты отслеживают требования сторов и их обновления, проверяют продукт на их соответствие, тестируют UI/UX, а также смотрят требования в разных странах.

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

    • Тестирование требований
    • Unit-тестирование
    • Дымовое (smoke) тестирование
    • Инсталляционное тестирование
    • Тестирование критического пути
    • Исследовательское тестирование
    • Функциональное тестирование
    • Нефункциональное тестирование
    • Регрессионное тестирование
    • Альфа-тестирование
    • Бета-тестирование

    Основные инструменты, которые мы используем для тестирования ПО

    Postman — набор инструментов для тестирования API — программного интерфейса приложения. Помогает протестировать функциональность до внедрения API в клиентское приложение.

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

    Postman+Newman+Jenkins — данная комбинация технологий применяется для автоматизации тестирования API. Планируем внедрить в ближайшем будущем.

    Cucumber+Appium — используется для автоматизации тестирования мобильных приложений.

    Charles — позволяет мониторить HTTP/HTTPS трафик. Программа работает как прокси-сервер между мобильным приложением (в нашем случае) и сервером этого приложения. Charles записывает и сохраняет все запросы, которые проходят через подключенный к нему телефон, и позволяет их редактировать.

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

    Пол, возраст и стаж — параметры, а PICT будет применяться для проверки их значений. В другом кейсе может быть не 3 параметра, а 50, а число их комбинаций — достигать тысяч).

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

    Apache JMeter, ЯндексТанк — применяем для тестирования производительности приложения.

    JUnit, NUnit — применяются для написания unit-тестов.

    Fiddler — используется для тестирования запросов и сервисов.

    Pixel Perfect — расширение браузера, которое помогает при тестировании верстки.

    Burp Suite — отличный инструмент для тестирования безопасности системы.

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

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

    В заключение

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

    Помните, что даже мощная маркетинговая компания не поможет вам достичь успеха. Да, сначала вы привлечете много пользователей, но они тут же сбегут при наличии багов, сторы быстро заполнятся плохими отзывами, а life-time value будет на нуле.
     
    Если у вас есть вопросы по тестированию ПО или нужна команда опытных QA-инженеров, пишите нам! Консультация бесплатна, свяжитесь с нами прямо сейчас!

Поделиться

Последние статьи

The foundation of OZiTAG, a custom web development company

Как мы применяем Непрерывную Интеграцию и Непрерывное Развертывание для автоматизации разработки ПО

8 способов применения Интернета вещей в производстве

OZiTAG признана лидирующей компанией по мобильной и веб-разработке

Штатный дизайнер vs дизайн-студия: Почему мы выбрали второе и что лучше для клиента

Как мы запустили социальную сеть для создания, поиска и посещения мероприятий

Как проходит тестирование программного обеспечения в нашей компании

OZiTAG выступила партнером студенческой IT Олимпиады Bit-Cup 2018!

Как IoT-проект Neurosonic привлек клиентов из США, Европы, Азии, Великобритании на Orgatec

Как мы создали IoT-решение для управления продуктами & релаксации