knowledgeserfer

Рівні незалежності

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

Завдання тестового менеджера

• Планування тестування, обрання інструментів, підходів до тестування, оцінка часу, зусиль та вартості тестування, придбання, ресурсів, визначення рівнів тестування, циклів та планування управління інцидентами, вирішення, чи потрібна автоматизація
• Вирішення, які тестові середовища потрібні
• Представлення та аналіз показників моніторингу
• Адаптація планування на основі моніторингу
• Підготовка підсумкових звітів про тестування

Завдання тестувальника

• Створення специфікації тесту та перегляд тестів
• Використання інструментів адміністрування та керування тестами, а також інструментів моніторингу тестів
• Підготувка та отримання тестових даних
• Впровадження тестів на всіх рівнях тестування
• Виконання, автоматизація тестів
• Перегляд планів тестування та внесення свго внеску у них

Тестове планування

Структура документа з планування тестування охоплюється «Стандартом документації тестування програмного забезпечення» (IEEE 829, попередня але все ще багато в чому актуальна версія):

• Політика тестування (організація)
• Стратегія тестування (продукт)
• Генеральний план тестування (проєкт)
• План перевірки рівня (деталі)

Завдання тестового планування

• Підхід до тестування та процедури тестування, включаючи визначення рівнів тестування та критеріїв входу та виходу
• Ризики та цілі тестування
• Що тестувати, які ролі виконуватимуть тестову діяльність, які потрібні ресурси та хто їх використовуватиме
• Як повинні проводитися тестові дії, як будуть оцінюватися результати тестування
• Метрики для моніторингу та контролю підготовки та виконання тестів, усунення дефектів і проблем із ризиками
• Планування аналізу та проєктування тестів, впровадження, виконання та оцінювання тестів
• Тестова документація: обсяг, рівень деталізації, структура та шаблони
• Інтеграція та координація діяльності з тестування в діяльність життєвого циклу програмного забезпечення

План тестування

План тестування містить наступні елементи:

• Ідентифікатор плану тестування
• Список літератури
• Вступ
• Тестові елементи
• Ризики програмного забезпечення
• Функції для перевірки
• Функції, які не підлягають тестуванню
• Підхід
• Критерії проходження/непроходження предмета
• Критерії призупинення/відновлення
• Результати тестування
• Тестові завдання, що залишилися
• Потреби середовища
• Потреби в кадрах і навчанні
• Обов’язки
• Розклад
• Планування ризиків і непередбачених ситуацій
• Дозволи
• Глосарій

Критерії входу/виходу

Entry Criteria	Exit Criteria
Наявність та готовність тестового середовища	Метрики ретельності, такі як покриття коду, функціональність або ризик
Готовність тестових інструментів у тестовому середовищі	Оцінка щільності дефектів або метриків надійності
Наявність коду, який можливо тестувати	Варість
Наявність тестових даних	Графіки такі як ті, що базуються на часі до виходу на ринок
	Залишкові ризики, такі як невиправлені дефекти або нестача тестового покриття в певних областях

Тестова оцінка

• Підхід на основі показників або підхід на основі експертної думки
• Характеристики продукту: тестова база, розмір продукту, складність предметної області, вимоги
• Характеристики процесу розробки: стабільність організації, інструменти, що використовуються, процес тестування, навички залучених людей і тиск часу
• Результат тестування: кількість дефектів і обсяг необхідних доопрацювань

Тестові процеси моніторингу та контролю

• Щільність дефектів – кількість дефектів, виявлених у компоненті чи системі, поділена на розмір компонента чи системи (виражений у стандартних термінах вимірювання, наприклад, рядків коду, кількість класів або функціональних точок)
• Частота збоїв – кількість збоїв за одиницю часу, кількість збоїв у кількості транзакцій, кількість збоїв у кількості запусків комп’ютера.

Моніторинг прогресу тестування

• Забезпечте зворотній зв’язок і наочність щодо тестової діяльності
• Метрики використовуються для оцінки прогресу
• Відсоток виконаної роботи при підготовці тесту
• Відсоток виконаної роботи з підготовки тестового середовища
• Інформація про дефекти
• Тестове покриття вимог, ризиків або коду
• Суб’єктивна довіра тестувальників до продукту
• Дати тестових контрольних точок
• Витрати на тестування, включаючи вартість майбутніх знайдених помилок

Тестова звітність

• Опис підсумкового звіту про тестування наведено в «Стандарті документації тестування програмного забезпечення» (IEEE 829).
• Узагальнення інформації про тестування
• Що сталося під час тестування
• Проаналізована інформація та досягнуті показники
• Досягнуті результати: адекватність цілей тесту для цього рівня тесту, адекватність використаних тестових підходів, ефективність тестування щодо поставлених цілей.

