Основні принципи організації процесу тестування

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

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

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

З чого ж починати організацію процесу тестування?

Я виділяю 11 основних критеріїв в організації процесу тестування:

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

Тому, будь-який керівник, перед яким стоїть завдання організації процесу тестування, повинен поставити такі питання:

Тільки після того, як ми отримаємо відповіді на ці питання, можна починати переходити до стандартів.

Я виділяю такі нормативні документи, які дійсно потрібно вивчити перед тим, як починати будувати процес:

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

Будь-ІТ процес завжди повинен задовольняти потребам бізнесу!

Ми розберемо основні критерії побудови процесу тестування.

Метою тестування є виявлення дефектів, перевірка відповідності ПЗ заявленим вимогам, а також надання зворотного зв'язку про дефекти всім зацікавленим сторонам.

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

Говорячи про область тестування, ми повинні прекрасно розуміти, що саме нам належить тестувати. Це можуть бути системи, компоненти, бізнес процеси. Для того, щоб це зрозуміти, то потрібно просто відповісти на два питання:

Найчастіше, то що треба тестувати і то що будемо може сильно відрізнятися. Це залежить від можливостей вашого процесу тестування. «Що треба» часто диктується бізнесом і керівництвом, тому хороший керівник повинен завжди розуміти, «що потрібно» тестувати. Як говориться в приказці: «За двома зайцями поженешся, жодного не зловиш», так і тут. Завжди краще якісно тестувати то, що дійсно ви можете тестувати вашою командою, ніж хапатися за все, що просить бізнес і нічого не встигати вчасно, та ще й пропускати критичні дефекти.

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

У кожного підходу є свої переваги і недоліки, тому перед формуванням команди потрібно визначити ваші очікування від команди і ваші можливості.

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

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

Комунікації і взаємодія

Взаємодія, як всередині команди тестування, так і з іншими учасниками процесу ЖЦПО, є невід'ємною частиною організації будь-якого процесу, а в нашому випадку процесу тестування.

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

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

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

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

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

Методологія тестування

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

Стандартно поділяють 2 загальноприйнятих підходу до організації процесу ЖЦПО:

• каскадна методологія
• гнучка методологія

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

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

Тому, можна виділити 3 підходи до тестування ПО:

• Тестування, засноване на вимогах
• Тестування, засноване на ризики
• експертне тестування

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

Для гнучкої методології часу на розробку тест-кейсів зазвичай не буває, тому готуються чек-листи. Набір перевірок можуть визначатися як не по формалізованим вимогам, так і на основі ризиків ПО (тестування, засноване на ризики).

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

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

Якщо при оцінці виходять високі ризики великих втрат у разі відмови від тестування ПО, то потрібно задуматися про те, як правильно організувати тестування. Стандартно - це димова, функціональне тестування , Інтеграційне, регресійні, навантажувальний, санітарний, призначене для користувача види тестування. Залежно від ПО і проекту можуть застосовуватися і інші види тестування, наприклад, якщо у нас проект по гейм-дів, то це альфа і бета тестування.

документування процесу

Варто документувати процес чи ні? Коли документувати? Чи потрібно писати непотрібну документацію і витрачати на це час?

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

Основним стандартному по документуванню процесу тестування є IEEE 829.

До основних документів можна віднести:

• стратегія тестування
• Тест-план
• Матриця покриття вимог
• Тест-кейси
• протоколи тестування
• Звітність про тестування

Якщо розглядати гнучку методологію, то ми можемо формалізувати:

• Стратегію тестування (описує порядок тестування і підхід до виконання робіт з тестування ПО)
• Тест-план (в короткому змісті для спринту не менше 2-х тижнів, при менших термінах спринту ведення не актуальне)
• Чек-листи (аналогія тест-кейсів, коротко описують перевірки в тестуванні)

Управління ризиками

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

Управління ризиками в тестуванні важливий процес, що дозволяє керівнику виконувати проактивні дії до момент настання проблем.

Вести ризики можна декількома способами:

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

При заклад ризику визначається його статус:

• ідентифіковано
• відстежується
• запобігає
• реалізовано
• закрито

Вплив і ймовірність в 4-х пріоритетах.

Ну і найважливіше - це стратегія по роботі з ризиком:

• уникнення
• мінімізація
• передача
• ухвалення

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

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

Вимірювання процесу тестування

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

Інструменти і інфраструктура

Який же процес тестування без інструментів? Це виходить ручна праця заради ручної праці 🙂 Я думаю багато хто з вас часто чули про написання тест-кейсів в документах ворд, про побудови графіків і діаграм в екселя. Але, навіщо витрачати зусилля, якщо ринок пропонує нам готові продукти управління тестування, такі як HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr і багато інших.
Тому, якщо ви приступили до організації процесу тестування, то робіть цей процес зручним і ефективним. Пишіть тест-кейси в зручних формах готових продуктів, інтегруйте інструменти з системою управління завданнями, налаштовуйте автоматизоване тестування і т.д.

Підходячи до вибору інструменту потрібно завжди розуміти:

• Які завдання ви плануєте виконувати?
• Який у вас бюджет на інструменти?

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

Крім інструментів управління тестування, до інструментів тестування також можна віднести:

• Система управління дефектами і завданнями (може включатися в систему управління тестуванням)
• Допоміжні інструменти (для скріншотів, зняття логів, роботи з БД, SOUP UI для XML і т.д.)
• Інструменти автоматизації ( TestComplete , Selenium і т.д.)
• Системи управління знаннями (на wiki движку)

Тепер поговоримо про інфраструктуру. У поточному контексті свого оповідання я маю на увазі тестові середовища.

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

Стандартно я виділяю наступні типи тестових середовищ:

• Середовище розробки (чи можна її відносити до тестової ?, але тим не менше)
• Середу тестування системи (може бути розгорнута одна або кілька систем, компонент, не вимагає серйозних потужностей)
• Середа інтеграції (повноцінний інтеграційна середовище для перевірки працездатності наскрізних бізнес-процесів)
• середа навантажувального тестування (Основне вимоги - відповідність потужностями бойовому контуру)
• Середа ПродЛайк / ПреПрод (середа для налагодження готового протестированного билда, проведення інсталяційного тестування)

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

Удосконалення процесу

Я дуже часто говорю таку фразу, що «Будь-який процес, неважливо який, завжди повинен постійно вдосконалюватися», на що дуже часто чую «Навіщо, наш процес і так добре працює».

Але це не так. Чому ми повинні постійно вдосконалювати процес тестування:

1. Мета тестування не можуть бути однаковими, вони постійно змінюються в залежності від потреб бізнесу, що диктується ринком.

2. ІТ сфера постійно розвивається. Приходять нові технологи підходи, які завжди дозволяються вдосконалювати процес тестування.

Як то кажуть, досконалості немає меж!

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

Запланували - .Сделалі - Проаналізували - скорегувати

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