Month: October 2023

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

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

Розробка програмного забезпечення і тестування ПЗ (версія 3.1)

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

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

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

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

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

• Моделі послідовної розробки
• Ітераційні та інкрементальні моделі розробки

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

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

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

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

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

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

Приклади:

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

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

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

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

Моделі SDLC в контексті (версія 3.1)

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

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

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

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

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

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

Тестування в контексті життєвого циклу розробки ПЗ (версія 4.0)

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

Деякі дії в рамках процесів розробки програмного забезпечення також можна описати більш детальними методами розробки програмного забезпечення та методами Agile. Приклади включають: розробку, керовану приймальним тестуванням (ATDD), розробку, керовану поведінкою (BDD), дизайн, керований доменом (DDD), екстремальне програмування (XP), розробка, керована функціями (FDD), Kanban, Lean IT, Scrum та розробка керована тестами (TDD).

Вплив життєвого циклу програмного забезпечення на тестування (версія 4.0)

Для успіху тестування має бути адаптовано до SDLC. Вибір SDLC впливає на:

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

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

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

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

SDLC та хороші тестові практики (версія 4.0)

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

• Для кожної діяльності з розробки програмного забезпечення існує відповідна тестова діяльність, тому всі дії з розробки підлягають контролю якості
• Різні рівні тестування мають конкретні та різні цілі тестування, що дозволяє тестуванню бути належним чином повним, уникаючи надмірності
• Аналіз і прєктування тесту для даного рівня тестування починається під час відповідної фази розробки SDLC, щоб тестування могло відповідати принципу раннього тестування
• Тестувальники беруть участь у перевірці робочих продуктів, щойно чернетки цієї документації доступні, щоб це раннє тестування та виявлення дефектів могли підтримувати стратегію зсуву вліво (shift-left approach)

Тестування як драйвер розробки ПЗ (версія 4.0)

TDD, ATDD і BDD є подібними підходами до розробки, де тести визначаються як засіб керування розробкою. Кожен із цих підходів реалізує принцип раннього тестування і дотримується підходу зсуву вліво, оскільки тести визначаються до написання коду. Вони підтримують ітераційну модель розробки. Ці підходи характеризуються наступним чином:

• Розробка на основі тестування (TDD). Направляє кодування через тестові випадки (замість обширного про’ктування програмного забезпечення) (Бек 2003). Спочатку пишуться тести, потім пишеться код, щоб задовольнити тести, а потім тести та код переробляються.
• Розробка на основі приймальних випробувань (ATDD). Виводить тести з критеріїв прийнятності як частину процесу про’ктування системи (Gärtner 2011). Тести пишуться до того, як частина програми розробляється для задоволення тестів
• Розробка на основі поведінки (BDD). Виражає бажану поведінку програми за допомогою тестових випадків, написаних простою природною мовою, яку легко зрозуміти зацікавленим сторонам – зазвичай у форматі Given/When/Then. (Челімський 2010). Потім тестові випадки автоматично перетворюються на виконувані тести.

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

DevOps та тестування (версія 4.0)

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

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

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

DevOps не позбавлений ризиків і викликів, які включають:

• Необхідно визначити та встановити конвеєр доставки DevOps
• Необхідно запровадити та підтримувати інструменти CI/CD (Continuous Integration/ Continuous Development)
• Автоматизація тестування потребує додаткових ресурсів, її може бути важко встановити та підтримувати

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

Підхід зсуву вліво (Shift-Left Approach, версія 4.0)

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

Є кілька хороших практик, які ілюструють, як досягти «зсуву вліво» під час тестування, зокрема:

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

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

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

• Що було успішним і що варто зберегти?
• Що не вдалось і можна було б покращити?
• Як запровадити вдосконалення та зберегти успіхи в майбутньому?

Серед типових переваг для тестування виділяють:

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

