Як і в багатьох інших стартапах у наших проектах, у перший рік існування народилися гори коду, які хоч і були непогано покриті unit-тестами, але все ж залишалися практично не охоплені з точки зору функціонального тестування. У перший час ми обходилися невеликим чек-листом. Проблем не виникало, поки на проекті було кілька тестувальників, які добре знають всі тонкощі проекту. Але, як це завжди буває, якщо одна людина з невеликої команди йде, то необхідно знайти йому адекватну заміну. І ось тут виникли великі труднощі.
Наш проект має дуже складну структуру: один тільки розділ може мати документацію більш ніж на 100 сторінок. Плюсом, звичайно, йде паровоз з недокументованих фіч і індивідуальних «хотілок» замовника, які члени команди-початківці можуть прийняти за баги.
На щастя, в нашій компанії існує і активно розвивається напрямок по роботі зі студентами та фахівцями-початківцями. Недолік з кадрами легко можна усунути, але ось як швидко підключити новачка до роботи? Було вирішено впровадити докладні тест-кейси, що описують весь набір функцій проекту. Для вирішення завдання на першому етапі ми вирішили не гнатися за платними рішеннями, а використовувати одну з безкоштовних систем управління тестами. Вибір припав на TestLink.
Впровадження
Сам TestLink написаний на PHP, і особливих проблем з установкою не виникло. Ми створили базу даних, дали права на татка, і установка пройшла як по маслу.
Далі ми завели в системі проект, створили структуру проекту і почали писати тести. Сама мета впровадження даної системи полягала в тому, щоб ми змогли виявити корисність або марність подібних систем для наших проектів.
Як ми використовуємо ресурси команди і TestLink
Після того, як ми написали і перевірили свої тести, настав час випробувати систему на людях. Ми розподілили готові тести серед початківців співробітників і стажистів. Перший же прогін показав, що використання докладних тестів дозволило знайти безліч багів в потаємних місцях проекту, куди зазвичай не дотягувалися руки в силу пріоритетності роботи інших фіч.
TestLink в даний час використовується не в повну силу. Він включає можливість використання не тільки тестів, а й умов. Використання умов бачиться дуже перспективною можливістю даної системи. Умови відносяться до тестів як багато до багатьох, що дозволяє реалізувати кілька наступних моделей використання:
- Зв'язати тести, що зачіпають один і той же набір функцій, однією умовою. Це дозволить ефективно і швидко створювати інкрементні прогони, наприклад, для гарячих виправлень.
- Винести в умови деякі обмеження, які мають бути досягнуті для вдалого проходження тесту.
З огляду на те, що наші тести поки не встигли обзавестися умовами, нижче ми не будемо про них згадувати.
Вплив TestLink на якість тестування
Якість тестування після впровадження TestLink, однозначно, зросла. Ми дуже вдячні цій системі управління тестами за докладні звіти після прогону тестів і за те, що вона познайомила нас з тим, як необхідно підходити до тестування. Зараз ми маємо непогану налагоджену систему тестування свого проекту, завдяки якій новий співробітник через буквально півдня буде повністю включений в роботу з проектом і, самостійно зробивши прогін всіх тестів, зможе зрозуміти до 80% функцій проекту.
Плюси і мінуси TestLink
Незважаючи на всі переваги, зіткнулися ми і з низкою недоліків системи. Природно, все дуже суб'єктивно, і для інших компаній наші претензії будуть здаватися необґрунтованими. Ми не виключаємо, що можливо, деякі з недоліків можна усунути, вивчивши документацію або покопавшись трохи в коді, але мета стояла трохи інша. Нам було необхідно швидко оцінити корисність подібної системи всередині нашої компанії.
Достоїнства:
- Розвинена система ролей. Дуже гнучко можна налаштувати доступи для різних співробітників і так само оперативно відняти ці самі права.
- Проста і зрозуміла система структурування проекту. Проект - Група тестів - Тест - Кроки (Ріс. 2).
- Легкий розподіл тестів між тестувальниками. Можна вибирати групи тестів або окремі тести, а також просто скопіювати розподіл тестів з минулого релізу (Рис. 3).
- Красиві звіти за прогонами в різних форматах, у тому числі з можливістю відправки поштою всім відповідальним і зацікавленим результатами співробітникам (Ріс. 4).
Недоліки:
- Немає посилань на окремі сторінки всередині системи. Замість того, щоб надіслати колезі посилання, доводиться називати проект, групу тестів і номер тесту.
- Проблема з верійністю тестів. У нашому випадку з типовими параметрами неможливо переглянути різні версії тестів з вікна прогону тестів або у розділі редагування, вибравши Compare versions.
- Інтеграція з Redmine. Вона є, але не вдалося її повністю налаштувати на роботу з нашим Redmine з ходу в обидва боки (необхідні або додаткові плагіни, або дозволи).
- Юзабіліті. Без підготовки не очевидно, які кнопочки натискати, щоб все працювало (Рис. 1).
Міні-огляд можливостей TestLink
Продемонструємо роботу системи на прикладах з наших проектів. Повний огляд системи робити не має сенсу. Основний посил, в даному випадку, спрямований на те, щоб показати, як виглядає система всередині, і чи зможете ви з нею ужитися або не варто навіть встановлювати. Тому ми опустимо етапи встановлення системи на сервер, а також етапи закладу проекту.
Перше, що бачить тестувальник, відкривши TestLink ‒ це стартовий екран (Рис. 1).
Ріс. 1 ‒ Стартовий екран роботи з проектом TestLink
Звідси починається будь-яка активність у проекті. Тут виконується:
- редагування/створення тестів;
- призначення користувачів, відповідальних за прогін;
- створення збірок;
- редагування параметрів самого проекту.
Сторінка редагування тестів включає такі можливості, як:
- створення/редагування нового тесту;
- створення/редагування групи тестів;
- робота з версіями тестів;
- створення/редагування кроків у тестах.
Ріс. 2 ‒ Редагування тестів у TestLink
Далі розглянемо розподіл тестів з тест-планів.
Для цього слід розбити тести на різні групи, які потім можуть використовуватися для прогонів, що підходять під задані умови. На малюнку 3 видно, що в даному випадку тести розподілені за видами тестування, які ми проводимо для обраного проекту. Для інших проектів у нас є різні варіанти розбиття на тест-плани, наприклад, на проектах, де немає поділу тестів по групах і потрібно кожен раз проганяти всі тести без винятку, ми завели тест-плани для Production і Staging оточень.
Ріс. 3 ‒ Редагування тест-плану
Призначати тести членам вашої команди дуже просто. У лівій частині вікна (рис. 4) можна вибрати як один тест, так і групу тестів, а також використовувати фільтри для пошуку потрібних тестів. Потім можна призначити тестрівника, відповідального за прогон конкретного тесту на конкретній платформі, за допомогою чек-боксів і випадаючих списків у правій частині розділу.
Ріс. 4 ‒ Розподіл завдань з тестувальників у TestLink
Після розподілу тестів прогін виглядає, як на малюнку 5. На ньому доступне наступне:
- Опис всіх кроків, які необхідно виконати;
- Поле для введення зауважень;
- Відмітка про пройденість тесту.
Крім перелічених елементів, можна побачити і додаткову інформацію:
- Попередні прогони;
- Платформа, на якій необхідно здійснити перевірку;
- Опис складання продукту;
- Опис тест-плану (не відображено на малюнку 5).
Ріс. 5 - Прогін тестів у TestLink
Відразу після розподілу тестів ми вже можемо спостерігати за появою даних щодо звітів тестувальників у розділі «Звіти» TestLink. У розділі показано багато параметрів:
- Стеження за результатами прогону;
- Експорт у популярні формати;
- Надсилання звітів поштою зацікавленим особам;
- Угруповання тестів за різними ознаками, представленими в лівій частині малюнка 6.
Ріс. 6 ‒ Система формування звітів про прогони в TestLink
Ув'язнення
Сподіваюся, наш досвід впровадження TestLink відкриє для вас нові горизонти. Можливо, хтось нарешті відмовиться від ведення документації в таблицях. Нам би хотілося почути в коментарях вашу думку про TestLink або про подібні розробки, як ви їх використовуєте, яка ступінь інтеграції ваших інструментів, що зручно і незручно.
