Category: ISQTB Certified Tester Foundation Level. Курс для початківців

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

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

Question 1

Which of the following is likely to benefit most from the use of test tools providing test capture and replay facilities?

1. Integration testing.
2. System testing.
3. User acceptance testing.
4. Regression testing.

Question 2

Which of the following benefits are MOST likely to be achieved by using test tools?
(i) Easy to access information about tests and testing.
(ii) Reduced maintenance of testware.
(iii) Easy and cheap to implement.
(iv) Greater consistency of tests.

1. ii and iv
2. ii and iii
3. i and iv
4. i and iii

Question 3

A company recently purchased a commercial off-the-shelf application to automate their bill-paying process. They now plan to run an acceptance test against the package prior to putting it into production. Which of the following is their most likely reason for testing?

1. To detect bugs in the application.
2. To gather evidence for a lawsuit.
3. To build confidence in the application.
4. To train the users.

Question 4

A tool that supports traceability, recording of incidents or scheduling of tests is called:

1. A debugging tool.
2. A test execution tool.
3. A dynamic analysis tool.
4. A test management tool.

Question 5

A typical commercial test execution tool would be able to perform all of the following EXCEPT:

1. comparison of expected outcomes with actual outcomes.
2. reading test values from a data file.
3. generating expected outputs.
4. recording test inputs.

Question 6

Capture and replay facilities are least likely to be used to:

1. Recovery testing
2. GUI testing
3. User requirements.
4. Performance testing

Question 7

When an organization considers the use of testing tools, they should:

1. Use a tool in order to help define a good test process because the tool will force process repeatability and therefore enforce good test process.
2. Always start by bringing in automated test execution tools as these tools have the greatest return on investment and therefore should be introduced first.
3. Perform analysis of the test process and then assess whether it can be supported through the introduction of tool support.
4. Allow the developers to select the testing tools because tools are technical and developers have the appropriate skills to advise on test tool selection and configuration.

Question 8

From the list below, select the recommended principles for introducing a chosen test tool in an organization?
1. Roll the tool out to the entire organization at the same time.
2. Start with a pilot project.
3. Adapt and improve processes to fit the use of the tool.
4. Provide training and coaching for new users.
5. Let each team decide their own standard ways of using the tool.
6. Monitor that costs do not exceed initial acquisition cost.
7. Gather lessons learned from all teams.

1. 1, 2, 3, 5.
2. 2, 3, 4, 7
3. 1, 4, 6, 7.
4. 3, 4, 5, 6.

Question 9

Which of the following would NOT be a typical target of testing support tools?

1. Automate activities that require significant resources when done manually
2. Automate activities that cannot be executed manually
3. Automate repetitive tasks
4. Automating repetitive inspections

Question 10

The place to start if you want a (new) test tool is:

1. Invite a vendor to give a demo.
2. Find out what your budget would be for the tool.
3. Analyze your needs and requirements.
4. Attend a tool exhibition.

Question 11

Given the following types of tool, which tools would typically be used by developers and which by an independent test team:
(i.) static analysis.
(ii.) performance testing.
(iii.) test management.
(iv.) dynamic analysis.
(v.) test running.
(vi.) test data preparation.

1. developers would typically use ii, iv and vi; test team I, ii and v.
2. developers would typically use i and iv; test team ii, iii, v and vi.
3. developers would typically use i, iii, iv and v; test team ii and vi.
4. developers would typically use i, iv and vi; test team ii, iii and v.

Question 12

A data driven approach to test automation design is best described as:

1. Using action words to describe the actions to be taken, and the test data.
2. Scaling to support large numbers of users.
3. Being based on Equivalence Partitioning testing techniques.
4. Separating out the test data inputs and using a generic script that can real the test data and perform the same test steps with different data.

Question 13

What are the potential benefits from using tools in general to support testing?

1. Greater responsiveness of users, reduction of tests run, objectives not necessary.
2. Greater repeatability of tests, reduction in repetitive work, objective assessment.
3. Greater quality of code, reduction in paperwork, fewer objections to the tests.
4. Greater quality of code, reduction in the number of testers needed, better objectives for testing.

Question 14

Dynamic Analysis Tools are used to:

1. Determine differences between files or databases.
2. Monitor and report on how a system behaves under a variety of conditions.
3. Find defects, such as memory leaks, while software is executing.
4. Measure the percentage of specific types of code structure that have been exercised.

Question 15

