fbpx

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

     За допомогою цієї шпаргалки Вам буде добре => шляхом повторення закріпити та систематизувати великі обсяги інформації. А також за потреби зможете швидко освіжити в пам’яті свої знання із теорії тестування, для того щоби успішно підготуватися до співбесіди на позиції Junior QA або Middle QA тест-інженера.

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

     Для зручності велику кількість питань розділяємо на 8 частин (планується). І Ви теж можете вивчати… намагатися запам’ятовувати матеріал згідно цих частин.

Питання #1 Що таке тестування програмного забезпечення?

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

Питання #2 Чому потрібне тестування програмного забезпечення?

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

  1. Тестування дозволяє перевірити, чи правильно реалізовані усі вимоги до ПЗ, що розроблялось.
  2. Тестування також демонструє, що створене ПЗ працює відповідно до специфікацій і відповідає визначеним вимогам до продуктивності.
  3. Тестування гарантує зацікавленим сторонам, що продукт працюватиме так як передбачено і як того бажається.
  4. Тестування допомагає у виявленні дефектів, помилок. Та забезпечує розпізнавання критичних помилок, їх вирішення — ще до етапу розгортання програмного забезпечення.
  5. Тестування допомагає перевірити належну інтеграцію та взаємодію кожного компонента в системі.
  6. Фактично, тестування економить час розробки ПЗ, виявляючи проблеми та вузькі місця ще на ранніх етапах розробки.
  7. Як правило: дефекти, виявлені на початкових фазах SDLC, призводять до меншої вартості та використання ресурсів для корекції.
  8. Тестування запобігає потраплянню неякісного програмного продукту до кінцевого користувач, уникнення ризику отримати погану репутацію чи відгук компанії розробнику.
  9. Команда із тестування, на відміну від команди розробників дивиться під іншим кутом зору на процес розробки ПЗ, тим самим виступає у ролі неупередженого арбітра.

Питання #3 Роль тестування в розробці програмного забезпечення

Отже, Чому ж тестування настільки важливе?

Код пишуть люди, а людям властиво помилятися. По статистиці: на кожну тисячу рядків коду припадає від 5 до 15 помилок, пошук і виправлення яких і займає багато часу розробки та налагодження ПЗ. Окрім того наслідки «дефектного» програмного забезпечення можуть бути найрізноманітнішими — від незначних до катастрофічних, і навіть смертельних. Тому тестування є одним із найважливіших та найвідповідальніших етапів. Повторюємо: тестування допомагає не лише виявити помилки, а й запобігти їх виникненню у майбутньому!

Питання #4 Отже, які головні цілі тестування?

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

Питання #5 Коли слід припинити тестування?

ПАМ’ЯТАЙТЕ: Тестування програмного забезпечення, як ремонт у будинку — процес нескінченний. Цей процес можливо лише свідомо зупинити. Тестування може бути зупинено, коли виконується одна або декілька з наступних умов:

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

Питання #6 Що таке Забезпечення Якості (Quality Assurance)?

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

Питання #7 Що таке контроль якості?

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

Питання #8 Опишіть характерні відмінності між Quality Assurance і Quality Control?

Quality Assurance включає в себе Quality Control поряд з іншими процесами щодо поліпшення якості роботи компанії.

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

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

Говорячи іншими словами, Quality Assurance гарантує, що процес поставлений правильно і дає передбачуваний результат, в той час як Quality Control гарантує, що продукт задовольняє вказаному набору вимог.

ЧИТАЙТЕ роз’яснення з життєвими прикладами у дописі: Quality Assurance у кожен бізнес!

Також ЗВЕРНІТЬ УВАГУ! на поняття:

(Quality Management) або Менеджмент Якості — скоординована діяльність з керівництва та управління організацією, стосовно забезпечення якості. Зазвичай включає в себе розробку політики у сфері якості та цілей у сфері якості, планування яким чином цих цілей реально досягнути, управління якістю, та методи поліпшення якості чи забезпечення стабільної якості. [ISO 9000-2011; Глоссарій стандарту термінів, застосовуваних у тестуванні програмного забезпечення.]

