Основні запитання з теорії тестування, що часто запитують на співбесідах для Junior/Middle спеціалістів

---

1. Що таке тестування?
Перевірка відповідності між реальною та очікуваною поведінкою програми на кінцевому наборі тестів, обраному певним чином.
[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]

2. Цілі тестування.
· Виявлення дефектів
· Підвищення впевненості в рівні якості
· Надання інформації для прийняття рішень
· Запобігання дефектів
[Сертифицированный тестировщик. Программа обучения Базового уровня. Версия 2011]

3. QA, QC, Testing.
Забезпечення якості (quality assurance) – частина менеджменту якості, спрямована на створення впевненості, що вимоги до якості будуть виконані.
Управління якістю (quality control) – частина менеджменту якості, спрямована на виконання вимог до якості.
Тестування (testing) – Процес, що містить в собі всі активності життєвого циклу, як динамічні, так і статичні, що стосуються планування, підготовки та оцінки програмного продукту і пов’язаних з цим результатів робіт з метою визначити, що вони відповідають описаним вимогам, показати, що вони підходять для заявлених цілей та визначення дефектів.

Менеджмент якості (quality management) – скоординована діяльність з керівництва та управління організацією, стосовно до якості.
Примітка – Керівництво та управління до якості зазвичай включає в себе розробку політики у сфері якості та цілей у сфері якості, планування якості, управління якістю, забезпечення якості та поліпшення якості.
[ГОСТ ISO 9000-2011; Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2).]

4. Основні види тестування.
· Функціональне тестування
· Нефункціональне тестування
· Тестування структури / архітектури програмного забезпечення (структурне тестування)
· Тестування змін: підтверджувальне і регресійне тестування
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Класифікація видів Тестування: по знанню системи, по об’єкту тестування, по суб’єкту тестування, за часом проведення тестування, за критерієм “позитивності” сценаріїв, за ступенем ізольованості тестованих компонентів, за ступенем автоматизації тестування і за ступенем підготовки до тестування.
[Тестирование Дот Ком, Савин]
За якими атрибутам характеристик якості ми тестуємо?
У ПЗ є 6 характеристик якості: Функціональні можливості (Functionality), Надійність (Reliability), Практичність (Usability), Ефективність (Efficiencies), Ремонтопридатність (Maintainability) і Мобільність (Portability). У кожної характеристики є атрибути.
[ГОСТ Р ІСО / МЕК 9126-93]

5. Відмінності Load and Performance testing.
Тестування навантаження (load testing) – вид тестування продуктивності, що проводиться з метою оцінити поведінку компонента або системи під збільшені навантаження (число одночасно працюючих користувачів і / або число транзакцій) для визначення максимального рівня навантаження компонента або системи.)
Тестування продуктивності (performance testing) – процес тестування з метою визначити продуктивність програмного продукту.
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]
Load vs Performance Testing
Нам здалося, що Load і Performance Testing переслідують все ж одну і ту ж мету: перевірка продуктивності (часу відгуку) на різних навантаженнях. Власне тому ми й не стали розділяти їх. У той же час хто то може розділити. Головне все таки розуміти цілі того чи іншого виду тестування і постаратися їх досягти.
[Джерело]

6. Не функціональні види тестування.
· Нефункціональне тестування – включає тестування навантаження, тестування продуктивності, стрес-тестування, тестування зручності використання, тестування відновлення, тестування надійності і тестування переносимості. Це тестування того, “як” система працює.
· Тестування структури / архітектури програмного забезпечення (структурне тестування)
· Тестування змін: підтверджувальне і регресійне тестування.
Примітка: Регресійне тестування може виконуватися на всіх рівнях тестування і включає функціональне, нефункціональне і структурне тестування.
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