Тестовий контроль

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

• Прийняття рішень на основі інформації тестового моніторингу
• Зміна пріоритетів тестів
• Зміна розкладу тестування через наявність або відсутність тестового середовища
• Зміна критерію вступу

Управління конфігураціями

Встановити та підтримувати цілісність продуктів. Все має бути пов’язано. Керування конфігурацією допомагає:

• Унікально ідентифікувати (і відтворити) тестований елемент, тестові документи, тести та тестові джгути
• Контролювати зміни цих характеристик
• Записувати та повідомляти про зміни
• Статус обробки та реалізації
• Перевірка відповідності встановленим вимогам

Ризик і тестування

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

Проєктні Ризики

Проєктні ризики – це ризики, пов’язані зі здатністю проєкту досягати своїх цілей.

Потенційні області збою в програмному забезпеченні або системі відомі як ризики продукту.

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

Підхід заснований на ризику

Створіть проактивні можливості для зниження рівня ризику продукту, починаючи з початкових етапів проекту:

• Визначте методи тестування, які необхідно використовувати
• Визначте обсяг тестування, яке необхідно провести
• Надайте пріоритет тестуванню, щоб якомога раніше виявити критичні дефекти
• Визначте, чи можна використовувати будь-яку діяльність, не пов’язану з тестуванням, для зменшення ризику (наприклад, навчання недосвідчених спеціалістів)

Управління дефектами (статуси)

Розбір тестових питань по п’ятому розділу

В цьому відео робиться спроба розібрати кілька десятків питань по п’ятому розділу сілабусу ISTQB CTFL.

Всі питання з відео з правильними відповідями наводяться нижче.

Question 1

Which of the following metrics would be most useful to monitor during test execution?

1. Percentage of requirements for which a test has been written.
2. Number of defects found and fixed.
3. Number of test environments remaining to be configured.
4. Percentage of test cases written.

Question 2

Which of the following is most likely to be mentioned as a project risk?

1. Unexpected illness of a key team member
2. Data corruption under network congestion
3. Failure to handle a key use case
4. 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?

1. Ideas for the test case improvement
2. History of the report
3. Actual result
4. Identification (Software and hardware) of the VCR

Question 4

Which of the following risks represents the highest level of risk to the project:

1.  Likelihood of failure = 1%, potential cost of impact = $1 m.
2. Likelihood of failure = 10%, potential cost of impact = $500,000.
3. Likelihood of failure = 20%, potential cost of impact = $150,000.
4. 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?

1. The price for which the software is sold
2. Difficulty of fixing related problems in code
3. The technical staff in the meeting
4. The harm that might result to the user

Question 6

Which of the following statements is most true about test conditions?

1. An item or event of a component or system that can be verified by one or more test cases.
2. The grouping of a composite set of test cases which, when tested as a whole, reveal a positive or negative result.
3. A testable component derived from business requirements.
4. 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

1. i,ii are false and iii , iv are true
2. i,iii,iv are true and ii is false
3. i,ii,iii are true and iv is false
4. 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?

1. A single test item
2. The test object
3. Control of the test project
4. 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?

1. An incident report
2. A test summary report
3. A bug report
4. A defect report

Question 10

According to the ISTQB Glossary, what do we mean when we call someone a test manager?

1. A test manager manages a collection of test leaders.
2. A test manager gets paid more than a test leader.
3. A test manager is the leader of a test team or teams.
4. A test manager reports to a test leader.

Question 11

According to the ISTQB Glossary, what is a test level?

1. An ISTQB certification.
2. A test type.
3. A group of test activities that are organized together.
4. 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

1. a, c and d
2. a, b and f
3. a, d and e
4. 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?

1. The remaining 15 defects should be confirmation tested prior to release.
2. The programmers should focus their attention on fixing the remaining known defects prior to release.
3. The remaining 10% of test cases should be run prior to release.
4. 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.

1.  v-3, w-4, x-1, y-5, z-2
2. v-2, w-5, x-1, y-4, z-3
3. v-3, w-2, x-1, y-5, z-4
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.

1. i, ii and iv.
2. i, iii and v.
3. ii, iii and iv,
4. 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

1. ii is True; i, iii, iv are False
2. i,ii,iii are true and iv is false
3. ii & iii are True; i, iv are False
4. 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?

1. Item pass/fail criteria
2. Summary
3. Impact
4. Incident description

Question 18

Metrics collected during testing includes

1. System test cases planned / executed / passed.
2. Discrepancies reported / resolved.
3. Staff hours.
4. All of the above.

Question 19

Poor software characteristics are

1. Only Project risks
2. Only Product risks
3. Project risks and Product risks
4. Project risks or Product risks

Question 20

The following best describes the defect density:

