Month: January 2024

Незалежне тестування (версія 3.1)

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

Однак незалежність не є заміною обізнаності, і розробники можуть ефективно знаходити багато дефектів у власному коді.

Ступені незалежності в тестуванні включають наступне (від низького рівня незалежності до високого рівня):

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

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

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

Потенційні переваги незалежності тестування включають:

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

Потенційні недоліки незалежності тестування включають:

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

Завдання тестового менеджера і тестувальника (версія 3.1)

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

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

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

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

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

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

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

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

Ролі у тестуванні (версія 4.0)

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

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

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

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

Незалежність тестування (версія 4.0)

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

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

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

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

В цьому відео починаємо працювати з секцією 5.1.
00:01:46 Independent Testing (v 3.1)
00:14:14 Tasks of a Test Manager and Tester (v 3.1)
00:30:41 Roles in Testing (v 4.0)
00:36:08 Independence of Testing (v 4.0)

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

В цьому відео працюємо з тестами до 4 розділу.
00:00:23 Static test design techniques
00:01:08 Dynamic test design techniques
00:02:38 Працюємо з тестами

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

Question 1

One of the fields on a form contains a text box which accepts alphabets in lower or upper case. Identify the invalid Equivalence class value.

1. CLa01ss.
2. cLASS.
3. CLASS.
4. Class.

Question 2

“Experience based” test design techniques, typically

1. Use decision tables to generate the Boolean test conditions to be executed.
2. Identify the structure of the system or software at the component, integration or system level.
3. Use the skill, intuition and experience of the tester to derive the test cases, using error guessing and exploratory testing.
4. Establish traceability from test conditions back to the specifications and requirements.

Question 3

A piece of software has been given for testing. What tests from the following will you perform?
1) Test the areas most critical to business processes
2) Test the areas where faults will be maximum
3) Test the easiest functionalities

1. 1 is true, 2&3 are false.
2. 1&2 are false, 3 is true
3. 1,2 &3 are true.
4. 1&2 are true and 3 is false.

Question 4

Which of the following is a white box testing design characteristic?

1. To be based on specifications.
2. To be based on an analysis of the test basis documentation.
3. To be based on an analysis of the structure of the component or system.
4. To include both functional and non-functional testing.

Question 5

Which of the following test design techniques is not a black box technique?

1. Equivalence partitioning
2. State transition testing
3. Boundary value analysis
4. Statement coverage

Question 6

A program validates a numeric field as follows: Values less than 10 are rejected, values between 10 and 21 are accepted, values greater than or equal to 22 are rejected. Which of the following input values cover all of the equivalence partitions?

1. 10, 21, 22.
2. 10, 11, 21.
3. 3, 20, 21.
4. 3, 10, 22.

Question 7

Consider the following statements:
(i.)100% statement coverage guarantees 100% branch coverage.
(ii.)100% branch coverage guarantees 100% statement coverage.
(iii.) 100% branch coverage guarantees 100% decision coverage.
(iv.)100% decision coverage guarantees 100% branch coverage.
(v.)100% statement coverage guarantees 100% decision coverage.

1. i & v are True; ii, iii & iv are False.
2. ii is True; i, iii, iv & v are False.
3. ii, iii & iv are True; i & v are False.
4. ii & iii are True; i, iv & v are False.

Question 8

Consider the following:
Pick up and read the newspaper.
Look at what is on television.
If there is a program that you are interested in watching then switch the television on and watch the program.
Otherwise.
Continue reading the newspaper.
If there is a crossword in the newspaper then try and complete the crossword. Define SC and DC.

1. SC = 2 and DC = 2.
2. SC = 2 and DC = 3.
3. SC = 1 and DC = 3.
4. SC = 1 and DC = 1.

Question 9

Considering the following pseudo-code, calculate the MINIMUM number of test cases for statement coverage, and the MINIMUM number of test cases for decision coverage respectively.
READ A READ B READ C
IF C>A THEN
IF C>B THEN
PRINT ‘C must be smaller than at least one number’
ELSE PRINT ‘Proceed to next stage’
ENDIF
ELSE PRINT ‘B can be smaller than C’
ENDIF

