В цьому документі описаний процес тестування програмних продуктів в компанії Join.To.IT: як влаштовані процеси, роль QA в команді, як проходить тестування, хто відповідає за якість, як процес тестування в розробці працює зараз і до чого ми прагнемо прийти.

Якість ≠ Тестування

Для того, щоб отримати якісний продукт, потрібно відповідально і якісно робити все з самого початку. Ось чому, в нашій компанії QA в основному залучається в процес розробки з самого початку, ще на етапі збору та аналізу проектної документації, це по-перше. По-друге, одне тестування не зможе забезпечити якість продукту, тому якісними повинні бути всі процеси розробки й нести відповідальність за якість повинен кожен член команди. I, по-третє, розробку і тестування не можна розглядати окремо, ці два процеси повинні тісно переплітатися одне з одним, а спеціалісти спілкуватися між собою і ділитися фідбеками (це проходить на щоденних Stand-ups). В результаті якість досягається не виявленням багів, а запобіганням їх, і це ціль усієї команди.

У 2019 році компанія перейшла на Spotify Agile Methodology.

Основною її ідеєю є розподіл команд на так звані "squad". Кожен squad містить спеціалістів різних областей програмування, які формують full-stack команду. На чолі такої команди стоять PM і Head of squad. Кожен squad займається своїми проектами. Детальніше про Spotify Agile Methodology можна ознайомитися за посиланням.

Ролі

Основні ролі на проекті в JTI:

• Head of PM - Dmytro Khomych, старший PM у компанії.
• PM (project manager) - це спеціаліст, який відповідає за усі процеси пов'язані з розробкою ПЗ (програмного забезпечення), оцінкою ризиків та звіту клієнтам. PM планує і відповідає за процеси розробки та тестування, дедлайни і в цілому за роботою своєї команди. PM роль на пряму підпорядковується ролі Head of PM.
• Старший розробник або Squad Master або Head of Squad - це спеціаліст з глибокими технічними знаннями та навичками, який відповідає за якість коду, виконує код-рев’ю, бере участь в плануванні sprints разом з PM, розподілом задач між командою розробки, проводить внутрішнє навчання і мітинги з командою розробників. QA тісно співпрацюють зі старшими розробниками з приводу всіх технічних питань пов'язаних з налаштуванням тестового середовища, структури баз даних, та інших.
• Розробник - спеціаліст, який більшість свого часу пише код функціональності продукту, який поставляється користувачу. Він бере участь в estimate, створенні проектної документації, визначає структуру даних і загальну структуру, пише unit tests (де це необхідно), а також тестує свій код і відповідає за якість своєї роботи.
• QA Team Lead або старший QA - це спеціаліст з глибокими технічними знаннями в області тестування. З одного боку він виступає QA спеціалістом і входить в команду розробки основних, великих проектів компанії, а з іншого, виступає менеджером QA команди: бере участь у наймі спеціалістів в команду QA, займається розподілом ресурсу QA в squad та на проекти, систематично проводить рев’ю результатів тестування проектів, проводить внутрішнє навчання і мітинги з командою спеціалістів з тестування. Також старший QA займається розвитком команди тестування, покращенням процесів та автоматизацією тестування.
• QA інженер - спеціаліст по забезпеченню якості продукту, діяльність якого спрямована на покращення процесів розробки ПЗ, запобігання багів на ранніх етапах розробки та виявлення багів в продукті. Докладніше описано в розділі “QA в Join.To.IT”

SDLS (Software development lifecycle) - життевий цикл програмної системи.

Основні етапи SDLS компанії.

Етап 1. Збір і оформлення проектної документації.

Основні:

• Project Profile Page
• Прототип
• Дизайн
• Project Requirements документ - основний документ з описанням цілі, основних бізнес задач, описанням функціональних і нефункціональних project requirements

Детально ви можете прочитати тут - link.

Етап 2. Тестування “Project Requirements” спеціалістом QA. Докладно про це розказано в наступних розділах.

