Тема 11. Тест-менеджмент

З чого почати у тестуванні на основі ризику?

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

Яка формула PERT?

E=(O+4M+P)/6, де O - оптимістична оцінка тривалості завдання, M - найімовірніша оцінка тривалості завдання, P - песимістична оцінка тривалості завдання.

Хто виконує роль тестувальника на system test level?

На system test level роль тестувальника виконує незалежна група тестування.

Що визначають Entry criteria? (вхідні, або початку)

Entry criteria (найчастіше звані definition of ready в Agile-розробці - DoR) визначають попередні умови для виконання заданої тестової дії. ("тобто що повинно бути готове до початку тестування; готовність тестових даних, вимог, оточення, код повинен бути вилитий на тестове оточення")

Що визначають Exit criteria? (віхідні, або завершення)

Exit criteria (частіше звані definition of done в Agile-розробці - DoD) визначають, які умови мають бути досягнуті, щоб оголосити рівень тестування або набір тестів завершеними. ("можемо прописати, що всі тестові активності завершені, кількість відповідних баг-репортів не повинні перевищувати якогось відстоку, наприклад не повинно бути blocker, critical, а major - %")

Який тип тестування часто використовується всередині реактивної стратегії?

Exploratory testing - тип тестування, який часто використовується всередині реактивної стратегії.

Що таке PERT? (Техніка оцінки за трьома точками)

Program (Project) Evaluation and Review Technique (скорочено — PERT) — техніка оцінки та аналізу програм (проектів), яка використовується при управлінні проектами. PERT — це спосіб аналізу завдань, необхідних для виконання проекту. Особливо, аналізу часу, який потрібен для виконання кожної окремої задачі, а також визначення мінімального необхідного часу для виконання всього проекту.

Що включає в себе тестування на основі ризику?

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

Як називається подія, коли дефект є, але тест пройшов успішно?

false negatives (type II error)

Як називається подія, коли дефекту немає, але тест зафейлився?

false positives (type I error). "Це значить, що тест-кейс спроектований некоректно, і він не бачить дефекту. Потрібно, наприклад, змінити тестові дані, перефразувати тест-кейс."

Що зазвачай включають в себе баг репорти про помилки, знайдені при динамічному тестуванні?

Баг репорти про помилки, знайдені при динамічному тестуванні зазвичай включають: ● id ● заголовок або короткий опис ● дата виявлення дефекту, автор ● інформація про тестове оточення ● кроки відтворення помилки ● актуальний та очікуваний результати ● severity та priority ● додаткові матеріали (скріншоти, відео, посилання на додаткові матеріали)

Що передбачає вибір підходу до тестування?

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

Як вираховується О?

Від попередньої оцінки M віднімаємо час на ризики і отримуємо оптимістичну оцінку (O)

Що таке "Тест-базис" (Test Basis)?

Документ, на підставі якого визначаються ВИМОГИ до компонента чи системи.

Що має враховувати графік виконання тестування?

Графік виконання тестування має враховувати: • пріоритети, • залежності, ("першими проводимо тести, від яких залежать інші тести; залежності: наприклад, між частинками функціональності; між тест-кейсами (але цього потрібно уникати; тест-кейси повинні бути максимально незалежні") • confirmation тести, ("перевірка баг-репортів (ретест); і на це теж треба закладати час") • regression тести, • найефективнішу послідовність виконання тестів.("наприклад, пріоретизуємо якусь функціональність")

Коли може бути складений графік виконання тестів?

Графік виконання тестів може бути складений після того, як тест-кейси та процедури тестування створені та зібрані у набори тестів.

Які є найбільш часто використовувані методи оцінки тестів (Test Estimation Techniques)?