QA & QC
Модель ієрархії QA, QC, QM і тестування

Питання #9 Яка різниця між Verification (Верифікація) and Validation?

# Verification Validation
1. Верифікація — процес оцінки системи і її компонентів з метою співставлення результатів поточного етапу розробки, початково сформованим умовам. Тобто, виконання заданих завдань, цілей, строків по розробці продукту та відповідність стандартам. Валідація — це процес перевірки того, що розроблене програмне забезпечення відповідає визначеним бізнес-вимогам та потребам користувачів.
2. Це статичний процес аналізу, в першу чергу документації, а не фактичного кінцевого продукту. Передбачає динамічне тестування програмного продукту шляхом його запуску і різноманітних перевірок.
3. Верифікація — це процесно орієнтований підхід. Перевірка — продуктовий орієнтований підхід.
4. Відповідає на запитання: “Чи правильно ми будуємо продукт?” Відповідає на запитання: “Ми на шляху побудови правильного продукту?”
5. Помилки виявлені під час фази Верифікації вимагають на правки меншої вартості коштів/ витрачених ресурсів на фіксення порівнючи з вартістю помилок знайдених під час фази Валідації. Помилки виявлені під час фази Валідації вимагають більших витрат вартості / ресурсів /часу. А ще пізніше помилка ця ж сама помилка може коштувати ще дорожче.

Питання #10 What is SDLC?

SDLC (Software Development Life Cycle) — Життєвий Цикл Розробки Програмного Забезпечення. Охоплює сукупність всіх дій, що виконуються під час розробки програмного забезпечення.

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

  1. Розробка та аналіз вимог;
  2. Проектування;
  3. Впровадження (реалізація);
  4. Тестування;
  5. Розгортання;
  6. Технічне обслуговування.
SDLC model
Модель Життєвого Циклу Розробки Програмного Забезпечення

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

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

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

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

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

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

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

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

Головне завдання бета-тестів — оцінити можливості і стабільність роботи програми з точки зору її майбутніх користувачів. Тому на роль бета-тестерів запрошуються звичайні люди, які мають досвід роботи з програмами такого типу або, або ще краще, з попередньою версією цієї ж програми, але при цьому не є професійними тестувальниками. Також у ролі бета-тестерів може виступати Support команда замовника. І нарешті, може бути оголошено відкрите бета-тестування , коли на роль бета-тестерів запрошують всіх бажаючих. Тестувальникам початківцям ми рекомендуємо слідкувати за наборами бета-тестерів на проекти: Mozilla, Linux, Майкрософт, Apple, Selenium та ін. відомих програмних продуктів. Це гарний шанс здобути досвід.

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

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

Питання #11 Поясніть STLC – Software Testing life cycle.

STLC (Software Testing life cycle Життєвий цикл тестування програмного забезпечення) — це всі дії, що виконуються під час тестування програмного продукту.

Фази включають:

Requirement Analysis & Clarification questions — на цьому етапі аналізуються вимоги, задаються уточнюючі запитання та затверджуються документи вимог, визначаються обсяги тестування.

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

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

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

Test execution — на цьому етапі виконуються тест-кейси, рапортується про баги та про помилки шляхом вносу у баг-трекінгові системи, відбувається повторне тестування після їх фіксення.

Test closure and reporting   відбувається підбиття підсумків, складається тест-репорт з остаточних результатів тестування, формуються тестові метрики.

Software Testing life cycle

Питання #12 Що таке тестове середовище?

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

Питання #13 Артефакти тестування:

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

Найбільш поширеними тестовими артефактами є:

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

Набір тест-кейсів і наборів (Test Case & Test suite) — це послідовність дій, за якою можна перевірити чи відповідає тестована функція встановленим вимогам.

Чек Ліст (Check List) — це документ, який описує те що повинно бути протестовано. Потрібен щоб контролювати хід процесу тестування. І зручний артефакт для поділу обов’язків.

Чіт-ліст (Cheat Sheet) — це список перевірок, який повторюється.

Баг-репорт (Bug Reports / Defects) — це заключний документ, що описує ситуацію або послідовність дій, яка призвела до некоректної роботи об’єкта тестування, із зазначенням статистичних даних, обгрунтування причин і очікуваного результату.

