Competence framework

Bug report (attributes)

- Bug number or the identification label you use - Bug title - Environment or platform it is present in - Priority or severity - Bug description - Steps to reproduce - Expected results and actual results - Attachment

Project Team Roles and Responsibilities

- Business analyst - Product owner - Developer - QA Engineer - UX designer - UI designer

Quality assurance Quality control QA testing

- Quality assurance - part of quality management focused on providing confidence that quality requirements will be fulfilled. - Quality control is part of QA. - QA testing - is a function of software quality that assures that procedures and standards are appropriate for a project and are correctly executed.

​​Agile frameworks

- Scrum - Kanban - XP (Extreme programming) - Crystal - DSDM (Dynamic Systems Development Method) - FDD (Feature-driven development)

Testing documentation overview (classification)

- Test Plan and Test Strategy - Checklist - Test Case - Test Suite - Test Incident Report (Bug/Defect reports) - Traceability Matrix

What is tested on each testing level ?

- Unit (Component) level: модулі, програми, об'єкти, класи - Integration testing level: інтерфейси між компонентами, взаємодія з різними частинами системи, такими як операційна система, файлова система та апаратне забезпечення, або інтерфейси між системами. - System testing level: вся система/продукт - Acceptance testing level: alfa and beta testing

Main methodologies

- Waterfall - V-model - Iterative model - Agile manifesto (Scrum, Kanban)

Scrum process (meetings)

- daily scrum - sprint planning - sprint retrospective - backlog refinement - sprint review

What are the main testing types according to ISTQB?

- functional - non-functional - structure or architecture - related to changes (confirmation testing, or re-testing, regression testing)

5 scrum phases

- initiation - planning and estimation - implementation - reviewing - releasing

Scrum team composition

- product owner - scrum master - dev team

Some of the benefits of non-functional tests

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

Main test objectives

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

What is quality?

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

Functional testing (sub-types)

1) Unit Testing 2) Integration Testing 3) Interface Testing 4) System Testing 5) Regression Testing 6) Smoke Testing 7) Sanity Testing 8) Acceptance Testing

Non-functional testing (sub-types)

1. Performance Tests. 2. Load Tests. 3. Stress Tests. 4. Volume Tests. 5. Security Tests. 6. Upgrade & Installation Tests. 7. Recovery Tests.

SDLC Phases

1. Planning 2. Define requirements 3. Design and Prototyping 4. Software development 5. Testing 6. Deployment 7. Operations and Maintenance

Fundamentals of Agile Software Development

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

7 testing principles

1. Тестування показує наявність дефектів 2. Вичерпне тестування неможливе 3. Дочасне тестування 4. Кластеризація дефектів 5. Парадокс пестицидів 6. Тестування залежить від контексту 7. Відсутність помилок помилок

Team size (Agile)

4-9

Related to changes testing types

Confirmation testing, or re-testing Regression testing

STLC Phases

Requirement analysis Test planning Test case design and development Test environment setup Test execution Test cycle closure

Smoke vs Sanity

Smoke testing: - Виконується на початкових збірках програмного продукту перед регресійним тестуванням - Мотивом є перевірка стабільності нової зібраної версії продукту в цілому Sanity testing: - Проводиться на збірках, які успішно пройшли димові випробування і перед циклом регресійного тестування - Основною метою є перевірка раціональності системи в деталях, щоб приступити до ретельного тестування

Which stages form the fundamental test process ?

Test Planning and Control Test Analysis and Design Test Implementation and Execution Evaluating Exit Criteria and Reporting Test Closure

main attributes of a test case

TestCaseId Test Summary Description pre-condition Test Steps Test Data Expected result Actual result Test Result Automation Status Date Executed by

Name all testing levels

Unit (Component) level Integration testing level System testing level Acceptance testing level

Bug, error, defect

We can say that a mistake made by a programmer during coding is called an error, an error found during the unit testing in the development phase is called a defect, an error found during the testing phase is called a bug and when an error is found at an end user's end is called as the failure.

Recovery Testing

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

Why is testing necessary?

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

Objectives of Non-functional testing

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

What could be a trigger for Regression testing?

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

Regression Testing

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

Functional testing