Етап 3. Планування розробки продукту (або його частини). На цьому етапі PM розбиває всі роботи на частини, в компанії ми їх називаємо майлстоунами, підготовляє product backlog і заносить його в Trello - інструмент для управління проектами. Далі планується дата старту проекту і для команди розробників планується sprint, який займає 2 робочих тижня (хоча можуть відрізнятися залежно від проекту та вимог клієнта) та готуються Acceptance Criteria (AC).

Етап 4. Написання АС спеціалістом QA. Кожна задача backlog в Trello повинна містити перелік АС.

Детальніше про АС можна ознайомитися тут - link.

Етап 5. Розробка і тестування. Ці процеси проходять паралельно. План розробки відбувається за допомогою sprints, а план тестування складається щонеділі в четвер (на наступні 2 тижні) на QA planning зустрічі.

Етап 6. Реліз.

Етап 7. Підтримка прoекту (якщо це потрібно клієнту).

1. Backlog - тут знаходяться всі задачі по проекту.
2. Sprint (2 тижні або 1 тиждень, залежить від проекту) - після створення спринту PM переносить сюди картки або з Backlog або з Need to fix. Перед запуском Sprint QA готує АС і добавляє їх у трело картку.
3. In process - як тільки розробник розпочне роботу над певним завданням, він повинен взяти карту зі спринту в цій колонці. Після завершення завдання розробник проганяє АС і, якщо всі АС виконуються успішно (може бути не виділений АС, але повинні бути коментарі від розробника чому не виділений), передає картку на PM-а.
4. Review by PM - після виконання завдання розробник перекидає картку в цю колонку з колонки In Process. PM проводить рев’ю цих задач, проганяє АС і переносить картку в наступну колонку, якщо рев’ю пройшло успішно, або в Sprint/Need to fix якщо завдання не виконане, з коротким описанням, що саме не так.
5. Preparation for QA - після успішного рев’ю PM може зберігати завершені завдання в цій колонці, і як тільки настає сенс перевірки задач переміщає їх до наступного стовпця.
6. Ready for QA - тут знаходяться майлстоуни, які повністю готові до тестування: налаштований тестовий сервер (для web-систем тестування проходить на окремому тестовому сервері з окремою базою даних), готові тестові збірки (для мобільних додатків), рев’ю на тестовому середовищі пройшло успішно, проектна документація актуальна, всі потрібні доступи описані в Profile page та в Pinned message в групі проекту в Rocket chat. Перед тим, як взяти задачу в роботу QA повинен впевнитися, що до тестування все готово (документація, тестове середовище, всі потрібні доступи).
7. Testing in Process - як тільки QA бере в роботу карточку, він повинен перемістити її з Ready for QA в цю колонку.
8. Need to fix - якщо після тестування в системі є баги, тоді QA переносить цю карточку в дану колонку.
9. Ready for FULL Testing before release - QA переносить карточку в цю колонку, якщо після тестування багів по даному модулю на всіх потрібних тестових середовищах не виявлено. Тут збираються всі модулі по проекту і чекають повного тестування, яке проводиться перед здачею всього проекту.
10. DONE - сюди потрапляють картки, які успішно пройшли повне тестування перед релізом. В іншому випадку, вони переміщуються тестувальником в Need to fix, а всі картки з DONE переносяться знову в Ready for FULL Testing before release, тому що після фіксу поламаних модулів, необхідно буде повторно зробити тестування.

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

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