7. Тестування установки.
Тестування установки (installation testing) – Перевіряє працездатність методів установки, налаштування і видалення програми на всіх підтримуваних платформах.
[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

8. Тестування документації, основні принципи.
Перевірка документації (documentation testing) – Перевіряє точність всієї документації користувача.
Системне тестування вимагає тестування документації. Для цього за допомогою документації перевіряють спосіб подання описаних раніше системних тестів. Наприклад, якщо запланований якийсь навантажувальний тест, то слід використовувати документацію для підбору конкретних варіантів. Крім того, шляхом безпосередньої інспекції необхідно перевірити точність і ясність викладу користувальницької документації. Будь-які процедури, які фігурують у документації, повинні кодуватися і пропускатися через програму.
[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

Читаючи й аналізуючи документацію, слід передусім приділити увагу її точності, повноті, ясності, простоті використання і тому, наскільки вона відповідає духу програмного продукту.
[Тестирование программного обеспечения, Канер, Фолк, Нгуен, 2 издание]

9. Основні принципи Usability testing.
Оптимально, коли зручність використання тестують кінцеві користувачі, а не тестувальники. Завдання тестувальника може полягати в підготовці набору практичних значень, пов’язаних з реальною діяльністю, повторюваних тестових завдань, які повинен буде виконати кожен користувач. Проектуйте ці тестові сценарії так, щоб у процесі їх виконання користувач зіткнувся з усіма аспектами програмного забезпечення, знайомлячись з ними в якомусь певному або випадковому порядку.
Важливу роль відіграє збір та аналіз докладних, точних даних. Реальним початком процесу збору даних є розробка детальних користувальницьких інструкцій і списку завдань. Закінчується ж цей процес зведенням в воєдино результатів спостережень, зроблених користувачами, або відповідей користувачів на анкети після проведення тестів.
Нарешті, результати тестування повинні бути правильно інтерпретовані, і на основі отриманих висновків розробники мають внести в ПЗ відповідні зміни.
[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

10. Артефакти тестування.
Основними поняттями RUP (Rational Unified Process) є артефакт (artifact) і прецедент (precedent). Артефакти – це деякі продукти проекту, породжувані або використовувані в ньому при роботі над остаточним продуктом. Прецеденти – це послідовності дій, виконуваних системою для отримання спостережуваного результату.
[Джерело]
2 варіант відповіді на питання:
У відповідність з процесами або методологіями розробки ПЗ, під час проведення тестування створюється і використовується певна кількість тестових артефактів (документи, моделі і т.д.). Найбільш поширеними тестовими артефактами є:
План тестування (Test Plan) – це документ описує весь обсяг робіт з тестування, починаючи з опису об’єкта, стратегії, розкладу, критеріїв початку і закінчення тестування, необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
Набір тест кейсів і наборів (Test Case & Test suite) – це послідовність дій, за якою можна перевірити чи відповідає тестована функція встановленим вимогам.
Дефекти / Баг Репорт (Bug Reports / Defects) – це документи, що описують ситуацію або послідовність дій, яка призвела до некоректної роботи об’єкта тестування, із зазначенням причин і очікуваного результату.
[Джерело]

11. Тест план і check-list.
План тестування (Test Plan) – це документ, що описує весь обсяг робіт з тестування, починаючи з опису об’єкта, стратегії, розкладу, критеріїв початку і закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення.
[Джерело]
Чек-ліст – це документ, що описує що має бути протестовано. При цьому чек-ліст може бути абсолютно різного рівня деталізації. На скільки детальним буде чек-лист залежить від вимог до звітності, рівня знання продукту співробітниками і складності продукту.
Чек-ліст потрібен для:
· Не забути необхідні тести
· Для поділу завдань за рівнем кваліфікації
· Для збереження звітності і результатів тестування
Що має бути в Чек-лісті:
· Список перевірок (з необхідної ступенем деталізації)
· Статус перевірок:
збірка, на якій проводилося тестування
тестове оточення (якщо є)
тестувальник
· Результат перевірки
[Джерело]

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

[Джерело]

13. Основні поля test case.
Тестовий сценарій (test case) – Набір вхідних значень, передумов виконання, очікуваних результатів і фактичних результатів, розроблений для певної мети або тестової умови, таких як виконання певного шляху програми або ж для перевірки відповідності певній вимозі.

Основні поля тестового сценарію: Набір вхідних значень, передумов виконання, очікуваних результатів і фактичних результатів.
[IEEE 610 – Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

14. Життєвий цикл бага
Блок-схема, що показує основні статуси і можливі переходи від статусу до статусу в процесі його існування:

Опис даної схеми.
Припустимо ви знайшли баг і зареєстрували його в баг трекінг системі. Відповідно до нашої блок-схемі він отримає статус “Новий”. Тестувальник, відповідальний за валідацію нових баг репортів, або координатор проекту (в залежності від розподілу ролей у команді) може перевести його в один з наступних статусів:
· “Відхилений”, якщо даний баг невалідний або повторний, або ж його просто не змогли відтворити
· “Відкладений”, якщо даний баг не потрібно виправляти в даній ітерації
· “Відкритий”, якщо виправити бага необхідно
Розглянемо тепер по порядку кожен з варіантів.
1. Відхилений. У цьому випадку ви можете або посперечатися про долю вашого багрепорта, змінивши статус на “Відкритий заново” або закрити його – статус “Закритий”
2. Відкладений. Баг репорт в статусі “Відкладений” можна перевести в статус “Відкритий”, коли буде потрібно виправлення або в статус “Закритий”, якщо вже не буде потрібно.
3. Відкритий. Саме в такому стані розробник отримує баг репорт для виправлення. Він може відхилити (подальші дії дивіться в пункті 1) або виправити баг. Баг репорт в статусі “Виправлений” перекладається на тестувальника для перевірки. У разі якщо проблема все ще відтворюється, виставляється статус “Відкритий заново” і баг репорт направляється назад на доопрацювання до розробника. Якщо ж виправлення було успішним, то баг репорт переводиться в статус “Закритий”.
* * *
Необхідно зазначити, що дана схема сильно спрощена. Для більшої наочності і, можливо, зручності роботи на проекті, ви можете додати додаткові статуси і переходи, тим більше, що сучасні баг трекінгові системи дозволяють це робити. Правда майте на увазі, що заплутані схеми переходів і зайві статуси можуть значно ускладнити життя.
Примітка 1: в деяких системах баг трекінгу створений баг репорт відразу отримує статус “Відкритий” без додаткової валідації
Примітка 2: багато баг трекінгових систем дозволяють перевідкривати закриті баги, проте особисто я проти такої практики, тому й не описував подібний перехід у вище поданому життєвому циклі
Примітка 3: Розглянутий вище життєвий цикл заснований на тому, що в команді є хтось, відповідальний за призначення баг репортів. У випадку, якщо такої ролі на проекті немає, то баги призначаються розробниками самостійно, і тоді для уникнення путаниці, є сенс ввести ще один проміжний статус “У розробці” (In progress), що показує, що даний баг репорт вже призначений і знаходиться на стадії виправлення.
[Джерело]

15. Bug report, Основні поля bug report.
Звіт про баг (bug report): Див. Звіт про дефект.
Звіт про дефект (defect report): Документ, що містить звіт про будь-які нестачі в компоненті або системі, який може привести компонент або систему до неможливості виконати потрібну опцію.
[IEEE 829 – Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Різні багтрекінгові системи, пропонують нам різні поля для заповнення та різні структури опису дефектів. Наведена нижче приклад – те, що рекомендують використовувати у вигляді шаблону баг репорту.
Шапка
Короткий опис (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) – Ім’я співробітника, призначеного на вирішення проблеми
Оточення
ОС / Сервіс Пак і т.д. / Браузера + версія / … Інформація про оточення, на якому був знайдений баг: операційна система, сервіс пак, для WEB тестування – ім’я і версія браузера і т.д.
Опис
Кроки відтворення (Steps to Reproduce) – Кроки, за якими можна легко відтворити ситуацію, що призвела до помилки.
Фактичний Результат (Result) – Результат, отриманий після проходження кроків до відтворення
Очікуваний результат (Expected Result) – Очікуваний правильний результат
Доповнення
Прикріплений файл (Attachment) – Файл з логами, скріншот або будь-який інший документ, який може допомогти прояснити причину помилки або вказати на спосіб вирішення проблеми
[Джерело]

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

Градація серйозних дефектів (Severity)
S1 Блокуюча (Blocker)
Блокуюча помилка, що приводить додаток в неробочий стан, в результаті якого подальша робота з тестованої системою або її ключовими функціями стає неможлива. Рішення проблеми необхідно для подальшого функціонування системи.
S2 Критична (Critical)
Критична помилка, неправильно працює ключова бізнес логіка, діра в системі безпеки, проблема, яка призвела до тимчасового падіння сервера або приводить в неробочий стан деяку частину системи, без можливості вирішення проблеми, використовуючи інші вхідні точки. Рішення проблеми необхідно для подальшої роботи з ключовими функціями тестируемой системою.
S3 Значна (Major)
Значна помилка, частина основний бізнес логіки працює некоректно. Помилка не критична або є можливість для роботи з тестованої функцією, використовуючи інші вхідні точки.
S4 Незначна (Minor)
Незначна помилка, що не порушує бізнес логіку частини програми, що тестується, очевидна проблема для користувача інтерфейсу.
S5 Тривіальна (Trivial)
Тривіальна помилка, яка не стосується бізнес логіки додатка, погано відтворена проблема, малопомітна за допомогою користувальницького інтерфейсу, проблема сторонніх бібліотек або сервісів, проблема, не надає ніякого впливу на загальну якість продукту.

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

Порядок виправлення помилок з їх пріоритетами:
High -> Medium -> Low
[Джерело]

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

18. Use case відміну від test case
Сценарій використання системи (use case): Послідовність операцій у взаємодії актора і компонента або системи зі значимим результатом, при якій актором може бути як користувач, так і все, що може обмінюватися інформацією з системою.
Тестовий сценарій (test case): Набір вхідних значень, передумов виконання, очікуваних результатів і пострезультатів виконання, розроблений для певної мети або тестової умови, такої як виконання певного шляху програми або ж для перевірки відповідності певним вимогам.
[IEEE 610 – Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

19. Верифікація та валідація.
Верифікація (verification): Підтвердження наданням об’єктивних доказів того, що встановлені вимоги були виконані.
Примітки
1. Термін “верифікований” використовують для позначення відповідного статусу.
2. Діяльність з підтвердження вимоги може включати в себе:
· Здійснення альтернативних розрахунків;
· Порівняння специфікації на новий проект з аналогічною документацією на проект;
· Проведення випробувань і демонстрацій;
· Аналіз документів до їх випуску.

Валідація (validation): Підтвердження наданням об’єктивних доказів того, що вимоги, призначені для конкретного використання або застосування, виконані.
Примітки
1. Термін “валідація” використовують для позначення відповідного статусу.
2. Умови застосування можуть бути реальними або змодельованими.

Об’єктивне свідчення (objective evidence): Дані, що підтверджують наявність або істинність чого-небудь.
Вимога (requirement): Потреба або очікування, яке встановлено, зазвичай передбачається чи є обов’язковим
Специфікація (specification): Документ, що встановлює вимоги.
Випробування (test): Визначення однієї або декількох характеристик відповідно до встановленої процедури.
[ГОСТ ISO 9000-2011.]

20. Граничні умови, класи еквівалентності.
Граничне значення (boundary value): Вхідні значення або вихідні дані, яке перебуває на межі еквівалентної області або на найменшій відстані від обох сторін грані, наприклад, мінімальне або максимальне значення області.
Еквівалентна область (equivalence partition): Частина області вхідних або вихідних даних, для якої поведінка компонента або системи, ґрунтуючись на специфікації, вважається однаковою.
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

21. Різниця між тестуванням desktop and web.
Одні з думок:
1.Веб-тестування зачіпає ряд питань, які зазвичай не виникають при традиційному тестуванні десктоп додатків. Прикладами спеціалізованого веб-тестування можуть служити такі речі як: тестування сумісності браузера, тестування Web доступності, перевірка на «мертві» посилання, а також відстеження повідомлень між клієнтом і сервером.

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

3. Дурниці це все, висмоктані з пальця, c урахуванням розвитку інтернет технологій ніякої різниці немає.
[Джерело]

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

Тестувальник = техпідтримка – ідеал для невеликих і середніх компаній. У великих виникнуть проблеми, там краще набирати вже спеціально навчених людей. Ідеальної схеми не існує, і як би ми не намагалися охопити всі проблеми, кожному необхідно зібрати свій конструктор з підходів та методик. Адже кожна компанія і її продукти унікальні, і навряд чи хтось знає, що підходить саме вам.
[Джерело]

23. Відмінність Sanity від Smoke.
Тест працездатності (sanity test): Див. Димове тестування.
Димове тестування (smoke test): Вибірка із загального числа запланованих тестових сценаріїв, що покриває основну функціональність компонента або системи. Проводиться з метою упевнитися, що базові функції програми в цілому працюють коректно, без заглиблення в деталі. Щоденна збірка і димове тестування є передовими практичними методами.
Вхідний тест (intake test): Спеціальний тип димового тестування для прийняття рішення, чи готовий компонент або система готові для подальшого детального тестування. Зазвичай починається на початку фази тестування.
[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Інша думка:
Відмінність санітарного тестування від димового (Sanity vs Smoke testing)
У деяких джерелах помилково вважають, що санітарне та димове тестування – це одне і теж. Ми ж вважаємо, що ці види тестування мають “вектора руху”, напрямки в різні боки. На відміну від димового (Smoke testing), санітарне тестування (Sanity testing) направлено вглиб функції, що перевіряється, в той час як димове направлено вшир, для покриття тестами якомога більшої функціоналу в найкоротші терміни.
[Джерело]

24. Розробка Agile і Waterfall.

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

[Джерело]

Гнучка розробка програмного забезпечення (англ. Agile software development, agile-методи) — клас методологій розробки програмного забезпечення, що базується на ітеративній розробці, в якій вимоги та розв’язки еволюціонують через співпрацю між самоорганізовуваними багатофункціональними командами. Гнучка розробка – найкращий засіб для підвищення продуктивності розробників програмного забезпечення.
[Джерело]

25. Яка система розробки використовується на проекті зараз.
Яка система розробки використовується у вас – вам краще знати.

26. Які ролі на проекті займає Junior, Middle, Senior.
Junior:

Middle:

Senior:

[Джерело]

27. Різниця між error, bug, failure.
Помилка (error) Дія людини, яке призводить до неправильного результату.
[IEEE 610]
Баг (bug): Див. Дефект.
Дефект (defect): Вада в компоненті або системі, яка може привести компонент або систему до неможливості виконати необхідну функцію, наприклад невірний оператор або визначення даних. Дефект, виявлений під час виконання, може призвести до відмов компонента або системи.
Відмова (failure): Відхилення компонента або системи від очікуваного виконання, експлуатації або результату.
[Стандартний глосарій термінів, які використовуються в тестуванні програмного забезпечення (Версія 2.2)]