1. Ratio of discovered errors per size of code.
2. Number of modifications made per size of code.
3. Number of failures reported against the code.
4. 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?

1. Software traceability process
2. Incidence management process
3. Testing design process
4. 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?

1. Test tasks
2. Test team training
3. Exit criteria
4. Environmental needs

Question 23

What is the KEY difference between preventative and reactive approaches to testing?

1. Preventative testing is always analytical; reactive testing is always heuristic.
2. Preventative tests are designed after the software has been produced; reactive tests are designed early in response to review comments.
3. Preventative tests and reactive tests are designed as early as possible.
4. 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?

1. 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.
2. 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.
3. 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.
4. 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. 1 and 2.
2. 3 & 4.
3. All of the above.
4. None of the above.

Question 26

What is Risk analysis?

1. Evaluating risks.
2. Evaluating controls.
3. Evaluating vulnerabilities.
4. 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

1. I, II and IV are true; III is false
2. II and IV are true; I and III are false
3. I, II and III are true; IV is false
4. 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.

1.  i, ii, iii
2. ii, iii
3. i, iii, iv
4. i, ii, iii, v

Question 29

Why is independent testing important?

1. Independent testing is more effective at finding defects.
2. Independent testers should determine the processes and methodologies used.
3. Independent testers are dispassionate about whether the project succeeds or fails.
4. 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?

1. Keep tests and test coverage hidden from programmers.
2. Develop system requirements, design specifications and usage models.
3. Handle all test automation duties.
4. Gather and report test progress metrics.

Question 31

Which of the following factors is an influence on the test effort involved in most projects?

1. The departure of the test manager during the project.
2. Unexpected long-term illness by a member of the project team.
3. The quality of the information used to develop the tests.
4. Geographical separation of tester and programmers.

Управління дефектами (версія 3.1)

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

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

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

Типові звіти про дефекти мають такі цілі:

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

Звіт про дефект, поданий під час динамічного тестування, зазвичай містить:

• Ідентифікатор
• Назва та короткий опис дефекту, про який повідомляється
• Дата звіту про дефект, організація, та автор
• Ідентифікація тестового елемента (елемента конфігурації, що тестується) і середовища
• Фаза життєвого циклу розробки, на якій спостерігався дефект
• Опис дефекту, щоб зробити можливим відтворення та вирішення, включаючи журнали, дампи бази даних, знімки екрана або записи (якщо їх виявлено під час виконання тесту)
• Очікувані та фактичні результати
• Масштаб або ступінь впливу (серйозності) дефекту на інтереси зацікавлених сторін
• Терміновість/пріоритет виправлення
• Стан звіту про дефект (наприклад, відкрито, відкладено, дублікат, очікує на виправлення, очікує тестування підтвердження, повторно відкрито, закрито)
• Висновки, рекомендації та схвалення
• Глобальні проблеми, наприклад інші області, на які можуть вплинути зміни внаслідок дефекту
• Історія змін, як-от послідовність дій, виконаних членами команди проєкту щодо дефекту, щоб ізолювати, виправити та підтвердити його як виправлений
• Посилання, включаючи тест кейс, який виявив проблему

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

Приклад змісту звіту про дефект можна знайти в стандарті ISO (ISO/IEC/IEEE 29119-3), де звіти про дефекти називаються звітами про інциденти.

Управління дефектами (версія 4.0)

Оскільки однією з основних цілей тестування є виявлення дефектів, налагоджений процес управління дефектами має важливе значення. Незважаючи на те, що тут ми говоримо про «дефекти», повідомлені аномалії можуть виявитися справжніми дефектами або чимось іншим (наприклад, помилковим спрацьовуванням, запитом на зміну) — це вирішується під час обробки звітів про дефекти. Про аномалії можна повідомити на будь-якому етапі SDLC, а форма залежить від SDLC. Як мінімум, процес управління дефектами включає робочий процес для обробки окремих аномалій від їх виявлення до їх закриття та правила для їх класифікації. Робочий процес, як правило, включає дії з реєстрації повідомлених аномалій, їх аналізу та класифікації, прийняття рішення щодо належної відповіді, як-от виправити чи залишити все як є, і, нарешті, закрити звіт про дефекти. За цим процесом повинні стежити всі зацікавлені сторони. Бажано обробляти дефекти статичного тестування (особливо статичного аналізу) подібним чином.

Типові звіти про дефекти мають такі цілі:

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

Звіт про дефект, який реєструється під час динамічного тестування, зазвичай містить:

• Унікальний ідентифікатор
• Назва з коротким описом аномалії, про яку повідомляється
• Дата, коли була помічена аномалія, організація, та автор, включаючи роль
• Ідентифікація тестового об’єкта та тестового середовища
• Контекст дефекту (наприклад, тестовий кейс, що виконується, тестова діяльність, фаза SDLC та інша відповідна інформація, така як методика тестування, контрольний список або тестові дані, що використовуються)
• Опис збою, щоб уможливити відтворення та вирішення, включаючи кроки, які виявили аномалію, а також будь-які відповідні журнали тестування, дампи бази даних, знімки екрана або записи
• Очікувані та фактичні результати
• Серйозність дефекту (ступінь впливу) на інтереси зацікавлених сторін або вимоги
• Пріоритет виправлення
• Статус дефекту (наприклад, відкрито, відкладено, дублікат, очікує на виправлення, очікує перевірки підтвердження, повторно відкрито, закрито, відхилено)
• Посилання (наприклад, на тестовий приклад)

Деякі з цих даних можуть автоматично включатися під час використання інструментів керування дефектами (наприклад, ідентифікатор, дата, автор і початковий статус). Шаблони документів для звіту про дефекти та приклади звітів про дефекти можна знайти в стандарті ISO/IEC/IEEE 29119-3, де звіти про дефекти називаються звітами про інциденти.

В цьому відео починаємо працювати з секцію 5.6.
00:00:54 Defect Management
00:08:50 Defect reporting
00:13:19 Defect Report

Ризики і тестування. Введення (версія 4.0)

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

Основними видами діяльності з управління ризиками є:

• Аналіз ризику (що складається з ідентифікації та оцінки ризику)
• Контроль ризику (складається з пом’якшення ризику та моніторингу ризику)

Тестовий підхід, у якому тестові дії вибираються, пріоритезуються та керуються на основі аналізу та контролю ризиків, називається тестуванням на основі ризиків.

Визначення ризику (версія 3.1)

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

Визначення ризику (версія 4.0)

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

• Імовірність ризику – ймовірність виникнення ризику (більша за нуль і менша за одиницю)
• Вплив ризику (шкода) – наслідки цієї події

Ці два фактори виражають рівень ризику, який є мірою ризику. Чим вищий рівень ризику, тим важливіше управління цим ризиком.

Ризики продукту і ризики проєкту (версія 3.1)

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

Приклади ризиків продукту включають:

• Програмне забезпечення може не виконувати призначені функції відповідно до специфікації
• Програмне забезпечення може не виконувати призначені функції відповідно до потреб користувача, клієнта або зацікавлених сторін
• Архітектура системи може недостатньо підтримувати деякі нефункціональні вимоги.
• За певних обставин певне обчислення може бути виконано неправильно
• Структура керування циклом може бути закодована неправильно
• Час відповіді може бути недостатнім для високопродуктивної системи обробки транзакцій
• Відгуки про досвід користувача (UX) можуть не відповідати очікуванням продукту

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

1. Проблеми проєкту:
   • Можуть виникати затримки в доставці, виконанні завдання або задоволенні критеріїв виходу чи визначення виконаного
   • Неточні оцінки, перерозподіл коштів на проєкти з вищим пріоритетом або загальне скорочення витрат в організації можуть призвести до недостатнього фінансування
   • Пізні зміни можуть призвести до значної переробки
2. Організаційні питання:
   • Навички, навчання та персонал можуть бути недостатніми
   • Проблеми з персоналом можуть спричинити конфлікти та проблеми
   • Користувачі, бізнес-персонал або експерти з певної тематики можуть бути недоступні через суперечливі бізнес-пріоритети
3. Політичні питання:
   • Тестувальники можуть не повідомляти належним чином свої потреби або результати тестування
   • Розробники або тестувальники можуть не врахувати інформацію, отриману під час тестування та оглядів (наприклад, не вдосконалювати практику розробки та тестування)
   • Можливе неправильне ставлення до тестування або очікування від нього (наприклад, недооцінка цінності пошуку дефектів під час тестування)
4. Технічні проблеми:
   • Вимоги можуть бути визначені недостатньо добре
   • Вимоги можуть бути не виконані через існуючі обмеження
   • Тестове середовище може бути не готове вчасно
   • Перетворення даних, планування міграції та підтримка інструментів можуть виконуватися із запізненням
   • Недоліки в процесі розробки можуть вплинути на послідовність або якість робочих продуктів проєкту, таких як дизайн, код, конфігурація, тестові дані та тестові випадки
   • Погане управління дефектами та подібні проблеми можуть призвести до накопичення дефектів та інших технічних боргів
5. Проблеми з постачальниками:
   • Третя сторона може не надати необхідний продукт чи послугу або збанкрутувати
   • Контрактні питання можуть спричинити проблеми для проєкту

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

Ризики продукту і ризики проєкту (версія 4.0)

