×

Тестування. Фундаментальна теорія

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Шановне панство, нарешті переклав статтю українською. Якщо виявили неточності перекладу — прошу в коментарі :) Все буде Україна!

UPD: Запрошую гсоті на подкасти QA Балачки, а також пропоную замість зайвох феліжанки кави задонатити на дрони для 3 ОШБ, які я збираю власноруч на постійній основі. Прогрес можна відслідковувати в інсті. Дякую, що наближаєте перемогу!

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

Нижче основи основ для повторення перед співбесідою на посаду Trainee та Junior: визначення тестування, якість, верифікація / валідація, цілі, етапи, тест-план, пункти тест-плану, тест-дизайн, техніки тест-дизайну, traceability matrix, тест-кейс, чек-ліст, дефект, error/defect/failure, баг репорт, severity vs priority, рівні тестування, види / типи, підходи до інтеграційного тестування, принципи тестування, статичне та динамічне тестування, дослідницьке / ad-hoc тестування, вимоги, життєвий цикл багу, стадії розробки програмного забезпечення, таблиця прийняття рішень, qa/qc/test engineer, діаграма зв’язків.

Друга частина про методології тут.

Всі зауваження, коригування та доповнення дуже вітаютсья.

Тестування програмного забезпечення — перевірка відповідності між реальною та очікуваною поведінкою програми, що здійснюється на скінченній множині тестів, вибраних у певний спосіб. У більш широкому розумінні, тестування — це одна з методик контролю якості, яка включає активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) та аналізу отриманих результатів (Test Analysis).

Якість програмного забезпечення (Software Quality) — це сукупність характеристик програмного забезпечення, які відносяться до його здатності задовольняти встановлені та передбачувані потреби. [Quality management and quality assurance]

Верифікація (verification) — це процес оцінки системи або її компонентів з метою визначення, чи відповідають результати поточного етапу розробки умовам, сформованим на початку цього етапу [IEEE]. Так, верификація включає перевірку, чи досягаються наші цілі, терміни та завдання, визначені на початку поточної фази розробки проекту.
Валідація (validation) — це процес визначення відповідності розроблюваного ПЗ очікуванням і потребам користувача, вимогам до системи [BS7925-1].
Також можна зустріти інший тлумачення:
Процес оцінки відповідності продукту явним вимогам (специфікаціям) називається верифікацією (verification), тоді як оцінка відповідності продукту очікуванням та вимогам користувачів називається валідацією (validation). Також часто можна зустріти таке визначення цих понять:
Валідація — «is this the right specification?».
Верифікація — «is the system correct to specification?»

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

Етапи тестування:
1. Аналіз продукту
2. Робота з вимогами
3. Розробка стратегії тестування та планування процедур контролю якості
4. Створення тестової документації
5. Тестування прототипу
6. Основне тестування
7. Стабілізація
8. Експлуатація

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

Основні пункти плану тестування
В стандарті IEEE 829 перераховано пункти, з яких має (може) складатися план тестування:
a) Test plan identifier;
b) Introduction;
c) Test items;
d) Features to be tested;
e) Features not to be tested;
f) Approach;
g) Item pass/fail criteria;
h) Suspension criteria and resumption requirements;
i) Test deliverables;
j) Testing tasks;
k) Environmental needs;
l) Responsibilities;
m) Staffing and training needs;
n) Schedule;
o) Risks and contingencies;
p) Approvals.

Тест дизайн — це етап процесу тестування програмного забезпечення, на якому створюються тестові сценарії (тест-кейси) відповідно до попередньо визначених критеріїв якості та цілей тестування.
Ролі, відповідальні за тест дизайн:
• Тест-аналітик — визначає «ЩО тестувати?»
• Тест-дизайнер — визначає «ЯК тестувати?»

Техніки тест-дизайну

• Еквівалентне Розбиття (Equivalence Partitioning — EP). Наприклад, у вас є діапазон припустимих значень від 1 до 10, ви повинні вибрати одне правильне значення всередині цього інтервалу, скажімо, 5, а також одне неправильне значення за межами інтервалу, наприклад, 0.

• Аналіз Граничних Значень (Boundary Value Analysis — BVA). На прикладі вище, для позитивного тестування ми обираємо мінімальну і максимальну границі (1 і 10), а також значення, які менше і більше границь (0 і 11). Аналіз Граничних Значень може застосовуватися до полів, записів, файлів або будь-яких сутностей з обмеженнями.

• Причина / Наслідок (Cause/Effect — CE). Зазвичай це створення комбінацій умов (причин) для отримання відповіді від системи (Наслідок). Наприклад, ви перевіряєте можливість додавання клієнта за допомогою певної екранної форми. Для цього вам потрібно буде ввести кілька полів, таких як «Ім’я», «Адреса», «Номер телефону», а потім натиснути кнопку «Додати» — це «Причина». Після натискання кнопки «Додати», система додає клієнта до бази даних і відображає його номер на екрані — це «Наслідок».

• Попереднє вгадування помилок (Error Guessing — EG). Це коли тестувальник використовує свої знання системи та здатність інтерпретувати специфікацію для «вгадування» умов, за яких система може видати помилку.
Наприклад, специфікація стверджує: «користувач повинен ввести код». Тестувальник буде думати: «Що, якщо я не введу код?», «Що, якщо я введу неправильний код?» і так далі. Це і є передбачення помилки.

• Вичерпне тестування (Exhaustive Testing — ET) — это Крайній випадок. В межах цієї техніки вам потрібно перевірити всі можливі комбінації вхідних значень, і в принципі, це має виявити всі проблеми. На практиці застосування цього методу неможливе через величезну кількість можливих вхідних значень.

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

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

стать вік діти
1 чоловік до 25 дітей немає
2 жінка до 25 дітей немає
3 чоловік 25-60 дітей немає
4 жінка 25-60 дітей немає
5 чоловік старше 60 дітей немає
6 жінка старше 60 дітей немає
7 чоловік до 25 дітей є
8 жінка до 25 дітей є
9 чоловік 25-60 дітей є
10 жінка 25-60 дітей є
11 чоловік старше 60 дітей є
12 жінка старше 60 дітей є

А можна вирішити, що нам не потрібні всі комбінації значень всіх параметрів з усіма, а ми хочемо лише переконатися, що ми перевіримо всі унікальні пари значень параметрів. Так, саме так. Наприклад, з точки зору параметрів статі та віку, ми хочемо переконатися, що точно перевіримо чоловіка до 25 років, чоловіка у віці від 25 до 60 років, чоловіка після 60 років, а також жінку до 25 років, жінку у віці від 25 до 60 років і жінку після 60 років. І точно так само для всіх інших пар параметрів. І таким чином, ми можемо отримати значно менше наборів значень (вони містять усі пари значень, хоча деякі можуть повторюватись):

стать вік діти
1 чоловік до 25 дітей немає
2 жінка до 25 дітей є
3 чоловік 25-60 дітей є
4 жінка 25-60 дітей є
5 чоловік старше 60 дітей є
6 жінка старше 60 дітей є

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

Traceability matrix — Матриця відповідності вимог — це двовимірна таблиця, яка містить відповідність між функціональними вимогами (functional requirements) продукту і підготовленими тестовими сценаріями (test cases). В заголовках стовпців таблиці розташовані вимоги, а в заголовках рядків — тестові сценарії. На перетині рядків і стовпців розташовані позначки, які показують, що вимога з поточного стовпця покрита тестовим сценарієм з поточного рядка.
Матриця відповідності вимог використовується QA-інженерами для перевірки покриття продукту тестами. Вона є невід’ємною частиною плану тестування.

Тестовий сценарій (Test Case) — це артефакт, що описує набір кроків, конкретні умови та параметри, необхідні для перевірки реалізації функції, що тестується, або її частини.
Приклад:
Action Expected Result Test Result
(passed/failed/blocked)
Open page «login» Login page is opened Passed

Кожен тест-кейс повинен мати 3 частини:
PreConditions — перелік дій, які приводять систему до стану, придатного для проведення основної перевірки. Або перелік умов, виконання яких свідчить про те, що система знаходиться в стані, придатному для проведення основного тесту.
Test Case Description Перелік дій, що переводять систему з одного стану в інший, для отримання результату, на основі якого можна зробити висновок про відповідність реалізації поставленим вимогам.
PostConditions Список дій, що переводять систему в початковий стан (стан до проведення тесту — initial state)
Види Тестових Сценаріїв:
Тест кейси розділяються за очікуваним результатом на позитивні та негативні:
• Позитивний тест кейс використовує лише коректні дані та перевіряє, що додаток правильно виконав викликану функцію.
• Негативний тест кейс оперує як коректними, так і некоректними даними (принаймні один некоректний параметр) та має на меті перевірити виникнення виключних ситуацій (спрацювання валідаторів). Він також перевіряє, що викликана функція застосунком не виконується при спрацюванні валідатора.

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

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

Error — це помилка користувача, коли він намагається використовувати програму неправильним способом.
Наприклад, введення літер у поля, де потрібно вводити числа (вік, кількість товару і т.д.).
В якісній програмі передбачені такі ситуації, і виводяться повідомлення про помилку (error message) з червоним хрестиком.
Bug (defect) — це помилка розробника (або дизайнера, або іншої особи, яка бере участь у розробці), тобто коли в програмі щось йде не так, як планувалося, і програма виходить з-під контролю. Наприклад, коли немає жодного контролю над введенням користувача, в результаті неправильні дані можуть спричинити збої або інші непередбачувані проблеми у роботі програми. Або всередині програма побудоавана так, що з самого початку не відповідає очікуванням.
Failure — це сбій (не обов’язково апаратний), який виникає в роботі компонента, програми або системи. Так, існують дефекти, які приводять до сбоїв (A defect caused the failure) і існують такі, які не призводять. UI-дефекти, наприклад. Але апаратний збій, незалежний від програмного забезпечення, також є failure.

Баг Репорт (Bug Report) — це документ, що описує ситуацію або послідовність дій, що призвели до некоректної роботи об’єкта тестування, з вказанням причин і очікуваного результату.
Шапка
Короткое описание (Summary) Короткий опис проблеми, чітко вказуючи на причину і тип помилкової ситуації.
Проєкт (Project) Назва проєкту, що підлягає тестуванню
Компонент застосунку (Component) Назва частини або функції тестируемого продукту
Номер версії (Version) Версія, на якій була виявлена помилка
Серйозність (Severity) Найбільш поширена п’ятирівнева система класифікації серйозності дефекту:
• S1 Блокуючий (Blocker)
• S2 Критичний (Critical)
• S3 Значний (Major)
• S4 Незначний (Minor)
• S5 Тривіальний (Trivial)
Пріоритет (Priority) Пріоритет дефекту:
• P1 Високий (High)
• P2 Середній (Medium)
• P3 Низький (Low)
Статус (Status) Статус помилки. Залежить від використовуваної процедури та життєвого циклу помилки (bug workflow and life cycle)

Автор (Author) Створювач баг-репорту
Назначено (Assigned To) Ім’я співробітника, призначеного для вирішення проблеми
Середовище (Environment)
ОС / Сервісний пак і т.д. / Браузер + версія / ... Інформація про середовище, на якому була виявлена помилка: операційна система, сервісний пак, для веб-тестування — назва і версія браузера і т.д.
...
Опис
Кроки для відтворення (Steps to Reproduce) Кроки, за якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний результат (Result) Результат, отриманий після пройдених кроків для відтворення
Очікуваний результат (Expected Result) Очікуваний правильний результат
Додатково (Additional)
Прикріплений файл (Attachment) Файл з логами, знімком екрана або будь-яким іншим документом, який може допомогти уточнити причину помилки або вказати на шлях вирішення проблеми.

Severity vs Priority
Серйозність (Severity) — це атрибут, що характеризує вплив дефекту на працездатність застосунку.
Пріоритет (Priority) — це атрибут, що вказує на послідовність виконання завдання або усунення дефекту. Можна сказати, що це інструмент менеджера з планування робіт. Чим вищий пріоритет, тим швидше потрібно виправити дефект.
Серйозність (Severity) встановлюється тестувальником.
Пріоритет (Priority) встановлюється менеджером, тімлідом або замовником.

Градація серйозності дефекта (Severity)

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

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

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

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

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