В цьому відео починаємо працювати з секцією 2.1.
00:01:11 Моделі життєвого циклу розробки програмного забезпечення (визначення)
00:02:08 Розробка і тестування програмного забезпечення
00:18:09 Моделі життєвого циклу розробки програмного забезпечення в контексті
00:27:18 Тестування в контексті Моделі життєвого циклу розробки програмного забезпечення
00:39:51 Життєвий цикл розробки програмного забезпечення і якісні тестові практики
00:43:07 Тестування як драйвер для Розробки програмного забезпечення
00:50:59 Девопс та тестування
01:00:22 Підхід “зсув-вліво”
01:07:00 Ретроспектива і покращення процесу

Ціна помилки чи дефекту

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

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

І ще один момент. Чим раніше виявляється помилка чи дефект, тим дешевше їх виправити.

Якість ПЗ

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

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

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

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

Ефективність (Efficiency) – здатність ПЗ забезпечувати необхідний рівень продуктивності згідно з виділеними ресурсами, часом та іншими зазначеними умовами.

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

Портативність (Portability) – характеризує ПЗ з точки зору легкості його перенесення з одного оточення (software/hardware) в інше.

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

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

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

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

Question 1

Which of the following is most important to promote and maintain good relationships between testers and developers?

1. Understanding what managers value about testing.
2. Explaining test results in a neutral fashion.
3. Identifying potential customer work-arounds for bugs.
4. Promoting better quality software at any cost.

Question 2

Which is not a testing principle

1. Early testing.
2. Pesticide paradox.
3. Exhaustive testing.
4. Defect clustering.

Question 3

According to the ISTQB Glossary, a risk relates to which of the following?

1. Negative consequences that could occur.
2. Negative consequences that will occur.
3. Negative feedback to the tester.
4. Negative consequences for the test object.

Question 4

According to the ISTQB Glossary, the word ‘bug’ is synonymous with which of the following words?

1. Defect
2. Mistake
3. Error
4. Incident

Question 5

A test team consistently find between 90% and 95% of the defects present in the system under test. While the test manager understands that this is a good defect-detection percentage for her test team and industry, senior management and executives remain disappointed in the test group, saying that the test team misses too many bugs. Given that the users are generally happy with the system and that the failures which have occurred have generally been low impact, which of the following testing principles is most likely to help the test manager explain to these managers and executives why some defects are likely to be missed?

1. Absence-of-errors fallacy
2. Exhaustive testing is impossible
3. Defect clustering
4. Pesticide paradox

Question 6

Deciding How much testing is enough should take into account: (i). Level of Risk including Technical and Business product and project risk. (ii.) Project constraints such as time and budget. (iii.) Size of Testing Team. (iv.) Size of the Development Team.

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

Question 7

Typically, exit criteria may consist of:

1. Defining the amount, level of detail structure, and templates for the test documentation.
2. Estimates of defect density or reliability measures.
3. Adequacy of the test approaches taken.
4. Discussions on disaster recovery.

Question 8

Detecting a defect at which of the following stage is most economical?

1. Build.
2. Deployment.
3. Testing.
4. Design.

Question 9

During which test activity could faults be found most cost effecftively?

1. Execution.
2. Design.
3. Check Exit criteria completion.
4. Planning.

Question 10

Ensuring that test design starts during the requirements definition phase is important to enable which of the following test objectives?

1. Finding defects through dynamic testing.
2. Preventing defects in the system.
3. Finishing the project on time.
4. Gaining confidence in the system.

Question 11

What factors should be considered to determine whether enough testing has been performed? I. The exit criteria. II. The budget. III. How big the test team is. IV. The product’s risk profile. V. How good the testing tools are. VI. Sufficient details of the system status to allow decisions

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

Question 12

Evaluating testability of the requirements and system are a part of which phase?

1. Test Implementation and execution.
2. Test Analysis and Design.
3. Evaluating exit criteria and reporting.
4. Test Planning and control.

Question 13

Test Implementation and execution has which of the following major tasks? I. Developing and prioritizing test cases, creating test data, writing test procedures and optionally preparing the test harnesses and writing automated test scripts. II. Creating the test suite from the test cases for efficient test execution. III. Verifying that the test environment has been set up correctly. IV. Determining the exit criteria.

