Проблеми з тестуванням на проекті для не QA
Вітаю! Я Ігор Берегівський, мені 26 років, п’ять з яких працюю тестувальником. Коли дізнався, що є така професія, одразу ж загорівся, оскільки з дитинства любив досліджувати, як працюють різні механізми й наскільки вони міцні. За час роботи в QA я встиг здобути сертифікацію ISTQB Advanced Level у тест-менеджменті, лідити команду із 14 тестувальників, менеджити частину відділу тестування, викладати курс із тестування й жодного разу не змінити компанію :)
У цій статті розповім, як тестування під час розробки допомогло нам — компанії Diligences — створити готовий до релізу внутрішній продукт, що переріс у своєрідний стартап. Стаття буде корисною для проджект/продакт-менеджерів, тімлідів і початківців у сфері забезпечення якості. Водночас для досвідчених QA я можу здатися Капітаном Очевидністю :)
Проблеми клієнтів під час тестування
Однією з особливостей моєї роботи є те, що, окрім розробки власних продуктів та аутсорсу повного циклу розробки програмного забезпечення, працюю на аутсорсі окремих активностей: тільки тестування, чи тільки девелопмент, чи інші активності. Зважаючи на специфіку роботи компанії, я стикався з різними клієнтами, і в кожного з них були свої проблеми з якістю, які вони самостійно вже не могли заменеджити.
Відсутність команди тестування
Можна подумати, що якщо у вас кращі девелопери на ринку, то ви завжди отримаєте bug-free-продукт, але насправді ні. Такий підхід працюватиме протягом деякого часу, на перших стадіях розробки. Чому? Тому що, яким би хорошим девелопер не був, він тестуватиме те, що продукт має робити. Водночас тестувати потрібно й те, що продукт не має робити, — вплив фіксів, нових фіч і зміни середовища на тестування.
До прикладу, на одному з проектів у нас було два абсолютно протилежні за стилем роботи розробники: один з них постійно перевіряв, чи його фіча працює на тестовому білді, а інший навіть не відкривав білд, що надсилав на тестування. У результаті білди від другого розробника досить часто крешились на відкритті, водночас і на білдах від розробника, що тестував самостійно, ми також знаходили щонайменше 5 багів у кожному тестовому білді.
Несвоєчасне тестування
Частина наших клієнтів уже мала команду тестування, але сам процес забезпечення якості й тестування відбувався досить пізно в процесі розробки (перед релізом чи після того, як фіча повністю готова). Це призводить до того, що набагато більше часу витрачається на пошук першопричин багів, знайдених командою тестування, і як наслідок — перенесення релізу.
Брак стратегії тестування
Це те, про що не всі тестувальники знають. У такому разі тестування відбуватиметься швидко, без структури, без можливості передбачити, що і як протестують. Чому це погано? Тому що за такого підходу метрики на проекті не будуть репрезентативними й у деяких випадках їх зовсім не можна буде побудувати, а також неможливо буде оцінити рівень якості продукту, а деякі зміни може бути не протестовано взагалі.
Надто багато розробки, надто мало виправлень
Коли у вас дуже багато фіч, які потрібно розробити, але ви не маєте часу для якості, це призводить до великої кількості багів, які не на часі. Але в найближчих релізах для них теж не буде часу й саме через розробку нових фіч. Ви можете сказати, що це не проблема, оскільки загалом фіча працює. Це так, але нині сервіси, які розробляють, не є унікальними, і користувачі з легкістю переходитимуть на якісніші сервіси, можливо, з дещо меншим функціоналом.
Triple W проблем
Усі ці проблеми я намагався об’єднати в групи triple W або ж у назву всім відомої гри What? Where? When?
Що тестувати
Передусім потрібно тестувати базовий функціонал ПЗ для того, щоб зрозуміти, чи доцільно тестувати конкретну збірку ПЗ (привіт Smoke test). Зрозуміти це можна доволі просто: якщо базовий функціонал buggy, продовжувати детальніше тестування сенсу немає. Після цього потрібно тестувати власне функціонал або зміни, що впроваджуються в програмне забезпечення, для того, щоб дослідити, на скільки якісно реалізовано ці зміни чи функціонал. Тестуйте пов’язаний функціонал, щоб не пропустити регресію, що може виявитися в досить неочікуваних місцях.
Де тестувати
Тестуйте на відокремленому середовищі. Відокремленому й від розробки, і від продакшену. Здебільшого це проблема на веб-проектах і на проектах, де багато чого залежить від бекенду. Погано це тому, що невідокремлене середовище постійно змінюватиметься внаслідок нових змін (баг-фіксів тощо). Найкраща ситуація, якщо у вас буде три розділених середовища: одне для розробки, ще одне для тестування й останнє — для продакшену.
Тестуйте на різних, наперед визначених комбінаціях софту й hardware: це допоможе вам не пропустити багів, специфічних для середовища. Особливо це стосується проектів для мобільних пристроїв.
Тестуйте на правильних збірках. Перед початком тестування потрібно пересвідчитися в тому, що ви тестуєте на правильних збірках, щоб не марнувати свій час.
Коли тестувати
Будь-який досвідчений тестувальник скаже вам прописну істину: тестування потрібно починати якомога раніше, у процесі розробки програмного забезпечення, але це буде неповна відповідь.
Вимоги. Досить багато багів закладено ще в самих вимогах, тому спочатку потрібно тестувати саме їх. Це можуть бути як типові помилки чи суперечності, так і використання ненативних дизайн-елементів системи, розробка яких триватиме набагато довше й з більшою кількістю багів, а також користувацький досвід, що веде в нікуди, чи брак елементів системи.
Розробка функціонала. Тестування не має відбуватися після релізу чи після того, як фіча повністю готова, особливо якщо вона досить велика. Тестувати потрібно в процесі розробки функціонала, що дасть змогу швидше й легше знаходити баги та першопричину. Найочевиднішим для мене є цей пункт: перед злиттям у master — для того, щоб мастер-гілка була завжди стабільною й готовою до релізу. Так буде легше створювати реліз-кандидати й вони будуть менш забагованими.
Тільки те, що ви почали тестування рано, не означає, що потрібно рано й закінчувати :)
Тестування до релізу. Тестуйте після злиття в мастер — так ви зможете швидше побачити регресію, а вона є практично завжди. Якщо ви тестуєте перед злиттям у мастер, після злиття в мастер, це не означає, що вам не треба тестувати реліз-кандидатів. Вам потрібно підготувати набори тестів для тестування реліз-кандидатів для того, аби бути впевненими, що продукт усе ще виконує те, чого від нього очікує користувач. Будуйте свої тести й набори тестів, базуючись на критеріях приймання, — так ви звертатимете увагу на те, що важливо для клієнта.
Як і в будь-якій компанії, що надає послуги щодо розробки ПЗ, у нас працюють люди, тому ми також мали багато факапів. Ось деякі з них:
- На одному з наших проектів ми пропустили тестування оновлення, тому додаток крешився відразу після оновлення, але в разі установки з нуля він не падав. Це призвело до збільшення кількості тикетів у підтримці користувачів.
- В іншому проекті не проводили тестування зворотної сумісності: після переходу на нову структуру бази даних старі дані не мігрували, однак, на щастя, ми виявили цю проблему перед випуском і виправили її.
- Не мали зв’язку з клієнтом: нікому не подобається, коли люди заважають їм запитаннями, але водночас клієнт не дав змоги отримувати інформацію за запитом.
Як це працює
Яскравим прикладом буде те, як ми починали розробляти один з наших продуктів як сайд-проект, який тепер переріс у продукт зі 100+ унікальними користувачами на день (крім працівників компанії). DueFocus — всеохопний трекер часу, який розробляли вільні від комерційних проектів деви і який з’єднується з більшістю менеджмент-систем та показує, на що й скільки свого робочого часу ви використовуєте.
Якось ми вирішили перетворити його на комерційний проект і почали з таких цифр:
- один місяць витрачали на реліз кожної фічі;
- 40% усіх багів перевідкривали;
- у беклогу було 74 мінорні баги й 6 major-багів.
І ми мали такий тестовий репорт:
Як бачимо, кількість багів зростала, але здебільшого вони не були критичними (за типом друкарських помилок і багів у користувацькому інтерфейсі). Загалом непогано, але фідбеки від бета-користувачів були жахливими.
Тому ми вирішили прилучити команду тестування, щоб визначити проблеми. Передусім ми визначили найважливіший функціонал для кінцевих користувачів і написали тестове покриття за цими випадками. Це стало нашим першим чеклістом, який ми почали використовувати для тестування перед кожним релізом. Також почали писати баг-репорти, що містили всю потрібну інформацію — Steps to reproduce, Version, Actual and Expected result, — і додали критерії прийняття до кожної фічі, яку розробляли. І ось що ми отримали:
Кількість багів зросла, і це дуже добре, оскільки це ті баги, які ми не бачили раніше. Тепер їх можна виправити.
Водночас ми й далі поліпшували процеси. Коли девелопери виправляли баги, ми почали тестувати не тільки їхнє виправлення, але й увесь модуль, що дало змогу виявляти регресію всередині модуля. Також після написання тест-кейсів ми отримали інформацію про те, як має поводитися продукт, і почали формувати документацію.
Після кожної ітерації ми отримували все більше й більше документації. Через що кількість тикетів, повернених як перевідкриті через непорозуміння, зменшилася. Тільки 10% тикетів були перевідкритими після наших змін у процесах :) Тут ви можете побачити динаміку зменшення кількості відкритих багів.
Усе було добре, але за деякий час бета-тестувальники знову стали скаржитися на нові баги. Ми почали досліджувати природу цих багів і зрозуміли, чому так стається, — конфлікти між модулями. Ми тестували тільки модуль під час змін, а нові баги виникали на перетині двох модулів.
Тому ми впровадили регресійне тестування всієї системи перед релізом для кінцевих користувачів. Звісно ж, час для релізу трішки збільшився, але врешті-решт ми отримували якісніший продукт. Також після кількох ітерацій ми зрозуміли, що мали проблеми із сумісністю кількох модулів, тому повністю їх переписали, і, як ви бачите, кількість багів почала зменшуватися.
Отже, наприкінці ми впровадили три процеси:
- Acceptance-тестування кожної фічі, яку було змерджено в dev stage.
- Smoke-тестування кожної збірки.
- Регресійне тестування перед кожним релізом на прод.
І ці три процеси допомогли нам поліпшити такі метрики:
- Період реалізації фічі зменшився до 1 тижня.
- Кількість перевідкритих тикетів знизилася до 3%.
- Кількість тикетів про баги в системі підтримки користувачів зменшилася із 40 тикетів на місяць до 5.
Ось такий приклад того, як 3 маленькі процеси можуть змінити користувацький досвід і пришвидшити процес розробки.
Підсумовуючи
На завершення я хотів би поділитися корисними порадами, які вам потрібно пам’ятати, коли ви тестуєте й розробляєте свій продукт:
Збирайте метрики — базову інформацію про рівень якості продукту, яка допоможе вам визначити найпроблемніші місця в додатку до того, як трапиться катастрофа.
Користуйтеся загальноприйнятою термінологією. Вам потрібно використовувати терміни, які визначено в стандартах ISO / IEEE та інших стандартах, щоб ви розмовляли спільною мовою з іншими. Так, вам потрібно припинити називати своє передрелізне тестування smoke-тестуванням, тому що smoke-тестування — це швидкий тест, щоб визначити, чи прийнятна збірка для подальшого тестування.
Не бійтеся змінювати. Процес і метрики — це не правила, які визначено раз і назавжди. Ви можете змінити їх, коли відчуєте, що вони не працюють для вас. Ідеальним прикладом може бути один з наших клієнтів, який кожні рік-півтора змінює всю організаційну структуру, щоб відповідати новим цілям компанії.
