Статья «Как справиться с проблемами в унаследованном проекте после 3 других команд» рассказывает, через что пришлось пройти команде разработчиков, чтобы через полтора года получить достаточно стабильный программный продукт.
Здесь мы хотим рассказать, чем занималась команда тестирования, чтобы эффективно проверять все изменения, сделанные разработчиками, и гарантировать, что продукт соответствует ожиданиям заказчиков и конечных пользователей.
Унаследованный продукт без аналитиков, документации, процессов тестирования и в целом кишащий багами – настоящий вызов для любой команды. И привлечение тестировщиков к такому продукту было лишь делом согласия заказчика.
Хочется заметить, что изучение узконаправленной бизнес логики, да еще и для конкретного иностранного государства, может оказаться вещью весьма нетривиальной. На это можно смотреть, как если бы вы установили на машину американского инженера – 1С «Бухгалтерию» и попросили бы с ней поработать, причем именно так, как это делают русские бухгалтера.

1. С чего начать тестировщику, если есть только код.

Первое, что мы сделали, это внимательно изучили все возможные статьи и сайты, посвященные здравоохранению. Начиная с того, какие бывают стандарты обмена электронной медицинской информации, и заканчивая просмотром фотографий госпиталей, где установлено переданное в наши руки ПО. Конечно, мимо нас не прошли потенциальные конкуренты и просто приложения для голосовой расшифровки.
Вторым этапом знакомства с приложением было тесное общение с заказчиком. Благодаря перепискам и полученным наброскам help-документации (4 слайда презентации), нам удалось выявить несколько критичных моментов:

• Как происходит запись (девайсы, форматы аудио)
• Шаблоны писем, которые формируются из расшифровок, надиктованных врачами.
• Роли пользователей: Доктора, Секретари, Транскрайберы, Секретари-редакторы (следят за качеством текста), отдел печати
• Список интеграционных систем
• Общий ЖЦ документов

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



2. Саппорт как источник знаний.

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

3. Все должно быть максимально приближенно к реальности.

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


Philips LFH3200/00

DVR Philips DPM8000

Infinity foot control

Еще важным моментом для эффективного тестирования стали эмуляции интеграционных систем.
Мы старались минимизировать «черные ящики» во всем процессе тестирования и изучать, с какими исходящими данными работают сторонние сервисы. Например, Mirth Connector (интерфейс для работы с HL7 сообщениями), WinDip (система электронной документации), Docman (электронный сервис для отправки писем). Каждый сервис имеет свои форматы, и очень важно предоставлять им правильные данные для дальнейшей обработки.
Мы опирались на простое правило: чем ближе к реальности проводятся тесты, тем критичнее и важнее находятся баги, а следовательно, и само тестирование становится более эффективно.

4. Ищите лояльных пользователей.

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

5. End-to-End тестирование.

Одним из масштабных тестов для нас стало End-to-End тестирование. Оно означало провести полную проверку приложения, начиная от установки на чистую машину с драйверами для устройств и заканчивая распечатыванием писем и упаковыванием их в конверт. End-to-end тесты позволили нам четко понять, какие пробелы в знаниях по системе у нас все еще присутствуют, каких тестовых серверов нам не хватает и правильное ли мы имеем представление об админской части приложения.
Самое главное было воссоздать полную работу госпиталей, отправку документов на расшифровку, проверку этих работ, обработку писем с последующей распечаткой и пересылкой в различные интеграционные системы. Мы подбирали наиболее приближенные по размерам тексты, изучили статистику по размерам аудио, посмотрели, какие виды форматирования наиболее часто применяются в письмах. В общем устроили настоящую ролевую игру, осталось одеть только белые халаты.
Конечно же, после этого мы отправили наши отчеты заказчику, указав на наиболее значимые изъяны приложения, а также указали, каких еще данных нам не хватает для изучения систем.

6. Итого

Итогом данной работы был солидный отчет, объясняющий заказчику, как работает наша система и какие в ней имеются проблемы. Также мы добились осознанного тестирования, дополнив Jira (Zephyr) и Confluence многочисленными тест-кейсами (более 1000), чек-листами, спецификациями и даже юзер-гайдами (более 50 статей) для наших заказчиков.
Но самым главным достижением для нас стал тот факт, что заказчик нам стал доверять как экспертам и очень внимательно относится к нашим советам. Теперь ни одна спецификация не разрабатывается без нашего статического тестирования, а мы, в свою очередь, блюдем контроль, чтобы вся документация хранилась в актуальном состоянии в нашей вики.
В заключение хочется сказать, что это лишь малая часть всех мер, которые обеспечивают качественное, осознанное и самое главное юзер-ориентированное тестирование. Параллельно этим действиям происходят наладка процессов тестирования внутри команды, разворачивание автоматизированного тестирования, подбор инструментов, настройка и стабилизация тестовых стендов и многое много другое.
Здесь же показано, как можно проводить самый сложный этап – «Вхождение в проект» при минимальной поддержке со стороны заказчика, отсутствием аналитиков и с максимальной эффективностью.

Спасибо за внимание!