Ризики продукту пов’язані з характеристиками якості продукту (наприклад, описані в моделі якості ISO 25010). Приклади ризиків продукту включають: відсутність або неправильну функціональність, неправильні обчислення, помилки під час виконання, погану архітектуру, неефективні алгоритми, неадекватний час відповіді, погану взаємодію з користувачем, вразливі місця в безпеці. Ризики продукту, коли вони виникають, можуть призвести до різних негативних наслідків, зокрема:

• Невдоволення користувачів
• Втрата прибутку, довіри, репутації
• Шкода третім особам
• Високі витрати на обслуговування, перевантаження служби підтримки
• Кримінальні покарання
• У крайніх випадках фізичні пошкодження, травми або навіть смерть

Проєктні ризики пов’язані з управлінням і контролем проєкту. Проєктні ризики включають:

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

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

Тестування засноване на ризику та якість продукту (версія 3.1)

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

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

У підході, що ґрунтується на оцінці ризику, результати аналізу ризику продукту використовуються для:

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

Тестування на основі ризиків спирається на колективні знання та розуміння зацікавлених сторін проєкту для проведення аналізу ризиків продукту.

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

• Аналізу (і регулярної переоцінки) того, що може піти не так (ризики)
• Визначення, з якими ризиками важливо боротися
• Впровадження заходів для пом’якшення цих ризиків
• Складання планів на випадок непередбачених обставин, щоб подолати ризики, якщо вони стануть реальними подіями

Крім того, тестування може виявити нові ризики, допомогти визначити, які ризики слід пом’якшити, і знизити невизначеність щодо ризиків.

Тестування засноване на ризику та якість продукту (версія 4.0)

З точки зору тестування, метою аналізу ризику продукту є усвідомлення ризику продукту, щоб зосередити зусилля на тестуванні таким чином, щоб мінімізувати залишковий рівень ризику продукту. В ідеалі аналіз ризиків продукту починається на ранній стадії SDLC.

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

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

Аналіз ризику продукту може вплинути на ретельність і обсяг тестування. Його результати використовуються для:

• Визначення обсягів тестування, яке необхідно провести
• Визначення конкретних рівнів тестування та запропонування типів тестів для виконання
• Визначення методів тестування, які будуть використані, і охоплення, якого потрібно досягти
• Оцінка зусиль, необхідних для виконання кожного завдання
• Надання пріоритетів тестування, щоб якомога раніше виявити критичні дефекти
• Визначення, чи можна застосувати будь-які дії на додаток до тестування для зменшення ризику

Контроль ризику продукту (версія 4.0)

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

Що стосується контролю ризику продукту, після аналізу ризику можливі кілька варіантів реагування на ризик, наприклад, пом’якшення ризику шляхом тестування, прийняття ризику, передача ризику або план дій у непередбачених ситуаціях (Veenendaal 2012). Заходи, які можна вжити для зменшення ризиків продукту шляхом тестування, такі:

• Виберіть тестувальників із належним рівнем досвіду та навичок, які підходять для певного типу ризику
• Застосовуйте належний рівень незалежності тестування
• Проведіть огляди та статичний аналіз
• Застосовуйте відповідні методи тестування та рівні покриття
• Застосуйте відповідні типи тестів, спрямовані на пов’язані характеристики якості
• Виконайте динамічне тестування, включаючи регресійне тестування

В цьому відео починаємо працювати з секцію 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)

Тестовий моніторинг і контроль (версія 3.1)

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

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

Приклади тестових контрольних дій включають:

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

Тестовий моніторинг і контроль (версія 4.0)

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

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

• Зміна пріоритетів тестів, коли виявлений ризик стає проблемою
• Повторна оцінка того, чи відповідає тестовий елемент критеріям входу або критеріям виходу через переробку
• Налаштування розкладу тестування для усунення затримки в доставці тестового середовища
• Додавання нових ресурсів, коли і де це необхідно

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

Метрики, які використовуються у тестуванні (версія 3.1)

Показники можна збирати під час і в кінці тестової діяльності, щоб оцінити:

• Прогрес у порівнянні з запланованим графіком і бюджетом
• Поточна якість об’єкта тестування
• Адекватність тестового підходу
• Ефективність тестової діяльності щодо цілей

Загальні тестові показники включають:

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

Метрики, які використовуються у тестуванні (версія 4.0)

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

Загальні тестові показники включають:

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

Мета, зміст і аудиторія тестових звітів (версія 3.1)

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

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

• Статус тестової діяльності та прогрес щодо плану тестування
• Фактори, що перешкоджають прогресу
• Заплановані тестування на наступний звітний період
• Якість об’єкта тестування

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

Типові підсумкові звіти про тестування можуть містити:

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

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

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

Стандарт ISO (ISO/IEC/IEEE 29119-3) стосується двох типів звітів про тестування, звітів про хід тестування та звітів про завершення тестування (у цьому сілабусі називають підсумковими звітами про тестування), і містить структури та приклади для кожного типу.

