Впровадження Альфа тестування і альфа лабораторії в проектах

У сучасному світі IT ми повинні бути готові адаптувати і покращувати наш процес постачання високоякісного продукту. Тестування є найважливішою і трудомісткою частиною в життєвому циклі розробки. Є багато методик і технік, які дозволяють ефективно виконувати тестування. Але іноді й вони не рятують від негативної реакції замовника. Замовник залишається незадоволеним, дивиться на сторону конкурента.

У моїй практиці є декілька яскравих прикладів. Давайте їх розглянемо.

Кілька років тому ми розробляли фічу для дзвінків з локальної АТС на мобільні пристрої. Ідея полягала в тому, щоб наш замовник отримував доступ до функціональності АТС зі свого мобільного пристрою за коштами IVR-меню. Часу і сил ми витратили пристойно. Після офіційного релізу ми були впевнені, що замовник заплаче від розчулення. Яке ж було дізнатися, що наша реалізація йому здалася занадто складною. Ну не хотів чекати по 40 секунд поки «залізна» леді пояснить йому, що наступним натискати — 1, 2 або 3. В результаті цей функціонал доопрацьовувався і не став популярний у замовника.

Інший яскравий приклад – це назва прапорів у нашому додатку. Зібралися якось разом канадець французького походження, американець і росіянин і давай писати назви полів в інтерфейсі. У результаті британський замовник зажадав все переробити.
В обох прикладах ми витратили додатковий час і сили.

Що ж ми робимо? На мій погляд, існує кілька основних причин: погані вимоги, відсутність експертизи, малоефективні тест плани, складний продукт, невірна оцінка, відсутність процесів.

Як же ми можемо виправити ситуацію? Кожен проект застосовує певні стандартні практики. Ви можете запланувати додатковий час, додаткові тести в QA команді, проводити суворе рев'ю коду. Але не завжди вони призводять до бажаного результату.

Як варіант оптимального рішення, я розглядаю впровадження альфа тестування в проектах будь-якої складності. Це ефективний спосіб проведення тестування та нарощування командного експертизи.

Під Альфа-тестуванням прийнято розуміти імітацію реальної роботи з системою штатними розробниками або тестерами, або реальна робота з системою потенційними користувачами/замовником. Найчастіше альфа-тестування проводиться на ранній стадії розробки продукту, але в деяких випадках може застосовуватися для закінченого продукту в якості внутрішнього приймального тестування. Хочу відразу обмовитися, я поділяю QA тестування і Альфа тестування. У мене в проекті є програмісти, тестувальники, технічна підтримка, архітектори, і є окрема команда з альфа тестування. Фокус цієї команди — це знаходження помилок під час щоденного використання нашої системи. Цій команді не потрібно робити по 100 тестів в день. Вони думають про якість продукту, а не про метрики.

А тепер від слів до справи. Я пропоную перейти до побудови ефективної альфа лабораторії у вашому проекті. Принадність альфа тестування полягає в тому, що тестування йде безперервно. Ви і ваші колеги використовуєте ваш софт або залізо кожен день, імітуючи при цьому поведінка реального користувача. Але для того, щоб провести таке тестування ефективно вам необхідно формалізувати цей процес.

Я розділила практичну частину на 10 основних кроків. Давайте детально розглянемо кожен крок.

Крок 1. Перший і найважливіший крок-це визначення інфраструктури. Потрібно визначити доцільність такої лаби, є досить часу на її розгортання, навіщо вона взагалі потрібна у вашому проекті, чи є у вас необхідні кошти. Ну що визначилися, тоді давайте продовжимо.

Крок 2. Я вважаю, що дизайн і QA команди відповідають за правильність та адекватність вимог. Вимагайте від архітекторів складати вимоги для кожного продукту і релізу, працюйте з бізнес-аналітиками. Проводите рев'ю у себе в команді і надсилайте вимоги назад, якщо вони незрозумілі. Загалом, займіть активну позицію в цьому питанні.

Крок 3. На кроці номер 3 потрібно продумати майбутню лабораторію. Визначте перелік необхідного заліза і софта, намалюйте схему майбутньої лабораторії, заплануйте час.

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

Крок 5. Потрібно узгодити вашу ідею з замовником. Замовником в цьому випадку може бути або ваш безпосередній керівник, його бос чи зовнішній інвестор. Гроші на лабораторію та проведення тестування потрібно виділити.

Крок 6. Наступний важливий крок — це вибір прайму для цієї активності. Не поспішайте і подумайте тричі. Він повинен бути спокійним, організованим, комунікабельним і допитливим людиною.

Крок 7. У вас з'явився прайм, пора подумати про тестовій стратегії і тестах. Використовуйте стандартні темплейти. Обов'язково потрібно подумати над: технічними ризиками, активностями, фічами для тестування, інструментарієм, термінами.

Крок 8. Ось ми і підійшли до виконання тестів. Проведіть цей тестовий прогін як можна ефективніше. Я рекомендую використовувати різноманітні техніки тестування. Наприклад, specification-based, usage-based, fault-based techniques.

Крок 9. Окремої уваги заслуговує звіт. Вам він необхідний, для того щоб зробити висновки про результати тестування і про якість продукту. Ми збираємо статистику дзвінків, конференцій і використаним фічами. Всі знайдені баги теж йдуть у цей звіт.

Крок 10. Ми на фінішній прямій. Будь-який процес необхідний нам для того, щоб поліпшити якість програмного забезпечення. Альфа лабораторія це можливість бути на крок попереду і передбачити реакцію кінцевого користувача. Дуже важливо від релізу до релізу цю лабораторію розвивати. Тому не лінуйтеся, продумайте і заплануйте наступне: обов'язково проведіть ретроспективу, зробіть рев'ю вимог для нового релізу, створіть нових користувачів.

В рамках нашої компанії ми вже впровадили таку лабораторію для одного з наших замовників. І я можу сказати, що ми бачимо дуже позитивний ефект. Ми змусили програмістів використовувати їх код. Знайшли 80 багів за один рік, краще стали розуміти вимоги і бажання замовника, більше конструктивного спілкування з технічною підтримкою. Важливим результатом є те, що ми знизили кількість багів, знайдених на бета-тестуванні і на сайтах замовника.

Загалом, ми спробували і всім радимо. Дерзайте!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.