What is a potential risk in using tools to support testing?

1. The tool will repeat exactly the same thing it did the previous time.
2. Insufficient reliance on the tool, i.e. still doing manual testing when a test execution tool has been purchased.
3. Unrealistic expectations, expecting the tool to do too much.
4. The tool may find defects that aren’t there.

Question 16

What type of tools to be used for Regression Testing

1. Performance
2. Record/Playback
3. A. & B.
4. None

Question 17

Which of the following activities should be performed during the selection and implementation of a testing tool?
(i) Investigate the organisation’s test process.
(ii) Conduct a proof of concept.
(iii) Implement the selected tool on a project behind schedule to save time.
(iv) Identify coaching and mentoring requirements for the use of the selected tool.

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

Question 18

Which of the following are advanced scripting techniques for test execution tools?

1. Playback-driven and keyword-driven
2. Data-driven and capture-driven
3. Data-driven and keyword-driven
4. Capture-driven and keyhole-driven

Question 19

Which of the following are potential benefits of adding tools to the test process?
(I.) Reduction of repetitive testing procedures.
(II. )Ability to hire testers with fewer technical skills.
(III.) Ability to get an objective assessment of progress.
(IV.) Greater consistency in testing procedures.

1. II, III and IV
2. I, II and III
3. I, III and IV
4. I, II and IV

Question 20

Which of the following is likely to benefit most from the use of test tools providing test capture and replay facilities?

1. Integration testing.
2. System testing.
3. User acceptance testing.
4. Regression testing.

Question 21

Which of the following are potential benefits of using test support tools?

1. Reducing repetitive work and gaining easy access to test information
2. Ensuring greater consistency and minimizing software project risks
3. Allowing for greater reliance on the tool to automate the test process
4. Performing objective assessment and reducing the need for training

Основні принципи обрання інструментів (версія 3.1)

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

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

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

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

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

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

Фактори успіху при обранні інструменту (версія 3.1)

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

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

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

В цьому відео починаємо працювати з секцію 6.2.
00:00:45 Main Principles for Tool Selection (V 3.1)
00:12:21 Pilot Projects for Introducing a Tool into an Organization (V 3.1)
00:15:47 Success Factors for Tools (V 3.1)

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

Інструменти тестування можна використовувати для підтримки однієї або кількох дій тестування. До таких засобів відносяться:

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

Класифікація інструментів тестування (версія 3.1)

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

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

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

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

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

Деякі інструменти пропонують підтримку, яка зазвичай більше підходить для розробників (наприклад, інструменти, які використовуються під час тестування компонентів та інтеграції). Такі інструменти позначені «(D)».

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

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

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

Підтримка інструментів для статичного тестування

• Інструменти статичного аналізу (D)

Підтримка інструментів для проєктування та впровадження тестів

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

• Інструменти тестування на основі моделі
• Засоби підготовки тестових даних

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

Підтримка інструментів для виконання тестів і журналювання

Існує багато інструментів для підтримки та вдосконалення виконання тестів і ведення журналів. Приклади цих інструментів:

• Інструменти виконання тестів (наприклад, для запуску регресійних тестів)
• Інструменти покриття (наприклад, покриття вимог, покриття коду (D))
• Перевірка джгутів (D)

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

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

• Інструменти тестування продуктивності
• Інструменти динамічного аналізу (D)

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

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

Інструментальна підтримка тестування (версія 4.0)

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

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

Переваги та ризики автоматизації тестування (версія 3.1)

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

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

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

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

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

Переваги та ризики автоматизації тестування (версія 4.0)

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

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

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

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

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

Особливі міркування щодо виконання тестів та інструментів керування тестами (версія 3.1)

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

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

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

• Виробляти корисну інформацію у форматі, який відповідає потребам організації
• Підтримувати постійну відстежуваність вимог у інструменті керування вимогами
• Для зв’язку з інформацією про версію тестового об’єкта в інструменті керування конфігурацією

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

В цьому відео починаємо працювати з секцію 6.1.
00:02:17 Test Tool Considerations (v 3.1)
00:04:53 Test Tool Classification (v 3.1)
00:22:36 Tool Support for Testing (v 4.0)
00:27:21 Benefits and Risks of Test Automation
00:48:58 Special Considerations for Test Execution and Test Management Tools (V 3.1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Опис підсумкового звіту про тестування наведено в «Стандарті документації тестування програмного забезпечення» (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