Градація пріоритету дефекта (Priority)
P1 Високий (High)
Помилку необхідно виправити якнайшвидше, оскільки її наявність є критичною для проекту.
P2 Середній (Medium)
Помилку необхідно виправити, її наявність не є критичною, але вимагає обов’язкового вирішення.
P3 Низький (Low)
Помилку необхідно виправити, її наявність не є критичною і не вимагає негайного вирішення.

Рівні тестування

1. Модульне тестування (Unit Testing)
Модульне тестування перевіряє функціональність і виявляє дефекти в окремих компонентах додатка, які можуть бути доступні і піддаватися тестуванню окремо (модулі програм, об’єкти, класи, функції та інше).

2. Інтеграційне тестування (Integration Testing)
Перевіряється взаємодія між компонентами системи після проведення компонентного тестування.

3. Системне тестування (System Testing)
Основною метою системного тестування є перевірка функціональних та нефункціональних вимог у системі в цілому. Під час цього тестування виявляються дефекти, такі як неправильне використання ресурсів системи, непередбачені комбінації даних на рівні користувача, несумісність з оточенням, непередбачені сценарії використання, відсутність або неправильна функціональність, незручність використання та інші.

4. Операційне тестування (Release Testing)
Навіть якщо система відповідає всім вимогам, важливо переконатися, що вона задовольняє потреби користувача та виконує свою роль у своєму експлуатаційному середовищі, як це було визначено в бізнес-моделі системи. Слід враховувати, що бізнес-модель також може містити помилки. Тому так важливо провести операційне тестування як останній крок у валідації. Крім цього, тестування в середовищі експлуатації дозволяє виявити і нефункціональні проблеми, такі як: конфлікти з іншими системами, пов’язаними з бізнесом або програмними та електронними середовищами; недостатня продуктивність системи в умовах експлуатації і т. д. Так, виявлення таких проблем на етапі впровадження є критичною і витратною проблемою. Тому так важливо проводити не тільки верифікацію, але й валідацію ще з самого початку розробки програмного забезпечення.

5. Приймальне тестування (Acceptance Testing)
Формальний процес тестування, який перевіряє відповідність системи вимогам і проводиться з такими цілями:
• визначення, чи задовольняє система приймальним критеріям;
• прийняття рішення замовником або іншою уповноваженою особою щодо того, чи приймається додаток чи ні.

Види / типи тестування

Функціональні види тестування

• Функціональне тестування (Functional testing)
• Тестування користувацького інтерфейсу (GUI Testing)
• Тестування безпеки (Security and Access Control Testing)
• Тестування взаємодії (Interoperability Testing)

Нефункціональні види тестування

• Всі види тестування продуктивності:
o Тестування навантаження (Performance and Load Testing)
o Тестування на стрес (Stress Testing)
o Тестування стабільності або надійності (Stability / Reliability Testing)
o Тестування обсягу (Volume Testing)
• Тестування встановлення (Installation Testing)
• Тестування зручності використання (Usability Testing)
• Тестування на відмову та відновлення (Failover and Recovery Testing)
• Конфігураційне тестування (Configuration Testing)

Пов’язані зі змінами види тестування

• Димове тестування (Smoke Testing)
• Регресійне тестування (Regression Testing)
• Повторне тестування (Re-testing)
• Тестування збірки (Build Verification Test)
• Санітарне тестування або перевірка узгодженості/правильності (Sanity Testing)

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

Тестування користувацького інтерфейсу (GUI Testing) — це функціональна перевірка інтерфейсу на відповідність вимогам, таким як розмір, шрифт, кольори, послідовність дій (consistent behavior).

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

Тестування взаємодії (Interoperability Testing) — це функціональне тестування, яке перевіряє здатність застосунку взаємодіяти з одним або кількома компонентами або системами. Це включає тестування сумісності (compatibility testing) і інтеграційне тестування.

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

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

Обсягове тестування (Volume Testing) має на меті отримання оцінки продуктивності при збільшенні обсягів даних у базі даних застосунку.

Тестування стабільності або надійності (Stability / Reliability Testing) має на меті перевірку працездатності додатка під час тривалого (багатогодинного) тестування з середнім рівнем навантаження.

Тестування встановлення (Installation Testing) спрямоване на перевірку успішної установки і налаштування, а також оновлення або видалення програмного забезпечення.

Тестування зручності використання (Usability Testing) — це метод тестування, спрямований на встановлення ступеня зручності використання, навчаності, зрозумілості та привабливості для користувачів розроблюваного продукту в контексті визначених умов. Сюди також входять:
User eXperience (UX) — це враження, яке відчуває користувач під час використання цифрового продукту, тоді як User Interface (UI) — це інтерфейс, який дозволяє взаємодіяти «користувач — веб-ресурс».

Тестування на відмову та відновлення (Failover and Recovery Testing) перевіряє тестований продукт з точки зору здатності протистояти і успішно відновлюватися після можливних відмов, спричинених помилками програмного забезпечення, відмовами обладнання або проблемами зв’язку (наприклад, відмова мережі). Метою даного виду тестування є перевірка систем відновлення (або дублювання основного функціоналу систем), які у випадку виникнення відмов забезпечують збереженість та цілісність даних тестованого продукту.

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

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

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

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

Тестування збірки (Build Verification Test) — це тестування, спрямоване на визначення відповідності випущеної версії критеріям якості для подальшого початку тестування. За своїми цілями, тестування збірки є аналогом Димового Тестування, спрямованого на перевірку нової версії перед подальшим тестуванням або використанням. Воно може проникати глибше, в залежності від вимог до якості випущеної версії.

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


Підходи до інтеграційного тестування:
• Знизу вгору (Bottom-Up Integration)
Всі низькорівневі модулі, процедури або функції збираються разом і потім тестуються. Після цього збирається наступний рівень модулів для проведення інтеграційного тестування. Даний підхід є корисним, якщо всі або майже всі модулі розроблюваного рівня готові. Крім того, цей підхід допомагає визначити рівень готовності застосунку на основі результатів тестування.
• Зверху вниз (Top-Down Integration)
Спочатку тестуються всі високорівневі модулі, а потім поступово додаються низькорівневі. Всі модулі нижчого рівня симулюються заглушками з аналогічною функціональністю, і по мірі готовності вони замінюються реальними активними компонентами. Таким чином ми проводимо тестування зверху вниз.
• Великий вибух («Big Bang» Integration)
Всі або майже всі розроблені модулі об’єднуються разом у вигляді завершеної системи або її основної частини, після чого проводиться інтеграційне тестування. Такий підхід дійсно дозволяє зекономити час. Однак, якщо тест-кейси та їх результати записані невірно, процес інтеграції може стати значно складнішим, що стане перешкодою для команди тестування у досягненні основної мети інтеграційного тестування.

Принципи тестування

Принцип 1 — Тестування демонструє наявність дефектів (Testing shows presence of defects)
Тестування може показати, що дефекти присутні, але не може довести, що їх немає. Тестування зменшує ймовірність наявності дефектів у програмному забезпеченні, але навіть якщо дефекти не були виявлені, це не доводить його коректність.

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

Принцип 3 — Раннє тестування (Early testing)
Щоб знайти дефекти якомога раніше, активності з тестування повинні бути розпочаті на початкових етапах життєвого циклу розробки програмного забезпечення або системи і повинні бути спрямовані на конкретні цілі.

Принцип 4 — Кластеризація дефектів (Defects clustering)
Зусилля з тестування повинні бути спрямовані пропорційно очікуваній, та пізніше, фактичній щільності дефектів за модулями. Зазвичай, більшість дефектів, виявлених під час тестування або спричинивших основну кількість відмов системи, знаходиться в невеликій кількості модулів.

Принцип 5 — Парадокс пестицидів (Pesticide paradox)
Якщо одні й ті самі тести будуть виконуватися багато разів, в кінцевому рахунку цей набір тестових сценаріїв більше не знайде нових дефектів. Щоб подолати цей «парадокс пестицидів», тестові сценарії повинні регулярно переглядатися й коригуватися, нові тести повинні бути різноманітними, щоб охопити всі компоненти програмного забезпечення або системи й знайти якомога більше дефектів.

Принцип 6 — Тестування залежить від контексту (Testing is context dependent)
Тестування виконується по-різному залежно від контексту. Наприклад, програмне забезпечення, в якому безпека має критичне значення, тестується інакше, ніж сайт електронної комерції.

Принцип 7 — Омана щодо відсутності помилок (Absence-of-errors fallacy)
Виявлення та виправлення дефектів не допоможуть, якщо створена система не відповідає користувачеві і не задовольняє його очікування та потреби.

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

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

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

Вимоги до вимог:
• Коректність
• Однозначність
• Повнота набору вимог
• Відсутність суперечностей у наборі вимог
• Перевіряемість (здатність до тестування)
• Трасованість
• Зрозумілість

Життєвий цикл дефекту (бага)


Етапи розробки програмного забезпечення (ПЗ) — це етапи, які проходять розробники програмного забезпечення, перш ніж програма стає доступною для широкого кола користувачів. Розробка програмного забезпечення починається з першого етапу — етапу «пре-альфа», і продовжується через різні етапи, на яких продукт вдосконалюється та модернізується. Завершальним етапом цього процесу є випуск на ринок остаточної версії програмного забезпечення — «релізу для широкого загалу користувачів».

Програмний продукт проходить наступні етапи:
• Аналіз вимог до проєкту.
• Проєктування.
• Реалізація.
• Тестування продукту.
• Впровадження та підтримка.

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

Життєвий цикл розробки програмного забезпечення:
• Збір вимог
• Планування і дизайн
• Розробка/імплементація
• Тестування
• Деплоймент
• Підтримка

Життєвий цикл тестування програмного забезпечення:
• Пре-альфа
• Альфа
• Бета
• Кандидат на реліз
• Реліз
• Післярелізний

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

QA/QC/Test Engineer

Отже, ми можемо побудувати модель ієрархії процесів забезпечення якості: Тестування — частина Контролю якості (QC). QC — частина Забезпечення якості (QA).

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


Джерела: www.protesting.ru, bugscatcher.net, qalight.com.ua, thinkingintests.wordpress.com, книга ISTQB, www.quizful.net, bugsclock.blogspot.com, www.zeelabs.com, devopswiki.net, hvorostovoz.blogspot.com.

Ресурси рекомендовані в коментарях Sofiya Novachenko: istqbexamcertification.com www.testingexcellence.com

👍ПодобаєтьсяСподобалось77
До обраногоВ обраному156
LinkedIn

Найкращі коментарі пропустити

ОК, после прочтения этой статьи курсы QA уже не нужны.

Ще варто загадати про requirement traceability matrix (матриця покриття вимог), в загальному про етапи розробки і місце тестування в цих етапах.
Підходи до Integration Testing — Bottom Up, Top Down, Big Bang.
З тестової документації ще є поняття Quality Assurance Plan, Test Strategy.
Валідація / Верифікація — пояснення і різниця між термінами.
Взагалі класні ресурси istqbexamcertification.com і www.testingexcellence.com де по теорії багато що розжовується і пояснюється.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Мета тестування- збільшити ймовірність правильної роботи ПЗ
./ а також
збільшити ймовірність відповідності ПЗ всім описаним вимогам
./ і
надання інформації про стан ПЗ на даний момент.

Етапи тестування: (без відповідей на питання хто? що робить? коли? навіщо? скільки? немає цілісного сценарію, що сумно)
1. Аналіз продукту (що на загал має бути, певно)
2. Робота з вимогами (можливо, яке має бути ПЗ)
3. Розробка стратегії тестування та планування процедур контролю якості (опірні точки прийняття рішень важливі)
4. Створення тестової документації (бюрократія, позіхи і дотошність)
5. Тестування прототипу (наявної частини програми?)
6. Основне тестування
7. Стабілізація (стабілізатори, гомогенізатори, ароматизатори...)
8. Експлуатація (техпідтримка, певне)

Тест план (Test Plan) — це документ, який описує весь обсяг робіт з тестування, починаючи від опису об’єкта, стратегії, графіка, критеріїв початку і закінчення тестування, до необхідного обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
Відповідає на запитання:
Що потрібно тестувати?
Що будете тестувати? (типу потрібно і будете, потрібно і не будете, не потрібно і будете, не потрібно і не будете :J ?)
Як будете тестувати?
Коли будете тестувати?
Критерії початку тестування.
Критерії завершення тестування.