1. 2, 4.
2. 3, 2.
3. 3, 3.
4. 2, 3.

Question 10

Equivalence partitioning is:

1. A black box testing technique appropriate to all levels of testing
2. A black box testing technique used only by developers
3. A white box testing technique appropriate for component testing
4. A black box testing technique than can only be used during system testing

Question 11

What is static analysis?

1. The decision between using white and black box test techniques.
2. Executing software to validate the most common path through the code.
3. A technique to find defects in software source code and software models, performed without executing code.
4. It is a testing technique used during system testing.

Question 12

Features of White Box Testing Technique:
(i.) We use explicit knowledge of the internal workings of the item being tested to select the test data.
(ii.) Uses specific knowledge of programming code to examine outputs and assumes that the tester knows the path of logic in a unit or a program.
(iii.) Checking for the performance of the application
(iv.) Also checks for functionality.

1. i, ii are true and iii and iv are false.
2. ii ,iii is true and i,iv is false.
3. iii is true and i,ii, iv are false.
4. iii and iv are true and i,ii are false.

Question 13

Consider the following pseudo code:
Begin
Input X, Y
If X > Y
__Print (X, ‘is greater than’, Y)
Else
__Print (Y, is greater than or equal to’, X)
Endlf
End

What is the minimum number of test cases required to guarantee both 100% statement coverage and 100% decision coverage?

1. Statement coverage = 3, Decision coverage = 3
2. Statement coverage = 2, Decision coverage = 2
3. Statement coverage = 1, Decision coverage = 2
4. Statement coverage = 2, Decision coverage = 1

Question 14

For the code fragment given below, which answer correctly represents minimum tests required for statement and branch coverage respectively?
Discount rate=1;
Fare = 1000;
If ((person == “senior citizen”) and (“travel month = January”))
Bonuspoints = 100+Bonuspoints
If (class==”first”) discountRate = .5;
Fare = fare * discountRate;

1. Statement Coverage = 2, Branch Coverage = 4
2. Statement Coverage = 2, Branch Coverage = 2
3. Statement Coverage = 1, Branch Coverage = 3
4. Statement Coverage = 1, Branch Coverage = 2

Question 15

What is decision table testing?

1. It’s a testing design technique based in the internal software structure.
2. It’s a static test design technique.
3. It’s a testing design technique to verify decisions.
4. It’s a testing design technique based in the system requirements.

Question 16

Given the following code, which is true:
IF A > B
THEN C = A – B
ELSE C = A + B
ENDIF
Read D
IF C = D
Then Print “Error”
ENDIF

1. 3 tests for statement coverage, 3 for branch coverage.
2. 2 tests for statement coverage. 3 for branch coverage.
3. 1 test for statement coverage, 3 for branch coverage.
4. 2 tests for statement coverage, 2 for branch coverage.

Question 17

Given the following specification, which of the following values for age are in the SAME equivalence partition? If you are less than 18, you are too young to be insured. Between 18 and 30 inclusive, you will receive a 20% discount. Anyone over 30 is not eligible for a discount.

1. 17, 18, 19.
2. 17, 29, 31.
3. 29, 30, 31.
4. 18, 29, 30.

Question 18

Given the following:
Switch PC on
Start “outlook”
IF outlook appears THEN
Send an email
Close outlook

1. 1 test for statement coverage, 2 for branch coverage.
2. 1 test for statement coverage, 1 for branch coverage.
3. 2 tests for statement coverage, 3 for branch coverage.
4. 1 test for statement coverage. 3 for branch coverage.

Question 19

Equivalence Partitioning is best defined as:

1. An technique that divides inputs into groups that are expected to exhibit similar behaviors.
2. Applying to time-related data classes only.
3. A form of white-box testing.
4. A method to reduce test coverage.

Question 20

Which of the following best describes the Black-box technique?

1.  It uses decision coverage for completeness.
2. It ensures all possible branches in the code are tested.
3. It is based on the internal structure of the system.
4. It can be done without reference to the internal structure of the component or system.