У наступних питаннях більш детальніше ➡

Питання #14 Що таке план тестування?

План тестування (Test Plan) — це офіційний документ, що описує увесь обсяг робіт з тестування, необхідні ресурси та часові оцінки виконання процесу тестування, починаючи з опису об’єкта, стратегії, розкладу, критеріїв початку і закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення. Тест план розробляється згідно вимог і документації: Requirement Documents (технічні вимоги до програмного забезпечення), Software Requirement Specifications (специфікації програми).

Тест-план у пунктах повинен відповідати на питання:

  • Що треба тестувати?
  • Що будемо тестувати?
  • Як будемо тестувати?
  • Коли будемо тестувати?
  • Критерії початку тестування.
  • Критерії закінчення тестування.

В ідеалі тест-план повинен описувати:

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

Тест-план — це головний документ, яким оперує QA інженер.

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

Питання #15 Що таке Check List?

Як ми вже згадували вище Чек Ліст (Check List) — це документ, який описує що має бути протестовано. Check List може бути абсолютно різного рівня деталізації. На скільки детальним буде Check List залежить від вимог до звітності, рівня знання продукту співробітниками і складності продукту.

Що має бути зазначено в Check List:

  • Список перевірок (з необхідної ступенем деталізації);
  • Статус перевірок: (збірка, на якій проводилося тестування, тестове оточення (якщо є), тестувальник);
  • Результати перевірки.

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

Питання #16 Що таке Use Case?

Юзкейс (Use Case) — це перелік дій, сценарій по якому САМЕ користувач взаємодіє з додатком, програмою для виконання якоїнебудь дії для досягнення конкретної мети. Тестування по юзкейсам проводиться для того, щоб виявити додаткові логічні баги і дірки в додатку, які складно знайти в тестуванні індивідуальних модулів, частин програми окремо один від одного. Юзкейс тестування може проводиться, як частина приймального (Acceptance) тестування.

Для кращого  сприйняття Use Case часто малюють у вигляді діаграм з переходами:

Use Case diagram
Приклад Use Case diagram

Питання #17 Що таке тестовий сценарій?

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

Питання #18 Що таке Test Case?

Test Case — це сукупність умов з передумовами, вхідними значеннями та очікуваними результатами у документованій формі.

За видами тестові випадки бувають:

1. Позитивний тест-кейс — використовує тільки коректні дані і перевіряє правильність виконання даної функції.

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

Питання #19 Які деякі атрибути, структура Test Case?

У спрощеному вигляді у Test Case можуть бути розписані наступні атрибути:

# Параметри: Опис:
1. Test Case Id унікальний ідентифікатор Test Case
2. Test Summary ім’я, короткий зміст чи назва. Назва повинна бути короткою та інформативною, щоб розкривати суть тест кейсу без його повного прочитання.
3. Description докладний опис тесту.
4. Prerequisite or pre-condition необхідна умова попередня умова або набір  передумов, яких слід дотримуватися перед виконанням тестових кроків.
5. Test Steps тестові кроки для виконання тесту.
6. Expected result  очікуваний результат від того, щоб пройти тест.
7. Actual result фактичний результат після виконання тестових кроків.
8. Test Result  статус виконання тесту, мінімально Pass / Fail / Blocked / Not  Applicable.
9 Priorities пріоритетність (high, medium, low, normal) тощо
10. Automation Status статус автоматизації вказує нам чи програма автоматизована чи ні.
11. Attachments додатки картинок екрану, відео, файлів, логів і т.д., що може бути використане, як наявний доказ поведінки системи.
12. Comments важливі коментарі
13. Reference посилання на джерела тест кейсу (вимоги, тест дизайн, інше) а також на інші пов’язані тест кейси.
14. Date дата виконання випробувань.
15. Executed by Ім’я особи, яка виконує Test Case.
16. Postponed    відкладений, в коментарі необхідно написати причину.

Дізнатися дещо більше про Test Case рекомендуємо тут на сайті, у методичному розділі ➡  Теорії Тестування

Питання #20 Що таке тестовий скрипт?

Тестовий скрипт — це автоматизований Test Case, запущений будь-якою спеціалізованою програмою чи написаний на будь-якій скриптовій мові програмування. Це, в основному, сукупність інструкцій для оцінки роботи програми.

Питання #21 Що таке помилка BUG?

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

Питання #22 Що таке дефект?

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

Існує ще така «заковирка» Помилка з назвою (Error) — це дія людини, яка призводить до неправильного результату.

Гадаю різницю коли Вас запитають Ви зможете пояснити?

Питання #23 Які деякі атрибути звітності про дефекти?

# Параметри: Опис:
1. Defect Id унікальний ідентифікатор дефекту.
2. Defect Summary Короткі відомості про дефекти — короткий опис дефекту в одному рядку, більше схожий на назву дефекту.
3. Defect  Description докладний опис дефекту.
4. Steps to reproduce Шляхи відтворення — кроки до відтворення дефекту.
6. Expected result Очікуваний результат — очікувана поведінка, з якої програма відхиляється через дефект.
7. Defect Severity Виходячи з критичності дефекту, це поле можна встановити на незначну, середню, основну або пробку.
8. Priority  Виходячи з терміновості дефекту, це поле можна встановити за шкалою від P0 до P3.

Питання #24 Які інструменти управління помилками або дефектами Ви знаєте?

Найпоширеніші Баг-трекінгові системи — Jira, Bugzilla, Redmine, Mantis, Quality Center тощо.

Питання #25 Що таке щільність дефектів?

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

Питання #26 Що таке пріоритет дефектів?

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

Питання #27 Що таке Priority severity?

Priority severity (Серйозність дефектів) — це ступінь тяжкості дефекту, що впливає на функціональність програми. Виходячи з цієї точки зору, ми можемо вирізняти різні ступені дефектів, починаючи від незначних (minor) до критичних (critical) або показувати статус stopper (пробка, ступор).

Питання #28 Наведіть приклади Low priority,  High priority-Low, High priority-High severity defects?

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

Питання #29 Що таке критична помилка BUG?

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

Питання #30 Що таке блокатор Blocker bug?

Blocker bug — це помилка високого пріоритету та високого ступеня важкості, яка буквально блокує, не надає можливості провадити тестування програми далі або основної частини програми.

Питання #31 Що таке заглушка у програмі?

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

Питання #32 Поясніть життєвий цикл Багу або опишіть різні стани помилки?

Bug при розробці програмного забезпечення проходить наступні етапи:

 Опис:  Статус:
New коли Баг або дефект щойно виявлені, то вони знаходиться в New state у багтрекінговій системі.
Assigned нещодавно виявлений Баг повертаєтьсяі відповідному розробнику у якого він, наприклад, виник або тому хто повинен його пофіксити.
Open коли розробник працює над помилкою, Баг перебуває в Open state також ця позначка означає, що Баг потрібно виправити.
Rejected/Not a bug Баг відхилено, якщо розробник вважає, що помилки не має або вона не підтверджена, оскільки Баг не змогли відтворити — невалідний Баг.
Deferred означає, що виправлення Багу відкладається на деякий час (до наступних релізів), виходячи з терміновості та критичності помилки.
Fixed помилка спричинена розробником, позначається ним як виправлена.
Test виправлений баг висить за тестером, доки він його не протестить після виправлення. Якщо проблема все ще відтворюється, то відкривається наступний статус, “Наново відкритий”.
Reopened якщо тестера не задовольняє виправленя, помилка переміщується до стану повторного відкриття.
Verified після завершення етапу тестування, якщо тестер відчуває що помилку, вирішено, він буде Баг позначати як підтверджений.
Closed  після того, як помилка перевірена, вона переміщується в статус “Закритої”

Те саме ілюструємо, блок-схема показує основні статуси і можливі переходи від одного статусу до іншого статусу в процесі існування Багу:

Статус Багу

Ілюстрація з презентації Bugs & Bug life cycle

ПОРАДА: намагайтеся, коли працюєте уникати складних схем переходів, та зайвих статусів аби не заплутатися!

Related posts

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.