Якість програмного забезпечення (Software Quality) — це характеристики програмного забезпечення, завдяки яким ПЗ задовольняє встановлені та передбачувані потреби. [Quality management and quality assurance].
Тобто клієнт хоче кримнашзнову, тестувальник визначає, чи ПЗ видасть саме результат кримнашзнову, і як воно клієнтові буде потенційно прогнозоване можемзіркальнапабухтєть

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

Валідація (validation) — це визначення відповідності ПЗ потребам користувача і вимогам до системи [BS7925-1].
Напевне, тестувальник визначає, чи ПЗ робить те, що хоче клієнт, і чи розробник у моменті не вдосконалює систему, яка ще позавчора робила все, що має робити.
Варіанти значень:
Оцінювання відповідності ПЗ прописаним програмістами вимогам (специфікаціям)- це верифікація (verification), а відповідність продукту вимогам користувачів- це валідація (validation).
Ще одне визначення цих понять:
Валідація — «is this the right specification?».
Верифікація — «is the system correct to specification?»
Спершу
валідація визначає правильність специфікації, потім
верифікація визначає відповідність ПЗ щодо правильної специфікації.

Здається вам треба статтю писати)

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

Штош))) розберемо «на пальцях»

Тестування програмного забезпечення —
співставлення реальної та очікуваної поведінки програми. Здійснюється певною кількістю тестів, вибраних у певний спосіб.
Включає
планування робіт (Test Management), проектування тестів (Test Design),
виконання тестування (Test Execution) та
аналіз отриманих результатів (Test Analysis).
Себто такий собі бек-енд)

Брала участь у безкоштовному марафоні- промоушені платного курсу навчання для тестувальників.
«Ось як описується баг, ось як заповняти поля у Jira, ось необхідний мінімум теорії»
Перші два завдання за готовим зразком зробила запросто. З теорії, нібито необхідної, вгадала 2 відповіді з 12. Бо теорія не про прості зрозумілі дії. А про те, що в світі є це, і оце, і ще оте.
У першому уроці придбаного мною платного курсу- посилання на оцю статтю. Інформації навалили, як .уйло в чемодан, подумала я.

І- що?
Визубрити, як отченаш, заважає моє застаріле переконання у важливості розуміти матеріал. Та й без хоч якогось застосування тій зубрьожці гріш ціна.
Пам’ятаю, як вчили у школі. От правило, от приклади на це правило, от винятки, от приклади на винятки.
Пам’ятаю, як вчили в медунівері. От хворий на приймальному відділенні, от які документи заповнити, от як обстежити.
Не описували всіх працівників системи охорони здоров’я, від санітарки до міністра. Замість описувати всі можливі процеси в лікуванні, всі задачі і функції- чомусь подавали Інформацію поетапно і з певним обсягом необхідних ДІЙ відносно поданої Інформації.

Питання до автора статті: що пропонуєте робити з усією поданою Інформацією?

Це цікаво, такої пред’яви в мене ще не було, а тут вже 300+ коментарів і було різне ) Отже,
по-перше, на цьому ресурсі і, тим паче, на багатьох інших є купа матеріалу, який мені не цікавий/не зрозумілий/не корисний і, власне, я то просто не читаю. Якщо вам особисто це не корисне, я ж нікого не змушую набивати перегляди )
по-друге, я не є бенефіціаром тих курсів. Я знаю, що цей топік багато де використовується, як референс, але мене про це ніхто не питає ) Це відкритий ресурс, тим паче, що багато людей контріб’ютили в цей текст, так що він вже давно не зовсім мій, а більше належить до ком’юніті, а я виступаю просто мейнтейнером ) Єдине, що матеріальне від цього топіку я отримав — це футболка і светр від доу за перший мільйон переглядів. Футболку прислали замалу, то чекаю другого мільйона зі сподіванням, що пришлють футболку розміром більше )
в-третє, я це написав не коли вчився, а коли вже шукав другу роботу. Тобто на той момент я це все знав і з теорії і щось з досвіду. Але мені бракувало одного місця, де буде це все разом для повторення. Не для вивчення. Я зробив це для себе і вирішив, що це може комусь ще бути корисно саме для повторення перед співбесідою. Я навіть знаю менеджерів, які проходяться по цьому матеріалу, щоб згадати базову теорію для проведення співбесіди, а не тільки для проходження. Але знову ж таки, пригадати, що там є, а не вивчити з нуля. Для вивчення якраз вам і пропонують курси. Якщо курси обмежуються тільки цим топіком, то вас трошки обманули.
в-четверте, якщо ви бачите опортуніті розкрити тему, якої вам не вистачає — розберіться з нею і створіть свій матеріал. Тільки так наступним після вас буде легше. Допомагаючи одне одному ми, як спільнота, будемо розвиватися швидше і якісніше. Наприклад, Техніки тест-дизайну для «чайників» Тестувальниці важко давалася ця тема під час навчання, вона з нею розібралася і написала матеріал, який має допомогти іншим розібратися саме в цій темі.

Ясно, що справа темна :)
В історії медицини був період, коли пацієнта лікував той лікар, який знав напам’ять більше мегабайт) медичних параграфів. І от поки конкуренти-айболити коло ліжка хворого виголошували свої бліц-промови... роботи в них могло і не стати.
Але що на сучасній співбесіді може бути усний екзамен з основ теорії... тобто вифільтровують хто більше знає мегабайт)- ... ну ок, таке вже життя.
Зараз справді багато «курсів», що по суті є конвейєром відеолекцій і підбіркою інформації з відкритих джерел.
А створювати свій матеріал- це ж спершу ЦА дослідити, болі і решту маркетингу... тут хоч би додуматись, як вивчити з нуля :)

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

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

А про найлегший вступ через тестування- мені це озвучував програміст, що сам перевчився з тестувальника.

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

Склалося враження, що вся теорія тестування існує десь у вигляді стрункої системи чи алгоритма на кшталт if... than ... else..., і де прописані всі goto
:)
Вам успіхів!

I think a great job was done. Thank you.

Нарешті!
Хоч одна нормальна корисна практична стаття на DOU!
Дякую автору за класний контент!

в поясненні, що таке тест сценарій є складнощі перекладу зі словом «тестируємої»)

Дякую, виправив. Підстава від чату гпт )

ще помітив в принципах тестування в 7 пункті слово «заблуження» також не дуже коректно звучить, можливо омана тут краще підійде

SDLC описано неправильно, альфи і таке інше — це стадії дев-тестінг-деплой.
Я б рекомендував замінити на:
1. Збір вимог.
2. Планування і дизайн.
3. Розробка/імплементація.
4. Тестування.
5. Деплоймент.
6. Підтримка.

Згоден, оновив і додав

В техніках тест дизайну здається правильніше перекласти
Причина / Наслідок
А не причина / слідство
Це до коригувань😊

Красно дякую! ) Як то можна було не помітити ) Переклад з чатом гпт це та ще забавка )

Дякую за статтю, корисно! Допомогає підготуватись до співесіди)

Величезне ДЯКУЮ!!! Ця стаття — це космос!

Мой вариант требований к требованиям. Требование должно быть:
1)Единичным — требование описывает одну и только одну вещь.
2)Завершенным — требование полностью определено в одном месте и вся необходимая информация присутствует.
3)Последовательным — требование не протеворечит другим требованиям.
4)Атомарным — требование не может быть разбито на ряд более детальных требований без потери завершенности.
5)Актуальным — требование не стало устаревшим с течением времени.
6)Выполнимым — требование может быть реализовано в пределах проекта.
7)Недвусмысленным — требование кратко определено без обращения к техническому жаргону. Возможна одна и только одна интерпретация.
8)Обязательным — требование представляет определенную заинтересованным лицом характеристику, отсутствие которой приведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятию требования.
9)Проверяемым — реализованность требования может быть определена через один из четырех воможных методов: осмотр, демонстрация, тест или анализ.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Дякую! Вдало вирішив перевірити, чи не має десь збитої в один документ теорії тестування)

Мені здається, що треба навпаки, а не так: Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’
Верифікація передує валідації, і перевіряє саме специфікацію, а не систему.

Как по мне оригинал логичен. Верификация — правильно ли по спеке, валидация — а та ли ваще спека. Эксперты, нам нужно третье мнение )

Верифікація — робота системи з точки зору документації
Валідація — робота системи з точки зору користувача

Автор був «на собеседовании на Middle QA» і далі розказує про основи для Trainee and Junior :)

Ці основи можуть запитати і потенційного міддла

Коментар порушує правила спільноти і видалений модераторами.

Отличная статья. Очень помогла при подготовке к первому собеседованию.

Вы только это под-учили и пошли на собес? // Вы сейчас работаете в QA?

Опа, приехали. Значит,

Exhaustive testing is impossible

А ещё фундаментальная теория называется...
Это же надо, не можете сделать полный перебор.
А точнее не хотите.
Hint: у математиков с их бесконечнымм множествами как-то получается, а тут сразу невозможно

Я ж так понимаю, это сарказм? Бо у матиматиков с их теориями то всё возможно, а здесь на это денег никто не даст )

Бо у матиматиков с их теориями то всё возможно, а здесь на это денег никто не даст )

Можно подумать что вы это умеете чтоб вам на это денег давать. А то вот математикам которые умеют — очень даже дают денег, взять хотя бы machine learning.

Кстати, если аргумент был про деньги — тогда стоит писать что-то про «exhaustive testing is expensive». А то сразу невозможно...

Давайте, чтоб не быть голословной — вы проведёте эквсперимент. Берём условный сайт www.amazon.com и тестируем все возможные комбинации. Не забудьте про локализацию и геолокацию (некоторые компании делают разный UI под разные страны). Как закончите — жду вас с победной вестью )

Ок, если я пойду делать Exhaustive testing для Amazon, то вам предлагаю сходить кое-что проверить.
Например что для всех прямоульных треугольников сумма квадратов катетов равна квадрату гипотенузы.

Прошу заметить, что у Amazon кейсов намного меньше чем существует прямоугольных треугольников (их бесконечное количество если что). И для треугольников такую проверку уже сделали. Причем давно.

були проведены розрахунки для КОЖНОГО варіанту трикутника окремо?

Это бесполезный спор, он никуда не приведёт )

Если, чтобы провернуть Exhaustive testing нужен либо полный перебор либо его еквивалент. Вот этот еквивалент нам и должен быть интересен. И как его сделать знают те же математики, у которых вообще теоремы про бесконечно большие множества, и ничего, сделали.

эквиваленты и достигаются техниками тестирования — классами эквивалентности, граничными значениями, доменным тестированием и так далее. Именно они уменьшают количество тест-кейсов БЕЗ уменьшения покрытия. А исчерпывающее тестирование действительно невозможно. На вашем примере — это как если бы математики доказывали НА КАЖДОМ ВОЗМОЖНОМ прямоугольном треугольнике эту теорию.

Оце норм, більше мільйона переглядів!

Почти 6 лет уже висит. Не теряет актуальность.

Наверное там где написано «Жизненный цикл разработки ПО» (SDLC), имелось ввиду «Жизненный цикл ПО» (SLC)

Автору великий респект за пророблену роботу,мене цей док виручав) на мою думку ще варто додати State Transition техніку)

он ее походу называет диаграмой связей

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

подскажите, пожалуйста, как тестировать калькулятор. Нужно для собеседования.

Во-первых, ответ на вопрос легко гуглится.

Во-вторых, к калькулятору применима часть тестов карандаша: youtu.be/Erctsy6i0zo

В-третьих, к IT в целом везде и всюду применяется бритва Оккама.

При чем тут бритва Оккама?
А при том, что не надо задавать вопросы, ответы на которые легко найти, даже если это вопрос в стиле: «У меня табуретка из красного дерева, а Гугл говорит, что можно сидеть на табуретках из дуба, но я не могу понять, а можно ли сидеть на табуретках из красного дерева?» — табуретка — это абстракция. А за незнание понятия абстракции в этом нашем IT без предупреждения выбивают зубы.

Спасибо за ответ.
Про карандаш смотрела.
Компания дала базовый курс программирования, но кстати тесты нам не давались. На собеседование к тестировщикам HR сказала почитать как тестировать калькулятор. Все что гугл показывает это абстрактные рассказы типа теста на карандаш (www.youtube.com/...​tsy6i0zo&feature=youtu.be). Я так понимаю мне нужно выучить какие есть тестирование и по пунктам рассказать процесс. Никакого примера кода нет?

Из всего сказанного непонятно ничего.

1) Вам собеседование (интервью) на тестировщика проходить?
Если на тестировщика, то на мануального?
Или на автоматизатора?
Или на какого-нибудь white-box или Software Engineer in Test?

2) Если на мануального, то скачайте с ресурса «nnmclub(.)to» курс «GeekBrains | Тестировщик ПО (2019) PCRec [H.264/720p-LQ]» и пройдите его. Там для новичков все разжевано.

Или этот курс: www.portnov.com/2018 — структура немного упоротая, но разобраться можно.

Или курсы на ресурсе «coursehunter» — «Школа для начинающих тестировщиков», «Тестирование веб-приложений 2.0» и какие-нибудь еще от «softwaretesting» по вкусу.

Ну и книгу типа «Тестирование Дот Ком» прочитайте.

3) Если на автоматизатора, то на том же «coursehunter» есть «Selenium WebDriver + Java для начинающих» и «Инструменты для автоматизации тестирования с Selenium + Java».

Код пишут либо автоматизаторы, либо white-box-тестировщики, либо Software Engineer in Test.
Мануальные по большей части тестируют руками, без какого-либо кода, лишь со временем осваивая автоматизацию и кодинг вообще.

Статья объемная и хорошая, но канонизировать не стоит, поскольку она где-то неполна, а где-то неточна или ее точность сомнительна. Некоторые моменты, такие как градация приоритетов и северити, — это просто один из возможных вариантов.

Всё правильно. Вроде за правду в последней инстанции никто и не борется ) Тем более, что материалу то уже почти 5 лет )

Мне кажется в определении баг-репорта ошибка —

с указанием причин и ожидаемого результата

я конечно только учусь, но думаю стоит различать шаги, которые привели к ошибке, и причины, ее спровоцировавшие, что есть намного более глубинная вещь, без знания кода программы в которой не разобраться. Или я неправ?

Я думаю автор имел ввиду не строчку кода, а логические причины ошибки. Типа шаги такие-то привели к тому, что текст стал длиннее (причина) и теперь кнопка не влазит в экран на мобильном. Как-то так )

Сегодня на собеседовании мне доказывали что есть 6 уровень тестирование, который находиться перед приемочным и называется «релизный ».
Сказал что об этом пишут везде.
Коллеги, вы знаете такой?

Больше скажу. Есть ещё и пред-релизный. Только не у всех ) У них есть релизный, вы не угадали )

Та не, то непонятная шутка была. Я за ISTQB не слежу, но уверен там такого не появилось ) То их местный жаргон.

Чудова стаття. Дуже дякую та бажаю Вам успіхів в усьому!

Sanity testing — тестирование на исправность или на готовность к работе лучше звучит, и да, спасибо за работу!

Спасибо большое, очень классная статья. Мой конспект перед каждым собеседованием. Еще предложения:

* не называть Pairwise парным тестированием,

* не использовать термин «Санитарное тестирование»,

* не переводить Test Case как тестовый случай, бо это ситуация,

* не заявлять разницу между regression testing и re-testing,

* пересмотреть определение Regression testing.

Давайте разбираться )
1. Подправил, отправляю обратно на ревью )
2. Звучит так себе, согласен ) Предложите замену
3. Это достаточно распространённый перевод... Есть альтернативы?
4. Тут хотелось бы подробней
5. № 4

2. Если под «санитарным тестированием» подразумевалось Sanity Testing, то прямой перевод вида «тестирование на вменяемость» или что-то подобное вполне может подойти
3. Тест, тестовый сценарий

Про санити — спорный вопрос. Я согласен, что «санитарное» звучит так себе (хотя к такому все привыкли, как и называть решения по автоматизации фреймворками), но «тестирование на вменяемость» точно большинству ясность не внесёт.
По второму — точно, чёт сразу не подумал, пасиб )

Но только это не так. Эти термины идут из разных классификаций

Можно и определения посмотреть, но ключевая разница между этими видами тестирования в том, на что делается больший упор. Smoke тестирование в первую очередь подразумевает высокую частоту выполнения тестовых запусков. Sanity тесты в первую очередь подразумевают обширный, но довольно поверхностный охват проверяемой системы. Эти наборы тестов могут совпадать, так как у них есть общая черта — предпочтительно малое время выполнения. Но цели и основной упор у таких наборов тестов разный.

Эти термины идут из разных классификаций

Из каких?

Sanity тесты подразумевают обширный, но довольно поверхностный охват проверяемой системы.

А где граница между «обширно, но поверхностно»?

Почему предлагается сравнивать частоту с широтой обхвата? Нельзя широко и часто? Что, нельзя узко и часто? Широко и редко? Узко и редко?

Smoke тестирование в первую очередь подразумевает высокую частоту выполнения тестовых запусков.

Это значит, что Sanity подразумевает низкую частоту выполнения тестовых запусков?

Смоук не подразумевает «частоту выполнения». Можно делать смоук раз в релиз, раз в год, или вообще без него обойтись — это просто один из этапов, как мытьё рук перед едой. Разумно делать его перед каждым обновлением, но это только рекомендация, а не принуждение.

Определения смотреть можно и нужно. Посмотрите в ISTQB определение Smoke и Sanity — они там приведены по-отдельности. Как вы объясните тамошний фокус с этими терминами?

А где граница между «обширно, но поверхностно»?
Почему предлагается сравнивать частоту с широтой обхвата?

А я и не предлагаю сравнивать частоту с широтой обхвата. Более того, из-за разной природы данных характеристик (как теплое и мягкое), я как раз и указал, что равенство smoke и sanity несколько неуместно. Множество тестов вполне себе может пересечься, но в общем случае эти наборы разные.

Нельзя широко и часто? Что, нельзя узко и часто? Широко и редко? Узко и редко?

Можно, но это либо не будет иметь смысл либо это будет другой вид тестирования.

Смоук не подразумевает «частоту выполнения». Можно делать смоук раз в релиз, раз в год, или вообще без него обойтись — это просто один из этапов, как мытьё рук перед едой. Разумно делать его перед каждым обновлением, но это только рекомендация, а не принуждение.

Да если так разобраться, то и тестирование в целом — это, скорее, рекомендация, а не принуждение. Всё можно делать и по всякому. Но все-таки хорошо бы, если и использовать те или иные виды тестирования, то использовать их по назначению, с целью извлечения максимальной пользы от каждого из них.

Определения смотреть можно и нужно. Посмотрите в ISTQB определение Smoke и Sanity — они там приведены по-отдельности. Как вы объясните тамошний фокус с этими терминами?

Я это могу объяснить тем, что sanity != smoke, как я и утверждал изначально. Или, как минимум, возразил вашему утверждению

Sanity = Smoke.
И всё просто.

Собственно, с этого и начался разговор.

Я принял ваше утверждение, и запросил его объяснение.

Вы объясните-уточните?

Я привел свое виденье разницы. Вы в свою очередь сослались на ресурс, который тоже указывает на

sanity != smoke

. Беглый поиск по гуглу выдаст еще кучу сравнений. Моё виденье этих видов тестирования вполне может отличаться от других, но общее то, что равенство между ними не ставится, так как цели и применение данных видов тестирования в общем случае различается.

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

1.

«Попарное тестирование» прямо хочется использовать, бо звучит просто и коротко, но правильно будет переводить эти простые английские слова сложносоставными определениями, вроде «Последовательное комбинирование всех свойств для пары двух отдельно рассматриваемых сущностей», но это реально усложняет всё...

Простого решения пока что не знаю.

Для этого ж и придумывают называния сложным вещам и патерны для решения схожих проблем ) Попарно, может, и не идеально, но сойдёт

Парно-комбинаторное тестирование )))

2.

Cмотрите в суть и проверяйте всё обратным переводом.

В английском языке понятие «Санитарный» заявлено как sanitary или sanitarian, поэтому переводить слово «Sanity» как «Санитарный» — мхм, очень глупо. Но очень распространённо.

«Sanity» надо переводить как «Адекватный / Здоровый / Годный к несению строевой службы». То есть, проверили билд поверхностно, и если он адекватный, то можем туда углубляться, иначе не надо.

И вообще, «Sanity check» используют не только тестировщики. Пример: testitquickly.com/...​sanita-in-corpore-sanity

Так вот. Даже если не придираться к переводу, а зырить в суть, то «Санитарное тестирование» ничем не отличается от «Smoke testing». Те же действия для той же цели.

Да, это два отдельных слова, и кажется, что и смыслы должны быть отдельными. Не надо так.

Поэтому не надо его переводить так, как к этому все привыкли, и не надо выносить его в отдельный пункт.

PS Неоднократно на собеседованиях спрашивал про разницу между «регрессионным» и «регрессивным» тестированием, и множество раз люди напрягаются и таки придумывают разнциу между ними. Реально капец...

Я тут больше согласен с Mykola Kolisnyk

К чему этот вопрос? У нас получается какая-то Terms Driven Discussion больше чем по сути. Алексей, зачем вы здесь пишете? ) Если сильно не нравится — напишите своё лучше. На этом же прогресс и построен. Если вы переживаете, что я всё испортил и 600К просмотров — это очень плохо, то не пишите здесь. Ибо каждый коммент отправляет нотификейшн части людей, которые уже прочитали статью и следят за комментами.

И много это помогло тестировщикам в практической жизни? знание разницы между

регрессионным" и «регрессивным» тестированием,

? просто в разных источниках названо по разному эдинной теории тестирования как таковой нет .... в одной конторе меня тестировщика с 10 годами стажа (на тот момент) спросили разницу между багом и дефектом — и я её таки не знал .... за 11 лет стажа ни разу не пригодилась

так разницы ж нета между регрессионным и регрессивным — в том то и шутка. При такой невнимательности 11 лет опыта вызывают вопросики:)

Спасибо КЕП Я тебе больше скажу

регрессивным

названо У Савина и отсюда пошли несоответствия .... только Смысл это спрашивать? от этого поменяеться что то на практике?

3.

Вообще, даже большинству англоязычных людей до сраки, что означает слово Case в ’Test Case’, но это слово очень контекстное и тащит за собой множество смыслов, поэтому важно понять его правильный перевод.

testitquickly.com/...​sena-cai-verzi-pe-pervaz

А чем сценарий не подходит?

Инструкция всегда основана на сценарии. Не бывает тест-кейсов, которые внутри себя не содержат сценарии.

Однако можно сценарии писать отдельно.

То есть, разница между test case и test scenario огроменна :) Но в киевской тусовке тестировщиков считается, что это одна и та же бубуйня, и незачем ею заморачиваться.

4.

Не надо заявлять новичкам разницу между regression testing и re-testing, точно так же, как не надо их просить объяснить разницу между борщом и танком — это вообще разные вещи.

В предложении поразмыслить «В чем разница между regression testing и re-testing?» кроется и «а между ними есть общее».

Предполагаю, что как только произойдёт осмысление термина regression (понять, почему и зачем это делается, а не примитивное «как именно это делается»), то и предложение объяснить разницу между regression testing и re-testing становится смешным.

але 99% співбесід на пре-middle рівнях включають в себе питання, що таке regression testing, що таке re-testing і яка між ними різниця. І від кандидата очікують почути саме те, що написано в цій темі, а не його намагання розказати «а между ними есть общее».

99% співбесід на пре-middle рівнях вообще можно не проводить, бо к ним готовятся на вот этом уровне и результат их соответствующий. На такие собеседования ходят такие же недомидл-сеньоры, которые спрашивают только про то, что лежит на поверхности, бо если их самих кто-то вскопает, то они свои сеньорские эполеты заслуженно потеряют.

99% кандидатов на пре-middle рівнях бесперебойно тарабанять определения, которые заявлены в этой теме, но не могут объяснить эти термины по-отдельности.

Потом появляется 99% тем с вопросом «А почему всё так сложно на пре-middle рівнях?» Там не сложно. Просто 99% готовятся только по материалу, который здесь представлен, и считают его исчерпывающе достаточным. Да, он достаточен для сдачи зачёта в универе — сдал и забыл. А для работы это не подходит.

