Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Що таке ефективний процес STLC — розповідаю на прикладі продуктової команди

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Всім привіт! На зв’язку Богдан Бацмай, Manual QA Engineer з продуктової IT-компанії Universe. Маю понад три роки досвіду в тестуванні, працював у більше як десяти веб та мобайл-проєктах в сферах social casino, enterprise, e-commerce та utilities, з яких в чотирьох проєктах брав участь в створенні продукту з нуля.

Починав занурюватись у світ тестування з web-напряму та поступово перейшов в mobile-тестування в компанії Universe. Зараз я в команді, яка займається створенням утиліт, постійно в розробці 7 продуктів, тому тема побудови правильного процесу тестування для нас дуже важлива.

Сьогодні хочу поговорити про побудову процесів тестування на проєкті, які забезпечать якісний вихід релізу в попередньо визначені терміни. Ця стаття буде цікавою для QA Engineer будь-якого рівня, оскільки побудова флоу STLC є базою у світі тестування.

Розберімось спочатку з терміном STLC. Отже, життєвий цикл тестування програмного забезпечення (STLC) являє собою набір процесів, які відбуваються один за одним, що дозволяють забезпечити якість продукту на високому рівні.

Всі ці процеси імплементуються в загальний флоу розробки продукту, тому вони є невід’ємною частиною етапів розробки програмного забезпечення (ПЗ). Правильно налаштований флоу STLC дозволяє оптимізувати роботу технічної команди для ефективного використання часу протягом підготовки релізу.

Що ж таке хороший процес життєвого циклу тестування програмного забезпечення? Та як його побудувати, щоб не виконувати зайву роботу? Розповім на прикладі побудованого флоу нашої продуктової команди.

Під час формування процесу тестування в життєвому циклі розробки ПЗ ми враховували наступні фактори:

  • обмеження в часі;
  • відсутність задокументованої звітності;
  • включення команди тестування на ранніх стадіях розробки ПЗ.

Такі умови були сформовані нашою командою для швидкого та ефективного виходу кожного релізу.

Тож, на основі вищеперелічених факторів ми сформували флоу з наступних етапів.

Перший етап. Аналіз вимог

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

  • команда QA залучається на першу зустріч з обговорення певної гіпотези, на якій відбувається попередня валідація ідеї для впровадження в наступному релізі додатка. QA Engineer вказує на корнер кейси або не врахований функціонал при проєктуванні гіпотези, і таким чином допомагає Product Manager дізнатись більше контексту про технічну сторону створення функціонала.

На даному етапі QA Engineer вже розпочинає аналізувати технічне завдання, формувати тест-план та визначає user-кейси, які необхідно буде протестувати в майбутньому релізі. Ще однією перевагою включення команди тестування є те, що на такій ранній стадії QA Engineer вже попередньо оцінює трудовитрати на поточний реліз та може чітко сформувати ризики щодо виконання технічного завдання.

На основі зауважень та пропозицій інших членів команди, Product Manager формує технічну документацію з описом реалізації функціоналу та передає її на етап QA Review — процес, на якому відбувається валідація технічної документації тестувальником.

  • Після отримання технічної документації (ТЗ) QA Engineer розпочинає процес QA Review. На даному етапі тестувальник проводить детальний аналіз всієї документації, щоб була чітко описана кожна вимога, що, відповідно, зекономить час розробки необхідного функціоналу. Для якісної валідації ТЗ необхідно змоделювати майбутній функціонал та розібрати кожен пункт документації для виокремлення неописаного функціоналу та корнер кейсів. Обов’язками QA Engineer на цьому етапі є також і перевірка того, що абсолютно всі необхідні ресурси вже наявні для виконання розробки функціоналу.

Product Manager виконує коригування технічного завдання після внесених правок зі сторони QA Engineer та повертає оновлену документації на повторний процес QA Review.

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

Підсумуємо: аналіз вимог є дуже важливим етапом в життєвому циклі тестування програмного забезпечення оскільки він допомагає виявити велику частину неточностей чи дефектів на ранньому етапі життєвого циклу розробки програмного забезпечення (SDLC). Все ж інвестування часу в проведення процесу валідації ТЗ шляхом залучення команди QA дозволяє не зупинятись під час вже самої розробки і максимально коректно проестімувати вихід релізу.

Другий етап. Написання тестової документації

На цьому етапі створюється технічна документація для якомога більшого покриття всіх вимог, що описані в ТЗ. В залежності від типу проєкту та часових рамок для виходу релізу розрізняють різні типи тестової документації, що використовується під час тестування: тест-кейси, чеклісти, user-кейси та інші.

Після передачі технічного завдання в розробку девелоперам, розпочинається етап написання тестової документації.

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

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

Третій етап. Виконання тестування додатка

Даний етап розпочинається після того, як команда девелоперів передала першу частину реалізованого функціоналу на тестування. Розробник віддає новий функціонал частинами і в такому разі QA Engineer розпочинає процес тестування після встановлення додатка на девайс. В нашій команді QA Engineer абсолютно автономно працює, оскільки самостійно стягує необхідні дані з віддаленого репозиторію та встановлює додаток на девайс за допомогою Xcode. Такий підхід дозволяє ефективно виконувати тестування, оскільки тестувальнику не потрібно очікувати готовий білд від девелопера.

QA Engineer розпочинає тестування з використанням попередньо сформованої тестової документації. Спочатку тестування відбувається в девелоп-середовищі. Перевагами девелоп-середовища можна виокремити безпечність для тестування, тобто воно не є повністю ідентичним продсередовищу, та можливість здійснювати тестові оплати за допомогою Sandbox-юзерів.

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

Тестування препрод версії є аналогічним до тестування девелоп-середовища, лише додаються перевірки встановлення та оновлення додатку. Особливостями препрод-середовища є те, що воно є абсолютно ідентичним до продсередовища, яким користуються кінцеві користувачі з App Store, тобто для тестування такої збірки з TestFlight використовуються ті ж ключі та ендпоінти, що і в останньому продрелізі.

Закінчення етапу тестування додатка відбувається після того, як QA Engineer пересвідчився, що в препрод версії немає критичних багів. Потім тестувальник передає Delivery Manager збірку для подальшого відправлення на рев’ю в App Store.

Після опублікування нової версії додатка на продсередовищі QA Engineer повинен здійснити смоук-тестування нової збірки. Таким чином, тестувальник перевіряє додаток зі сторони кінцевого користувача та виконує основні перевірки функціонала додатка, щоб пересвідчитись у відсутності несправностей на продсередовищі.

Четвертий етап. Підтримка продукту

QA-команда повинна постійно відслідковувати актуальний стан поточної продверсії додатка. Наша команда використовує наступні процеси перевірки актуального стану продукту:

  • Щоденна перевірка на наявність крашів в сервісі Google Firebase Crashytics. Краші є одним з ключових аспектів в досвіду користувача. Користувач не буде використовувати додаток, який має явні та часті краші. Тому високий рівень Crash-free додатку є одним з основних показників якості додатка.
  • Щоденна перевірка патернів поведінки користувачів на основі аналізу продуктових метрик продукту в аналітичних бордах. Такі патерни можна відстежувати за допомогою івентів аналітики, які записуються в аналітичних сервісах (наприклад, Amplitude). Побачивши значну просадку в ключових показниках, QA Engineer може виявити наявну проблему на релізній версії додатка.
  • Робота з відгуками кінцевих користувачів. Після отриманого відгуку наша команда намагається отримати максимальну кількість інформації від юзера та на основі такої інформації виявити місце для покращення додатка чи наявний баг.
  • Щоденний моніторинг актуального стану ендпоінтів бекенду додатків. Команда QA кожного дня виконує перевірки відправлення запитів до бекенду кожного додатка за допомогою Postman. Такі перевірки дозволяють виявити можливі проблеми, що пов’язані з бекендом, особливо реєстрації користувача та здійснення покупки.

Результат на кожному з етапів

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

Перший етап. Аналіз вимог

  • Валідація гіпотези.
  • Презентація технічного завдання.
  • Процес QA Review.

Другий етап. Написання тестової документації

  • Написання та оновлення тестової документації проєкту.

Третій етап. Виконання тестування додатка

  • Тестування на девсередовищі.
  • Тестування на пре-продсередовищі.
  • Смоук-тестування нової версії на продсередовищі.