Question 21

What is a test condition?

1. A statement of test objectives and test ideas on how to test.
2. An item or event that could be verified by one or more test cases.
3. The process of identifying differences between the actual results and the expected results for a test.
4. All documents from which the requirements of a component or system can be inferred.

Question 22

In a flight reservation system, the number of available seats in each plane model is an input. A plane may have any positive number of available seats, up to the given capacity of the plane. Using Boundary Value analysis, a list of available – seat values were generated. Which of the following lists is correct?

1. 0, 1, 2, capacity plus 1, a very large number.
2. 0, 1, 10, 100, capacity, capacity plus one.
3. 0, 1, capacity, capacity plus 1.
4. 1, 2, capacity -1, capacity, capacity plus 1.

Question 23

Why are error guessing and exploratory testing good to do?

1. They will ensure that all of the code or system is tested.
2. They can be used most effectively when there are good specifications.
3. They can find defects missed by specification based and structure-based techniques.
4. They don’t require any training to be as effective as formal techniques.

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

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

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

Історія користувача представляє функцію, яка буде цінною для користувача або покупця системи чи програмного забезпечення. Історії користувачів мають три важливі аспекти (Jeffries 2000), які разом називаються «3 C»:

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

Найпоширеніший формат історії користувача: «Як [роль], я хочу [досягнути мети], щоб я міг [результивна бізнес-цінність ролі]», а потім критерії прийняття.

Спільне авторство історії користувача може використовувати такі методи, як «мозковий штурм» і розумового пов’язування (mind mapping). Співпраця дозволяє команді отримати спільне бачення того, що має бути надано, беручи до уваги три точки зору: бізнес, розробка та тестування.

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

Приймальні критерії (версія 4.0)

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

Критерії прийнятності використовуються для:

• Визначення обсягу історії користувача
• Досягнення консенсусу серед зацікавлених сторін
• Опису як позитивних, так і негативних сценаріїв
• Слугують як основа для перевірки прийнятності історії користувача
• Дозволяють точне планування та оцінку

Є кілька способів написати критерії прийняття для історії користувача. Два найпоширеніші формати:

• Орієнтований на сценарій (наприклад, формат Given/When/Then, що використовується в BDD)
• Орієнтований на правила (наприклад, список перевірки маркерів або таблична форма відображення введення-виведення)

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

Розробка керована приймальним тестуванням – Acceptance Test-driven Development (ATDD)

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

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

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

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

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

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

В цьому відео починаємо працювати з секцією 4.5.
00:00:41 Collaboration-based Test Approaches
00:01:45 Collaborative User Story Writing
00:07:11 Acceptance Criteria
00:10:59 Acceptance Test-driven Development (ATDD)

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

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

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

До цих технік відносять:

• Вгадування помилок
• Дослідницьке тестування
• Тестування на основі контрольного списку

Вгадування помилок (версія 3.1)

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

• Як програма працювала в минулому
• Якого роду помилки, як правило, допускаються
• Збої, які виникли в інших програмах

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

Вгадування помилок (версія 4.0)

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

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

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

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

Дослідницьке тестування (версія 3.1)

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

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

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

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

Дослідницьке тестування (версія 4.0)

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

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

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

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

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

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

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

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

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

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

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

В цьому відео починаємо працювати з секцією 4.4.
00:00:37 Experience-based Test Techniques
00:03:14 Error Guessing
00:10:34 Exploratory Testing
00:21:25 Checklist-based Testing

Техніки тестування білої скриньки (версія 3.1)

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

Техніки тестування білої скриньки (версія 4.0)

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

• Перевірка операторів (тверджень, заяв)
• Тестування гілок

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

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

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

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

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

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

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

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

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

Тестування гілок і покриття (версія 4.0)

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

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

Коли досягається 100% покриття розгалужень, усі розгалуження в коді, безумовні та умовні, перевіряються тестовими випадками. Умовні розгалуження зазвичай відповідають істинному чи хибному результату рішення «якщо…тоді», результату оператора switch/case або рішення вийти чи продовжити цикл. Однак виконання гілки за допомогою тестового кейсу не виявить дефекти у всіх випадках. Наприклад, він може не виявити дефекти, які потребують виконання певного шляху в коді.