Два найбільш часто використовувані методи оцінки: •Metrics-based technique: оцінка зусиль з тестування на основі показників попередніх аналогічних проектів або на основі типових значень ("як правило, для наступних ітерацій") •Expert-based technique: оцінка зусиль з тестування на основі досвіду власників тестових завдань чи експертів ("наприклад, тестувальник на своєму досвіді з подібного проекту розуміє, скільки він часу витрачає на створення тест-кейсів і т.і.)

Як вираховується Р?

До оцінки M додаємо додаткові ризики (наприклад: захворів один тестувальник, зламалось тестове оточення і потрібен додатковий час на його ремонт, тощо) і отримуємо песимістичну оцінку (P)

Що можуть включати дії з планування тестування?

Дії з планування тестування можуть включати: • Визначення обсягу, цілей та ризиків тестування. • Визначення загального підходу до тестування. • Інтеграція та координація дій тестування у діях життєвого циклу програмного забезпечення. • Прийняття рішень про те, що тестувати, людей та інших ресурсів, необхідних для виконання різних дій з тестування, і про те, як будуть виконуватися дії з тестування.("наприклад, розробники пишуть юніт-тести, і це фіксуємо в тест-плані") • Планування дій з аналізу, проектування, реалізації, виконання та оцінки тестів або на певні дати (наприклад, при послідовній розробці), або в контексті кожної ітерації (наприклад, під час ітеративної розробки).("наприклад, плануємо дії на спринт") • Вибір метрик для моніторингу та контролю тестування ("що будемо відслідковувати: час, наприклад") • Бюджетування тестових активностей ("займається ПМ, але тест-менеджер комунікує з ПМ") • Визначення рівня деталізації та структури тестової документації (наприклад, шляхом надання шаблонів, наприклад документів) ("описується, наскільки детально описуються кроки в тест-кейсах, наскільки детально потрібно описувати чек-листи, з чого повинен складатись звіт з тестування")

Які активності можуть охоплювати дії тест-моніторингу та контролю?

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

Що визначає конроль тестування (тест-контроль)?

Контроль тестування ВИЗНАЧАЄ будь-які керівні або коригувальні ДІЇ, вжиті в результаті збору інформації та показників, які (можливо) повідомляються.

Приклад використання техніки оцінки за трьома точками.

Кількість тест-кейсів: 5 Час на написання 1 тест-кейсу: 3 хв Час на тестування 1 тест-кейсу: 3 хв Припустимо, що у нас може знайтись 3 дефекти в рамках тестування Час на заведення 1 баг-репорту: 2 хв Час на ретест 1 дефекту: 3 хв Допустимо, що на ймовірні ризики ми закладемо ще 20% від оптимістичної оцінки для отримання реалістичної оцінки Для написання test summary report виділимо 10 хв Для песимістичної оцінки врахуємо ще на додаткові ризики 30% часу від оптимістичної оцінки M = 5*3+5*3+3*2+3*3+10+11(це 20% від 55) = 66 хв O = 5*3+5*3+3*2+3*3+10 = 55 хв P = 5*3+5*3+3*2+3*3+10+11(це 20% від 55)+16,5(це 30% від 55) = 82,5 хв Е = (55+4*66+82,5)/6 = 66,9 хв

Що є метою тест-моніторингу?

МЕТОЮ моніторингу тестування Є ЗБІР інформації, а також НАДАННЯ зворотного ЗВ'ЯЗКУ та огляд тестових дій.

Для чого можуть збиратись метрики?

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

Мутаційне тестування. Що це за метод?

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

Для чого призначене мутаційне тестування?

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

Хто виконує роль тестувальника на acceptance test level?

На acceptance test level роль тестувальника виконують бізнес-аналітики, профільні фахівці, користувачі.

Хто виконує роль тестувальника на component test level?

На component test level роль тестувальника виконує розробник.

Хто виконує роль тестувальника на integration test level?

На integration test level роль тестувальника виконує розробник або тестувальник.

Хто виконує роль тестувальника на operational acceptance test level?

На operational acceptance test level роль тестувальника виконує персонал з операцій та/або системного адміністрування.(""це я підтип приймального тестування, проводять девопси (системні адміністратори)"

Хто виконує роль тестувальника на system integration test level?

На system integration test level роль тестувальника виконує незалежна група тестування. ("може бути команда як всередені команди розробки, або з якоїсь фріланс-біржі")

Що впливає на планування?

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

Що є найважливішою діяльність тест-менеджера у будь-якому тестовому проекті?

Найважливішою діяльність тест-менеджера у будь-якому тестовому проекті є ПЛАНУВАННЯ тестування.

Що визначає розклад виконання тестів?

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

Що таке "Тестова умова" (Test condition)?

ОБ'ЄКТ ЧИ ПОДІЯ У компоненті чи СИСТЕМІ, що має бути перевірено одним чи декількома тестовими наборами. Наприклад: ФУНКЦІЯ, транзакція, ВЛАСТИВІСТЬ, атрибут якості чи структурний елемент.("ЩО ПЕРЕВІРЯЄМО")

Де використовується планування тестування?

ПЛАНУВАННЯ тестування використовується В ПРОЕКТАХ розробки та впровадження «З НУЛЯ», а також під час ОБСЛУГОВУВАННЯ (зміна та виправлення). ("якщо фраланс, можемо створювати тест-план для себе, але з практики у таких випадках тест-план створюється рідко, хіба що на вимогу замовника тестування")

Через що певний рівень незалежності тестувальника робить його роботу більш ефективною в області знаходження дефектів?

Певний рівень незалежності тестувальника робить його роботу більш ефективною в області знаходження дефектів ЧЕРЕЗ НЕСХИЛЬНІСТЬ ДО CONFIRMATION BIAS. Але незалежність не применшує знань розробника про систему, розробники також можуть ефективно шукати баги у своєму коді.

Де може бути задокументоване планування?

Планування може бути задокументоване В ОСНОВНОМУ ПЛАНІ тестування ТА В ОКРЕМИХ планах тестування ДЛЯ РІВНІВ тестування, таких як system testing та acceptance testing, або ДЛЯ окремих ТИПІВ тестування, таких як usability testing та performance testing.

Приклади дій з тест-контролю?

Приклади дій з тест-контролю включають: • Зміна пріоритетів тестів при виявленні ризику (наприклад, якщо програмне забезпечення було доставлене із запізненням) • Зміна розкладу тестування через доступність або недоступність тестового середовища або інших есурсів • Повторна оцінка того, чи відповідає елемент тестування entry або exit criteria через доопрацювання

Приклади проектних ризиків: організаційні проблеми

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

Приклади проектних ризиків: політичні питання

Приклади проектних ризиків: Політичні питання: ● Тестувальники не можуть належним чином повідомляти про свої потреби та/або результати тестування. ● Розробники та/або тестувальники можуть не відслідковувати інформацію, отриману в ході тестування та ревью (наприклад, не покращувати методи розробки та тестування). ● Може бути неправильне ставлення до тестування або очікування від нього (наприклад, нерозуміння цінності виявлення дефектів під час тестування).

Приклади проектних ризиків: проблеми з постачальниками

Приклади проектних ризиків: Проблеми з постачальниками: ● Третя сторона може не надати необхідний продукт чи послугу, або збанкрутувати ● Контрактні проблеми можуть спричинити серйозні труднощі для проекту

Приклади проектних ризиків: проблеми проекту

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

Які є продуктові фактори, що впливають на трудовитрати з тестування?

Продуктові фактори: ● ризики пов'язані з продуктом ● якість тестового базису ● розмір товару ● складність доменної області ● вимоги до якісних характеристик (безпека, надійність) ● необхідний рівень деталізації документації ● законодавчі вимоги та стандарти

Тест-менеджер. Цо це за роль?

Тест менеджер - РОЛЬ, відповідальна за ПРОЦЕС ТЕСТУВАННЯ та УПРАВЛІННЯ тестовими АКТИВНОСТЯМИ.

Приклади проектних ризиків: технічні проблеми

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

Приклади ризиків продукту

Приклади ризиків продукту включають: • Програмне забезпечення може не виконувати намічені функції відповідно до специфікації • Системна архітектура може не підтримувати достатньо певні нефункціональні вимоги ("наприклад, архітектура може не давати можливості підтримувати високий рівень продуктивності, масштабування") • Конкретне обчислення може бути виконано неправильно за певних обставин ("обчислення якогось часу відповідно до часового поясу, локалізація - потрібна мова може не підтягнутись") • Час відгуку може бути недостатнім для високопродуктивної системи обробки транзакцій ("це стосовно performance; якщо такий ризик є, то необхідно робити покращення; щоб знизити ризик, необхідно провести навантажувальне тестування") • User experience (UX) відгуки можуть не відповідати очікуванням продукту

Що включає в себе продуктовий ризик (Product Risk)?

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

Що таке проектний ризик (Project Risk)?

Проектний ризик - ризик, пов'язаний з управлінням та контролем (тестового) проекту, наприклад: відсутність кадрів, жорсткі терміни, вимоги, що змінюються, і т.д.

Що таке confirmation bias?

Підтверджувальне упередження (англ. confirmation bias), інша назва — упередження мого боку (як — «ти на чиєму боці?»), — це тенденція шукати або інтерпретувати інформацію таким чином, щоб вона підтверджувала власні переконання або гіпотези.(Вікіпедія)

Що таке підхід до тестування (test approach) з точку зору стратегії?

Підхід до тестування (test approach) - це реалізація стратегії тестування на конкретному проекті.

Що є відправною точкою для вибору технік тестування, рівнів тестування та типів тестування, а також для визначення entry criteria та exit criteria (або definition of ready та definition of done)?"

Підхід до тестування є відправною точкою для вибору технік тестування, рівнів тестування та типів тестування, а також для визначення entry criteria та exit criteria (або definition of ready та definition of done).

Що таке ризик?

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

Що передбачає ризик?

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

Які бувають ризики?

Ризики бувають продуктові та проектні.

Хто може виконувати роль тест-менеджера?

Роль тест менеджера може виконувати кваліфікований тест менеджер, ПМ, лід розробки або quality assurance менеджер ("будь-яка менеджерська роль, керівник, з точки зору тестування"). На великих проектах кілька команд тестування можуть бути підзвітні одному тест менеджеру.

Де вище ступіль деталізації: у стратегії чи тест-плані?

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

Як вираховується рівень ризику?

Рівень ризику = ймовірність виникнення ризику × вплив, якщо він справді стався.

У чому відмінність стратегії від тест-плану?

СТРАТЕГІЯ покриває процес тестування продукту ЗАГАЛОМ, а ТЕСТ ПЛАН зазвичай покриває якусь ЧАСТИНУ тестування чи окремий реліз.

Що таке стратегія тестування (test strategy)?

Стратегія тестування (test strategy) - це загальний спосіб проведення тестування на кожному з рівнів тестування, незалежно від проекту, у всій організації.

Що таке Reactive стратегія?

Стратегія, схильна до змін.ТЕСТИ МОЖУТЬ ЗМІНЮВАТИСЬ залежно від отриманих результатів тестування. Пріоритети у тестуванні також можуть змінюватись, залежно від поточної ситуації.

Що таке Directed (consultative) стратегія?

Стратегія, що спирається на ПОРАДИ, рекомендації, інструкції від СТЕЙКХОЛДЕРІВ чи ЕКСПЕРТІВ доменної галузі, технологічних експертів. Такі експерти можуть бути з компанії або запрошені з-за.

Що таке Process-compliant (standard-compliant) стратегія?

Стратегія, яка включає аналіз, дизайн і розробку тестів НА ОСНОВІ ЗОВНІШНІХ правил, СТАНДАРТІВ, законів, а також стандартів доменної області.("як правило, запрошуються зовнішні вузьконаправлені спеціалісти")

Що таке Regression-averse стратегія?

Стратегія, яка має на меті максимально СПРОСТИТИ РЕГРЕСІЮ. Найчастіше саме в цій стратегії всю регресію (ту частину, що доцільно) автоматизують. (averse неприхильний, "рус- нерасположенный") ("це стратегія мінімазації реграсії, коли немає ресурсів для підтримки великої регресії, запрошуємо AQA")

Чи потрібно фіксувати баги?

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

Що таке Analytical (Risk-based) стратегія?

Тип тестової стратегії, що базується на аналізі якихось факторів (вимог або ризиків). Тестування засноване на ризиках є прикладом аналітичного підходу, коли ТЕСТИ РОЗРОБЛЯЮТЬЯ та пріоритезуються залежно ВІД РІВНЯ РИЗИКУ.

Ким може виконуватись тестування?

Тестування може виконуватися різними людьми, які займають різні ролі: - тестувальники - інші ролі (замовник, розробник, тощо).

Що таке тестування на основі ризику (RBT - Risk-based Testing)?

Тестування на основі ризику (RBT) - це тип тестування програмного забезпечення, який базується на ймовірності ризику.

Чому надає пріоритет тестування на основі ризику?

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

Що таке Methodical стратегія?

Тип стратегії який спирається на СИСТЕМАТИЧНЕ ВИКОРИСТАННЯ будь-яких визначених НАБОРІВ ТЕСТІВ або тестових умов, таких як список найбільш ймовірних типів помилок, список важливих характеристик якості або прийняте бачення компанії на мобільний додаток або веб-сторінки.(""наприклад, сформовані шаблони з ймовірними типами помилок для інтернет-магазину"")

Що таке Model-based стратегія?

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

Що включають типові entry criteria?

Типові entry criteria включають: ● доступність тест базису ("тобто тестових вимог") ● доступність тестового оточення ● доступність інструментів для тестування ● доступність даних для тестування та інших необхідних ресурсів.

Що включають типові exit criteria?

Типові exit criteria включають: • усі заплановані тести виконані • досягнуто певного рівня покриття вимог • не залишилося невирішених high-priority або severity дефектів • всі області високого ризику були повністю протестовані, залишилися невирішеними лише незначні залишкові ризики • бюджет на тестування витрачено • графік був виконаний, наприклад, дата релізу вже настала, і продукт повинен бути випущений.

Якими можуть бути типові завдання тестувальника ("тут маємо на увазі і Manual I Automation")?

Типові завдання тестувальника: • ПЕРЕГЛЯД та СПРИЯННЯ у виконанні ТЕСТ-ПЛАНу. • АНАЛІЗ ТА ОЦІНКА ВИМОГ, user story та acceptance criteria, специфікації та моделі для перевірки (т. е. тест-базис). • Визначення та документування ТЕСТОВИХ УМОВ, а також відстеження залежності тест- кейсів, тестових умов, тест-базису ("відповідальні за створення тест-кейсів"). • Проектування, налаштування та перевірка ТЕСТОВИХ СЕРЕДОВИЩ, часто в координації із системним адмініструванням та управлінням мережею. • Дизайн та ВПРОВАДЖННЯ ТЕСТ-КЕЙСІВ та тест-процедур. • Підготовка та отримання тестових даних. ("записуємо їх в тест-кейси, беремо їх з умов") • СКЛАДАННЯ детальних ГРАФІКІВ виконання тестів. • ВИКОНАННЯ ТЕСТІВ, оцінка результатів та ДОКУМЕНТУВАННЯ ВІДХИЛЕННЯ від очікуваних результатів. • ВИКОРИСТАННЯ відповідних ІНСТРУМЕНТІВ для полегшення тестування.("для тестування API - Postman, для тестування попіксельного порівняння - Pixel Perfect") • АВТОМАТИЗАЦІЯ ТЕСТІВ у міру необхідності (може підтримуватись розробником або експертом з автоматизації тестування). • ОЦІНКА НЕФУНКЦІОНАЛЬНИХ ХАРАКТЕРИСТИК, таких як ефективність, надійність, зручність використання, сумісність та переносимість.("як правило, запрошують вузькопрофільних спеціалістів") • ПЕРЕВІРЯЄ тести, розроблені ІНШИМИ тестувальниками.

Типові метрики?

Типові метрики: ● відсоток виконаної роботи під час підготовки тест кейсів (скільки тест кейсів написано із запланованих) ("чи встигаємо з графіком на фазі тест-дизайну чи ні") ● відсоток виконаної роботи у підготовці тестового оточення ("наскільки готове тестове оточення") ● відсоток пройдених тестів (скільки failed/passed/blocked із загальної кількості) ● інформація про дефекти (скільки знайдено, скільки інцидентів, у якій області ПЗ виявлено баги ("там зможено провести більш детальне Sanity тестування тієї функціональності"), яка у них severity, скільки невирішених багів) ● рівень покриття тест базису ("чи всі вимоги покриті тест-кейсами, чи якісь покриті надлишково") ● вартість тестування ("Project manager")

У risk-based підході, для чого використовуються результати аналізу продуктових ризиків?

У risk-based підході, результати аналізу продуктових ризиків використовуються для: ● Визначення використовуваних технік тестування ● Визначення конкретних рівнів та типів тестування, які необхідно виконати (наприклад, тестування безпеки, тестування доступності) ● Визначення обсягу тестування, яке необхідно провести ("наприклад, якусь функцію потрібно більш детально протестувати, тому що там є більше продуктових ризиків (наприклад, використовувалась бібліотека (framework), яка я новою для розробників") ● Пріоритезація тестування, щоб якомога раніше виявити критичні дефекти ("у першу чергу покриваємо найбільш критичні ризики для нашої системи") ● Визначення, чи можна використовувати будь-які активності на додаток до тестування зниження ризику (наприклад, навчання недосвідчених дизайнерів, "розробників", тестувальників").

Які цілі написання баг-репортів?

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

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

Чинники, пов'язані з процесом розробки: ● стабільність та зрілість процесів в організації ("наприклад, знаємо перехід статусів баг-репортів, юзер-сторі; або знаємо, коли краще не створювати баг-репорт, а прокомікувати з розробником") ● модель розробки (Agile, послідовний) ● підхід до тестування ("аналітичний, методичний...") ● використовувані інструменти ("часто буває, що testrail висне") ● процес тестування ● дедлайни ("чи вони чіткі, чи можемо відхилитись")

Які є чинники, що впливають на трудовитрати з тестування?

Чинники, що впливають на трудовитрати з тестування: • продуктові фактори • чинники, пов'язані з процесом розробки • чинники, пов'язані з людьми • результати тестування

До чого діяльність з управління ризиками забезпечує підхід?

Щоб звести до мінімуму можливість відмови продукту, діяльність з управління ризиками забезпечує підхід до: ● Аналізу (і регулярній переоцінці) ризиків, що може піти не так ● Визначення, з якими ризиками важливо боротися ● Впровадження дій, щоб зменшити ці ризики ● Складання планів дій у разі непередбачених обставин, щоб упоратися з ризиками, якщо вони стануть фактичними подіями ("якщо ризик відбудеться, який у нас є план Б; якщо єдиний тестувальник захворіє, testrail перестав підтримуватись (робимо backup)")

Які є тестові стратегії та підходи?

• Analytical (Risk-based) • Model-based • Methodical • Process-compliant (standard-compliant) • Directed (consultative) • Regression-averse • Reactive

Які можливі недоліки незалежного тестування?

• Занадто велика ІЗОЛЯЦІЯ МОЖЕ ПОРУШИТИ необхідне СПІЛКУВАННЯ між тестувальниками та розробниками.(інша компанія, і контактування йде через одну людину, або інша країна) • Незалежне тестування може стати слабким місцем ЗА НЕСТАЧІ необхідних РЕСУРСІВ (наприклад, звинувачення у затримці релізу).(коли незалежне тестування - то тій команді може не вистачити бюджету) • РОЗРОБНИКИ можуть втратити ПОЧУТТЯ ВІДПОВІДАЛЬНОСТІ за якість, тому що можуть подумати: «Тестувальники все одно виявляють проблеми». • Незалежним тестувальникам МОЖЕ БРАКУВАТИ деякої важливої ІНФОРМАЦІЇ (наприклад, об'єкт тестування).(наприклад, якщо щось з оточенням, то команда тестувальників буде заблокована деякий час, особливо якщо є проблеми з комунікацією; або щось не занесено в вимоги- особливо в Scrum, де менш документується, ніж у Waterfall)

Що можуть включати типові завдання тест-менеджера?

• Розробка або перегляд ПОЛІТИКИ та СТРАТЕГІЇ тестування для організації. • ПЛАНУВАННЯ тестових АКТИВНОСТЕЙ з урахуванням контексту та розуміння цілей та ризиків тестування. Це може включати вибір ПІДХОДІВ до тестування, оцінку часу, зусиль та витрат на тестування, отримання ресурсів, визначення рівнів тестування та циклів тестування, а також планування управління дефектами. • Складання та РЕДАГУВАННЯ тест-планів. • КООРДИНУВАННЯ ТЕСТ-ПЛАНІВ з project manager, product owner та іншими. • ІНІЦЮЮВАННЯ аналізу, проектування, впровадження та виконання тестів, ВІДСТЕЖУВАННЯ ходу та результатів тестування, а також перевірка досягнення EXIT CRITERIA (або definition of done).("Визначає, як будуть проектуватись тест-кейси (чи може будуть використовуватись чек-листи), слідкує за графіком, дії щодо коректив") • Введення та ЗБИРАННЯ відповідних МЕТРИК.("кількість дефектів на проекті, кількість витраченого часу, кількість "дефектів" (тобто зауважень, які по суті не визнались дефектами)") • ПРОСУВАННЯ ТА ЗАХИСТ ТЕСТУВАЛЬНИКІВ всередині компанії. • ПІДВИЩЕННЯ ЕКСПЕТРНОСТІ команди тестування.

Як виконується техніка оцінки за трьома точками?

● Декомпозуємо беклог вимог ("ділимо на маленькі частини") ● Оцінюємо, скільки тест-кейсів нам буде потрібно написати для тестування даного беклогу ● Оцінюємо, скільки часу нам потрібно для написання одного тест-кейсу і множимо на загальну кількість тест-кейсів ("опираємось на свій досвід, або на метриках, зібраних з попередніх проектів, ...краще взяти з запасом") ● Оцінюємо, скільки часу нам потрібно для виконання тестування базуючись на одному тест-кейсі і множимо на загальну кількість тест-кейсів ("опираємось на свій досвід, або на метриках, зібраних з попередніх проектів, ...краще взяти з запасом") ● Оцінюємо, скільки приблизно у нас може виникнути дефектів в рамках реалізації вимог з беклогу (припущення) ● Оцінюємо, скільки часу нам потрібно для заведення одного баг-репорту і множимо на загальну кількість баг-репортів (з припущення) ● Оцінюємо, скільки часу нам потрібно на ретест одного дефекту і множимо на загальну кількість дефектів (з припущення) ● Оцінюємо, скільки часу нам потрібно на створення звітності ("наприклад, звіт з test rail") ● Враховуємо ризики, які ймовірніше відбудуться (продуктові та проектні) ● Все сумуємо і отримуємо +/- найімовірнішу оцінку наших трудовитрат на тестування (M) ● Від попередньої оцінки M віднімаємо час на ризики і отримуємо оптимістичну оцінку (O) ● До оцінки M додаємо додаткові ризики(наприклад: захворів один тестувальник, зламалось тестове оточення і потрібен додатковий час на його ремонт, тощо) і отримуємо песимістичну оцінку (P)

Які переваги незалежного тестування?

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

Які є чинники, що впливають на трудовитрати з тестування, пов'язані з людьми?

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

Які є чинники, що впливають на трудовитрати з тестування - результати тестування?

● кількість та серйозність знайдених багів ● кількість роботи, яку необхідно переробити ("більше багів, - більше часу на баг-репорти, більше часу на ретест, більше часу, щоб зробіти більш детальне регресійне тестування в даній функціональності")

Ступіні незалежності тестування (від автора; за зростанням)?

● немає незалежного тестування, розробник сам тестує свій код; ● незалежний розробник чи тестувальник, член команди розробки; наприклад, іншій розробник тестує код автора (code review); ●незалежна команда тестувальників всередині компанії, вони підзвітні ПМ або іншій менеджмент ролі; ● незалежні тестувальники з бізнес-організації (з боку кастомера) або користувачі, або тестувальники вузької спеціалізації (usability, security, performance, regulatory/compliance); ● незалежна команда тестування не з організації, що розробляє програмне забезпечення (аутсорс/аутсаф).