Четвертий етап. Підтримка продукту

  • Аналіз рівня Crash-free в сервісі Google Firebase Crashlytics.
  • Робота з відгуками кінцевих користувачів.
  • Аналіз продуктових метрик для відслідковування основних показників стабільності роботи додатка на основі патернів поведінки користувачів.
  • Щоденний моніторинг актуального стану ендпоінтів бекенду додатків.

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

Правильно організована структура виконання процесів тестування гарантує якомога ширше тестове покриття програмного забезпечення.

Тому, організовуйте процес STLC, виходячи з ваших потреб та особливостей вашого проєкту і пам’ятайте: правильно організована структура тестування проєкту дозволить вам зарелізити проєкт вчасно!

👍ПодобаєтьсяСподобалось24
До обраногоВ обраному14
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую. Цікаво побачити — як працюють в різних компаніях. Далі кілька уточнень.

В тексті фігурує термін «тестувальник» і «QA інженер». Сподіваюсь, тут є розуміння, що це дві різні ролі,які мають трохи різні обов’язки часто, чи у вас це те саме?

«команда QA залучається на першу зустріч з обговорення певної гіпотези...» — між ким і ким відбувається ця зустріч?
Чи присутня така роль в компанії як бізнес-аналітик? Якщо так, то чи точно варто бути присутніми на етапі гіпотези? Чи є на зустрічах розробники?

«...і таким чином допомагає Product Manager дізнатись більше контексту про технічну сторону створення функціонала» -
чи присутня у вашій компанії така роль як архітект, чи тех-лід з команди розробників? Бо щось підказує, що про технічну сторону створення функціоналу він знає однозначно трохи краще за команду тестувальників.

«Product Manager виконує коригування технічного завдання після внесених правок зі сторони
QA Engineer та повертає оновлену документації на повторний процес QA Review».
— черговий раз лякає, що команда розробників все ще десь осторонь. Можна десь разів зробити ревью, а потім один раз почути, що реалізувати це взагалі технічно неможливо.

«Тестувальник передає ТЗ в розробку лише після того, як він пересвідчився,
що документація повністю описує весь функціонал та всі необхідні матеріали вже передані
для майбутньої розробки» — скільки часу зазвичай займає «пересвідчитись» і чим був зайнятий розробник до цього часу?

«У проєктах нашої команди на цьому етапі використовуються чеклісти,
оскільки кожен проєкт має обмеження в часі для виходу релізу» — наскільки велика у вас програма/додаток, який ви розробляєте? Наскільки там багато функцій, скрінів і тд? Скільки проекту років? і чи він планується як довготривалий?

«В нашій команді QA Engineer абсолютно автономно працює, оскільки самостійно стягує необхідні дані з віддаленого репозиторію та встановлює додаток на девайс за допомогою Xcode. Такий підхід дозволяє ефективно виконувати тестування, оскільки тестувальнику
не потрібно очікувати готовий білд від девелопера.»
— чи був досвід роботи з CI/CD? Наскільки це оперативніше і швидше працює, якби просто зранку тестувальник мав би вже готовий білд, який треба просто заінсталити?
І у вас лише іОС додаток? Андроїдом не заморочуєтесь?

«Тестування в девелоп-середовищі триває доти, поки не буде забезпечений визначений рівень якості програмного забезпечення»
— хто його визначає? йдеться про якість, обговорену з замовником, згідно його вимог?

«Після виправлення всіх багів та дефектів...» — в чому різниця між багами і дефектами у вас?

«Зазвичай, для того, щоб залити збірку на препрод середовище...»
— тобто тестового середовища немає? ви працюєте суто на «дев->предпрод->прод»?
Якщо ж тестове є, то чим зумовлене тестування на дев середовщі («Спочатку тестування відбувається в девелоп-середовищі»)?
Запитую, бо це нечаста практика мати ймовірність впливати один на одного. На дев весь час можуть литись зміни, дев може впасти і треба десь тестувати, можуть набиватися дані, які впливають на роботу відділів, можуть переливатись якісь сервіси і тд. Ось тому і виникло питання.

Дякую. Зараз звучала не критика, а намагання зрозуміти — як працюють процеси саме у вас. Бо, як видно з моїх питань, багато речей не є розкритими

Підписатись на коментарі