Покриття гілок включає покриття операторів. Це означає, що будь-який набір тестів, який досягає 100% покриття гілок, також досягає 100% покриття операторів (але не навпаки).

Засноване на структурі або білої скриньки (Structure-based or White-box)

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

• Тестування операторів (заяв) і покриття
• Тестування рішень і покриття
• Інші методи на основі структури: покриття умов

Рівні

Рівень компонента: структура програмного компонента, тобто оператори, рішення, гілки або навіть окремі шляхи.

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

Системний рівень: структура може бути структурою меню, бізнес-процесом або структурою веб-сторінки.

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

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

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

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

Цикломатична складність

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

Формула цикломатичної складності:

M = L – N + 2*P

Де

• L – кількість ребер/ланок у графі
• N – кількість вузлів у графі
• P – кількість з’єднаних компонентів

Приклад:

Потік керування показує сім вузлів (фігур) і вісім ребер (лінії), таким чином, використовуючи формальну формулу, цикломатична складність становить 8-7 + 2*1=3. У цьому випадку немає виклику графа або підпрограми.

Приклади тестових питань

Яка мінімальна кількість тестів потрібна для 100% покриття операторів та 100% покриття рішень?

Disc = 0
Order –qty = 0
Read Order-qty
If Order-qty >= 20 then
Disc = 0.05
If Order-qty>=100 then
Disc = 0.1
End If
End If

З наведеної схеми видно, що для покриття стейтментів знадобиться один тест кейс, а для покриття рішень – 3 тест кейса.

Яка мінімальна кількість тестів потрібна для 100% покриття операторів та 100% покриття рішень?

If width>length
Then biggest_dimension=width
If height>width
Then biggest_dimension=height
End_if
Else biggest_dimension=length
If height>length
Then biggest_dimension=height
End_if
End_if

З наведеної схеми видно, що для покриття стейтментів знадобиться 2 тест кейса, а для покриття рішень – 4 тест кейса.

Яка мінімальна кількість тестів потрібна для 100% покриття операторів та 100% покриття рішень?

Ask: “What type of ticket do you require, single or return?”
If the customer wants ‘return’
Ask: “What rate, Standard or Cheap-day”?
If the customer replies ‘Cheap-day’
Say: “That will be $11.20”
Else
Say: “That will be $19.50”
Endif
Say: ”That will be $9.75”
Endif

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

Значення тестування операторів і рішень (версія 3.1)

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

Коли досягнуто 100% покриття рішення, воно виконує всі результати рішення, що включає перевірку істинного результату, а також хибного результату, навіть якщо немає явного хибного оператора (наприклад, у випадку оператора IF без else в коді)). Покриття операторів допомагає знайти дефекти в коді, які не перевірялися іншими тестами. Покриття рішень допомагає знаходити дефекти в коді, де інші тести не приймають ні правдивих, ні хибних результатів.

Досягнення 100% покриття рішень гарантує 100% покриття операторів (але не навпаки).

Значення тестування білої скриньки (версія 4.0)

Фундаментальна сильна сторона всіх методів «білої скриньки» полягає в тому, що під час тестування враховується вся реалізація програмного забезпечення, що полегшує виявлення дефектів, навіть якщо специфікація програмного забезпечення розпливчаста, застаріла або неповна. Відповідна слабкість полягає в тому, що якщо програмне забезпечення не реалізує одну або більше вимог, тестування білого ящика може не виявити отримані дефекти упущення (Watson 1996).

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

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

В цьому відео починаємо працювати з секцією 4.3.
00:01:16 White-box Test Techniques
00:06:21 Statement Testing and Coverage
00:12:47 Decision Testing and Coverage
00:23:07 Structure-based or White-box
00:20:21 Cyclomatic complexity
00:37:56 Приклади тестів
00:59:14 The Value of Statement and Decision Testing