DOU Проектор: TestCaseLab — инструмент для QA специалистов

В рубрике DOU Проектор все желающие могут презентовать свой продукт (как стартап, так и ламповый pet-проект). Если вам есть о чем рассказать — приглашаем поучаствовать. Если нет — возможно, серия вдохновит на создание собственного made in Ukraine продукта. Вопросы и заявки на участие присылайте на [email protected].

Идея

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

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

И тогда возникла идея: «А давайте попробуем запилить свою систему и ей пользоваться». Стоит попробовать! Профиль компании, специализация разработчиков, опыт разработки разносторонних веб-систем и, самое главное, желание — все толкало команду провести такой эксперимент и побыть самим в пресловутой роли «заказчика».

Реализация

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

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

Урок № 1: Хотя требования и были написаны, схемы нарисованы, ресурсы выделены — никто изначально не сделал более-менее точных эстимейтов по разработке и не поставил лимитов человеко-часов, которые компания готова выделить. Не смотря на то, что было сделано множество внешних проектов, это был первый внутренний проект/продукт.

Для реализации проекта был выбран следующий стек технологий: RoR, AngularJS, PostgreSQL, Redis, faye. Большая часть разработчиков до этого практически не имела опыта разработки на AngularJS (работали на Backbone). Но технология популярная, спрос среди клиентов на нее есть, поэтому решили воспользоваться случаем и прокачать скиллы.

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

Урок № 2: Недостаточно жесткий контроль, возникновение новых требований и меняющийся воркфлоу. В компании появлялись новые проекты и завершались старые, происходила ротация разработчиков. Как итог: разные стили написания кода и разные подходы к решениям тех или иных задач.

Первый прототип

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

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

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

Подготовка к выходу на внешний рынок

После того, как продукт стал достаточно стабилен, команда тестировщиков подтвердила, что им удобно пользоваться. Был произведен анализ конкурентов: их цены, предоставляемые фичи и ограничения по подпискам. С этого момента, продукт встал на «коммерческие рельсы».

К проекту были дополнительно привлечены дизайнер, верстальщик и постоянный менеджер, и, начиная с декабря 2015 — января 2016, проект вступил в новую активную фазу. Были поставлены следующие задачи:
1) Исправить недочеты в различных местах;
2) Разработать новый дизайн системы, не меняя общего UX (попросту сделать красивее);
3) Разработать посадочную страницу: дизайн с нуля + верстка;
4) Обновить верстку системы;
5) Разработать логику платных подписок и внедрить платежную систему;
6) Несколько новых небольших фич + общие мелкие улучшения.

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

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

Урок № 3: При работе над новой логикой подписок + внедрением платежных систем постоянно возникали новые идеи и предложения их реализовать. При работе на внешних проектах все разработчики и менеджеры компании уделяют много внимания важности написания юнит-тестов при разработке всех блоков. Здесь же этому уделялось не так много внимания (возможно, потому что постоянно менялись сотрудники). Как итог: многие новые изменения нарушали работу старой логики и вылезали неприятные баги.

Продакшн

К середине апреля 2016 продукт со всем необходимым функционалом был готов. Все последние разработки были в продакшне: закрыли обнаружившиеся дыры в безопасности, устранили найденные баги, применили неоднократно изменявшуюся логику подписок и, конечно, реализовали новый дизайн + посадочную страницу.

Готовый продукт стал выглядеть так:

Результаты

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

Итоги:
1) Было потрачено солидное количество человеко-часов;
2) Было наступлено на солидное количество «граблей» и найдены решения, как избегать подобных проблем в будущем;
3) Большая часть сотрудников компании получила очень интересный опыт разработки продукта «для себя»;
4) Команда тестировщиков побывала в роли неких Requirements Managers;
5) Руководство со своей стороны поняло, каково это быть заказчиком проекта;
6) Будем в будущем использовать полученный опыт во внешних проектах;
7) Есть продукт, которым можно гордиться!

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

Спасибо всем за внимание и приглашаем бесплатно попробовать TestCaseLab. Также будем благодарны за отзывы или предложения.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU