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

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

Що таке регресійне тестування?

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

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

Нижче наведено детальне порівняння з прикладом

Повторне тестування та регресійне тестування

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

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

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

• Повторне тестування проводиться з урахуванням виправлень дефектів.

• Перевірка дефектів не є частиною регресійного тестування

• Перевірка дефекту є частиною повторного тестування

• Залежно від проекту та наявності ресурсів, регресійне тестування може проводитись паралельно з повторним тестуванням.

• Пріоритет повторного тестування вищий за регресійне тестування, тому воно проводиться перед регресійним тестуванням.

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

• Ви не можете автоматизувати тестові випадки для повторного тестування

• Регресійне тестування називається загальним тестуванням

• Повторне тестування – це планове тестування

• Регресійне тестування проводиться для пройдених тестових випадків

• Повторне тестування проводиться лише невдалих тестів.

• Регресійне тестування перевіряє наявність несподіваних побічних ефектів

• Повторне тестування гарантує, що початкову помилку було виправлено

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

• Повторне тестування виконує дефект з тими самими даними і тим самим середовищем з різними входами з новим збиранням

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

• Тестові випадки для повторного тестування неможливо отримати до початку тестування.

КЛЮЧОВА РІЗНИЦЯ

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

Які питання я ставлю на співбесіді QA Junior+

Привіт Хабре! Мене звуть Іван, сьогодні поговоримо про питання на співбесідах Джуну + (від 6 місяців роботи) і дізнаємося, як відповісти на них не як ChatGPT. Я, як інженер з ручного та автоматизованого тестування, проводжу співбесіди на роль Junior+ QA (з подальшим зростанням в автоматизатори). Ділюся своїм списком запитань та відповідей, які я очікую почути. Мій корисний телеграм

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

Хекслет - Як пройти співбесіду на тестувальника: всі етапи та питання.

Telegra.ph - Співбесіда з QA. 250+ питань для Junior, Middle, Senior.

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

Вступ

У Росії QA, QC і тестування – одне й теж. В основному пишуть "Інженер із тестування" або "QA". Внесу ясність:

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

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

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

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

База для Junior QA

1. Що таке тестування?

Порівняння очікуваного результату з фактичним результатом. Тестування це не пошук багів!

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

2. Навіщо тестувати? Ціль тестування?

Є дві цілі тестування:

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

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

3. Які етапи тестування?

Під час підготовки релізу тестувальник виконує такі кроки:

1. Планування тестування.
2. Підготовка та виконання перевірок.
3. Складання звіту за результатами.

Докладніше:

1. Ініціація процесу тестування.
2. Виявлення прямих та непрямих вимог.
3. Генерація тестових випадків.
4. Відбір значних тестових випадків.
5. Проведення перевірок.
6. Фіксація результатів.
7. Аналіз результатів.
8. Передача інформації щодо відповідності перевіреного продукту вимогам.

Планування

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

Підготовка та тестування

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

Складання звіту

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

4. Які типи тестування можна назвати?

• функціональне тестування;
• дисфункція тестування;
• тестування змін. (пов'язані зі змінами)

4.1 Які види тестування можна назвати?

Питання 4 і 4.1 тісно сплетені і знайти адекватну межу між ними складно. Читайте тут і тут розбір про типи та види. По суті типи ділять усі види на три.

5. Які рівні тестування знаєте?

1. модульна/компонентна: здійснює перевірку функціональності та виявлення дефектів в окремих частинах програми, які можуть бути протестовані незалежно один від одного. Розробник пише модульні випробування для свого коду після його реалізації.
2. інтеграційна: виконує перевірку взаємодії між компонентами та зв'язку з різними частинами системи.
3. системна: проводить загальну перевірку функціональності всієї програми чи системи загалом високому рівні.
4. приймальна: проводиться перед передачею готового продукту замовнику для перевірки та прийняття.

Рівні йдуть по черзі і плутають послідовність = нерозуміння.

Увага! При вивченні матеріалів можна заплутатися між рівнями, методами і видами тестування. Ресурс, який я надав вище, вводить нас в оману відповіддю на питання "Які методики тестування Ви знаєте?"

МЕТОДИ тестування ви знайдете у питанні 15. А в помилковій відповіді використовуються рівні тестування з питання 5. Будьте пильні, дорогі Джуни.

6. Які техніки тест-дизайну знаєте?

• Граничні значення – перевіряємо дані на кордонах;
• Класи еквівалентності;
• Таблиці прийняття рішень;
• Причинно-наслідковий зв'язок;
• Попарне тестування;
• Тестування станів та переходів;
• Тестування на основі користувальницьких сценаріїв;
• Дослідницьке тестування – тестування та проектування документації одночасно.

7. Що таке техніка аналізу класів еквівалентності?

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

Своїми словами: це техніка тест-дизайну для перевірки введення всіх можливих даних. Щоб не перевіряти всі літери російського чи англійського алфавіту, досить запровадити одне значення, оскільки класи еквівалентні одне одному. Головне в таблиці КЕ – це різноманітна комбінація між різними класами.

8. Що таке техніка аналізу граничних значень? У чому цінність цієї техніки?

Граничні значення, також звані граничними значеннями, є важливою технікою тест-дизайну. Вони дозволяють нам визначити межі даних, наприклад, шляхом додавання 120 символів у полі "Ім'я" замість доступних 20 символів. Це дозволяє перевірити, як система обробляє екстремальні значення та може допомогти виявити потенційні помилки чи проблеми у програмному забезпеченні.

Техніка виділення ГЗ допомагає перевірити, чи коректно додаток обробляє межі КЕ, а також доповнити перевірки КЕ типу «діапазон» тестами на кордонах. Цінність також у скороченні тестових перевірок.

Поле "Ім'я"

Коментар

Значення біля кордону за межами класу

1 символ

Значення на самому кордоні

Значення біля кордону всередині класу

10 символів

Середнє значення всередині класу

Значення біля кордону всередині класу

20 символів

Значення на самому кордоні

Значення біля кордону за межами класу

Далеко за межами значення

9. Що таке Regression та Confirmation тестування, яка між ними різниця?

Regression - регрес перевіряє всю систему щодо змін і помилок після правки коду. Confirmation - перевірочне перевіряє виправлення помилки/бага/завдання.

10. Як часто слід проводити регресійне тестування товару?

Щоразу при зміні системи, при релізі з тестових стендів на пром.

11. Які види інтеграційного тестування?

• Підхід Великого вибуху - інтеграційне тестування виконується лише після того, як усі компоненти системи були розроблені та готові до інтеграції. У цьому випадку всі компоненти системи інтегруються одночасно і тестування проводиться для перевірки їх взаємодії.
• Інкрементальний підхід:
  • Східний підхід (згори донизу) – тестування починається з «верхніх» модулів і йде далі до «нижніх».
  • Підхід «знизу нагору» - працює навпаки, починається з низькорівневих модулів, потім переходять до високорівневих, у міру їхньої готовності.
  • Сендвіч – комбінація «згори донизу» та «знизу догори».

  12. Що таке Configuration Testing?

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

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

  13. Що таке Exploratory Testing?

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

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

  14. Які стандарти UI?

  • Принцип KISS(Keep It Simple, Stupid) - Принцип підтримки простоти, без ускладнення.
  • Не примушуй мене думати! - не давай зайвого приводу думати користувачеві, коли можна зробити простіше.
  • Ми видаляємо очевидне - не наголошувати на інтуїтивних діях.
  • Співвідношення сигналу та шуму - Прибирати непотрібні елементи, щоб не відволікати користувача.
  • Краще робоче, ніж модне - перевага функціональності перед модним дизайном.
  • Знайомі елементи керування - Використання стандартних інтерфейсних елементів, які користувачі вже знають.
  • Люди не читають - більше використовувати візуальні та інтерактивні елементи.
  • Принцип запозичення - Використання вже існуючих рішень, які добре працюють.
  • Гаманець Міллера - Обмеження кількості елементів в одному функціональному блоці до 5-7.
  • Принцип угруповання - поділ інформації на частини та дозування її подання.
  • Інтуїтивна ясність - кнопки та розділи повинні бути легко виявленими та зрозумілими.
  • Все корисно на очах - важливі елементи інтерфейсу мають бути видні та виділені.
  • Принцип 3 кліка - користувач повинен досягти потрібної інформації або розділу не більше ніж за 3 кліки.
  • Однорідність - Використання єдиного стилю у всьому продукті.
  • Спосіб вирішення проблеми - продукт має вирішувати проблеми користувачів, а чи не створювати нові.
  • Захист від випадкових дій - запобігання випадковому видаленню, замовленню, пересиланню або відправленню.
  • Принцип єдності - надання можливості керування налаштуваннями та елементами керування з одного місця, якщо це необхідно.
  • Тенденції - облік сучасних тенденцій, щоб інтерфейс не застарів до виходу проекту та відповідав його цілям.

  15. Що таке Black/Grey/White Box Testing?

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

  Метод сірої скриньки - тестування з деяким уявленням про внутрішню структуру ПЗ.

  Метод білого ящика - тестування внутрішньої структури та реалізації ПЗ.

  16. Що таке Performance Testing?

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

  17. Що таке Smoke та Sanity тестування та яка між ними різниця?

  Димове тестування - ця назва запозичена з найпростішої методики перевірки обладнання. Суть цієї методики полягала в подачі електроживлення на пристрій з подальшим наглядом за цим пристроєм. Якщо з'являвся дим, що супроводжувався запахом гару, це свідчило про серйозні проблеми. У виробництві програмного забезпечення димовий тест – це дуже простий та швидкий тест, що дозволяє з'ясувати, чи працює програма взагалі і чи дає вона очікувані результати. Такий вступ виділить вас серед кандидатів та продемонструє вашу начитаність. Книга - Філософія DevOps. Мистецтво управління IT.

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

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

  Відмінності між Smoke та Sanity тестуванням дивіться у питанні 19.

  18. Що таке Traceability Matrix?

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

  _{Матриця покриття вимог = Матриця трасування = Матриця трасування = Traceability Matrix}

  🟠 Помаранчевим кольором відзначено доступну функціональність ПЗ.

  🔵 Синім - Розділи ПЗ (Назви розділів приховані)

  🔴 Червоним - відзначені перетину ТК (білий порожній осередок означає відсутність тест-кейсів, а кольоровий порожній осередок говорить про відсутність даної функціональності в розділі).

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

  19. Що таке Sanity Testing?

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

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

  20. Що таке End-to-End тест?

  End-to-End тест (E2E тест) – це вид тестування програмного забезпечення, який перевіряє працездатність системи в цілому, від початку до кінця, з погляду користувача. Він імітує реальні сценарії використання та перевіряє, як різні компоненти системи взаємодіють один з одним.

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

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

  21. Що таке тестування безпеки?

  Тестування безпеки (Security Testing) - це процес перевірки системи або програми на наявність уразливостей, які можуть бути використані зловмисниками для несанкціонованого доступу, пошкодження даних або порушення конфіденційності.

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

  Три основні аспекти безпеки:

  1. Конфіденційність – щоб дані користувача не потрапили до чужих рук;
  2. Цілісність – щоб зміни до ПЗ міг вносити тільки користувач/адміністратор, який має на це повноваження;
  3. Доступність – щоб ресурси ПЗ були доступні користувачеві лише тоді, коли він належним чином авторизувався.

  22. Що таке тестування з урахуванням ризиків?

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

  23. Що таке динамічне тестування?

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

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

  24. Що таке «феномен пестициду»?

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

  25. Опишіть основні фази STLC? Дайте визначення Entry та Exit Criteria.

  Основні фази життєвого циклу тестування програмного забезпечення (Software Testing Life Cycle, STLC) включають такі етапи:

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

  Entry Criteria (критерії входу) - умови, які мають бути виконані перед початком кожної фази STLC. Вони визначають, коли можна приступати до наступної фази. Приклади критеріїв входу: наявність документації вимог, завершення попередньої фази, наявність тестових середовищ та даних.

  Exit Criteria (критерії виходу) - Умови, які повинні бути виконані для завершення кожної фази STLC. Вони визначають, коли можна перейти до наступної фази або завершити тестування. Приклади критеріїв виходу: виконання всіх тестових випадків, досягнення заданого рівня покриття тестування, звіт про результати та затвердження відділу розробки.

  26. Що таке Bug, Error, Failure, Fault?

  Bug (баг) - Ситуація, коли продукт не відповідає вимогам. Може бути викликаний помилкою в коді, що призводить до некоректної поведінки програми.

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

  Error (помилка) - неправильне розуміння вимог розробниками, що призводить до появи багів.

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

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

  27. Які атрибути баг-репорта? Які основні поля заповнення?

  Назва – Що? Де? Коли? Статус 403 у розділі кошика під час оновлення сторінки

  Опис - Детальний опис баг-репорту.

  Пріоритет - Який пріоритет виконання бага? Критичний – немає можливості працювати з кошиком, але не блокер (сервіс не впав зовсім)

  Передумова – Що потрібно зробити перед виконанням кроків? Увійти під Admin 123

  Кроки - Кожен крок – одна дія.

  ВР - Поведінка, яку очікуємо від системи (вимоги, специфікації) Статус 200

  ФР – поведінка, яку отримали від системи. Статус 403

  Додаток - (Скріншот, скринкаст, логи).

  28. Яка різниця між пріоритетом та серйозністю?

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

  29. Наведіть приклади серйозного, але з пріоритетного бага.

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

  30. У чому різниця між валідацією та верифікацією?

  Верифікація - Підтвердження, що функціональність працює відповідно до вимог.

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

  Валідація — підтвердження, що функціональність виконує ту мету, яку закладали спочатку.

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

  32. Що таке тест-план? Які елементи має?

  Тест-план - Це документ, який містить:

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

  34. Яка різниця між чек-листом та тест-кейсом?

  Чек-лист - список перевірок, а тест-кейс - Докладний покроковий опис пункту з цього списку. На один пункт чек-листа може припадати кілька тест-кейсів.

  за ТК протестувати ПЗ може людина з вулиці, яка не має уявлення про це, а по ЧЛ протестувати може лише фахівець, який знайомий із ПЗ.

  35. Наведіть приклад хорошого тест-кейсу.

  Перевірити відображення кнопки "Замовити" у вкладці Кошик

  В кошику доданий товар (Кейс 156)

  Увійти під користувачем: Admin пароль: 123

  Натиснути на профіль у верхньому правому кутку

  У бічному меню, що відобразилося, натиснути "Кошик"

  Перевірити активний стан кнопки "Замовити" (за умови, якщо є товар для замовлення)

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

  Дякую за прочитання цього важливого матеріалу. Я впевнений це допоможе вам у підготовці до співбесіди на роль manual QA. Телеграм для зв'язку

  • qa
  • тестування
  • тестування з
  • тестування веб-додатків
  • теорія тестування
  • manual testing
  • junior qa
  • тестування студентів
  • тестування в яндексі