1. I,II are true and III, IV are false
2. I,IV,III are true and II is false
3. II,III,IV are true and I is false
4. I,II,III are true and IV is false

Question 14

Test planning has which of the following major tasks? I. Determining the scope and risks, and identifying the objectives of testing. II. Determining the test approach (techniques, test items, coverage, identifying and interfacing the teams involved in testing, testware). III. Reviewing the Test Basis (such as requirements, architecture, design, interface) IV. Determining the exit criteria.

1. I,III,IV are true and II is false.
2. I,II,IV are true and III is false.
3. I,II are true and III,IV are false.
4. II,III,IV are true and I is false.

Question 15

Which of the following are ‘Exit Criteria’?

1. Acceptance criteria, completion criteria, pass/fail criteria.
2. Coverage of code, schedule, estimates of defect density.
3. The last executable statement within a component.
4. Cost overruns.

Question 16

Testing Process comprised of

1. Test Plan and Test Cases.
2. Test Log and Test Status.
3. Defect Tracking.
4. All of the above.

Question 17

Which of the following are valid test objectives? I. Finding defects. II. Gaining confidence about the level of quality and providing information. III. Preventing defects. IV. Debugging the code.

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

Question 18

The goal of software testing is to

1. Validate that the system behaves as expected.
2. Let the developer know the defects injected by him.
3. Execute the program with the intent of finding errors.
4. Debug the system.

Question 19

Though activities in the Fundamental test process may overlap or occur concurrently, identify the logical sequential process. (i) Test Implementation and Execution (ii) Test Closure activities (iii) Evaluating exit criteria and reporting (iv) Test Planning and Control (v) Test Analysis and Design

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

Question 20

What is not the primary data given by the tester in test execution?

1. Number of test executed to date.
2. Number of test cases written for change request.
3. Total number of tests.
4. Number of tests executed successfully to date.

Question 21

What is the need for test planning?

1. to understand testing process.
2. to perform ad hoc testing.
3. to utilize a balance of testing techniques.
4. to collect metrics.

Question 22

Which of the following test organizations has the highest level of independence?

1. Independent testers within the development teams
2. Independent testers from the user community
3. Independent test specialists for specific test types, such as usability, performance or certification test specialists
4. Code tested by another developer from the development team

Question 23

What is the USUAL sequence for performing the following activities during the Fundamental Test Process? (a) Analyze the test basis documents. (b) Define the expected results. (c) Create the test execution schedule. (d) Establish the traceability of the test conditions

1. d, a, c, b
2. a, d, c
3. a, d, b, c
4. a, b, c, d

Question 24

What should be taken into account to determine when to stop testing? I Technical risk; II Business risk; III Project constraints; IV Product documentation

1. I, II, and IV are true; III is false
2. I and II are true. III and IV are false
3. I, II, and III are true, IV is false.
4. III is true, I, II, and IV are false

Question 25

When should you stop testing?

1. when the test completion criteria have been met.
2. when no faults have been found by the tests run.
3. when all planned tests have been run.
4. when time for testing has run out.

Question 26

When what is visible to end-users is an imperfection in a work product where it does not meet its requirements, this is called:

1. An error.
2. A defect.
3. A fault.
4. A mistake.

Question 27

Which activities form part of test planning? (i) Developing test cases. (ii) Defining the overall approach to testing. (iii) Assigning resources. (iv) Building the test environment. (v) Writing test conditions.

1. iv& v are true, i, ii & iii are false.
2. i, ii &iv are true, iii & v are false.
3. i, ii & iii are true iv& v are false.
4. ii & iii are true, i, iv& v are false.

Question 28

It is recommended to perform exhaustive tests for covering all combinations of inputs and preconditions

1. Yes, it’s strongly recommended.
2. No, risk analysis and priorities should be used to focus testing efforts
3. Yes, and it’s also necessary to include all the exit combinations
4. Only the expert testers can make exhaustive tests.

Question 29

Which of the following is a major task of test planning?

1. Preparing test specifications.
2. Evaluating exit criteria and reporting.
3. Determining the test approach.
4. Measuring and analyzing results.