Конечно, 99% тестировщиков благодарны автору темы за то, что он собрал из щепок и песка этот псевдо-реферат (сделал за них всё то, что им полагалось делать самостоятельно), но этим же автор вносит свой огромный вклад в испорчивание пре-middle-уровневых кандидатов, ибо получилось громоздко, бессистемно, очень отрывисто и, как следствие, слабопонятно.

Ганглий является скоплением, состоящее из тел, дендритов и аксонов. Обычно имеет также оболочку из соединительной ткани. Часто соединяются между собой, образуя различные структуры. Пучки волокон, которые соединяют идентичный правый и левый ганглии, называются комиссуры. Пучки, соединяющие разноимённые ганглии (например, ганглии разных сегментов) называются коннективы. Ганглии могут сливаться, образуя более сложные структуры.

Это сокращённая цитата из Википедии. Даже если не знать, что такое ганглий, то всё смотрится норм, ибо это псевдо-реферат, в котором нет искажений (это цитата, там так и написано). И если на собеседовании про это спросят, то я оттарабаню эту фразу и ошарашу 99% недомидлоты своим безупречным знанием и изложением. А если бы кто-то вякнул «А конкретно что такое ганглий?», то на него все зашикали бы, как на дебила, бо всем же должно быть понятно, что такое ганглий. Не сдаваться и не признаваться в незнании — обычное поведение 99% на пре-middle рівнях.

«Энтерпрайз — это написание логики сепулек. Я не понимаю что это за сепульки, но мне уже понятны операции на сепульках, в каких таблицах сепульки локализованы, какие у них есть свойства, я даже уже знаю как создать сепульку через юай. Причем аналитик лекцию про устройство сепулятора продолбал, учебник не читал или не понял, а клиенту это нужно, потому что конкуренты говорят, что уже давно сепуляются! И консалтеры с бизнес-тренерами авторитетно утверждают что за сепулением — будущее» © twitter.com/...​tatus/1085940561440399362

6.

Нельзя объединять «Исследовательское / ad-hoc тестирование». Это то же, что заявить «русские и украинцы одинаковые».

Разница между ad hoc и exploratory testing в том, что они используются по-разному для разных целей, но для новичков это всё надо долго объяснять, и в двух словах ещё ни у кого не получалось.

Ключевой момент: в старых книгах никто не заявлял, что в ad hoc нет нужды использовать требования, или, более того, что это всё мы используем, когда требований нет. Надо требования. Надо тест-кейсы.

Под этим пунктом написано, что разница между терминами есть. Не говориться, что это одно и тоже, но подразумевается, что схожесть есть. Так же как и украинцы с русскими — ме не одинаковые, но, хотя бы глядя на наши дороги, понимаешь, что что-то между нами общего всё же есть )

Между указательным пальцем и МПХ тоже огромная разница и огромная схожесть.

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

в деталях нужно искать отдельные статью по сабжу. Здесь общая инфа вспомнить о чём речь для людей, которые годик на первой работе поработали и хотят идти дальше. Лично мне эта штука помогла нормально.

Коментар порушує правила спільноти і видалений модераторами.

Спасибо огромное за такую исчерпывающую информацию! Очень просто и здорово на писано!

Парное тестирование (Pairwise Testing)

Правильно буде не «Парне», а «Попарне»

Хм, никогда такой интерпретации не слышал ) Про программирование на русском тоже говорят «парное». Но я не филолог )

власне парне програмування це коли дві людини працюють разом(Pair programming\testing). І це ок переклад.
Pairwise testing — це підхід де вхідні параметри ділять на пари і перевіряють кожну з цих пар

Точняк, не то понял.

Боже мой, это же просто находка! Спасибо огромное!

Принцип 2 — Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)
Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию. Не согласен. Правильно спроектированную и написанную программу можно (и нужно) тестировать исчерпывающе.

рассчитать трудозатраты исчерпывающего тестирования «правильно спроектированную и написанную программы»?)) выделишь бюджет на него?))

Могу предложить метод проектирования. За бюджет это не ко мне.

Ну так может и обсуждать практики, которым уже много лет и применяются всеми и везде — тоже не к вам?)

Правильно спроектированную и написанную программу можно (и нужно) тестировать исчерпывающе.

ем. калькулятор. Вичерпне тестування це всі вхідні параметри, всі шляхи виконання.
Як таким чином протестувати калькулятор ?

Выбешивают неграмотные.. А по твоему исчерпывающее тестирование предполагает все варианты входных данных проверить? Тогда ты тупой..

по твоему исчерпывающее тестирование предполагает все варианты входных данных проверить

ТАК. тому воно вичерпне, тобто ВСІ можливі варіанти вхідних даних

Тогда ты тупой..

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

Михаил — знатный наркоман, посмотри его топики здесь))
так что кип ит изи

Я тоже подумал глянуть. Сами топики не осилил, но коменты говорят сами за себя.

Исчерпывающее тестирование предполагает проверку приложения со всеми возможными вариантами входящих данных. Допустим, мы делаем систему кредитования. До 10К тугриков один процент, после — другой. Исчерпывающее тестирование предполагает 10К вариантов в первом случае. А возьмём копейки — *100. А где тогда граница второго варианта? И это только одно условие. Добавим возраст — итого все кейсы множим на 2. Как всего этого достичь? И главное — где смысл )

Вы, реально считаете что трансляторы проверяют тестируя все возможные варианты входного текста? Вы хоть что-то слышали о формальных определениях, разбора регулярных выражений, парсерах, о проверке рекурсивных функций. Может читали что-то о структурах данных и связи с алгоритмами? Неужели вы не слышали о методах автоматического построения алгоритмов, о языке UML, о методах автоматической верификации, формального определения спецификаций и автоматической верификации?

формальных определениях, разбора регулярных выражений, парсерах, о проверке рекурсивных функций

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

Вы, реально считаете что трансляторы проверяют тестируя все возможные варианты входного текста?

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

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

Насильно мы тут почти никого не удерживаем. Я считаю, что вы сделали всё, что могли дабы просветить всю остальную неграмотную часть посетителей сего сайта, за что вам крайне благодарен и не смею больше отнимать вашего драгоценного времени. Исчерпывающего вам тестирования и хорошего настроения )

Спасибо. Но тестирование и проблемы безопасности не мое.. Я так зашел исправить пару ошибок.. По большей части грамматических.

Большое спасибо за ваш труд. Нам вас будет не хватать.

Не расстраивайся.. Я там много полезного написал. Перечитывайте.. Пойдет на пользу. Заодно маленький пример придумал по теме. Вот как тестить программу анализирующую арифметические выражения со скобками по всем правилам арифметики и приоритетов. Придумайте тестовые примеры.. Их не много должно быть.. Для исчерпывающего тестирования))) А я буду заходить смотреть..

Если точнее, то exhaustive testing возможно. Просто в подавляющем большинстве случаев оно не возможно за вменяемое для проекта (и даже для человека) время.
Это конечно если корректно считать coverage, а не как обычно.
Формулировки наше все)

Точнее это как я сказал. Для тех, кто в танке-«Правильно спроектированную программу полностью тестировать можно и нужно.» Обратите внимание на слово «правильно», а не так как пишут обычно...С криками вперед и быстрее там разберемся.. Пока бабло платят.

мой комментарий никак не касается «правильно» ли «неаправильно» спроектированной программы. Он касается того, что вкладывается в понятие «exhaustive testing»
Если следовать мейнстримным практикам (use cases), то насколько тестирование exhaustive связано с тем, как считать coverage.
Если даже не углубляться, а следовать например Linear code sequence and jump (LCSAJ)
en.wikipedia.org/...​ar_code_sequence_and_jump
И при этом стремится к полному покрытию, то даже для небольшого проекта это будут огромные цифры.
Перебрать их все, что вручную что автоматически, это ооочень долго. Даже может быть дольше чем весь цикл жизни проекта.
Вот поэтому и "

xhaustive testing возможно. Просто в подавляющем большинстве случаев оно не возможно за вменяемое для проекта (и даже для человека) время.

"

xhaustive testing возможно. Просто в подавляющем большинстве случаев оно не возможно за вменяемое для проекта (и даже для человека) время.

Надо научиться сначала программы писать. Если решать задачи в лоб (я называю этот метод в писать длину), то, конечно. И тестировать трудно и сопровождать. Не с того конца решать проблему надо.

4. Операционное тестирование (Release Testing).
Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. МоделИ

Также можно встретить иную интерпритацию:

интерпретацию. Я б еще значения на границах проверил.

Доброго времени суток, спасибо автору за статью. Прям хард-повторение. Хочу помочь улучшить вашу статью этим исправлением. У Вас опечатка в данном абзаце (выделил жирным) "

Cтатическое и динамическое тестирование
Статическое тестирование отличается от динамического тем, что производится без запуска программного кода продукта. Тестирование осуществляется путем анализа программного кода (code review) или скомпилированного кода. Анализ может производиться как вручную, так и с помощью специальных инструментальных средств. Целью анализа является раннее выявление ошибок и потенциальных проблем в продукте. Также к статическому тестирвоанию относится тестирования спецификации и прочей документации.

"

Очень классная статья, спасибо.
Меня еще спрашивали на ряду с дымовым, про тестирование критического пути и расширенное

Спасибо автору. Как вовремя я нашел эту статью, а то уже понесло читать то, о чем пока что имею мало представления и вряд ли спросят на собеседовании.

Техника тест — дизайна «Исчерпывающие тестирование».
Принцип 2 — «Исчерпывающее тестирование недостижимо (Exhaustive testing is impossible)».
Полезно знать недостижимые техники тест-дизайна :-D
Лучше свои знания сверять с авторитетными источниками.
www.istqb.org/...​-level-syllabus-2011.html
www.dahlan.web.id/...​ware Test Design_Good.pdf вот по техникам неплохая книга.
Подскажите, почему исчерпывающие тестирование отнесли к технике тест — дизайна, какой источник об этом говорит?

Источник: www.protesting.ru/...​/testdesign_technics.html
Техника тест дизайна помогает выбрать входящие значения для теста. Если нужно протестировать, что паспорт выдают с 14 лет, то по технике граничных значений мы возьмём 13 и 14. По исчерпывающему — 0 — 150 (условно). Это тоже своеобразный выбор значений.

по поводу уровней тестирования их больше istqbexamcertification.com/...​-software-testing-levels . А именно:
1. Unit testing:
2. Component testing:
3. Integration testing:
• Big bang integration testing
• Top down
• Bottom up
• Functional incremental
4. Component integration testing:
5. System integration testing:
6. System testing:
7. Acceptance testing:
8. Alpha testing:
9. Beta testing:

не собесе только не говорите, что уровней тестирования 9,
пусть это останется вашей маленькой тайной :)

PS: линк на сайт АТБ не правильный )))

С вашим остроумием — Петросян нервно курит) Открываем стандарт ISTQB и читаем. Если такое сочитание букв -ISTQB вам знакомо)) узнаем много нового для себя — что есть все таки подтипи для выше упомянутых типов тестирования)) а, и еще постарайтесь о release testing найти в стандарте)))

ну куда ж нам, простым смертным, до Вашей крутизны )))))

Ребят, давайте не переходить на личности. Оля права, с ISTQB не посморишь, у Тараса тоже хороший поинт. Если и расписывать всё, то как расширение привычной пятёрки. Далеко не все читали и помнят стандарт. Главное — понимание процесса, а не формальное определение.

Главная проблема, что чаще всего котируются формальные знания, потому «шо так написано в стандарте», а понимает ли человек почему так, и какие есть еще варианты трактовки — совершенно неважно.

Ольга кинула ссылку на коммерческий ресурс и люди котрые это читают, могут подумать, что это официальный источник и там все по ISTQB.
Это не так.
Данный ресурс написан тестировщиком прошедшим сертификацию и решившим поделиться своими знаниями.
Эти данные не являются официальными, и не совсем соответствуют терминоглогии ISTQB
как в разрезе FL так и в разрезе ATM, а являются больше обобщающими, так сказать «для общего развития» )
пруф:

This website is not the official website of ISTQB and we are not affiliated with ISTQB or ITB.

Information provided on this website is unofficial and may be subject to change. Please refer to the official website for official details, dates etc. This site is in no way, shape, or form affiliated with, approved by, authorized by, or otherwise related to the ISTQB, ITB or any of its related boards.

Очень большая просьба Ольге не вводить в заблуждение, не разобравшись в проблематике вопроса )
официальный ресурс организации www.istqb.org

