DOU Проектор: TestCaseLab – інструмент для QA фахівців - SEO Blog - все про пошукову оптимізацію та веб розробку українською.

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) Команда тестувальників побувала в ролі якихось Вимога Managers;
5) Керівництво зі свого боку зрозуміло, яке це бути замовником проекту;
6) Будемо в майбутньому використовувати отриманий досвід у зовнішніх проектах;
7) Є продукт, яким можна пишатися!

Сподіваємося, що дана стаття буде корисна, і ви зможете уникнути згаданих вище помилок, розробивши свій цікавий продукт.

Спасибі всім за увагу та запрошуємо безкоштовно спробувати . Також будемо вдячні за відгуки та пропозиції.

Опубліковано: 09/06/16 @ 10:36
Розділ Різне

SEO Блог