Мета функціонального тестування (Functional Testing) - виявлення невідповідностей між реальною поведінкою реалізованих функцій і очікуваною поведінкою відповідно до специфікації і вимог. Функціональні тести повинні охоплювати всі реалізовані функції з урахуванням найбільш ймовірних типів помилок. what the system should do

Test Strategy

Набір основних принципів, які визначають розробку тестів та регулюють те, як буде здійснюватися процес тестування програмного забезпечення. Метою стратегії тестування є забезпечення системного підходу до процесу тестування з метою забезпечення якості, відстежування, надійності та кращого планування. Testing objectives Methods of testing Total time for testing Resources required for the project Testing environment

Non-functional testing

Нефункціональне тестування описує тести, необхідні для визначення характеристик програмного забезпечення, які можуть бути виміряні різними величинами. У цілому, це тестування того, «як» система працює. How the system should behave

Main differences between Functional and Non-functional testing

Основна відмінність в тому, що функціональні тести перевіряють, чи відповідає ПЗ визначеним вимогам, а нефункціональне тестування з'ясовує, наскільки добре працює система загалом. Найкраще ці відмінності ілюструє такий приклад. За допомогою функціонального тесту ви переконаєтеся, чи правильно працює вхід в систему. В процесі з'ясується, чи можна зайти в систему через ім'я користувача та пароль. А от нефункціональний тест покаже, що вхід в систему триває 2 секунди. Цим самим тестом перевіряють, скільки користувачів можуть зайти в систему одночасно.

Scrum vs Kanban

Основна різниця між Scrum та Канбан — у довжині ітерацій. У Scrum ітерації - 2 тижні, у Kanban завдання програмісту можна «підсовувати» хоч щодня. Kanban дає більше гнучкості, якщо під гнучкістю розуміти частоту зміни пріоритетів

What is Localisation Testing ?

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

Exploratory testing pros and cons

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

How to perform retesting?

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

Positive vs Negative testing

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

Confirmation testing

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

What is the output of regression testing?

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

Difference between regression and retesting

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

Why is regression testing important in agile development?

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

When to start regression ?

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

Exploratory VS Ad-hoc testing

Різниця між Ad-Hoc і Exploratory Testing в тому, що теоретично, Ad-Hoc тестування може провести будь-хто, а для проведення Exploratory тестування необхідна фахова майстерність і володіння певними техніками тестування.

Difference between Static and Dynamic testing

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

What part of the project is covered by Static vs Dynamic testing ?

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

Scripted testing

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

stress testing

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

Volume Testing

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

What is the difference between load, stress, volume and performance testing ?

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

Load Testsing

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

Differences between Scripted and Exploratory testing

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

Structure or architecture testing

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

Ad-hoc testing

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

Smoke Testing

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

Unit Testing

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

Regression testing

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

Exploratory testing

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

Security Testing

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

Performance Teststing

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

Валідація

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

Верифікація

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

What is Agile Software Development?

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

Software Development Methodologies

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

Sanity Testing

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

System Testing

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

Interface Testing

Це тестування, спрямована на перевірку якості інтерфейсу користувача, а також його відповідності всім нормам і вимогам.

Integration Testing

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

Acceptance Testing

Цей вид тестування допомагає відшукати помилки, пов'язані зі зручністю та простотою програми для користувачів; Даний вид тестування є фінальним етапом перед запуском програми; Приймальне тестування здійснюється за допомогою реального сприйняття додатку кінцевими користувачами.

У чому специфіка тестування на Agile-проектах

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

How to perform cross browser testing?

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

Severity VS Priority

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

Priority

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

Compatibility testing

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

Test Plan

детальний документ, який описує стратегію тестування, цілі, графік, оцінку, результати та ресурси, необхідні для проведення тестування програмного продукту. Тест-план допомагає визначити підходи, необхідні для перевірки якості програми, що тестується. Test Plan identifier* • Introduction* Test items* Features to be tested* Features not to be tested* Approach* Enter/exit criteria* Suspension criteria and resumption requirements Test deliverables Testing tasks Environmental needs* Responsibilities Staffing and training needs Schedule* Risks and contingencies* Approvals*

Software Development Life Cycle Model

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

What is STLC

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

Static testing

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

Dynamic testing

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

Severity

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

Test charter

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

What is Usability testing?

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

What is Internationalisation Testing ?

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

Test case

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