QA в JTI підпорядковується на пряму QA Team Lead (питання пов'язані з графіком роботи, відпустками, планом робіт, звіти денні та в цілому по статусу розробки проектів, ІПР і тому подібне). Що стосується командної роботи на проекті, QA спеціаліст виконує завдання стосовно розробки, і звітує щодо прогресу для ПМ окремого проекту.

Основні функціональні обов’язки QA

В цілому QA виконує такі обов'язки в компанії:

1. Тестування та аналіз проектної документації. Допомога PM в актуалізації проектної документації.
2. Написання АС.
3. Участь в плануванні sprint.
4. Участь в щоденних Stand-Up по проекту.
5. Участь у щоденних QA StandUp з QA Team Lead.
6. Актуалізація Profile Page (інформація про проект у вкладці Kick-off Check-list, доповнення статусів тестування та написання АС у вкладці Estimate with status Tracker)
7. Участь в демо та ретроспективах.
8. Планування процесу тестування: QA planning - під керівництвом PM і QA Team Lead на основі sprint планів розробки.
9. Тестування web та мобільних додатків на різних стадіях їх циклу розробки, аналіз результатів тестування та надання своєчасних звітів про стан протестованих модулів системи своїй команді.
10. Тестування REST API.
11. Написання та підтримка тестової документації (AC, test suites, bug reports, user stories, etc.).
12. Комунікація з розробниками, ПМ та іншими членами команди відносно процесів розробки проекту (план, статус, покращення якості та процесу розробки, і тому подібне).
13. Участь в рев’ю проектів і внутрішніх зібраннях з QA Team Lead.
14. Виконання інших завдань керівника в рамках посади.

QA planning

Кожен четвер о 16:00 відбувається QA planning, на якому складається план тестування на наступний Sprint (2 тижні).

Основні ролі, що беруть участь в плануванні: QA Team Lead, Head of PM. Також, за необхідності, можуть бути присутні CEO і CTO й інші члени команди (PM, QA). На плануванні обговорюється, що кожен QA буде робити на протязі наступних 2 тижнів. План створюється на основі sprint плану розробки.

Основна ідея/ціль планування: підготувати АС для початку розробки окремих частин проекту та протестувати задачі, які вже зроблені, підготуватися до демо. При цьому в план вносяться всі потрібні до виконання задачі та ставиться пріоритет для них. Кожен QA Engineer складає свій план самостійно або з ПМ, відносно проектів, на яких він працює і передає свій план QA Team Lead (до 15:30). А далі QA Team Lead з Head of PM перевіряють план, фіналізують його і передають команді QA.

Ось QA planning документ. Кожен QA на протязі тижня, кожного дня заповнює результати по своєму плану (наприклад: done / 70% done / відмінили через… / замінили)

ВАЖЛИВО: документ завжди має бути в актуальному стані.

QA daily planning and standup

Кожного ранку QA Team Lead проводить внутрішній standup QA відділу. Тут обговорюється статус минулого робочого дня і план на сьогодні, а також окремі питання по проектам і процесам, якщо такі є.

QA виконує тестування за своїм недільним планом.

Перед стартом тестування QA має перевірити:

1. Наявність задачі в Трелло в статусі Ready for QA.
2. Виконані АС розробником.
3. Готовність тестового середовища: тестового сервера і тестової бази даних.
4. Наявність актуальної проектної документації.
5. Наявність всіх потрібних доступів.
6. Наявність всіх потрібних тестових девайсів.

Якщо щось не готове, потрібно максимально швидко вплинути на виправлення ситуації та розпочати тестування. Як що ж все-таки QA й PM не можуть владнати ситуацію, вони мають звернутися до QA Team Lead.

Перший етап тестування web-систем проводиться на одному браузері, зазвичай це Chrome. Спочатку проводиться перевірка виконання АС:

• якщо АС проходять успішно -> проводимо повне тестування модуля, описуємо окремі тест-кейсі (зазвичай в тому ж документі де містяться АС), заводимо баги,
• якщо АС не проходять -> заводимо баги, пишемо звіт в карточку задачі і переносимо її в "Need to fix".

Крос-браузерне і кросс-платформене тестування проводиться після того, як 80% багів на Chrome будуть закриті.

У кожного проекту є основний проектний документ (про проектну документацію вже було трохи описано в розділі SDLS в JTI).
Це живий документ, який розвивається разом із проектом.
Наразі, основний документ Project Requirements описується в Google Documents і містить назву версії. Всі версії зберігаються в Google Drive, корпоративного аккаунту. Для того, щоб команда мала доступ до всіх версій і могла в будь-який момент знайти останню, посилання на папку додається в Project Profile проекту.
Не вся документація, як і не всі проекти в компанії тестуються, але до ключових проектів завжди залучається QA. Після того, як документація по всьому проекту, або по якійсь його завершеній функціональності буде завершена, документ планується на передачу для інженерів по тестуванню. Перед передачею, відбувається зустріч PM і QA, на якій PM проводить коротке рев’ю документації проекту з метою, полегшення подальшої роботи QA з документом та визначення, чи взагалі готовий документ до тестування, чи може його потрібно допрацювати. Якщо документ потрібно допрацювати, PM отримує фідбеки на зустрічі та забирає документ на допрацювання.

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

При тестуванні проектної документації потрібно звертати увагу як на технічні аспекти, так і на логіку роботи системи, або функціональності в цілому: для чого вона? яка її основна ціль для юзера, а яка для бізнесу? Система - це один організм і вона повинна працювати як одне ціле, тому потрібно перевіряти не лише окремі модулі, а їх взаємодію, як вони впливають одне на одне. Окрім цього, в систему можуть підключатися додаткові системи, і це потрібно теж враховувати.

Виділимо основні аспекти перевірки проектної документації:

• Повнота. Виділяйте частини документу, де не вистачає інформації, або потрібні особливі знання, якими новачок для прикладу, не володіє (не можна упустити інформацію, яка для когось з команди очевидна, а для інших ні).
• Архітектура. Проаналізуйте архітектуру запропоновану в документі. Чи можна її реалізувати з доступними ресурсами? Яка інфраструктура буде використовуватися? Чи не занадто проста або складна архітектура? Чи буде вона зрозуміла користувачу?
• Грамотність. Не пропускайте граматичні, орфографічні й пунктуаційні помилки. Недбалість погано позначиться на майбутньому коді. Не будемо створювати підстав для недбалості.
• Узгодженість і несуперечливість. Переконайтеся в тому, що немає суперечливої інформації для одного компоненту або твердження в різних місцях документації, а також, діаграмах, дизайні, таблицях, тощо.
• Виконання бізнес і користувацьких задач. Переконайтеся в тому, що система виконує свою бізнес задачу, а також задачу користувача, перевірте чи зручно буде користувачу працювати з системою.
• Тестування. Наскільки тестопридатна система? Чи потрібні додаткові ресурси для тестування або особлива інформація та уміння? Обговоріть це з менеджером і якщо потрібно з розробниками й попросіть, щоб цю інформацію додали в документ.

Приклад оформлення звіту: link.

Буде корисним для ознайомлення: Методичка для менеджеров компании Join.To.IT

Після тестування проектної документації (проектна документація повинна бути актуалізована або PM або QA Engineer), настає наступний етап розробки проекту - написання Acceptance Criterias (частіше написанням АС займаються QA Engineer, рідше - РМ).

Деталізація АС залежить від таких факторів як: побажання замовника, бюджет на QA, склад команди розробки, статус проекту і проектної документації.

Зазвичай, АС оформлюються не надто детально, вони повинні покривати лише основні цілі та тестові випадки окремого модуля, при цьому вся детальна інформація і вимоги містяться в Проектній Документації по якій, при необхідності, будуть додатково описуватися тест-кейси при тестуванні.

Спочатку всі АС записуються в файл Google doc, допрацьовуються разом з QA, РМ або ВА, і переносяться в Трелло картку (після цього треба змінити статус AC в Project Profile).

В нашій компанії використовується баг-трекінгова ситема Redmine.

1. Створення нового проекту в Redmine

Проекти в Redmine створює або PM проекту або QA.

Враховуючи типи проектів в нашій компанії, маємо два типи проекту в Redmine:

• Web-проект
• Mobile-проект

Якщо проект складається з декількох проектів, перелічених вище, створюється 1 батьківський проект та 1 або 2 підпроекти. Батьківським проектом завжди виступає web проект. Налаштування для кожного типу проекту описані нижче.

Модулі

Issue - основний модуль системи, де знаходяться всі існуючі баги по проекту.

Documents - тут знаходяться вся потрібна інформація по проекту: посилання на Проектну документацію, доступи до тестового серверу, тестової бази даних, доступи до тестової документації і таке інше.

Трекери

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

Ticket - це трекер, де знаходяться баги, створені клієнтом (клієнти можуть створювати баги лише в цьому трекері)..

Review - це трекер для PM.

2. Правила оформлення баг репортів

3. Статуси бага

1. New (not assigned) - статус призначений для PM, якщо QA не впевнений на якого розробника цей баг призначати.
2. New - цей статус стоїть в полі за замовчуванням при створенні нового репорту. Баг призначається на відповідального розробника, або на ПМ, якщо це баг-питання, або баг-пропозиція.
3. In Progress - якщо проблема потребує багато часу (більше ніж 1 год), щоб її виправити, розробник присвоює цей статус багу і залишає його на собі (поле Assignne).
4. Waiting for response - цей статус може бути присвоєний будь-ким для бага, в тому випадку, якщо є якісь запитання або уточнення, при цьому баг призначається на людину, від якої потребується відповідь.
5. Resolved (NOT pushed) - цей статус встановлюється багу розробником після того, як баг виправлений, але білд з виправленням НЕ залитий на тестовий сервер, при цьому баг залишається на розробнику.
6. Resolved - цей статус встановлюється багу розробником після того, як баг виправлений і білд з виправленням залитий на тестовий сервер, при цьому баг переасайнюється на QA для ретесту.
7. Duplicate - може встановлюватися будь-ким, якщо для даного бага є дублікат. При цьому важливо в коментарі вставити лінк на актуальний баг. Якщо статус багу встановлює не QA, то баг призначається на QA.
8. Not a bug - може встановлюватися будь-ким, якщо баг вважається не багом, при цьому важливо прокоментувати цю позицію, і якщо статус встановлюється розробником, баг має бути призначений на PM для підтвердження, якщо PM - то баг призначається на QA.
9. Additional Work - статус встановлюється, якщо проблема не є помилкою, але було б чудово реалізувати функцію. Баг призначається клієнту, або PM.
10. Re-open - статус встановлюється QA або, в окремих випадках, PM, якщо баг не виправлений. При цьому важливо змінити значення поля "Number of re-open". Баг призначається на розробника.
11. Confirmed by QA - встановлюється QA, після ретесту бага, якщо баг є виправленим, при цьому баг призначається на розробника.
12. Deferred - встановлюється зокрема PM, якщо баг заморожений на деякий час.
13. Closed - встановлюється QA або PM, якщо баг не актуальний (при цьому потрібно добавити коментар) або після закриття багу статусу Not a bug.

Баг вважається закритим, якщо він має наступні статуси:

• Confirmed by QA,
• Duplicate,
• Deferred,
• Closed.

4. Списки багів в Redmine

В Redmine є можливість зберегти відфільтровані баги в cписки. Ці списки відображаються справа в модулі "Issues".
Цю можливість мають PM і QA.

Для того, щоб зберегти список потрібно:

1. відфільтрувати потрібним чином баги за допомогою фільтрів;
2. натиснути кнопку Save;
3. задати потрібні налаштування на сторінці списка і зберегти.

За замовчуванням, після першого тестування модулю, QA створює список багів для цього модулю з наступними параметрами:

1. для фільтру в "Issues":
   • Tracker is bug
   • Link to TRELLO card
2. Для сторінки списку:
• Задати Name (за замовчуванням: "[назва модуля] - opened bugs")
• Visible = to any users
• Group results by = Priority
• Зберегти список

Після збереження списку багів, посилання на нього треба прикріпити в Project Profile Page у відповідній колонці, та додати це посилання в коментарях у Трелло картці

Тест-кейси пишуться, якщо АС неінформаційні. Можуть бути описані в файлі з АС, або в окремому файлі в тій же папці, де документ з АС.

При цьому, в залежності від тяжкості модулю, QA Engineer може визначати формат написання тест-кейсів (можна писати і чек-лист для легких модулів)

Вимоги до документа:

• Назва: [назва проекту] - Test Suites (наприклад: Orcateс - Test Suites)
• ChangeLogsTable: перший лист, де містяться таблиця з основними даними, наприклад: link)
• General: другий лист, тут містяться загальні перевірки (наприклад: правильна реакція системи після переривання інтернету, правильний hover на side_bar_menu, і таке інше)
• Модулі = Окремий лист таблиці: тут міститься список перевірок на даний модуль. Обов’язкові колонки: Status of Case, #, Date, Use Case - Description, System Action, список Environments.