Во, а я думал сайт переделали )

вот это тут дебаты развернулись)) я как человек сдававший ISTQB и как человек которому попадался как раз такой вопрос — нужно было выбрать из списка какие есть уровни тестирования — могу сказать что я права. да, основных 4. но каждый из них имеет свои подвиды. если сайт который я скинула вам доверия не внушает, хотя по нему всегда все готовятся к экзамену, то ок. можете все перечисленные мною виды тестирования попробовать найти тут — glossary.istqb.org . официальный источник)

стандарт ISTQB

ISTQB не стандарт, а комерційна організація яка пропонує своє бачення на тестування

А что тогда стандарт по вашему?

Ну вы ж типа сдали istqb )
Должны знать стандарты по идее)
Там было это, даже вопрос попадается на экзамене)

Ваши комментарии направлены на то чтобы унизить человека. Ну никак вы не способны к конструктивному разговору... Я не типа, а сдавала и сдала экзамен) да, стандарты в istqb syllabus прописаны — в разделе на чем основано экзамен)) Ну и ? Что вы этим хотели сказать? Что документация экзамена не важна? Я вижу ваш слоган по жизни ’ лишь бы не молча’. Даже на четко поставленный вопрос отвечаете каким то глупым комментарием, а не четким ответом) я думаю те кому интересно тестирование мой комментарий поймут) до них дойдет) с вами и вашим острым умом общаться больше не буду)) p.s.. здесь люди типа делятся опытом. Типа дают ответы на вопросы. Обсуждают типа темы по тестированию , а не типа личные качества. Пишу вам типа на понятном вам языке) а то так вряд-ли дойдет)))

Может вы психологом пойдете работать?) Обеспечение качества и коммуникативные навыки, судя по коментариям — вот вообще не ваш конек ))))

Мне это уже говорили))) но я 💗 IT)

ISO/IEC/IEEE 29119 — але його дуже сильно критикують, відомі автори з тестування
є ще такі стандарти :
IEEE 829 Test Documentation
IEEE 1008 Unit Testing
BS 7925-1 Vocabulary of Terms in Software Testing
BS 7925-2 Software Component Testing Standard

стандарти, це те що випускають організації по стандартуванню. В тестуванні, як і в багатьох інженерних науках, все доволі відносно. Тому не завжди коректно покладатись на стандарти.
Наприклад, багато хто вважає є 3 рівні тестування — unit, integration, system. І в цьому є логіка. Тестування залежить від контексту і це потрібно завжди враховувати

то уровней тестирования 9

Декілька років тому, менеджер на внутрішньому екзамені хотів почути саме цей перелік :(

Сочувствую )))
а не просили расскзать про

— Hardware-software integration testing
— Feature interaction testing
— Customer product integration testing

? ))))

нє, він хотів почути у відповідь саме цю статтю

1. Unit testing:
2. Component testing:

а от яка різниця ? де починається\закінчується компонент ? дуже розмите поняття. Приклад з сайту — приклад інтеграційного тесту


Big bang integration testing
• Top down
• Bottom up
• Functional incremental

це не рівні тестування, а підходи до імплементації інтеграційного тестування

8. Alpha testing:
9. Beta testing:

взагалі ніякого відношення не мають до цього. ці види тестування вирішують різні задачі
Альфа тестування це швидше system\acceptance рівень.
Бета — acceptance, та і взагалі не дуже має спільного з тестуванням

Так вообще то это и есть подвиды 4х основных типов. Вы все правильно написали. И про тонкую грань тоже. В комментариях я писала что это подвиды. Просто скопировала с сайта с нумерацией, не знала что цель сидящих тут людей придраться к какой то нумерации))) и так понятно что это подвиды для людей которые в тестировании. Ну тут считается так круто сказать что istqb это фигня. В там то нужно две точки поставить или про АТБ пошутить))) p.s. Только насчёт Бета тестирования не соглашусь. Все таки альфа и бета относится к acceptance testing. Подвиды.

Ну про АТБ вы ж шутку не догнали)

АТБ==International Testing Board (сокращенно от International Software Testing Qualifications Board)

альфа и бета относится к acceptance testing. Подвиды

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

Доброго дня. а де можна про Acceptance Testing інформацію почитати?

Здравствуйте! В тестировании взаимодействия (interoperability testing) есть момент про тестирование совместимости (compatibility testing) — можете, пожалуйста, раскрыть тему последнего(совместимости)?

Доброго дня. Если коротко, то это тестирование совместимости системы с другими браузерами, железом, сетями, осями и т.д.

Жаль что не прочитал раньше, хорошо разбито и структурированно, без воды, емко
Освежил
П. С. Про локализации только на картинке есть

ISO 8402:1994

Этот стандарт уже отменен и вместо него используется ISO 9000:2015

Коментар порушує правила спільноти і видалений модераторами.

очепятка — tets case

Цели тестирвоания

 — старый баг, все забывал зарепортить :)

Добрый день. При изучении видов тестирования, есть вопросы:
1. Функциональные — в видах и типах тестирования вы указали, что это — функциональное тестирование, тестирование пользовательское интерфейса, безопасности и взаимодействия. Но,в схеме виды тестирования — функциональное (по целям) больше в себе ничего не имеет, все остальное — не функциональное. Это ошибка?
2. Есть ли разница? В перечне нефункциональных видов тестирование — название "Тестирование стабильности или надежности",но в схеме по — другому — "Надежности и восстановление после сбоев«,а в производительности — «Стабильности».
3. А куда входит кросс — браузерное тестирование? Его сдесь нет!

А куда входит кросс — браузерное тестирование?

а куда должно вхзодить тестирование котрое будет осуществляться на разных браузерах? одно и то же тестят или разное? это вопросы, чтобы вы подумали и дали себе ответ

День добрый.
По видам и типам лучше смотреть на то, что написано выше схемы. Кросс — браузерное тестирование — функциональное. Типы и виды не зависят от приложение. Не все приложения — веб, поэтому его тут нет. Поддержка браузеров — это требование к пролукту, соответственно — функционал.

к пролукту

прошу прощенья , а это кто?

Это очепятка *продукту

понял) думаю что за термин, никогда раньше не слышал)

Поддержка браузеров — это требование к пролукту, соответственно — функционал.

1. В різних браузерах можна робити як функціональні, так і не функціональні перевірки
2. Вимога до продукту бувають функціональні та не функціональні

Трудно не согласиться )

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

чего с чем?
как по мне так ты усложняешь и это всего лишь тестирвание продукта на разных браузерах и все, где там взаимодейстие?

istqbexamcertification.com/...​lity-testing-in-software
Тестування взаємодії\сумісності значить перевіряти продукт у роботі з різними середовищами. Для веб аплікації, різні середовища це і є браузери

Понял) понапридумывают термиологии , чтобы простые вещи сложно объяснять)))

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

Да, полностью согласен

не існує єдиної класифікації тестування. В різних джерелах може бути написано по різному.

Функциональные — в видах и типах тестирования вы указали, что это — функциональное тестирование, тестирование пользовательское интерфейса, безопасности и
взаимодействи

згідно з ISO 9126 на якому базується ISTQB — це вірно. Хоча ніде не написано про UI тестування.
зараз ISO 9126 замінено іншим стандартом, де безпека та взаємодія винесені як не функціональні аспекти.

Тестирование стабильности или надежности

це підвид performance testing

кросс — браузерное тестирование

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

Извините, а «тестирование пользовательское интерфейса» по новым стандартам — не функциональное? Можете назвать номер стандарта нового, пожалуйста?

ну вы написали, что

зараз ISO 9126 замінено іншим стандартом,

, есть ссылочка?

Здравствуйте, есть вопрос к ТС и всем кто в теме.
Модель качества программного обеспечения ISO/IEC 9126 определяет 6 целей (характеристики внутреннего и внешнего качества ПО) и 21 атрибут (подхарактеристик). Собственно для проверки этих характеристик и существуют различные виды тестирования. Условно их можно разделить на функциональные виды и не функциональные.

Согласно упомянутой выше модели качества, продукт имеет такую характеристику как Functionality и следующие подхарактеристики:

  • Suitability,
  • Accuracy,
  • Interoperability,
  • Functional Compliance,
  • Security.
В шпаргалке к функциональным видам тестирования ТС записал тестирование безопасности (Security Testing) и тестирование взаимодействия (Interoperability Testing) что верно в соответствии с моделью.

Вопрос:
Начиная с 2011 года модель ISO/IEC 9126 была замещена на ISO/IEC 25010 в которой Interoperability и Security не являются функциональным атрибутами. Корректно ли теперь причислять Security Testing и Interoperability Testing к функциональным видам тестирования?

Буду признателен на разъяснение по данному вопросу.

Если спросят на собеседовании, то вот именно это будет лучшим ответом ) А на самом деле куда более важно не знать к какому типу что относится, а понимать, что это такое и как это тестировать. Лично мне ближе старый вариант, но я уверен, что у людей, разрабатывавших новый стандарт, были причины переосмыслить.
Яркий представитель нефункционального типа — UX. Всё сделано по требованиям, но на сколько это удобно. Что же касается безопасности, то это функционал. У тебя либо base64 в куках либо двухфакторная аутентификация с физическим чипом.

Понял, благодарю Вас за пояснение.

модель ISO/IEC 9126 была замещена на ISO/IEC 25010

але ISTQB базується на 9126. і це дивно бо вийшло воно коли вже був 25010.
ІМХО, краще дати розгорнуту відповідь.
Хоча, багато людей пропустили цей пункт в ІСТКБ і не знають про це

Спасибо большое, очень классная статья. Мой конспект перед каждым собеседованием. Еще предложение внести Попарное тестирование в Техники тест дизайна.

Могли бы вы добавить метод пар в техники тест дизайна?

Спасибо большое! Перечитываю каждый день вашу статью, очень мне нравится она.

+1, статья он топ! спасибо. не хватает только black/white/grey-box’ов.

Кстати, Диаграмма связей, взрыв мозга .. ничего не понял ))

Зачем после «Санитарного тестирования» снова описывается техника тест-дизайна «Предугадывание ошибки» ??

Чувствуется мне, что это был баг ) Спасибо, убрал повторение.

Sanity и Smoke, в разных источниках вижу разные трактовки, а в ISTQB пишут, что это синонимы, разъесните кто-то поподробней, пожалуйста.

Эти понятия часто путают. Я бы сказал, что Smoke — преверка основных фич билда, дабы быстро сказать, что билд хороший. Sanity — проверка основного функционала фичи без глубокого тестирвоания, дабы быстро сказать, что фича хорошая. Но правильно так, как написано в ISTQB.

Я так поняла, сертификат ISTQB ценится, но не все термины так уж однозначно воспринимаются?

Сертификат однозначно ценится, но обычно меньше, чем реальные знания и опыт. Не все знают как оно в ISTQB написано и путают понятия. Самое главное — уметь думать.

Спасибо, просто перед собеседованием хотелось быть уверенной в своих ответах, но пока готовилась по двум-трем источникам было все норм, а когда количество источников перевалило за десяток понимание некоторых понятий стало расплываться. Плохо то, что не знаешь, по каким книгам учился тот, кто будет собеседование проводить. :)

Можно оперировать источниками и своим опытом. Лучший ответ на спорный вопрос — я понимаю это так и так это работает, а в ISTQB написано вот так. Главное, чтоб одно другому не противоречило.

Вопрос, насколько часто и что вы реально используете в проектах, из всего вышеперечисленного? Вопрос ко всей аудитории...

Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов.
Проводя параллель статьи и www.protesting.ru/…​ing/types/regression.html
Re-testing = Bug regression
Regression testing = Side effect regression

Вопрос перепутаны ли понятия? И где Регрессия старых багов (Old bugs regression)?

Я бы сказал, что Regression testing — это то, что написано у меня + «Side effect regression». Дописал в статье.

Old bugs regression
Честно говоря, никогда таким не занимался ) И даже не слышал, чтобы кто-то так делал. На старом проекте на такую активность могут уйти годы ) Тем более, что функционал меняется и степы в баге уже могут не соответствовать текущей реализации.
Был бы очень признателен, если бы вы с этим вопросом сходили на ISTQB и выяснили там, ибо то стандарт, а protesting — это ребятки, которые написали своим языком так же, как и я здесь. У нас с ними могут быть неточности, а стандарт — это закон.
В любом случае, спасибо!