Мета, зміст і аудиторія тестових звітів (версія 4.0)

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

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

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

Звіт про завершення тестування готується під час завершення тестування, коли проєкт, рівень тестування або тип тестування завершено та коли, в ідеалі, критерії виходу виконано. Цей звіт використовує звіти про хід тестування та інші дані. Типові звіти про завершення тестування включають:

• Підсумок тестування
• Тестування та оцінка якості продукту на основі оригінального плану тестування (тобто цілей тестування та критеріїв виходу)
• Відхилення від плану тестування (наприклад, відмінності від запланованого розкладу, тривалості та зусиль).
• Тестування перешкод і обхідних шляхів
• Тестові показники на основі звітів про хід тестування
• Незменшені ризики, не виправлені дефекти
• Отримані уроки, які стосуються тестування

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

Стандарт ISO/IEC/IEEE 29119-3 містить шаблони та приклади звітів про хід тестування (так звані звіти про статус тестування) і звітів про завершення тестування.

Комунікація статуса тестування (версія 4.0)

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

• Вербальне спілкування з членами команди та іншими зацікавленими сторонами
• Інформаційні панелі (наприклад, панелі інструментів CI/CD, панелі завдань і діаграми)
• Електронні канали зв’язку (наприклад, електронна пошта, чат)
• Онлайн-документація
• Офіційні протоколи тестування

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

Управління конфігурацією (версія 3.1)

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

Для належної підтримки тестування керування конфігурацією може передбачати забезпечення наступного:

• Усі тестові елементи унікально ідентифіковані, контролюються версіями, відстежуються зміни та пов’язані один з одним
• Усі елементи тестового програмного забезпечення однозначно ідентифікуються, контролюються версіями, відстежуються зміни, пов’язані один з одним і пов’язані з версіями тестового елемента(ів), щоб відстежуваність могла підтримуватися протягом усього процесу тестування
• Усі ідентифіковані документи та елементи програмного забезпечення містять однозначні посилання в тестовій документації

Під час планування тестування слід визначити та впровадити процедури керування конфігурацією та інфраструктурою (інструменти).

Управління конфігурацією (версія 4.0)

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

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

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

Для належної підтримки тестування CM забезпечує наступне:

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

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

В цьому відео починаємо працювати з секціями 5.3-5.4.
00:00:49 Test Monitoring and Control
00:12:20 Metrics Used in Testing
00:23:41 Purposes, Contents, and Audiences for Test Reports
00:45:56 Communicating the Status of Testing (V 4.0)
00:49:52 Configuration Management

Цілі і зміст тестового плану (версія 3.1)

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

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

Заходи з планування тестування можуть включати наступне, і деякі з них можуть бути задокументовані в плані тестування:

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

Зміст тестових планів може бути різним і може виходити за межі тем, визначених вище. Зразок структури плану тестування та зразок плану тестування можна знайти в стандарті ISO (ISO/IEC/IEEE 29119-3).

Тестова стратегія та тестовий підхід (версія 3.1)

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

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

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

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

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

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

Критерії входу та виходу (версія 3.1)

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

Типові критерії входу включають:

• Наявність тестованих вимог, історій користувачів або моделей (наприклад, при дотриманні стратегії тестування на основі моделі)
• Наявність тестових завдань, які відповідають критеріям виходу для будь-яких попередніх рівнів тестування
• Наявність тестового середовища
• Наявність необхідних засобів тестування
• Наявність тестових даних та інших необхідних ресурсів

Типові критерії виходу включають:

• Заплановані тести виконано
• Було досягнуто визначений рівень покриття (наприклад, вимог, історій користувачів, критеріїв прийнятності, ризиків, коду)
• Кількість невирішених дефектів знаходиться в узгодженому ліміті
• Кількість оцінених дефектів, що залишилися, досить низька
• Оцінені рівні надійності, ефективності продуктивності, зручності використання, безпеки та інших відповідних характеристик якості є достатніми

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

Графік виконання тестування (версія 3.1)

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

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

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

У деяких випадках можливі різні послідовності тестів із різними рівнями ефективності, пов’язаними з цими послідовностями. У таких випадках необхідно знайти компроміс між ефективністю виконання тесту та дотриманням пріоритетів.

Фактори, що впливають на тестові зусилля (версія 3.1)

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

Характеристики продукту

• Ризики, пов’язані з продуктом
• Якість тестової бази
• Розмір виробу
• Складність предметної області
• Вимоги до характеристик якості (наприклад, безпека, надійність)
• Необхідний рівень деталізації тестової документації
• Вимоги до законодавчої та нормативної відповідності

Характеристика процесу розробки

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

Характеристики людей

