Тестова стратегія у процесах тестування

В попередньому дописі ми розглянули ідеї, покладені в написання актуального тест-плану, і його можливі складові.

В порівнянні із тест-планом (а цими порівняннями повниться теоретична база QA), тестова стратегія є більш високорівневим, статичним і довгостроковим документом. Що це означає? 🤔

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

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

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

Не дивлячись на слово “тестова” в назві, стратегію далеко не завжди пише саме QA. Зазвичай це залежить від змісту документу. В тому випадку, коли формалізовані рішення більш процесуальні, аніж технічні, за тестову стратегію цілком може відповідати PM, бо по суті така тестова стратегія буде прямим продовженням бізнес-вимог і загальних робочих воркфлоу.

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

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

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

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

1️⃣ Скоуп робіт, який може нести в собі як домовленості щодо роботи над тестовою стратегією, так і домовленості стосовно типової послідовності тестових активностей. Типова послідовність всім відома з STLC (Software Testing Life Cycle), але на практиці далеко не всі етапи мають місце, і тим більше в тому ж порядку і в тих же часових діапазонах. Важливо вписувати сюди апроксимацію до реальної ситуації, а не бажану картину.

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

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

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

5️⃣ Тестові енви, тобто набори девайсів, ОС та екранів, а радше навіть їхні діапазони, які мають підтримуватися, виходячи із профілю послуг компанії. Сюди ж може входити робота із тестовими даними, тобто підготовка, збереження і відтворення відповідних файлів або станів застосунку.

6️⃣ Перелік інструментів для тестування, що є списком ключових технологій та технічних рішень. Зазвичай містить і організаційні рішення типу Jira, Trello, TestRail, PractiTest, і суто технічні під різні типи тестування — корисні браузерні розширення, інструменти з автоматизації, з тестування навантаження, інтерсептори трафіку. Також може містити вартість і обґрунтування експлуатації платних додатків для подальшого прийняття рішень на рівні менеджменту компанії.

7️⃣ Робота з ризиками має містити практично відпрацьовані загальні ризики із приблизною оцінкою їх впливу та стратегією зниження можливості в разі необхідності.

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