«Тест аналитик, будет думать: „Что, если я не введу код?“, „Что, если я введу неправильный код? “, и так далее. Это и есть предугадывание ошибки» — это тест дизайнер.
По твоим же собственным словам:
Тест аналитик — определяет «ЧТО тестировать?»
Тест дизайнер — определяет «КАК тестировать?»

Так вот — аналитика касается функционала, дизайн — че с этим функционалом делать. Не надо противоречить себе и стандартам в статье о тестировании.

По факту из-за тебя много джунов проЭПСИЛОНбут собес.
Не надо путать людей в очевидных вещах. Перепиши, пожалуйста, этот момент читаемо или удали что б не засоряло сервак.

Ты помочь хотел, подсказать что-то или просто показать какой ты классный пацан? Больше похоже на второе, тогда смысла разговаривать нет — давай просто подумаем, что все подумают, что ты классный пацан и будем счастливы.
Если всё же первое, то со второй цитатой не согласен — пруф в студию. В эрор гесинге — согласен, слово аналитик там лишнее, заменил на тестировщика.
PS Комменты, что статья помогла найти работу видел, что из-за неё не взяли — не видел. Без пруфа дальшнейший разговор не имеет смысла.

Это наверно так в институтах культуры учат общаться, вместо «спасибо» — "

%уйню
«, Вы же уже более 3-х лет в тестировании и сертификация вроде как есть в отличии от меня, а я не могу пока на джуна попасть. Но почему то понимаю что хотел сказать автор в слове «ЧТО» — это имеется ввиду оценивает какие функции («ЧТО»- форма регистрации,"ЧТО" — поле логина, «ЧТО» — платный функционал) вот ЧТО в первую очередь нужно, к примеру, нужно протестировать на сайте, а не
«Что, если я не введу код?»,
, как Вы сказали. А вот «КАК» это и есть предугадывание, анализ граничных значений и остальные техники тест дизайна. Если Вы не понимаете сути или не умеете анализировать то, что дал автор — не читайте, лучше пройдите еще раз сертификацию.

Ну вот, я не проЭПСИЛОН-ил. А сколько ты столь развернутых статей написал, чтобы обвинять автора?

Коментар порушує правила спільноти і видалений модераторами.

спасибо большое, отличная работа!

Очень понравились две статьи про UI и UX с наглядными примерами.
«Разница между UI и UX: определение терминов»
www.idg.net.ua/blog/otlichiya-ui-i-ux
«Грань между UI и UX»
m.habrahabr.ru/post/190840
Кратко:
В переводе с английского UI (user interface) — это интерфейс пользователя. С помощью такого интерфейса юзер может взаимодействовать, т. е. вести диалог с устройствами, машинами, программами. Хорошим примером пользовательского интерфейса является мобильный телефон с дисплеем и клавишами для различных функций, приборная панель автомобиля с кнопками управления и т. д. UI — это то, как видит и с чем взаимодействует пользователь на экране.

Ощущения и реакции, которые возникают у пользователя при взаимодействии с продуктом (в нашем случае это компьютерные программы, сайты, приложения и прочее), называются опытом взаимодействия (UX, user experience). UX — это то, что чувствует и запоминает пользователь в результате использования программы, приложения или сайта. UX учитывается при разработке UI, создании информационной архитектуры, юзабилити-тестировании.

UI является частью UX. Цель обоих — улучшить, упростить, сделать удобнее. Но, хоть данные термины и тесно связаны, они отнюдь не синонимы. Вы можете иметь отличный UI, но ужасный UX, и наоборот. Дизайнеры, в основном, занимаются именно UI. Отрасль UX изучают другие специалисты — проектировщики, аналитики, маркетологи. Чтобы достичь максимального результата, необходима профессиональная работа специалистов обеих областей.

Спасибо за ссылки. Только лучше, наверное убрать «m.» из ссылки на хабр. Не все с мобильных сидят.

Хочу обратить внимание на пункт «Тестирование удобства пользования», т.к. Usability testing (Тестирование удобства пользования) и GUI testing (Тестирование пользовательского интерфейса) — это совсем разные виды тестирования!!! Написано много статей про разницу между ними.

Usability testing (относистся к Нефункциональным видам тестирования):
Testing to determine the extent to which the software product is understood, easy to learn, easy to operate and attractive to the users under specified conditions. (ISTQB Glossary)
Тестирование удобства пользования или Usability Testing — это метод тестирования, направленный на установление степени удобства использования, обучаемости, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий. [ISO 9126]
Тестирование удобства пользования дает оценку уровня удобства использования приложения по следующим пунктам:
— производительность, эффективность (efficiency) — сколько времени и шагов понадобится пользователю для завершения основных задач приложения, например, размещение новости, регистрации, покупка и т.д.? (меньше — лучше);
— правильность (accuracy) — сколько ошибок сделал пользователь во время работы с приложением? (меньше — лучше);
— активизация в памяти (recall) — как много пользователь помнит о работе приложения после приостановки работы с ним на длительный период времени? (повторное выполнение операций после перерыва должно проходить быстрее чем у нового пользователя);
— эмоциональная реакция (emotional response) — как пользователь себя чувствует после завершения задачи — растерян, испытал стресс? Порекомендует ли пользователь систему своим друзьям? (положительная реакция — лучше);

GUI testing (относистся к Функциональным видам тестирования):
Testing performed by interacting with the software under test via the graphical user interface. (ISTQB Glossary)
Задачей тестирования графического интерфейся пользователя является обнаружение ошибок следующего характера:
— Ошибки в функциональности посредством интерфейса;
— Необработанные исключения при взаимодействии с интерфейсом;
— Потеря или искажение данных, передаваемых через элементы интерфейса;
— Ошибки в интерфейсе (несоответствие проектной документации, отсутствие элементов интерфейса);

Спасибо, согласен, исправил )

Вашого коменту тут дуже бракувало)

скажите какая существует классификация ошибок, я чего-то не могу разобраться(

Коментар порушує правила спільноти і видалений модераторами.

Дякую, систематизували теорію)

Спасибо за статью, Геннадий! Она очень помогает структурировать имеющиеся у меня теоретические знания по тестированию))

Дефект (он же баг) —
Bug (defect) —
Зачем дважды давать определения?

Первое — классическое определение бага, второе — наглядная разница между deffect, error, failure.

Большое спасибо за статью! За обе ее части :-) А на собеседовании не спрашивают про SoapUI, Git, Web-сервисы, модель OSI, базы данных и Linux? Хочется знать, к чему готовиться :-)

Хех, я спрашиваю web, rest, linux, сети, теорию и пара задачек ) Эта статья больше для новичков, которые только теорию могут знать и у них остальное не будут спрашивать и более опытных людей, которые знают, что конкретно готовить на собеседование и это только, чтобы освежить теорию. А оси и линукс — это проджект специфик.

Ясно :-) А можете привести примеры задачек?

Есть задачка на траблшутинг, но её привести не могу, только на собеседовании ;). А есть простая на сети: могу написать в личку.

Вряд ли мы встретимся на собеседовании :-)) Поэтому да, пожалуйста, напишите в личку один или несколько примеров задачек.

Геннадий добрый день! Вы можете мне тоже в личку написать пару примеров задачек, если не жалко... заранее спасибо

Доброго времени суток! Меня также интересует вопрос, чему больше всего стоит уделить внимание перед поиском работы qa. Какими вопросами приблизительно будут штурмовать студента (скоро выпускника) на собеседовании, если опыта работы, к сожалению в этой сфере нет,а есть только теоретическая база и база html, css, java и желание развиваться.
Если не затруднит, ответьте сюда или в личку. Спасибо!

Если опыта нет, то будут спрашивать то, что знаете. Нужно штудировать теорию. Пусть она будет без практики, но, если есть понимание этой теории, то будет хорошо. Не лишним будет спросить, о чём пойдёт речь на собеседовании. Могут ответить, что, к примеру, будут кроме тестирования спрашивать про линукс и сети — вот вам и карты в руки.

Спасибо, очень кратко изложено и максимально приблеженное к ISTQB

Огромное спасибо за материал! После одного прочтения, действительно, что то запомнилось!Лучше чем бегать по сайтам и искать ответ на каждый вопрос! Супер!!

Ужс сколько воды в этих тестированиях.

Замечательная статья! всё что нужно и в одном месте! Спасибо!

-

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

Да, нет. А что можно добавить по этому вопросу? Предлагайте, мож и сделаем лучше )

Я думаю, что кроссбраузерное тестирование не совсем к этой статье. Тут же вообще очень много чего нет. Тут только общая и самая основная теория. То, что ты предлагаешь относится именно к веб тестированию, что само по себе объёмно и заслуживает отдельной темы, которая включала бы кроссбраузерное тестирование.

Какая же крутая статья! Прямо все по полочкам! Огромное спасибо !

Автору спасибо! Классный конспект.

Очень круто! Спасибо!

Спасибо. Не ожидал, что рекрутерам такой материал тоже пригодиться. Вам, кстати, могу также предложить комментарии отсюда: megamozg.ru/post/10268 ;)

Великолепно

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Отличная статья, спасибо!! Тоже пытаюсь собрать и систематизировать информацию по тестированию ПО, так как постепенно теория забывается.. Кому интересно, заходите, смотрите.. Может что подскажете, посоветуете!! Давайте развиваться вместе!! www.youtube.com/...BwJFbPK43C-BTFLKSw/videos

хм, подборочка впечатляет. пойду ка я засяду на пару ночей)

Очень доступно подана информация о техниках тест дизайна www.youtube.com/watch?v=fn6kx7cuxGQ

Уровни Тестирования
1. Модульное тестирование (Unit Testing)
Компонентное (модульное) тестирование проверяет функциональность и ищет дефекты в частях приложения, которые доступны и могут быть протестированы по-отдельности (модули программ, объекты, классы, функции и т.д.).
2. Интеграционное тестирование (Integration Testing)
Проверяется взаимодействие между компонентами системы после проведения компонентного тестирования.
Первый уровень " Unit Testing" добавить модульное тестирования или компонентное, так как Вы используете в «Integration testin» компонентное тестирование, а до этого про него даже не вспоминали.

Сори, но я чёт не до конца понял суть претензий. Как по мне всё гут написано.

Тестирование пользовательского интерфейса (англ. UI Testing) — это вид тестирования исследования, выполняемого с целью определения, удобен ли некоторый искусственный объект (такой как веб-страница, пользовательский интерфейс или устройство) для его предполагаемого применения. Таким образом, проверка эргономичности измеряет эргономичность объекта или системы. Проверка эргономичности сосредоточена на определённом объекте или небольшом наборе объектов, в то время как исследования взаимодействия человек-компьютер в целом — формулируют универсальные принципы.

Входит в usability testing, как вы думаете?

Я думаю ТАК! просто іноді питають про UI testing, а оскільки ця стаття прекрасна для новачків, то мабуть буде добре, якщо буде винесено окремо таке визначення, щоб не було путанини. Але звісно це на Ваш розгляд, якщо Ви вважаєте що це зайве, то я сперечатись дуже не буду)
+ у визначенні

Failure — сбой (причём не обязательно аппаратный) в работе компонента, всей программы или системы. То есть, существуют такие дефекты, которые приводят к сбоям (A defect caused the failure) и существуют такие, которые не приводят. UI-дефекты например. Но аппаратный сбой, никак не связанный с software, тоже является failure.
Ви згадуєте про UI — дефекты

Согласен. Может, тогда имеет смысл дописать под описание юзабилити про UI и UX. Займусь на днях. Ещё раз спасибо )

Связанные с изменениями виды тестирования
....
•Повторное тестирование (re-testing)
Повторное тестирование (re-testing): Тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.
В чем разница между regression testing и re-testing?
Re-testing — проверяется исправление багов
Regression testing — проверяется то, что исправление багов не повлияло на другие модули ПО и не вызвало новых багов. -- - спрашивали в GlobalLogik

напоминает качественный копипаст с сайта протестинг

Тут солидная часть — качественный копипаст с протестинга. Но на протестинге далеко не всё, что мне нужно было, поэтому здесь ещё и качественный копипаст со многих других ресурсов, указанных в конце ;) Кстати, протестинг — первый из них )

И это мило что вы со всеми поделились собранной инфой.