• Навички та досвід залучених людей, особливо з подібними проєктами та продуктами (наприклад, знання предметної області)
• Згуртованість і лідерство в команді

Результати тестування

• Кількість і серйозність виявлених дефектів
• Обсяг необхідної переробки

Техніки оцінювання тестування (версія 3.1)

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

• Техніка, заснована на показниках: оцінка зусиль тестування на основі показників попередніх подібних проєктів або на основі типових значень
• Експертна методика: оцінка тестових зусиль на основі досвіду власників тестових завдань або експертів

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

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

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

Цілі і зміст тестового плану (версія 4.0)

План тестування описує цілі, ресурси та процеси тестового проєкту. План тестування:

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

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

Типовий зміст плану тестування включає:

• Контекст тестування (наприклад, обсяг, цілі тестування, обмеження, база тестування)
• Припущення та обмеження тестового проєкту
• Зацікавлені сторони (наприклад, ролі, обов’язки, відповідність тестування, потребам у наймі та навчанні)
• Комунікація (наприклад, форми та частота комунікації, шаблони документації)
• Реєстр ризиків (наприклад, ризики продукту, ризики проєкту)
• Підхід до тестування (наприклад, рівні тестування, типи тестування, методи тестування, результати тестування, критерії входу та критерії виходу, незалежність тестування, метрики, які потрібно зібрати, вимоги до тестових даних, вимоги до тестового середовища, відхилення від організаційної політики тестування та стратегії тестування )
• Бюджет і графік

Детальніше про план тестування та його зміст можна знайти в стандарті ISO/IEC/IEEE 29119-3.

Внесок тестувальника у планування ітерації та випуску (версія 4.0)

У ітераційних SDLC зазвичай відбувається два види планування: планування випуску та планування ітерації.

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

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

Критерії входу та виходу (версія 4.0)

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

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

Типові критерії виходу включають: показники ретельності (наприклад, досягнутий рівень охоплення, кількість невирішених дефектів, щільність дефектів, кількість невдалих випадків тестування) і критерії завершення (наприклад, заплановані тести виконано, статичне тестування виконано, усі повідомляються про знайдені дефекти, усі регресійні тести автоматизовані).

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

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

Техніки оцінювання (версія 4.0)

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

Виділяють наступні чотири методи оцінювання:

• Оцінка на основі коефіцієнтів. У цій техніці, заснованій на показниках, цифри збираються з попередніх проєктів в організації, що дає змогу отримати «стандартні» коефіцієнти для подібних проєктів. Коефіцієнти власних проєктів організації (наприклад, взяті з історичних даних) зазвичай є найкращим джерелом для використання в процесі оцінки. Потім ці стандартні співвідношення можна використовувати для оцінки зусиль тестування для нового проєкту. Наприклад, якщо в попередньому проєкті співвідношення зусиль на розробку та тестування було 3:2, а в поточному проєкті зусилля на розробку очікується в 600 людино-днів, зусилля на тестування можна оцінити як 400 людино-днів.
• Екстраполяція. У цьому методі, заснованому на показниках, вимірювання проводяться якомога раніше в поточному проєкті для збору даних. Маючи достатньо спостережень, зусилля, необхідні для роботи, що залишилася, можна приблизно оцінити шляхом екстраполяції цих даних (зазвичай шляхом застосування математичної моделі). Цей метод дуже підходить для ітераційних SDLC. Наприклад, команда може екстраполювати тестове зусилля в майбутній ітерації як усереднене зусилля з останніх трьох ітерацій.
• Методика Delphi. У цій ітераційній експертній техніці експерти роблять оцінки на основі досвіду. Кожен експерт окремо оцінює зусилля. Результати збираються, і якщо є відхилення, що виходять за межі узгоджених меж, експерти обговорюють свої поточні оцінки. Потім кожного експерта просять зробити нову оцінку на основі цього відгуку, знову окремо. Цей процес повторюється, поки не буде досягнуто консенсусу. Planning Poker — це варіант Wideband Delphi, який зазвичай використовується в розробці програмного забезпечення Agile. У Planning Poker оцінки зазвичай робляться за допомогою карток із числами, які представляють розмір зусиль.
• Трибальна оцінка. У цій експертній методиці експерти роблять три оцінки: найбільш оптимістичну оцінку (a), найбільш ймовірну оцінку (m) і найбільш песимістичну оцінку (b). Остаточна оцінка (E) є їх середнім зваженим арифметичним. У найпопулярнішому варіанті цієї методики оцінка обчислюється як E = (a + 4*m + b) / 6. Перевагою цієї методики є те, що вона дозволяє експертам розрахувати похибку вимірювання: SD = (b – a) / 6. Наприклад, якщо оцінки (в людино-годинах) такі: a=6, m=9 і b=18, тоді остаточна оцінка становить 10±2 людино-години (тобто від 8 до 12 людино-годин), оскільки E = (6 + 4*9 + 18) / 6 = 10 і SD = (18 – 6) / 6 = 2.

