Основні принципи обрання інструментів (версія 3.1)
Основні міркування при виборі інструменту для організації включають:
Оцінка зрілості власної організації, її сильних і слабких сторін
Виявлення можливостей для вдосконалення процесу тестування, що підтримується інструментами
Розуміння технологій, які використовуються об’єктом тестування, для вибору інструменту, сумісного з цією технологією
Розуміння інструментів побудови та постійної інтеграції, які вже використовуються в організації, щоб забезпечити сумісність та інтеграцію інструментів
Оцінка інструменту за чіткими вимогами та об’єктивними критеріями
Розгляд того, чи доступний інструмент для безкоштовного пробного періоду (і як довго)
Оцінка постачальника (включно з навчанням, підтримкою та комерційними аспектами) або підтримка некомерційних (наприклад, з відкритим кодом) інструментів
Визначення внутрішніх вимог до коучингу та менторства у використанні інструменту
Оцінка потреб у навчанні, враховуючи навички тестування (та автоматизації тестування) тих, хто працюватиме безпосередньо з інструментами
Розгляд переваг і недоліків різних моделей ліцензування (наприклад, комерційних або з відкритим кодом)
Оцінка співвідношення витрат і вигод на основі конкретного бізнес-кейсу (за потреби)
На останньому етапі слід провести оцінку підтвердження концепції, щоб визначити, чи ефективно інструмент працює з програмним забезпеченням, що тестується, і в межах поточної інфраструктури або, якщо необхідно, визначити зміни, необхідні для цієї інфраструктури для ефективного використання інструменту.
Пілотні проєкти під час впровадження інструмента в організації (версія 3.1)
Після завершення вибору інструменту та успішного підтвердження концепції впровадження обраного інструменту в організації зазвичай починається з пілотного проєкту, який має такі цілі:
Отримання глибоких знань про інструмент, розуміння як його сильних, так і слабких сторін
Оцінка того, як інструмент відповідає існуючим процесам і практикам, і визначення того, що потрібно змінити
Прийняття стандартних способів використання, керування, зберігання та обслуговування інструменту та продуктів тестування (наприклад, прийняття рішення щодо іменування файлів і тестів, вибір стандартів кодування, створення бібліотек і визначення модульності наборів тестів)
Оцінка того, чи будуть отримані вигоди за розумних витрат
Розуміння показників, які ви бажаєте, щоб інструмент збирав і звітував, а також налаштування інструменту, щоб ці показники можна було фіксувати та звітувати
Фактори успіху при обранні інструменту (версія 3.1)
Фактори успіху для оцінки, впровадження, розгортання та постійної підтримки інструментів в організації включають:
Поступове розгортання інструменту для решти організації
Адаптація та вдосконалення процесів відповідно до використання інструменту
Проведення тренінгів, інструктажу та наставництва для користувачів інструментів
Визначення вказівок щодо використання інструменту (наприклад, внутрішні стандарти для автоматизації)
Реалізація способу збору інформації про використання під час фактичного використання інструменту
Використання інструментів моніторингу та переваги
Надання підтримки користувачам даного інструменту
Збір уроків, отриманих від усіх користувачів
Також важливо переконатися, що інструмент технічно та організаційно інтегрований у життєвий цикл розробки програмного забезпечення, який може залучати окремі організації, відповідальні за операції, або сторонніх постачальників.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 6.2.
В цьому відео починаємо працювати з секцію 6.2. 00:00:45 Main Principles for Tool Selection (V 3.1) 00:12:21 Pilot Projects for Introducing a Tool into an Organization (V 3.1) 00:15:47 Success Factors for Tools (V 3.1)
Інструменти тестування можна використовувати для підтримки однієї або кількох дій тестування. До таких засобів відносяться:
Інструменти, які безпосередньо використовуються під час тестування, наприклад інструменти виконання тестів і інструменти підготовки тестових даних
Інструменти, які допомагають керувати вимогами, тестовими випадками, процедурами тестування, сценаріями автоматизованого тестування, результатами тестування, тестовими даними та дефектами, а також для звітування та моніторингу виконання тесту
Інструменти, які використовуються для аналізу та оцінки
Будь-який інструмент, який допомагає у тестуванні (електронна таблиця також є інструментом тестування в цьому значенні)
Класифікація інструментів тестування (версія 3.1)
Залежно від контексту інструменти тестування можуть мати одну або декілька з наступних цілей:
Підвищення ефективності тестування шляхом автоматизації повторюваних завдань або завдань, які потребують значних ресурсів, коли виконуються вручну (наприклад, виконання тесту, регресійне тестування)
Підвищення ефективності тестування шляхом підтримки ручного тестування протягом усього процесу тестування
Поліпшення якості тестової діяльності, дозволяючи більш послідовне тестування та вищий рівень відтворюваності дефектів
Автоматизація дій, які неможливо виконати вручну (наприклад, широкомасштабне тестування продуктивності)
Підвищення надійності тестування (наприклад, шляхом автоматизації порівняння великих даних або моделювання поведінки)
Інструменти можна класифікувати за кількома критеріями, такими як призначення, ціна, модель ліцензування (наприклад, комерційна чи з відкритим кодом) і використовувана технологія. Інструменти класифіковані в цій навчальній програмі відповідно до тестових дій, які вони підтримують.
Деякі інструменти чітко підтримують лише або переважно одну дію; інші можуть підтримувати більше однієї діяльності, але класифікуються за діяльністю, з якою вони найбільш тісно пов’язані. Інструменти від одного постачальника, особливо ті, які були розроблені для спільної роботи, можуть надаватися як інтегрований пакет.
Деякі типи інструментів тестування можуть бути нав’язливими, що означає, що вони можуть вплинути на фактичний результат тесту. Наприклад, фактичний час відповіді для програми може відрізнятися через додаткові інструкції, які виконує інструмент тестування продуктивності, або обсяг досягнутого покриття коду може бути спотворений через використання інструменту покриття. Наслідки використання інтрузивних інструментів називають ефектом зонда.
Деякі інструменти пропонують підтримку, яка зазвичай більше підходить для розробників (наприклад, інструменти, які використовуються під час тестування компонентів та інтеграції). Такі інструменти позначені «(D)».
Підтримка інструментів для керування тестуванням і тестовим програмним забезпеченням
Інструменти керування можуть застосовуватися до будь-яких тестових дій протягом усього життєвого циклу розробки програмного забезпечення. Приклади інструментів, які підтримують керування тестуванням і тестовим програмним забезпеченням, включають:
Інструменти керування тестами та інструменти керування життєвим циклом додатків (ALM)
Інструменти керування вимогами (наприклад, відстеження до об’єктів тестування)
Інструменти управління дефектами
Інструменти керування конфігурацією
Інструменти безперервної інтеграції (D)
Підтримка інструментів для статичного тестування
Інструменти статичного аналізу (D)
Підтримка інструментів для проєктування та впровадження тестів
Інструменти розробки тестів допомагають у створенні придатних для обслуговування робочих продуктів у проєктуванні та реалізації тестів, включаючи тестові випадки, тестові процедури та тестові дані. Приклади таких інструментів:
Інструменти тестування на основі моделі
Засоби підготовки тестових даних
У деяких випадках інструменти, які підтримують розробку та впровадження тестів, також можуть підтримувати виконання тестів і журналювання або надавати свої результати безпосередньо іншим інструментам, які підтримують виконання тестів і журналювання.
Підтримка інструментів для виконання тестів і журналювання
Існує багато інструментів для підтримки та вдосконалення виконання тестів і ведення журналів. Приклади цих інструментів:
Інструменти виконання тестів (наприклад, для запуску регресійних тестів)
Інструменти покриття (наприклад, покриття вимог, покриття коду (D))
Перевірка джгутів (D)
Підтримка інструментів для вимірювання продуктивності та динамічного аналізу
Інструменти вимірювання продуктивності та динамічного аналізу є важливими для підтримки діяльності з тестування продуктивності та навантаження, оскільки ці дії неможливо ефективно виконати вручну. Приклади цих інструментів:
Інструменти тестування продуктивності
Інструменти динамічного аналізу (D)
Підтримка інструментів для потреб спеціалізованого тестування
На додаток до інструментів, які підтримують загальний процес тестування, існує багато інших інструментів, які підтримують більш специфічне тестування нефункціональних характеристик.
Інструментальна підтримка тестування (версія 4.0)
Інструменти тестування підтримують і полегшують багато видів тестування. Приклади включають, але не обмежуються:
Інструменти управління – підвищення ефективності процесу тестування шляхом полегшення керування SDLC, вимогами, тестами, дефектами, конфігурацією
Інструменти статичного тестування – підтримують тестувальника у виконанні оглядів і статичного аналізу
Інструменти розробки та реалізації тестів – полегшують створення тестових випадків, тестових даних і тестових процедур
Інструменти виконання тестів і охоплення – полегшують автоматизоване виконання тестів і вимірювання охоплення
Нефункціональні інструменти тестування – дозволяють тестувальнику виконувати нефункціональне тестування, яке важко або неможливо виконати вручну
Інструменти, що підтримують масштабованість і стандартизацію розгортання (наприклад, віртуальні машини, інструменти контейнеризації)
Будь-який інший інструмент, який допомагає у тестуванні (наприклад, електронна таблиця є інструментом тестування в контексті тестування)
Переваги та ризики автоматизації тестування (версія 3.1)
Просто придбання інструменту не гарантує успіху. Кожен новий інструмент, запроваджений в організації, вимагатиме зусиль для досягнення реальних і тривалих переваг. Існують потенційні переваги та можливості використання інструментів у тестуванні, але є й ризики. Особливо це стосується інструментів виконання тестів (які часто називають автоматизацією тестування).
Потенційні переваги використання інструментів для підтримки виконання тесту включають:
Зменшення повторюваної ручної роботи (наприклад, запуск регресійних тестів, завдання налаштування/видалення середовища, повторне введення тих самих тестових даних і перевірка на відповідність стандартам кодування), що економить час
Більша узгодженість і повторюваність (наприклад, тестові дані створюються узгодженим чином, тести виконуються інструментом у тому самому порядку з тією ж частотою, а тести послідовно виводяться на основі вимог)
Більш об’єктивне оцінювання (наприклад, статичні вимірювання, охоплення)
Спрощений доступ до інформації про тестування (наприклад, статистичні дані та графіки про хід тестування, рівень дефектів і продуктивність)
Потенційні ризики використання інструментів для підтримки тестування включають:
Очікування щодо інструменту можуть бути нереалістичними (включно з функціональністю та простотою використання)
Час, вартість і зусилля для початкового впровадження інструменту можуть бути недооцінені (включаючи навчання та зовнішню експертизу)
Час і зусилля, необхідні для досягнення значних і постійних переваг від інструменту, можуть бути недооцінені (включаючи необхідність змін у процесі тестування та постійного вдосконалення способу використання інструменту)
Зусилля, необхідні для підтримки тестових робочих продуктів, створених інструментом, можуть бути недооцінені
На інструмент можна покладатися занадто багато (розглядається як заміна дизайну або виконання тесту або використання автоматизованого тестування, де ручне тестування було б кращим)
Контроль версій тестових робочих продуктів можна знехтувати
Проблеми взаємозв’язку та сумісності між критично важливими інструментами, такими як інструменти керування вимогами, інструменти керування конфігурацією, інструменти керування дефектами та інструменти від багатьох постачальників, можуть бути знехтувані
Постачальник інструменту може припинити діяльність, вилучити інструмент з експлуатації або продати інструмент іншому постачальнику
Постачальник може надати погану відповідь щодо підтримки, оновлень і виправлення дефектів
Проєкт з відкритим кодом може бути призупинено
Інструмент може не підтримувати нову платформу чи технологію
Може не бути чіткого права власності на інструмент (наприклад, для наставництва, оновлень тощо)
Переваги та ризики автоматизації тестування (версія 4.0)
Просто придбання інструменту не гарантує успіху. Кожен новий інструмент вимагатиме зусиль для досягнення реальних і тривалих переваг (наприклад, для впровадження інструменту, обслуговування та навчання). Існують також деякі ризики, які потребують аналізу та пом’якшення.
Потенційні переваги використання автоматизації тестування включають:
Економія часу завдяки зменшенню повторюваної ручної роботи (наприклад, виконання регресійних тестів, повторне введення тих самих даних тесту, порівняння очікуваних результатів із фактичними результатами та перевірка на відповідність стандартам кодування)
Запобігання простим людським помилкам завдяки більшій послідовності та повторюваності (наприклад, тести послідовно виводяться з вимог, дані тестів створюються систематично, а тести виконуються інструментом у тому самому порядку з тією ж частотою)
Більш об’єктивна оцінка (наприклад, охоплення) і надання показників, які є надто складними для визначення людьми
Спрощений доступ до інформації про тестування для підтримки управління тестуванням і звітності про тестування (наприклад, статистичні дані, графіки та зведені дані про хід тестування, рівень дефектів і тривалість виконання тесту)
Скорочений час виконання тесту для забезпечення раннього виявлення дефектів, швидшого зворотного зв’язку та швидшого часу виходу на ринок
Більше часу для тестувальників для розробки нових, глибших і ефективніших тестів
Потенційні ризики використання автоматизації тестування включають:
Нереалістичні очікування щодо переваг інструменту (включно з функціональністю та простотою використання).
Неточні оцінки часу, витрат, зусиль, необхідних для впровадження інструменту, підтримки сценаріїв тестування та зміни існуючого ручного процесу тестування.
Використання тестового інструменту, коли ручне тестування більш доречне.
Занадто покладатися на інструмент, наприклад, ігнорувати потребу критичного мислення людини.
Залежність від постачальника інструменту, який може припинити роботу, припинити використання інструменту, продати інструмент іншому постачальнику або надати погану підтримку (наприклад, відповіді на запити, оновлення та виправлення дефектів).
Використання програмного забезпечення з відкритим вихідним кодом, яке може бути залишено, що означає відсутність доступності подальших оновлень, або його внутрішні компоненти можуть потребувати досить частих оновлень як подальший розвиток.
Інструмент автоматизації не сумісний із платформою розробки.
Вибір невідповідного інструменту, який не відповідає нормативним вимогам або стандартам безпеки.
Особливі міркування щодо виконання тестів та інструментів керування тестами (версія 3.1)
Зазначені вище підходи вимагають досвіду роботи з мовою сценаріїв (тестувальників, розробників або спеціалістів з автоматизації тестування). При використанні підходів до тестування на основі даних або ключових слів тестувальники, які не знайомі з мовою сценаріїв, також можуть зробити свій внесок, створивши тестові дані або ключові слова для цих попередньо визначених сценаріїв. Незалежно від використовуваної методики створення сценаріїв, очікувані результати для кожного тесту потрібно порівнювати з фактичними результатами тесту або динамічно (під час виконання тесту), або зберігати для подальшого порівняння (після виконання).
Інструменти тестування на основі моделі (MBT) дозволяють зафіксувати функціональну специфікацію у формі моделі, наприклад діаграми діяльності. Зазвичай це завдання виконує системний розробник. Інструмент MBT інтерпретує модель, щоб створити специфікації тестового випадку, які потім можна зберегти в інструменті керування тестами або виконати інструментом виконання тестів.
Інструменти керування тестами часто потребують взаємодії з іншими інструментами чи електронними таблицями з різних причин, зокрема:
Виробляти корисну інформацію у форматі, який відповідає потребам організації
Підтримувати постійну відстежуваність вимог у інструменті керування вимогами
Для зв’язку з інформацією про версію тестового об’єкта в інструменті керування конфігурацією
Це особливо важливо враховувати під час використання інтегрованого інструменту (наприклад, керування життєвим циклом програми), який включає модуль керування тестуванням, а також інші модулі (наприклад, графік проєкту та інформацію про бюджет), які використовуються різними групами в організації.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 6.1.
В цьому відео починаємо працювати з секцію 6.1. 00:02:17 Test Tool Considerations (v 3.1) 00:04:53 Test Tool Classification (v 3.1) 00:22:36 Tool Support for Testing (v 4.0) 00:27:21 Benefits and Risks of Test Automation 00:48:58 Special Considerations for Test Execution and Test Management Tools (V 3.1)
Незалежні тестувальники від бізнес-організації або спільноти користувачів
Незалежні спеціалісти з тестування для певних типів тестів: тестувальники юзабіліті, тестувальники безпеки тощо.
Незалежні тестувальники, надані аутсорсингом або зовнішні для організації
Завдання тестового менеджера
Планування тестування, обрання інструментів, підходів до тестування, оцінка часу, зусиль та вартості тестування, придбання, ресурсів, визначення рівнів тестування, циклів та планування управління інцидентами, вирішення, чи потрібна автоматизація
Вирішення, які тестові середовища потрібні
Представлення та аналіз показників моніторингу
Адаптація планування на основі моніторингу
Підготовка підсумкових звітів про тестування
Завдання тестувальника
Створення специфікації тесту та перегляд тестів
Використання інструментів адміністрування та керування тестами, а також інструментів моніторингу тестів
Підготувка та отримання тестових даних
Впровадження тестів на всіх рівнях тестування
Виконання, автоматизація тестів
Перегляд планів тестування та внесення свго внеску у них
Тестове планування
Структура документа з планування тестування охоплюється «Стандартом документації тестування програмного забезпечення» (IEEE 829, попередня але все ще багато в чому актуальна версія):
Політика тестування (організація)
Стратегія тестування (продукт)
Генеральний план тестування (проєкт)
План перевірки рівня (деталі)
Завдання тестового планування
Підхід до тестування та процедури тестування, включаючи визначення рівнів тестування та критеріїв входу та виходу
Ризики та цілі тестування
Що тестувати, які ролі виконуватимуть тестову діяльність, які потрібні ресурси та хто їх використовуватиме
Як повинні проводитися тестові дії, як будуть оцінюватися результати тестування
Метрики для моніторингу та контролю підготовки та виконання тестів, усунення дефектів і проблем із ризиками
Планування аналізу та проєктування тестів, впровадження, виконання та оцінювання тестів
Тестова документація: обсяг, рівень деталізації, структура та шаблони
Інтеграція та координація діяльності з тестування в діяльність життєвого циклу програмного забезпечення
План тестування
План тестування містить наступні елементи:
Ідентифікатор плану тестування
Список літератури
Вступ
Тестові елементи
Ризики програмного забезпечення
Функції для перевірки
Функції, які не підлягають тестуванню
Підхід
Критерії проходження/непроходження предмета
Критерії призупинення/відновлення
Результати тестування
Тестові завдання, що залишилися
Потреби середовища
Потреби в кадрах і навчанні
Обов’язки
Розклад
Планування ризиків і непередбачених ситуацій
Дозволи
Глосарій
Критерії входу/виходу
Entry Criteria
Exit Criteria
Наявність та готовність тестового середовища
Метрики ретельності, такі як покриття коду, функціональність або ризик
Готовність тестових інструментів у тестовому середовищі
Оцінка щільності дефектів або метриків надійності
Наявність коду, який можливо тестувати
Варість
Наявність тестових даних
Графіки такі як ті, що базуються на часі до виходу на ринок
Залишкові ризики, такі як невиправлені дефекти або нестача тестового покриття в певних областях
Entry and Exit Criteria
Тестова оцінка
Підхід на основі показників або підхід на основі експертної думки
Характеристики продукту: тестова база, розмір продукту, складність предметної області, вимоги
Характеристики процесу розробки: стабільність організації, інструменти, що використовуються, процес тестування, навички залучених людей і тиск часу
Результат тестування: кількість дефектів і обсяг необхідних доопрацювань
Тестові процеси моніторингу та контролю
Щільність дефектів – кількість дефектів, виявлених у компоненті чи системі, поділена на розмір компонента чи системи (виражений у стандартних термінах вимірювання, наприклад, рядків коду, кількість класів або функціональних точок)
Частота збоїв – кількість збоїв за одиницю часу, кількість збоїв у кількості транзакцій, кількість збоїв у кількості запусків комп’ютера.
Моніторинг прогресу тестування
Забезпечте зворотній зв’язок і наочність щодо тестової діяльності
Метрики використовуються для оцінки прогресу
Відсоток виконаної роботи при підготовці тесту
Відсоток виконаної роботи з підготовки тестового середовища
Інформація про дефекти
Тестове покриття вимог, ризиків або коду
Суб’єктивна довіра тестувальників до продукту
Дати тестових контрольних точок
Витрати на тестування, включаючи вартість майбутніх знайдених помилок
Тестова звітність
Опис підсумкового звіту про тестування наведено в «Стандарті документації тестування програмного забезпечення» (IEEE 829).
Узагальнення інформації про тестування
Що сталося під час тестування
Проаналізована інформація та досягнуті показники
Досягнуті результати: адекватність цілей тесту для цього рівня тесту, адекватність використаних тестових підходів, ефективність тестування щодо поставлених цілей.
Тестовий контроль
Тестовий контроль описує будь-які керівні чи коригувальні дії під час тестового циклу:
Прийняття рішень на основі інформації тестового моніторингу
Зміна пріоритетів тестів
Зміна розкладу тестування через наявність або відсутність тестового середовища
Зміна критерію вступу
Управління конфігураціями
Встановити та підтримувати цілісність продуктів. Все має бути пов’язано. Керування конфігурацією допомагає:
Унікально ідентифікувати (і відтворити) тестований елемент, тестові документи, тести та тестові джгути
Контролювати зміни цих характеристик
Записувати та повідомляти про зміни
Статус обробки та реалізації
Перевірка відповідності встановленим вимогам
Ризик і тестування
Ризик можна визначити як можливість того, що подія станеться та призведе до потенційної проблеми. Рівень ризику визначатиметься ймовірністю та впливом.
Проєктні Ризики
Проєктні ризики – це ризики, пов’язані зі здатністю проєкту досягати своїх цілей.
Потенційні області збою в програмному забезпеченні або системі відомі як ризики продукту.
Проектні ризики
Продуктові ризики
Організаційні фактори (люди та навички)
Поставлено схильне до збоїв ПЗ
Технічні проблеми (вимоги, середовище, код)
Імовірність того, що програмне/апаратне забезпечення може завдати шкоди особі чи компанії
Питання постачальника
Низькі характеристики програмного забезпечення (наприклад, функціональність, надійність, зручність використання та продуктивність) і цілісність даних
Договірні питання
Програмне забезпечення, яке не виконує своїх призначених функцій
Project risks
Підхід заснований на ризику
Створіть проактивні можливості для зниження рівня ризику продукту, починаючи з початкових етапів проекту:
Визначте методи тестування, які необхідно використовувати
Визначте обсяг тестування, яке необхідно провести
Надайте пріоритет тестуванню, щоб якомога раніше виявити критичні дефекти
Визначте, чи можна використовувати будь-яку діяльність, не пов’язану з тестуванням, для зменшення ризику (наприклад, навчання недосвідчених спеціалістів)
Управління дефектами (статуси)
Розбір тестових питань по п’ятому розділу
ISTQB Certified Tester Foundation Level. Курс для початківців. Розділ 5. Практика.
В цьому відео робиться спроба розібрати кілька десятків питань по п’ятому розділу сілабусу ISTQB CTFL.
Всі питання з відео з правильними відповідями наводяться нижче.
Question 1
Which of the following metrics would be most useful to monitor during test execution?
Percentage of requirements for which a test has been written.
Number of defects found and fixed.
Number of test environments remaining to be configured.
Percentage of test cases written.
Question 2
Which of the following is most likely to be mentioned as a project risk?
Unexpected illness of a key team member
Data corruption under network congestion
Failure to handle a key use case
Excessively slow transaction-processing time
Question 3
A test engineer is testing a Video Player (VCR), and logs the following report: Title: Fast Forward stops after 2 minutes. It happens every time Expected result: Fast forward continues till the end of the tape Severity: High Priority: Urgent What important information did the engineer leave out?
Ideas for the test case improvement
History of the report
Actual result
Identification (Software and hardware) of the VCR
Question 4
Which of the following risks represents the highest level of risk to the project:
Likelihood of failure = 1%, potential cost of impact = $1 m.
Likelihood of failure = 10%, potential cost of impact = $500,000.
Likelihood of failure = 20%, potential cost of impact = $150,000.
Likelihood of failure = 5%, potential cost of impact = $500,000.
Question 5
A product risk analysis meeting is held during the project planning period. Which of the following determines the level of risk?
The price for which the software is sold
Difficulty of fixing related problems in code
The technical staff in the meeting
The harm that might result to the user
Question 6
Which of the following statements is most true about test conditions?
An item or event of a component or system that can be verified by one or more test cases.
The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
A testable component derived from business requirements.
Applies to software testing only.
Question 7
A Test Plan Outline contains which of the following: (i.) Test Items (ii.) Test Scripts (iii.) Test Deliverables (iv.) Responsibilities
i,ii are false and iii , iv are true
i,iii,iv are true and ii is false
i,ii,iii are true and iv is false
ii,iii are true and i and iv are false
Question 8
According to the ISTQB Glossary, a product risk is related to which of the following?
A single test item
The test object
Control of the test project
A potential negative outcome
Question 9
According to the ISTQB Glossary, what do we call a document that describes any event that occurred during testing which requires further investigation?
An incident report
A test summary report
A bug report
A defect report
Question 10
According to the ISTQB Glossary, what do we mean when we call someone a test manager?
A test manager manages a collection of test leaders.
A test manager gets paid more than a test leader.
A test manager is the leader of a test team or teams.
A test manager reports to a test leader.
Question 11
According to the ISTQB Glossary, what is a test level?
An ISTQB certification.
A test type.
A group of test activities that are organized together.
One or more test design specification documents.
Question 12
Based on the IEEE Standard for Software Test Documentation (IEEE Std 829), which of the following sections are part of the test summary report? (a.) Summary (b.) Test incident report identifier (c.) Test deliverables (d.) Risks and contingencies (e.) Variances (f.) Approvals (g.) Output specifications
a, c and d
a, b and f
a, d and e
a, e and f
Question 13
During test execution, the test manager describes the following situation to the project team: ‘90% of the test cases have been run. 20% of the test cases have identified defects. 127 defects have been found. 112 defects have been fixed and have passed confirmation testing. Of the remaining 15 defects, project management has decided that they do not need to be fixed prior to release.’ Which of the following is the most reasonable interpretation of this test status report?
The remaining 15 defects should be confirmation tested prior to release.
The programmers should focus their attention on fixing the remaining known defects prior to release.
The remaining 10% of test cases should be run prior to release.
The system is now ready for release with no further testing or development effort.
Question 14
Given the following sets of test management terms (v-z), and activity description (1-5), which one of the following best pairs the two sets? v – Test control. w – Test monitoring. x – Test estimation. y – Incident management. z – Configuration control.
1 – Calculation of required test resources. 2 – Maintenance of record of test results. 3- Re-allocation of resources when tests overrun. 4 – Report on deviation from test plan. 5 – Tracking of anomalous test results.
v-3, w-4, x-1, y-5, z-2
v-2, w-5, x-1, y-4, z-3
v-3, w-2, x-1, y-5, z-4
v-2, w-1, x-4, y-3, z-5
Question 15
From a Testing perspective, what are the MAIN purposes of Configuration Management?: (i) Identifying the version of software under test. (ii) Controlling the version of testware items. (iii) Developing new testware items. (iv) Tracking changes to test ware items. (v) Analysing the need for new testware items.
i, ii and iv.
i, iii and v.
ii, iii and iv,
ii, iv and v.
Question 16
In a risk-based approach the risks identified may be used to : (i.) Determine the test technique to be employed (ii.) Determine the extent of testing to be carried out (iii.) Prioritize testing in an attempt to find critical defects as early as possible. (iv.) Determine the cost of the project
ii is True; i, iii, iv are False
i,ii,iii are true and iv is false
ii & iii are True; i, iv are False
ii, iii & iv are True; i is false
Question 17
In an incident report, the tester makes the following statement, At this point, I expect to receive an error message explaining the rejection of this invalid input and asking me to enter a valid input. Instead the system accepts the input, displays an hourglass for between one and five seconds and finally terminates abnormally, giving the message, “Unexpected data type: 15.Click to continue.” ‘ This statement is likely to be found in which of the following sections of an IEEE 829 standard incident report?
Item pass/fail criteria
Summary
Impact
Incident description
Question 18
Metrics collected during testing includes
System test cases planned / executed / passed.
Discrepancies reported / resolved.
Staff hours.
All of the above.
Question 19
Poor software characteristics are
Only Project risks
Only Product risks
Project risks and Product risks
Project risks or Product risks
Question 20
The following best describes the defect density:
Ratio of discovered errors per size of code.
Number of modifications made per size of code.
Number of failures reported against the code.
Ratio of failure reports received per unit of time.
Question 21
Which of the following processes ensures that all items of testware are identified, version controlled, tracked for changes, so that traceability can be maintained throughout the test process?
Software traceability process
Incidence management process
Testing design process
Configuration management process
Question 22
The ISTQB Foundation Syllabus establishes a fundamental test process where test planning occurs early in the project, while test execution occurs at the end. Which of the following elements of the test plan, while specified during test planning, is assessed during test execution?
Test tasks
Test team training
Exit criteria
Environmental needs
Question 23
What is the KEY difference between preventative and reactive approaches to testing?
Preventative testing is always analytical; reactive testing is always heuristic.
Preventative tests are designed after the software has been produced; reactive tests are designed early in response to review comments.
Preventative tests and reactive tests are designed as early as possible.
Preventative tests are designed early; reactive tests are designed after the software has been produced.
Question 24
What is the primary difference between the test plan, the test design specification, and the test procedure specification?
The test plan is for managers, the test design specification is for programmers and the test procedure specification is for testers who are automating tests.
The test plan is the least thorough, the test procedure specification is the most thorough and the test design specification is midway between the two.
The test plan describes one or more levels of testing, the test design specification identifies the associated high-level test cases and a test procedure specification describes the actions for executing a test.
The test plan is finished in the first third of the project, the test design specification is finished in the middle third of the project and the test procedure specification is finished in the last third of the project.
Question 25
What needs to be done when there is an insufficient time for testing 1. Do Ad-hoc testing. 2. Do usability testing. 3. Do sanity testing. 4. Do a risk based analysis to prioritize.
1 and 2.
3 & 4.
All of the above.
None of the above.
Question 26
What is Risk analysis?
Evaluating risks.
Evaluating controls.
Evaluating vulnerabilities.
All of the above.
Question 27
Which factors contribute to humans making mistakes that can lead to faulty software? (I.) Setting aggressive schedule (II.) Integrating complex systems (III.) Allocating adequate resources (IV.) Failing to control changes
I, II and IV are true; III is false
II and IV are true; I and III are false
I, II and III are true; IV is false
I and II are true; III and IV are false
Question 28
What content would be in an incident report if that incident report was based on the IEEE 829 Standard for Software Test Documentation? (i). Identification of configuration items of the software or system. (ii). Software or system lifecycle process in which the incident was observed. (iii). Description of the anomaly to enable reproduction of the incident. (iv). Number of occurrences of the incident. (v). Classification of the cause of the incident for metrics and for reporting purposes.
i, ii, iii
ii, iii
i, iii, iv
i, ii, iii, v
Question 29
Why is independent testing important?
Independent testing is more effective at finding defects.
Independent testers should determine the processes and methodologies used.
Independent testers are dispassionate about whether the project succeeds or fails.
Independent testing is usually cheaper than testing your own work.
Question 30
Which of the following is among the typical tasks of a test leader?
Keep tests and test coverage hidden from programmers.
Develop system requirements, design specifications and usage models.
Handle all test automation duties.
Gather and report test progress metrics.
Question 31
Which of the following factors is an influence on the test effort involved in most projects?
The departure of the test manager during the project.
Unexpected long-term illness by a member of the project team.
The quality of the information used to develop the tests.
Geographical separation of tester and programmers.
Оскільки однією з цілей тестування є виявлення дефектів, дефекти, виявлені під час тестування, слід реєструвати. Спосіб реєстрації дефектів може відрізнятися залежно від контексту компонента або системи, що тестується, рівня тестування та моделі життєвого циклу розробки програмного забезпечення. Будь-які виявлені дефекти слід досліджувати та відстежувати від виявлення та класифікації до їх усунення (наприклад, виправлення дефектів і успішне підтверджувальне тестування рішення, відкладення наступного релізу, прийняття як постійне обмеження продукту тощо). Для того, щоб керувати всіма дефектами до вирішення, організація повинна встановити процес управління дефектами, який включає робочий процес і правила класифікації. Цей процес має бути узгоджений з усіма, хто бере участь в управлінні дефектами, включаючи архітекторів, дизайнерів, розробників, тестувальників і власників продуктів. У деяких організаціях реєстрація дефектів і відстеження можуть бути дуже неформальними.
Під час процесу керування дефектами деякі звіти можуть описувати помилкові спрацьовування, а не фактичні збої через дефекти. Наприклад, тест може бути невдалим, якщо мережеве з’єднання розірвано або минув час очікування. Така поведінка не є результатом дефекту тестового об’єкта, а є аномалією, яку необхідно дослідити. Тестери повинні намагатися звести до мінімуму кількість помилкових спрацьовувань, про які повідомляється як про дефекти.
Про дефекти можна повідомляти під час кодування, статичного аналізу, оглядів або під час динамічного тестування чи використання програмного продукту. Про дефекти можна повідомити через проблеми в коді чи робочих системах або в будь-якій документації, включаючи вимоги, історії користувачів і критерії прийнятності, документи розробки, тестові документи, посібники користувача або посібники зі встановлення. Щоб мати дієвий і ефективний процес управління дефектами, організації можуть визначити стандарти для атрибутів, класифікації та робочого процесу дефектів.
Типові звіти про дефекти мають такі цілі:
Надайте розробникам та іншим сторонам інформацію про будь-яку несприятливу подію, що сталася, щоб вони могли визначити конкретні наслідки, ізолювати проблему за допомогою мінімального відтворювального тесту та виправити потенційний дефект за потреби або іншим чином вирішити проблему
Надайте менеджерам тестування засоби відстеження якості робочого продукту та впливу на тестування (наприклад, якщо повідомляється про багато дефектів, тестувальники витрачатимуть багато часу на звітування про них замість того, щоб запускати тести, і буде потрібно більше підтверджуючих тестувань)
Надати ідеї для розробки та вдосконалення процесу тестування
Звіт про дефект, поданий під час динамічного тестування, зазвичай містить:
Ідентифікатор
Назва та короткий опис дефекту, про який повідомляється
Дата звіту про дефект, організація, та автор
Ідентифікація тестового елемента (елемента конфігурації, що тестується) і середовища
Фаза життєвого циклу розробки, на якій спостерігався дефект
Опис дефекту, щоб зробити можливим відтворення та вирішення, включаючи журнали, дампи бази даних, знімки екрана або записи (якщо їх виявлено під час виконання тесту)
Очікувані та фактичні результати
Масштаб або ступінь впливу (серйозності) дефекту на інтереси зацікавлених сторін
Терміновість/пріоритет виправлення
Стан звіту про дефект (наприклад, відкрито, відкладено, дублікат, очікує на виправлення, очікує тестування підтвердження, повторно відкрито, закрито)
Висновки, рекомендації та схвалення
Глобальні проблеми, наприклад інші області, на які можуть вплинути зміни внаслідок дефекту
Історія змін, як-от послідовність дій, виконаних членами команди проєкту щодо дефекту, щоб ізолювати, виправити та підтвердити його як виправлений
Посилання, включаючи тест кейс, який виявив проблему
Деякі з цих деталей можуть бути автоматично включені або керовані під час використання інструментів управління дефектами, наприклад, автоматичне призначення ідентифікатора, призначення та оновлення стану звіту про дефекти під час робочого процесу тощо. Дефекти, виявлені під час статичного тестування, зокрема переглядів, зазвичай документуються в інший спосіб, наприклад, у примітках до наради з перегляду.
Приклад змісту звіту про дефект можна знайти в стандарті ISO (ISO/IEC/IEEE 29119-3), де звіти про дефекти називаються звітами про інциденти.
Управління дефектами (версія 4.0)
Оскільки однією з основних цілей тестування є виявлення дефектів, налагоджений процес управління дефектами має важливе значення. Незважаючи на те, що тут ми говоримо про «дефекти», повідомлені аномалії можуть виявитися справжніми дефектами або чимось іншим (наприклад, помилковим спрацьовуванням, запитом на зміну) — це вирішується під час обробки звітів про дефекти. Про аномалії можна повідомити на будь-якому етапі SDLC, а форма залежить від SDLC. Як мінімум, процес управління дефектами включає робочий процес для обробки окремих аномалій від їх виявлення до їх закриття та правила для їх класифікації. Робочий процес, як правило, включає дії з реєстрації повідомлених аномалій, їх аналізу та класифікації, прийняття рішення щодо належної відповіді, як-от виправити чи залишити все як є, і, нарешті, закрити звіт про дефекти. За цим процесом повинні стежити всі зацікавлені сторони. Бажано обробляти дефекти статичного тестування (особливо статичного аналізу) подібним чином.
Типові звіти про дефекти мають такі цілі:
Надати особам, відповідальним за обробку та усунення повідомлених дефектів, достатньо інформації для вирішення проблеми
Забезпечити засоби відстеження якості робочого продукту
Надати ідеї щодо вдосконалення розробки та процес тестування
Звіт про дефект, який реєструється під час динамічного тестування, зазвичай містить:
Унікальний ідентифікатор
Назва з коротким описом аномалії, про яку повідомляється
Дата, коли була помічена аномалія, організація, та автор, включаючи роль
Ідентифікація тестового об’єкта та тестового середовища
Контекст дефекту (наприклад, тестовий кейс, що виконується, тестова діяльність, фаза SDLC та інша відповідна інформація, така як методика тестування, контрольний список або тестові дані, що використовуються)
Опис збою, щоб уможливити відтворення та вирішення, включаючи кроки, які виявили аномалію, а також будь-які відповідні журнали тестування, дампи бази даних, знімки екрана або записи
Очікувані та фактичні результати
Серйозність дефекту (ступінь впливу) на інтереси зацікавлених сторін або вимоги
Пріоритет виправлення
Статус дефекту (наприклад, відкрито, відкладено, дублікат, очікує на виправлення, очікує перевірки підтвердження, повторно відкрито, закрито, відхилено)
Посилання (наприклад, на тестовий приклад)
Деякі з цих даних можуть автоматично включатися під час використання інструментів керування дефектами (наприклад, ідентифікатор, дата, автор і початковий статус). Шаблони документів для звіту про дефекти та приклади звітів про дефекти можна знайти в стандарті ISO/IEC/IEEE 29119-3, де звіти про дефекти називаються звітами про інциденти.
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 5.6.
В цьому відео починаємо працювати з секцію 5.6. 00:00:54 Defect Management 00:08:50 Defect reporting 00:13:19 Defect Report
Організації стикаються з багатьма внутрішніми та зовнішніми факторами, які роблять невизначеним питання, чи досягнуть вони своїх цілей і коли (ISO 31000). Управління ризиками дозволяє організаціям підвищити ймовірність досягнення цілей, покращити якість своєї продукції та підвищити впевненість і довіру зацікавлених сторін.
Основними видами діяльності з управління ризиками є:
Аналіз ризику (що складається з ідентифікації та оцінки ризику)
Контроль ризику (складається з пом’якшення ризику та моніторингу ризику)
Тестовий підхід, у якому тестові дії вибираються, пріоритезуються та керуються на основі аналізу та контролю ризиків, називається тестуванням на основі ризиків.
Визначення ризику(версія 3.1)
Ризик передбачає можливість події в майбутньому, яка матиме негативні наслідки. Рівень ризику визначається ймовірністю події та наслідками (шкодою) від цієї події.
Визначення ризику(версія 4.0)
Ризик – це потенційна подія, небезпека, загроза або ситуація, виникнення якої викликає несприятливий ефект. Ризик можна охарактеризувати двома факторами:
Імовірність ризику – ймовірність виникнення ризику (більша за нуль і менша за одиницю)
Вплив ризику (шкода) – наслідки цієї події
Ці два фактори виражають рівень ризику, який є мірою ризику. Чим вищий рівень ризику, тим важливіше управління цим ризиком.
Ризики продукту і ризики проєкту (версія 3.1)
Ризик продукту передбачає можливість того, що робочий продукт (наприклад, специфікація, компонент, система або тест) може не задовольнити законні потреби своїх користувачів або зацікавлених сторін. Коли ризики продукту пов’язані з конкретними характеристиками якості продукту (наприклад, функціональна придатність, надійність, ефективність продуктивності, зручність використання, безпека, сумісність, зручність супроводу і портативність), ризики продукту також називають ризиками якості.
Приклади ризиків продукту включають:
Програмне забезпечення може не виконувати призначені функції відповідно до специфікації
Програмне забезпечення може не виконувати призначені функції відповідно до потреб користувача, клієнта або зацікавлених сторін
Архітектура системи може недостатньо підтримувати деякі нефункціональні вимоги.
За певних обставин певне обчислення може бути виконано неправильно
Структура керування циклом може бути закодована неправильно
Час відповіді може бути недостатнім для високопродуктивної системи обробки транзакцій
Відгуки про досвід користувача (UX) можуть не відповідати очікуванням продукту
Проєктний ризик включає ситуації, які, якщо вони виникнуть, можуть негативно вплинути на здатність проєкту досягти своїх цілей. Приклади проєктних ризиків включають:
Проблеми проєкту:
Можуть виникати затримки в доставці, виконанні завдання або задоволенні критеріїв виходу чи визначення виконаного
Неточні оцінки, перерозподіл коштів на проєкти з вищим пріоритетом або загальне скорочення витрат в організації можуть призвести до недостатнього фінансування
Пізні зміни можуть призвести до значної переробки
Організаційні питання:
Навички, навчання та персонал можуть бути недостатніми
Проблеми з персоналом можуть спричинити конфлікти та проблеми
Користувачі, бізнес-персонал або експерти з певної тематики можуть бути недоступні через суперечливі бізнес-пріоритети
Політичні питання:
Тестувальники можуть не повідомляти належним чином свої потреби або результати тестування
Розробники або тестувальники можуть не врахувати інформацію, отриману під час тестування та оглядів (наприклад, не вдосконалювати практику розробки та тестування)
Можливе неправильне ставлення до тестування або очікування від нього (наприклад, недооцінка цінності пошуку дефектів під час тестування)
Технічні проблеми:
Вимоги можуть бути визначені недостатньо добре
Вимоги можуть бути не виконані через існуючі обмеження
Тестове середовище може бути не готове вчасно
Перетворення даних, планування міграції та підтримка інструментів можуть виконуватися із запізненням
Недоліки в процесі розробки можуть вплинути на послідовність або якість робочих продуктів проєкту, таких як дизайн, код, конфігурація, тестові дані та тестові випадки
Погане управління дефектами та подібні проблеми можуть призвести до накопичення дефектів та інших технічних боргів
Проблеми з постачальниками:
Третя сторона може не надати необхідний продукт чи послугу або збанкрутувати
Контрактні питання можуть спричинити проблеми для проєкту
Ризики проєкту можуть впливати як на діяльність з розробки, так і на діяльність з тестування. У деяких випадках керівники проєктів несуть відповідальність за обробку всіх ризиків проєкту, але це не є незвичайним, коли менеджери тестування відповідають за ризики проєкту, пов’язані з тестуванням.
Ризики продукту і ризики проєкту (версія 4.0)
Ризики продукту пов’язані з характеристиками якості продукту (наприклад, описані в моделі якості ISO 25010). Приклади ризиків продукту включають: відсутність або неправильну функціональність, неправильні обчислення, помилки під час виконання, погану архітектуру, неефективні алгоритми, неадекватний час відповіді, погану взаємодію з користувачем, вразливі місця в безпеці. Ризики продукту, коли вони виникають, можуть призвести до різних негативних наслідків, зокрема:
Невдоволення користувачів
Втрата прибутку, довіри, репутації
Шкода третім особам
Високі витрати на обслуговування, перевантаження служби підтримки
Кримінальні покарання
У крайніх випадках фізичні пошкодження, травми або навіть смерть
Проєктні ризики пов’язані з управлінням і контролем проєкту. Проєктні ризики включають:
Організаційні проблеми (наприклад, затримки в постачанні робочої продукції, неточні оцінки, скорочення витрат)
Проблеми з людьми (наприклад, недостатні навички, конфлікти, проблеми з комунікацією, нестача персоналу)
Технічні проблеми (наприклад, погана підтримка інструментів)
Проблеми з постачальником (наприклад, збій доставки третьою стороною, банкрутство компанії-контрагента)
Ризики проєкту, коли вони виникають, можуть вплинути на графік, бюджет або обсяг проєкту, що впливає на здатність проєкту досягати своїх цілей.
Тестування засноване на ризику та якість продукту (версія 3.1)
Ризик використовується для зосередження зусиль, необхідних під час тестування. Він використовується, щоб вирішити, де і коли розпочати тестування, а також визначити області, які потребують більшої уваги. Тестування використовується для зменшення ймовірності виникнення несприятливої події або для зменшення впливу несприятливої події. Тестування використовується як діяльність зі зменшення ризиків, щоб надати інформацію про виявлені ризики, а також надати інформацію про залишкові (невирішені) ризики.
Ризик-орієнтований підхід до тестування надає проактивні можливості для зниження рівня ризику продукту. Він передбачає аналіз ризиків продукту, який включає ідентифікацію ризиків продукту та оцінку ймовірності та впливу кожного ризику. Отримана інформація про ризик продукту використовується для планування тестування, специфікації, підготовки та виконання тестових випадків, а також для моніторингу та контролю тестування. Ранній аналіз ризиків продукту сприяє успіху проєкту.
У підході, що ґрунтується на оцінці ризику, результати аналізу ризику продукту використовуються для:
Визначення методів тестування, які будуть використані
Визначення конкретних рівнів та типів тестування, які необхідно виконати (наприклад, тестування безпеки, тестування доступності)
Визначення обсягів тестування, яке необхідно провести
Надайте пріоритет тестуванню, намагаючись якомога раніше виявити критичні дефекти
Визначте, чи можна застосувати будь-які дії на додаток до тестування для зменшення ризику (наприклад, навчання недосвідчених дизайнерів)
Тестування на основі ризиків спирається на колективні знання та розуміння зацікавлених сторін проєкту для проведення аналізу ризиків продукту.
Щоб забезпечити мінімізацію ймовірності відмови продукту, заходи з управління ризиками забезпечують дисциплінований підхід до:
Аналізу (і регулярної переоцінки) того, що може піти не так (ризики)
Визначення, з якими ризиками важливо боротися
Впровадження заходів для пом’якшення цих ризиків
Складання планів на випадок непередбачених обставин, щоб подолати ризики, якщо вони стануть реальними подіями
Крім того, тестування може виявити нові ризики, допомогти визначити, які ризики слід пом’якшити, і знизити невизначеність щодо ризиків.
Тестування засноване на ризику та якість продукту (версія 4.0)
З точки зору тестування, метою аналізу ризику продукту є усвідомлення ризику продукту, щоб зосередити зусилля на тестуванні таким чином, щоб мінімізувати залишковий рівень ризику продукту. В ідеалі аналіз ризиків продукту починається на ранній стадії SDLC.
Аналіз ризику продукту складається з ідентифікації та оцінки ризику. Ідентифікація ризиків полягає у створенні повного списку ризиків. Зацікавлені сторони можуть ідентифікувати ризики за допомогою різних методів та інструментів, наприклад, мозкового штурму, семінарів, інтерв’ю або причинно-наслідкових діаграм. Оцінка ризику включає: класифікацію ідентифікованих ризиків, визначення їхньої ймовірності, впливу та рівня ризику, встановлення пріоритетів та пропонування шляхів їх усунення. Категоризація допомагає призначати заходи пом’якшення, оскільки зазвичай ризики, які потрапляють до однієї категорії, можна зменшити за допомогою подібного підходу.
Оцінка ризику може використовувати кількісний або якісний підхід або їх поєднання. У кількісному підході рівень ризику розраховується як множення ймовірності ризику та впливу ризику. У якісному підході рівень ризику можна визначити за допомогою матриці ризику.
Аналіз ризику продукту може вплинути на ретельність і обсяг тестування. Його результати використовуються для:
Визначення обсягів тестування, яке необхідно провести
Визначення конкретних рівнів тестування та запропонування типів тестів для виконання
Визначення методів тестування, які будуть використані, і охоплення, якого потрібно досягти
Оцінка зусиль, необхідних для виконання кожного завдання
Надання пріоритетів тестування, щоб якомога раніше виявити критичні дефекти
Визначення, чи можна застосувати будь-які дії на додаток до тестування для зменшення ризику
Контроль ризику продукту (версія 4.0)
Контроль ризиків продукту включає всі заходи, які вживаються у відповідь на ідентифіковані та оцінені ризики продукту. Контроль ризику продукту складається з пом’якшення ризику та моніторингу ризику. Пом’якшення ризику передбачає впровадження заходів, запропонованих в оцінці ризику, щоб зменшити рівень ризику. Мета моніторингу ризиків полягає в тому, щоб переконатися в тому, що дії щодо пом’якшення є ефективними, отримати додаткову інформацію для покращення оцінки ризику та визначення ризиків, що виникають.
Що стосується контролю ризику продукту, після аналізу ризику можливі кілька варіантів реагування на ризик, наприклад, пом’якшення ризику шляхом тестування, прийняття ризику, передача ризику або план дій у непередбачених ситуаціях (Veenendaal 2012). Заходи, які можна вжити для зменшення ризиків продукту шляхом тестування, такі:
Виберіть тестувальників із належним рівнем досвіду та навичок, які підходять для певного типу ризику
Застосовуйте належний рівень незалежності тестування
Проведіть огляди та статичний аналіз
Застосовуйте відповідні методи тестування та рівні покриття
Застосуйте відповідні типи тестів, спрямовані на пов’язані характеристики якості
Виконайте динамічне тестування, включаючи регресійне тестування
ISTQB Certified Tester Foundation Level. Курс для початківців. Секція 5.5.
В цьому відео починаємо працювати з секцію 5.5. 00:01:12 Risk Management (v 4.0) 00:04:15 Definition of Risk 00:07:41 Product and Project Risks 00:26:10 Risk-based Testing and Product Quality 00:39:42 Product Risk Control (v 4.0)