Очень полезная напоминалка.Огромное человеческое спасибо автору

Непогано, а головне стисло.

Gennadii Mishchevskii большое тебе человеческое СПАСИБО!!!!

Все очень лаконично и здорово скомпоновано, но я бы еще дополнил инфы о качестве и его метриках, нередко на интервью задают вопрос: «как измерить качество?», — думаю будет полезным:

— Метрики качества программного обеспечения
— Стандартная оценка значений показателей качества
www.intuit.ru/...0/237/lecture/6136?page=3

Это достаточно большая и разосторонняя тема. Прошёлся бегло и не нашёл короткого описания, чтоб было по делу.

Спасибо, клево написал.. :-)

Отличная статья, все самое нужное! Можно еще добавить к видам тестирования — По уровню знания системы: Black box testing, White box testing и Grey box testing.

Обновил шпору. Добавил пункты тест плана, таблицу принятия решений, сравнение qa, qc и тест инженера и диаграммы связей.

Error Guessing дважды описан, в техниках тест дизайна и в типах тестирования) Из пожеланий, добавьте еще, пожалуйста, вкратце о моделях разработки ПО

Вкратце о моделях не получится ) Хочу отдельно написать, но пока времени нет.

Хочу поблагодарить автора. Ваша статья мне очень сильно помогла в подготовке к собеседованиям. Я не говорю, что здесь указана вся информация о тестировании, но в статье содержатся, как сказал автор, основы основ для того, чтобы не ударить в грязь лицом во время интервью. Геннадий, спасибо Вам еще раз. Как результат, я прошел все собеседования и принят на испытательный срок.

Супер! Мои поздравления! )

Первую треть текста я буква-в-букву встречал в материалах на небезызвестном курсе QA :)

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

А где же метод всех пар, ортогональные массивы, таблицы принятия решений и тестирование переходных состояний?
Еще, честно говоря, не уловил что такое корректность требования? И, возможно, туда бы добавить реализуемость и тестируемость — а то требовать всякого можно :)

State transitional testing там есть, ортогональные массивы не стал вставлять, т.к. не так уж и часто их спрашивают у новичков. А на таблицу принятия решений стоит у меня напоминалка, как будет время — добавлю.

State transitional testing там есть
Не вижу, если честно — даже при помощи поиска по странице.
Возможно, у Вас где-то в исправленной версии это есть.

Уровни тестирования: 5. Операционное тестирование (Release Testing). Даже если система удовлетворяет всем требованиям, важно убедиться в том, что она удовлетворяет нуждам пользователя и выполняет свою роль в среде своей эксплуатации, как это было определено в бизнес моделе системы. Следует учесть, что и бизнес модель может содержать ошибки. Поэтому так важно провести операционное тестирование как финальный шаг валидации. Кроме этого, тестирование в среде эксплуатации позволяет выявить и нефункциональные проблемы, такие как: конфликт с другими системами, смежными в области бизнеса или в программных и электронных окружениях; недостаточная производительность системы в среде эксплуатации и др. Очевидно, что нахождение подобных вещей на стадии внедрения — критичная и дорогостоящая проблема. Поэтому так важно проведение не только верификации, но и валидации, с самых ранних этапов разработки ПО. -- - - це з літератури, яку мені колись рекрутер кидала

Спасибо, добавлю. Только не на пятое место, а на четвёртое, ибо после приёмочного тестирования идёт внедрение и эксплуатация. Согласны?

ні, Приймальне тестування (англ. Acceptancetesting)
Вхідні вимоги -Вимоги(Requirements)
Об’єкт тестування -Розроблена система
Визначення: На даному рівні завершений додаток(система)тестується Замовником, кінцевими користувачами або відповідними уповноваженими з метою визначення відповідності системи «Вимогам Замовника» і ГОТОВНОСТІ СИСТЕМИ ДО ВПРОВАДЖЕННЯ. Проектні випробування оформляють ПРОЦЕС ПЕРЕДАЧІ ПРОДУКТУ від Розробника Замовнику. Залежно від особливостей продукту і від вимог Замовника вони можуть проводитися в різній формі. Наприклад, у вигляді альфа- або бета-тестування.

а після цього

Операційне тестування (ReleaseTesting)
Вхідні вимоги -Бізнесмодель(BusinessCaseабоBusinessModel)
Об’єкт тестування -Розробленасистема

Визначення: Навіть якщо система задовольняє всім вимогам, важливо переконатися в тому, що вона задовольняє потребам користувача і виконує свою роль В СЕРЕДОВИЩІ СВОЄЇ ЕКСПЛУАТАЦІЇ, як це було визначено в бізнес-моделі системи. Слід врахувати, що і Бізнес модель може містити помилки.Тому так важливо провести операційне тестування як фінальний крок Валідації.

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

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

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

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

можливо...але мені це все давали вчити на джуна qa)

спс очень позновательно

Статическое тестирование это не только анализ программного кода (code review) или скомпилированного кода. Это также и анализ требований, спецификаций и другой проектной документации, которая прямо влияет на разработку продукта.

Также, необходимо правильно понимать понятия verification и validation.
Когда мы говорим о разработке продукта, то в конечном итоге у него всегда должны быть пользователи. Согласно требованиям пользователей (требованиям рынка) и их ожиданиям будут разработаны явные требования, которые и будут использоваться в процессе разработки самого продукта.
Процесс оценки соответствия продукта явным требованиям (спецификациям) и есть верификация (verification), в то же время оценка соответствия продукта ожиданиям и требованиям пользователей — есть валидация (validation). Также часто можно встретить следующее определение этих понятий:
Validation — ’is this the right specification?’.
Verification — ’is the system correct to specification?’.

Согласен. Я даже на собеседовании так ответил. Но после в интернете нашёл несколько другую интерпритацию. Ту, что выше. Так что же тогда считать более правильным вариантом?

Оба понятия, не смотря на то, что их определения отличаются, тесно связаны и служат одной и той же цели — созданию качественного продукта/системы/сервиса. Поэтому используются вместе в теории для определения понятия «тестирование». По моему мнению, именно по этой причине на практике многие ошибочно используют эти термины как определение одного и того же процесса.
Verification — процесс проверки продукта/системы/сервиса на соответствие уже существующим формальным требованиям. В то время как validation — это, можно сказать, процесс оценки того, насколько правильно были составлены те формальные требования, согласно которым создается (или был создан) продукт/система/сервис.

Я оставил оба варианта.

Згідно ISO 9000:2015:
verification
confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
validation
confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled

Ще додам таку діаграму
Думаю, що ’specific intended use’ із визначення ISO 9000:2015 відповідає ’needs and expectaion of customer’ з діаграми.

Спасибо за уточнение. Я читал материалы ISTQB со всеми стандартами, но не впечатлился. Напомнило какой-то сборник сухихи законов. Эта статья предназначена для того, чтобы быстро повторить. Я пытался написать менее формализованно и более понятно. Стандарты знать полезно, но с жизнью они имеют мало общего.

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

Полезная подборка терминов и понятий. В качестве замечания могу добавить следующее:
Определения Error, Defect требуют небольшой корректировки, чтобы отделить мух от котлет. Не стоит смешивать понятия defect и error.
Error/mistake — это как ошибка в использовании продукта со стороны пользователя, так и ошибка, которая была допущена в процессе дизайна и разработки продукта. Наличие подобной ошибки означает наличие дефекта (defect/bug/fault) и может как приводить к сбою (falilure), так и не приводить к сбою в работе продукта.

Функциональные виды тестирования
• Функциональное тестирование (Functional testing)
• Тестирование безопасности (Security and Access Control Testing)
• Тестирование взаимодействия (Interoperability Testing)

По идее, два последних пункта — это тоже нефункциональное тестирование :).

Вольный пересказ Рекса Блэка, для повторения есть силабус. Ничего особенного.

Хороший материал. Можно еще Issue и Mindmap`ы добавить

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

Дельное замечание. Добавил также из книги ISTQB английской версии.

Отличный пост! Очень четко описаны принципы) Кстати, можно добавить английскую интерпритацию названий принципов.

Классно!
Жаль, что все еще нельзя сами посты лайкать.

Кому интересна, обновил информацию. Добавил:
качество, верификация / валидация, traceability matrix, error/deffect/failure, подходы к интеграционному тестированию. Если есть что ещё — пишите )

+100 тебе к карме. Сам собирался такую штуку себе написать для собеседований, но ты опередил меня.

ПС Еще круто будет добавить что-то вроде схемы видов тестирования. Часто на собеседованиях спрашивают по видам.

Всегда пожалуйста ) Виды там есть, а что ты имеешь ввиду под схемой?

goo.gl/8WGnkk что-то на подобии этого)

ПС Хах) можно так надобавлять, что через полгода будет целая книга по основам тестирования) Потом автоматизацию еще добавить)

Да, я видел эту схему. Добавил.

Отличная статья! Очень содержательно, как по мне. Молодец и спасибо за информацию)

Ще варто загадати про requirement traceability matrix (матриця покриття вимог), в загальному про етапи розробки і місце тестування в цих етапах.
Підходи до Integration Testing — Bottom Up, Top Down, Big Bang.
З тестової документації ще є поняття Quality Assurance Plan, Test Strategy.
Валідація / Верифікація — пояснення і різниця між термінами.
Взагалі класні ресурси istqbexamcertification.com і www.testingexcellence.com де по теорії багато що розжовується і пояснюється.

а что тогда надо знать на мидл кьюея ?

Отличная шпаргалка! Без лишней воды. Можно сказать — идёшь на собеседование — должно как от зубов отскакивать.

Спасибо тебе, Добрый Человек! Для повторения самое оно. Все четко и красиво, без воды.

Хорошая шпаргалка )

Можно ещё добавить:
1) Техники тестирования
2) Чем отличаются error, failure и defect
3) Если уж упомянули про баг репорт, то было бы хорошо описывать и другую тестовую документацию

И ещё многое другое (особенно если написать и про обеспечение качества, используемые метрики и т. д.)

Техники тестирования в техниках тест дизайна. Или что-то ещё можно добавить?
Тут ещё очень и очень многое можно было написать, но оно и так у меня на 10 страниц ворда получилось ) Решил оставить самое основное.

Единственный вопрос — почему не в виде статьи, а сразу на форум?

В моём понимании статья — что-то новое, какая-то мысль. А у меня просто шпаргалка, копипаст с разных ресурсов. Делал для себя и решил поделиться. + люди подсказывают, что пропустил, я добавляю. Это черновой вариант.

Материал крутой, спасибо. Разве что редко когда можно предугадать о чем будет разговор на собеседовании. Готовишься по теории, а спрашивают по специфическим аспектам проекта и наоборот :)

Це все зібрано з ISTQB FL. Та інших відомих і доступних джерел. Лише декілька методів тест дизайну добавили. Як для мідла — це замало.
Треба ще розуміння ризиків, естімейтів. Розуміння гнучких підходів.
Також мене питались про різні white box техніки (це є в книзі Дороті Гретхем)

От меня тут буквально пару слов, всё остальное, правда, из разных источников, которые указаны в самом конце. И я в начале сразу оговорился, что это для Junior and Trainee. Естественно, что для мидла это не то, что надо.

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

Может, позже сделаю )

крутой материал, спасибо

забули ще про поняття error-guessing testing, який майже як exploratory, але вимагає знання продукту
error guessing: A test design technique where the experience of the tester is used to
anticipate what defects might be present in the component or system under test as a result
of errors made, and to design tests specifically to expose them.

і головне забула написати — стаття хороша. ))

Це мені одному здається, що половина тут написаного є фантазією адного/декількох авторів, а індустріальних стандартів толком немає.

Вот в JIRA


Major — Major loss of function.
Minor — Minor loss of function, or other problem where easy workaround is present.
Trivial — Cosmetic problem like misspelt words or misaligned text.
що не зовсім те, що описано тут.

Для ознайомлення цей текст підійде нормально. Але вимагати від кандидатів такі речі — це занадто.
Спитайте «що робив? з чим працював? що знаєш?» і потім по пару питань до кожної відповіді кандидата — і все стане зрозуміло.

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

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

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

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

Ми таки існуємо

Большое спасибо за представленный материал!

ОК, после прочтения этой статьи курсы QA уже не нужны.

Курсы QA вообще не нужны :)

Підписатись на коментарі