Пріоритезація тестових кейсів (версія 4.0)

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

• Пріоритезація на основі ризиків, де порядок виконання тестів базується на результатах аналізу ризиків. Спочатку виконуються тестові випадки, що охоплюють найважливіші ризики.
• Пріоритезація на основі покриття, де порядок виконання тесту базується на покритті (наприклад, покриття оператора). Тестові кейси, які досягають найвищого рівня покриття, виконуються першими. В іншому варіанті, що називається додатковим пріоритетом покриття, спочатку виконується тестовий кейс, який досягає найвищого покриття; кожен наступний тестовий кейс є тим, який досягає найвищого додаткового покриття.
• Пріоритезація на основі вимог, де порядок виконання тестів базується на пріоритетах вимог, що відстежуються до відповідних тестів. Пріоритети вимог визначаються зацікавленими сторонами. Спочатку виконуються тестові кейси, пов’язані з найважливішими вимогами.

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

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

Тестова піраміда (версія 4.0)

Піраміда тестів — це модель, яка показує, що різні тести можуть мати різну деталізацію. Модель тестової піраміди підтримує команду в автоматизації тестування та в розподілі тестових зусиль, показуючи, що різні цілі підтримуються різними рівнями автоматизації тестування. Шари піраміди представляють групи тестів. Чим вищий рівень, тим менша деталізація тесту, ізоляція тесту та час виконання тесту. Тести на нижньому рівні невеликі, ізольовані, швидкі та перевіряють невелику частину функціональності, тому зазвичай їх потрібно багато, щоб досягти прийнятного покриття. Верхній рівень представляє складні наскрізні тести високого рівня. Ці високорівневі тести, як правило, повільніші, ніж тести нижчих рівнів, і зазвичай вони перевіряють велику частину функціональних можливостей, тому зазвичай потрібно лише кілька з них, щоб досягти прийнятного покриття. Кількість і назва шарів може відрізнятися. Наприклад, оригінальна модель тестової піраміди (Кон 2009) визначає три рівні: «модульні тести», «сервісні тести» та «тести інтерфейсу користувача». Інша популярна модель визначає тести одиничних компонентів, тести інтеграції (інтеграції компонентів) і наскрізні тести. Також можна використовувати інші рівні тестування.

Тестові квадранти (версія 4.0)

Квадранти тестування, визначені Брайаном Маріком (Marick 2003, Crispin 2008), групують рівні тестування з відповідними типами тестування, діяльністю, технікою тестування та робочими продуктами в розробці програмного забезпечення Agile.

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

У цій моделі тести можуть стосуватися бізнесу або технологій. Тести також можуть підтримувати команду (тобто керувати розробкою) або критикувати продукт (тобто вимірювати його поведінку проти очікувань). Поєднання цих двох точок зору визначає чотири квадранти:

• Квадрант Q1 (звернення до технологій, підтримка команди). Цей квадрант містить компоненти та тести інтеграції компонентів. Ці тести мають бути автоматизовані та включені в процес CI.
• Квадрант Q2 (бізнес, підтримка команди). Цей квадрант містить функціональні тести, приклади, тести історій користувача, прототипи користувацького досвіду, тестування API та моделювання. Ці тести перевіряють критерії прийнятності та можуть бути ручними або автоматизованими.
• Квадрант Q3 (бізнес, критика продукту). Цей квадрант містить дослідницьке тестування, тестування зручності використання, тестування прийнятності користувача. Ці тести орієнтовані на користувача і часто ручні.
• Квадрант Q4 (розгляд технології, критика продукту). Цей квадрант містить димові тести та нефункціональні тести (крім тестів зручності використання). Ці тести часто автоматизовані.

В цьому відео починаємо працювати з секцією 5.2.
00:00:59 Purpose and Content of a Test Plan (v 3.1)
00:07:42 Test Strategy and Test Approach (v 3.1)
00:19:23 Entry Criteria and Exit Criteria (v 3.1)
00:26:34 Test Execution Schedule (v 3.1)
00:30:50 Factors Influencing the Test Effort (v 3.1)
00:34:49 Test Estimation Techniques (v 3.1)
00:41:31 Purpose and Content of a Test Plan (v 4.0)
00:46:40 Tester’s Contribution to Iteration and Release Planning (v 4.0)
00:50:46 Entry Criteria and Exit Criteria (v 4.0)
01:00:24 Estimation Techniques (v 4.0)
01:13:58 Test Case Prioritization (v 4.0)
01:20:49 Test Pyramid (v 4.0)
01:29:35 Testing Quadrants (v 4.0)