За качество ответит разработчик

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

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

Вопрос доверия

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

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

Для нас важно, чтобы клиенты понимали, как устроена кухня ИТ-разработки, и какие проверки проходит платформа «Эквио» перед каждым обновлением.

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

Зачастую бывает так: выбирая поставщика, смотрят только на сам продукт и цену.

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

Версии iOS и Android постоянно меняются. Это приводит к риску потери работоспособности приложений.

Подумайте сами, Apple кардинально обновляет версию iOS и выпускает новые мобильные устройства каждый год. Причем с момента первого обновления для новой версии iOS все последующие мини-обновления выходят чуть ли не ежемесячно. На февраль 2020 года текущая версия iOS уже 13.3.1. Минимум 10 небольших обновлений было после запуска iOS 13, и каждое из них могло сломать или внести сбой в мобильные приложения, которые установлены на смартфоне.

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

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

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

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

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

Совет: если поставщик и разработчик не готов подписывать SLA, лучше поищите другого партнёра.

Тестирование: мануальное, автоматическое, нагрузочное

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

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

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

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

К каждой команде разработчиков (у нас пять отдельных команд разработчиков работают над продуктом) прикреплено 1 или 2 мануальных тестировщика (ручное тестирование), которые чередуются каждые три месяца. Это нужно для того, чтоб исключить «замыливание глаз». Тогда у людей появляется свежий взгляд на проблему. Например, новый специалист всегда находит какие-то необычные баги.

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

Да. Это когда в Икее робот нажимает на стул: имитирует, как человек садится. В итоге получается, что каждый стул проходит 20 000 исследований и тестов, а покупатели получают гарантию качества этого стула.

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

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

Особенность платформы «Эквио» в том, что мы выдерживаем пиковые нагрузки, когда большое количество пользователей одновременно заходит в приложение. Мы видим, что во время таких нагрузок система ведёт себя по-другому, например, начинает медленнее работать. Автотесты проходят с нагрузочным тестированием, чтобы проверить платформу: как она работает в такой ситуации.

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

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

Независимый отдел качества и правильные конфликты

С 1 сентября 2019 года мы провели небольшую реорганизацию: ввели отдельный независимый отдел «Качества и релизов», который занимается исключительно контролем качества и одобрением нашей программы к релизу. Для этого мы организовали школу тестировщиков в Волгограде. По результатам этой школы мы набрали 5 специалистов.

На сегодняшний момент 12 человек занимаются тестированием «Эквио» (автотестами, нагрузочным и мануальным). Ещё 10 человек работают в колл-центре ― первой линии технической поддержки. К ним обращаются администраторы и пользователи при вопросах и подозрениях на баги.

Зачастую компании-разработчики вообще не имеют выделенных тестировщиков. Проверку проводят менеджеры по продажам, когда сдают проект. Это, конечно, экономно, но рискованно. Такая экономия несёт клиенту скрытые угрозы.

При выборе ИТ-решения обязательно выясните, как организован процесс тестирования продукта.

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

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

Таким образом у нас есть стальной щит и разумный конфликт интересов. Как бы менеджер по продажам не хотел быстро сдать проект клиенту и получить свою премию, наш отдел качества не даст разрешение, пока не будет уверен в надёжности продукта.

Система логирования

Чтобы всё происходило корректно, мы собираем данные о действиях пользователя ― делаем резервное логирование действий пользователя.

Логирование действий пользователя ― это сбор и запись данных обо всех действий пользователя, а также проблемах, если они возникали во время работы приложения. Это нужно для того, чтобы потом посмотреть дублирующую статистику. Иными словами, при логировании идёт параллельная запись статистики, чтобы ничто не потерялось.

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

Первая линия поддержки

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

Первая линия техподдержки стоит на защите интересов пользователей и администраторов «Эквио».

В стандартной IT-истории это называется первой линией поддержки, службой быстрого реагирования. На практике 95% проблем ― это пользователь просто что-то не понял. Остальные 5% ― это подозрение на баг или какая-то нестандартная ситуация, где необходимо вмешательство службы качества. В этом случае служба технической поддержки узнаёт, при каких обстоятельствах появился баг. Мы смотрим, когда пользователь последний раз входил, с какого устройства, на каком интернете, в общем всё, что там было (как раз тут и важно логирование действий пользователя, о котором мы говорили выше).

Например, у нашего клиента был случай: руководители заподозрили подвох в отличной сдаче тестов сотрудниками, буквально на 100%. Оказалось, что работники сделали WhatsApp чат и вывешивали туда результаты ― скрины. То есть каждый ученик сдавал тест, закрывал приложение, подсматривал результаты (ответы) в чате по скринам. Наконец, находил нужный скрин и возвращался в приложение, ставя галочку в нужном месте. Мы выяснили причину очень просто. Включили жёсткий режим тестирования: пользователю было запрещено уходить с экрана теста. Если он закрывал-открывал экран, начинал звонить другу с просьбой, как ответить на какой-то вопрос, то это ему не удавалось.

Задача разработки ― настроить процесс таким образом, чтобы выучить урок было проще и удобнее для пользователя. Это исключит любые методы обмана, которые всё равно раскроются. Мы всегда можем предоставить детальную информацию руководству компании по запросу. В этом заключается надёжность подрядчика и стремление к высокому уровню доверия.

Поддержка администраторов

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

Зачем было всё это читать?

Я приоткрыл нашу внутреннюю кухню разработки и честно рассказал, как устроена техподдержка, как мы относимся к тестированию и качеству. Хочется, чтобы бизнес-заказчики были более подкованы в вопросах ИТ, умели просчитывать на несколько шагов вперёд и задавали разработчикам правильные вопросы «на берегу». Очень расстраивает, когда клиенты вообще об этом не думают.

Относитесь серьезно и ответственно к выбору ИТ-партнёра. Сбой может затронуть весь организм вашей компании, всерьёз и надолго.

Чек-лист. Вопросы к разработчикам при выборе ИТ-решения:

• Кто и как тестирует приложение?
• Есть ли техподдержка?
• Как принимаются обращения пользователей: по телефону, почте, в мессенджерах?
• Сколько линий техподдержки есть и их обязанности?
• В какой срок исправляются баги?
• Готов ли разработчик подписать гарантии по устранению багов (SLA)?
• Готов ли разработчик мобильных приложений нести ответственность за поддержание работоспособности при будущих обновлениях iOS и Android?
• Добавьте свои вопросы.