Приклад документу: web, mobile.

Якщо документ Test Suites, або версія документу є новою, то потрібно:

• перенести документ в корпоративну папку тестування проекту
• додати посилання на папку з Test Suites в Redmine в розділ Documents проекту, щоб усі члени команди мали доступ до неї й мали змогу швидко знайти потрібну версію документу.

• QA працює за 2-тижневим планом, в якому зазначені всі задачі на 2 тижня.
• QA в організаційній структурі напряму підпорядковується QA Team Lead.
• QA бере участь в qa daily standup і standup по окремому проекту.
• QA повністю відповідає за якість проектів, а також процесів на проектах, на які він назначений (максимум 3-5 активних проектів). При цьому QA активно взаємодіє з ПМами своїх проектів, допомагає в плануванні, оформленні та підтримці актуального стану Проектної Документації, Project Profile Page, проведенні ретроспектив і демо.
• QA Team Lead - є ментором співробітників QA department, тому QA завжди може і повинен звертатися до QA Team Lead в разі виникнення питань, які сам або з ПМ не може вирішити.
• Основні типи робіт QA:
  1. Тестування проектної документації
  2. Оновлення проектної документації
  3. Написання тестової документації (АС, user stories, test cases, etc.)
  4. Тестування front-end та back-end (REST API)
• Компанія в основному працює в ScrumBan дошці - Trello і використовує баг-трекер Redmine.
• QA повинен вчасно і чітко надавати звіти про тестування команді і QA Team Lead.

Приклади звітів:

1. Звіти про тестування проектної документації та про написання АС:
   • Закончила тестирование требований для модулей 3.1-3.3 и 3.5 ‘Companies’. [Отчет](посилання на тестову документацію)
     Ответь, пожалуйста, на вопросы. По возможности, прошу ответить до 16-00 среды.
     @ekaterina.bolukh fyi
   
   
   • Закончила написание АС для модулей 3.1-3.3 и 3.5 ‘Companies’. [Отчет](посилання на тестову документацію)
     Ответь, пожалуйста, на вопросы. По возможности, прошу ответить до 16-00 среды.
     @ekaterina.bolukh fyi
     
2. Звіт про тестування в картку трелло:

   25.11.2021
   **Regression testing #1**
   _______________________
   Environment = Google Chrome Version 92.0.4515.107 (Official Build) (64-bit)
   [Link to the site]()
   Role: admin
   _________________________
   **Result:** bugs are open: 2
   [Link to the bug list]()
   

3. Звіт про тестування в чат проекту:

   Status of regression#3,
   Module ‘Goals’ (roles: ALL, environment: Windows 10, Chrome).
   *Total bugs in open = 5*
   *bugs by Status:*
   confirmed by QA = 7
   re-open = 2
   new = 3
   *bugs by Priority:*
   High = 1
   Normal = 1
   *bugs by Type:*
   back-end = 1
   front+back = 1
   front-end = 3
   Additional comment: Roles = staff and supervisor - are blocked by bug ID=129.

   Звіти залежать від ситуації, такий шаблон підходить для великих модулів проекту. Для менших модулів можна використовувати:

   *Results of testing:*
   1. Transaction: 70% - AC passed, 3 opened bugs, status = need to fix.
   2. History: 100% - AC passed, 1 opened bug for separate test-case, status = need to fix.
   3. Users CRUD: 100% - AC passed, 0 bugs, status = ready for full testing before release.
   

4. Редагування статусу milestone/task в документі Daily planning:

   Наприклад: done / 70% done / відмінили через… / замінили

5. Звіт наприкінці робочого дня в чат qa_department:

   @ekaterina.bolukh
   Report for today:
   1. Назва проекту: тип задачі (Requirement testing/AC/Testing/Regression testing):
   - Назва модуля - % виконання (і коментарі, якщо є необхідність)
   - Назва модуля - % виконання
   - Назва модуля - % виконання
   

Корисні посилання:

Методичка для менеджеров компании Join.To.IT
Введение в Postman
Rest API best Practices
Bug-Reports