Теоретичні питання Flashcards
Що таке тестування?
Перевірка відповідності між реальною та очікуваною поведінкою.
Якість ПЗ (Software Quality) це?
Якість ПЗ (Software Quality)
— це сукупність показників програмного забезпечення, які стосуються його здатності задовольняти встановлені і передбачувані потреби.
Чи потрібно тестування?
Так, Однією з основних мет тестування є виявлення дефектів в програмному забезпеченні перед його випуском. Це дозволяє забезпечити якість продукту та зменшити ризики.
Чи можа тестуванням знехтувати?
Ні, тестування не можна знехтувати, оскільки воно є необхідною частиною процесу розробки програмного забезпечення. Тестування допомагає виявляти помилки та дефекти в програмному забезпеченні та переконується в тому, що програма працює належним чином.
Цілі тестування:
- Перевірка того чи продукт відповідає вимогам і чи задовільняє кінцевого користувача
- Виявити дефект
- Тестування дозволяє визначити умови, за яких програма поводиться некоректно
- Запобігти дефекти
- Підвищення якості ПЗ
- Надання актуальної інформації про стан продукту зараз.
Коли ми повинні почати тестування в нашому проекті?
Тестування програмного забезпечення має починатися на початку життєвого циклу розробки програмного забезпечення.
Це допомагає виявити та усунути дефекти на ранніх стадіях SDLC, тобто на етапі збору вимог і проектування. Ранній початок тестування допомагає зменшити кількість дефектів і, зрештою, вартість переробки.
* Один із семи принципів тестування програмного забезпечення: «Раннє тестування економить час і гроші».
Баг- це
- Баг – це відхилення фактичного результату від очікуваного.
- Головне джерело очікуваного результату - це специфікація(вимоги).
- Специфікації самі не без гріха, і в цьому випадку, як і у випадку
повної їх відсутності, у нас є здоровий глузд, усталені
стандарти, досвід роботи, статистика, авторитетна думка та ін.
Яка різниця між bug, failure, error?
Bug (defect)– помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так як планувалося і програма виходить з-під контролю. Наприклад, коли відсутня валідація полів і в результаті неправильні дані викликають краші або інші збої у роботі програми. Або всередині програма побудована так, що від самого початку не відповідає тому, що від неї очікується.
Failure– збій (причому не обов’язково апаратний) у роботі компонента, всієї програми чи системи. Збій у роботі програми може бути індикатором наявності дефекту.
Error– помилка користувача, який намагається використовувати програму іншим способом. Наприклад, вводить літери в поля, де потрібно вводити цифри (вік, кількість товару тощо). У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку.
Цикл житття багу
New- вперше знайдено баг і внесено до системи.
Open- взято в роботу.
Assigned- назначено розробника, який буде виправляти баг.
Rejected (Not a bug) - розробник відхилив баг або не зміг відтворити. Ми маємо перевірити, чи баг відтворюється, і якщо так, то показати це розробнику.
Deferred - перенесено на наступні спринти через брак часу і низький пріоритет.
Fixed - розробник виправив баг і чекає на перевірку QA.
Verified - тестувальник перевірив баг.
Reopened- якщо баг не виправлено і він відтворюється, його перевідкривають.
Closed - якщо баг виправлено, його закривають.
Duplicate(Дублікат) (такий баг вже існує, або знаходиться в роботі)
Типи (багів)дефектів:
Functional (непраццює якийсь функціонал напр кнопка)
Security(наприклад якщо хтоссь може зламати пароль)
Usability (дефект зручності використання апр кнопка вилізна нап іншу кнопку)
User interface ( незавантажені стилі,, шрифт, картинки…)
Localization (частково не перекладений текст основного функціоналу і кнопок)
Spelling (помилки в правописі)
Perfomance (напр довге завантаження сторінки)
Що таке SDLC і йог етапи?
💡 (SDLC) — це процес розробки ПЗ з різними етапами та кроками, щоб перенести програмне забезпечення від ідеї до створення, впровадження та обслуговування.
- Requirements (Збір і аналіз вимог від клієнта або кінцевих користувачів.)
- Planning (Планування всього проекту розробки програмного забезпечення, включаючи обсяг проекту, часовий графік, бюджет, ресурси та управління ризиками.)
- Design (Проектування архітектури програмного продукту, модулів та інтерфейсу користувача на основі зібраних вимог)
- Development (Розробка програмного продукту з використанням відповідної мови програмування, фреймворку та системи керування базами даних)
- Testing (Тестування програмного продукту для виявлення та усунення будь-яких помилок або проблем, перш ніж він буде випущений для кінцевих користувачів)
- Deployment (Впровадження в цій фазі готову версію програми “віддають” клієнту в користування або “деплоять”в мережу
- Maintenance( Підтримка програмного продукту після його впровадження, виправляють існуючі баги та створюють нові версії програми.)
Яка різниця між SDLC і STLC?
Життєвий цикл розробки програмного забезпечення (SDLC) – це процес, який використовується індустрією програмного забезпечення для проектування,
розробляти та тестувати високоякісне програмне забезпечення. SDLC прагне створювати високоякісне програмне забезпечення, яке
відповідає або перевершує очікування клієнта, досягає завершення в терміни та кошториси.
Життєвий цикл тестування програмного забезпечення STLC — це послідовність різних дій, які виконує команда тестувальників
для забезпечення якості програмного забезпечення або продукту. STLC є невід’ємною частиною програмного забезпечення
Життєвий цикл розробки (SDLC). Але STLC займається лише фазами тестування.
Тестова документація -це?
Тестова документація – це набір документів, що створюється протягом усього циклу тестування. Документація допомагає команді однозначно трактувати кроки, терміни тестування, результати, звертатися до цієї інформації у спірних моментах.
Види тестової документації
Test strategy
Test plan
Чек лісти
Test Suite(Тест комплект)
Test case
Bug report
Test report
Test strategy - це?
Це не деталізований план дій
Стратегія тестування - відносно невеликий статичний(незміннй) докумет, який описує підходи до проведення тестування в рамаках компанії в цілому або її окремих департаментів.
Тест Стратегія:
- Створює Project Manager
- Високорівневий (не детальний) документ з інструкціями про те, як буде проходити тестування
- Поверхньо описує техніки, що будуть використовуватись,
систему для тестування тощо - Тест стратегію зазвичай не змінюють
- Описує загальні підходи та методології
Test plan - це?
Тест план(Test Plan) - це документ, що описує весь обсяг робіт з тестування, починаючи з опису об’єкта, стратегії, розкладу, критеріїв початку та закінчення тестування, до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення . Тест план складають тестувальники, або QA Lead
Тест план:
- Створює Test Manager або Test Lead
- В деталях описує об’єм тестування і дії, необхідні для проведення тестування
- Описує всі активності тестування: які використовувати техніки, графік, ресурси тощо
- Тест плани можуть бути змінені і оновлені
- Описує багато деталей та уточнень
Test Plan (найголовніші пункти:4,6,7,9,10,11,13,16)
- Test Plan Identifier
(Ідентифікатор документу, його номер) - References
(гіпер посилання(на якість документи, стандарти…)) - Introduction
(Вступ(короткий опис документу)) - Test items
(обєкти тестування(пар. незалежний від інших модулів, модуль який може працювати з ядром )) - Software Risk Issues
(Ризиковані місця(в цьому пункті обгворюються потенційно ризиковані місця, напр інтегрування чогось нового)) - Features to be tested
(Перечисляємо що плануємо протестувати) - Features not to be tested
(Experemental (експерементальні, наявність релізу буде залежати від попиту на цю функціональність), Legacy(спадоковість,функціональнвсть яка переходить з одної версїї в іншу)) - Approach
( Підходи, де будемо викор автотестування, нагрузочне…) - Item pass/fail criteria
(обоговорюється критерії щоб прийняти рішенння по новій версії, пройшла вона тест чи не пройшла,на основі кількості багів які залишились) - Suspension criteria and resumption requirements
(критериї призупинення тестування, і вимоги для відновлення) - Test deliverables
(перечисляються ті документи які обовязково команда тестування має складати) - Testing tasks
(задачі тестування, тут пописується що конкретно має убти зроблено і де) - Enviromental needs
(опис софта і техніки які потрібні для тестування) - Responsibilities
(відповідальності сторін описані, конкретна посада і відповідальність за якість вид документу) - Staffing and training needs
(описується розмір команди, і потреби команди для проекту(лекції, курси,тренінги)) - Schedule
(графіки, де вказується коли QA будуть отримувати зборки для тестування, і в які терміни мають приймати по них рішення) - Risks and contingencies
(ризики і робота з ними, план дій на випадок затримки в роботі, недостаній кількості людей в команді…ітд) - Approvals
(документ який затверджується різними учасниками процесу) - Glossary
(словник, абривіатур, скорочень)
</aside>
Чек ліст- це?
Чек-лист можна порівняти зі списком покупок: це перелік того, що потрібно перевірити. Якщо представити тестування деяких сценаріїв користувача в Нетфлікс у вигляді чек-листа, вийде наступне:
1. Оформити передплату.
2. Перегляд вітрини фільмів.
3. Запуск продовженого перегляду.
Статуси існують наступні: Passed, Failed, Blocked, In progress,
Skipped, Not run
Test Suite(Тест комплект)
(документ який містить набір тестів призначених для перевірки одної або суміжної функціональності)
Test case
(документ який описує набір кроків (інструкцію з описом дій) які потріно виконати для перевірки ОДНОГО очікуваного результату)
Один тест-кейс перевіряє одну конкретну функцію або сценарій користувача. Тест-кейс складається з інформації про те, що має бути перевірено, покрокової інструкції, як це перевірити, а також даних та умов, за яких потрібно проводити цю перевірку.
Тест-кейси та чек-лист складаються до тестування, це план того, як воно проходитиме. Тому в тест-кейсі може бути тільки очікуване значення, фактично ще невідомо. Якщо у процесі тестування виявляється невідповідність, його заносять у баг-репорт.
Bug report
Баг-репорт (Bug Report – звіт про помилку) – це технічний
документ, тому він створюється за певними правилами.
(документ який описує дефект додатку) в ньому описано:
- де і коли робити? (preconditions)
- що робили? (steps to reproduse)
- що отримали? (actual result)
- що очікували(expected result)
Test report
Тест-репорт (Test report)– звіт про виконання тест-кейсів, у ньому
зазвичай зображена загальна статистика, кількість виконаних тест-
кейсів та кількість знайдених помилок, висновок щодо релізу.
Назвіть характеристики хорошого тест-кейсу?
Хороший тест-кейс покриває як позитивні, так і негативні сценарії і виконує тільки одну дію за один раз та не перетинається з іншими.
Характеристики хорошого тесту-кейсу:
- набір тестів не повинен бути надмірним – повинен бути мінімальним і достатнім; рекомендовано використовувати розбиття на класи еквівалентності;
- тест-кейс не повинен бути надто простим чи, навпаки, складним;
- тест-кейс повинен бути точно визначеним;
- тест-кейс повинен бути уніфікованим;
- тест-кейс повинен бути однозначним і зрозумілим.
Яка різниця між тестовим випадком і тестовим сценарієм?
Test scenarioвизначається як будь-яка функціональність, яку можна протестувати. Його також називають тестовою умовою або тестом
можливість.
Приклад: Перевірте функціональність входу
Example: Test the login functionality
Test case — це набір дій, які виконуються для перевірки певної функції або функції вашого програмного забезпечення
додаток. Тестовий приклад містить тестові кроки, тестові дані, передумову та постумову, розроблені для конкретного
тестовий сценарій для перевірки будь-якої вимоги.
Приклад: тестовий вхід із дійсним іменем користувача та дійсним паролем
Example: Test login with a valid username and a valid password
- Тестовий сценарій можна протестувати за допомогою кількох тестів
Баг репорт складається з:
ID:
Summary:
Type: Bug
Status: New/open/Fixed/Not a bug(Rejected)/reopened/closed
Priority:Critical/High/Medium/Low
Severity: Blocker/Critical/High(Major)/Medium/Low(Minor)
Description:
Pre-condition:
We have already registered user and have credentials.
Steps to reproduce:
- Open login page(www.test.com/login);
- Complete “User name” field with a valid user name;
- Complete “Password” field with a valid password;
- Click on [Login] button;
- Observe the screen.
Actual result: Login pages is still displayed. No additional messages appear.
Expected result: Home page of registred user is displayed.
Additional info: 502 error appears in console.
Environment: OS:any(OS, Windows)
Attachment: (photo/video)
Browser: Chrome, Firefox, Safari, Opera (any version)
Build(version): 1.17(версія зборки)
Assign to:( на кого назначений баг)
Різниця між сереверіті і пріоріті?
Priority - наскільки важлива помилка з бізнесової точки зору(репутація компанії)(пріоріті важливіше виправиляти вшвидше)
Низьки:граматична помилка
Високий:помилка в лого
Severity- наскільки складна помилка
Блокер:не працює реєстрація/незавантажується основнап сторінка
Низький/косметичний: не перекладений тест
Приклади з різими северіті і пріоріті
Високий пріоритет і низька серйозність
Приклад 1
Кнопки трохи перекривають одна одну. (вони виконують свою функцію але візуально псують враження)
Приклад 2
Логотип компанії на головній сторінці містить орфографічну помилку. З точки зору функціональності, це ні на що не впливає, але це впливає на досвід користувача. Цей баг необхідно усунути з високим пріоритетом,навіть якщо він мінімально впливає на продукт.
Висока серйозність і низький пріоритет
Приклад 1
наприклад помилка яка виникла в такому функціоналі ПЗ яка рідко коли використовується
Тест кейси бувають
Позитивні — показують, що за коректних даних та очікуваних сценаріїв система виконує те, що має. Наприклад, якщо поле пароля дозволяє вписати цифри та символи, позитивний тест-кейс – перевірка на введення пароля, що складається з цифр та символів.
Негативні – показують, що з некоректних вхідних даних система відреагує правильно. Наприклад, виведе вікно з підказкою чи попередженням.
Чому помилки знайдені пізніше будуть коштувати дорожче?
Тут все просто: чим раніше ми знайдемо дефект, тим дешевше нам буде коштувати його виправлення. Зрозуміло, що виправити рядок в специфікації або коді простіше та дешевше, ніж вносити зміни в готовий продукт. Не кажучи вже про ситуацію, коли дефект знаходить замовник або кінцевий користувач – тут може постраждати репутація компанії-розробника, а такі збитки важко підрахувати.
Легше аиправити помилку в вимогах наранньому етапі ніж випарвляти вже готовий код.
Що таке вимоги (Специфікація)?
Це опис того як має працювати ПЗ, його вигляд.
Документ який описує якою буде система
Специфікація- це детальний опис того, як має працювати ПЗ.
Функціональні вимоги(набір функціональностей які потрібні для ПЗ яке розробляється, описують що система буде робити)
Нефункціональні вимоги (набір характеристик який описує як система буде рацювати)
Вимоги обговорюються на мітингу на якому присутні (developer, tester, busines analys)
Вимоги можна взяти з:
Документаціїї
Досвід користування аналогічнимими системами
Здоровий глузд, логічне використання
Статистичні данні (наприклад, що в середньому користувач втрачає терпіння впродовж 5 секун якщо сторінка не завантажитлась )
Спілкування (іноді вимоги треба уточнювати)
Рівні вимог:
Бізнес вимоги (business requirements):
1.Навіщо створюється
2. Яка користь з продукту
3. Як отримати прибуток
Користувацькі вимоги (user requirements)
1. Що користувач може робти задопомогою цього продукту
Продуктові вимоги (product requirements)
1. Функціональні(Що система повинна робити)
2. Нефункціональні (Як система повитнна працювати) наскільки продуктивно, наскільки задокументовано все має бути, в якому системному середовищі)
Критерії вимог?
- Повнота – Вимога повністю визначена і вся необхідна
інформація присутня. - Несуперечливість – Вимога не суперечить іншим вимогам
- Атомарність – Вимога не може бути розбита на ряд більш детальних вимог
без втрати завершеності. - Відслідковуваність – Вимога відповідає діловим
потребам як заявлено зацікавленими особами і задокументовано. - Актуальність – Вимога не стала застарілою з часом.
- Реалізовуваність– чи вимога взагалі технічно може бути виконана
- Недвозначність –відсутність двозначності вимоги; вимога описана чітко, зрозуміло і коротко;
- Важливість (пріоритетність)– не всі вимоги є однаково важливими, тому потрібна проріттеризація
8.Досяжність — чи реалізація вписується в часові й фінансові обмеження проекту - Вимірюваність — вимога має в чомусь вимірюватись (напр: заванатження сторінки має бути менше секунди)
Що таке (STLC)?
Життєвий цикл тестування програмного забезпечення (STLC)
- це послідовність кроків що проводяться в процесі тестування для забезпечення щоб забезпечити якість ПЗ
Фази STLC
- Аналіз вимог (аналізуємо вимоги, пріорітезуємо, перевіряєми чи одна дній не суперечать)(артефакт: RTM)
- Планування тестів (готуємо план тестуванння, співставляємо кошторис, графік, визначаємо ссередовище випрбування)(артефакт: Test plan)
- Розробка кейсів ( пишуться тест кейси)(артефакт: тест кейс)
- Налаштування тестового середовища( перерраховуються вимоги до обладнання та програмного забезпечення для тестового середовища)(проводиться смок тестування ПЗ в тестотвому середовищі) (артефакт: результати тесту на смок тестування)
- Виконання тесту(артефакти: оновлені тест кейси з результтатом, баг репорти)
- Закриття тестового циклу ( перревіряємо чи досягли критеріїв завршення тестування, якщо так то завершуємо його)(артефакти: звіт про закритття випробувань, тестові показники)
Що таке критерії входу та виходу в STLC?
Entry Criteria:Критерії входу—надають необхідні елементи, які необхідно мати перед початком нового етапу тестування.
Exit Criteria: Критерії виходу —визначають елементи, які необхідно мати перед тим, як етап може бути завершено
Що таке техніки тест дизайну? Для чого вони?
Тест дизайн- етап тестуванні ПЗ на якому плануються , проектуються і створюються тестові випадки(тест кейси) відповідно до визначених раніше критеріїв і цілей тестування.
Цілі тест дизайну?
Забезпечити покриття функціоналу додатку тестами.
В рамках чого небудь:
- Тести повинні покривати весь функціонал
- Тестів повинно бути мінімально достатньо
Техніки тест дизайну:
- Еквівалентні класи (Equivalence class)
- Граничні значення(Boundary Values)
3.Exploratory(дослідницьке) - PairWise(попарне зрівняння)
5.States & Transitions(стани і переходи)
6.Decision table(Таблиця прийняття рішень)
7.Error guessing(вгадування помилок)
8.Exhaustive testing(вичерпне тестування)
Еквівалентні класи (Equivalence class)
Підхід полягає в наступному: вхідні / вихідні дані розбиваються на класи
еквівалентності, за принципом, що програма веде себе однаково з кожним
представником окремого класу. Таким чином, немає необхідності тестувати всі
можливі вхідні дані, необхідно перевірити по окремо взятому представнику класу.
Граничні значення(Boundary Values)
Техніка граничних значень(Boundary Values Analysis) - техніка заключається в пошуку помилок на границях діапазонів еквівалентних класів
Граничні значення- це точки закінчення діапазонів еквівалентних класів на яких додаток міняє свою поведінку.
Exploratory(дослідницьке)
Explorary(тестування вільним пошуком)тестування методом вільного пошуку, або тестування без завчасно спроектованих тестів.
У дослідному тестуванні створюються неформальні тести, вони
виконуються, створюється звіт і все це робиться у процесі
тестування
Коли необхідно Exporatory:
- Якщо вимог немає або часто міняються
- Коли додаток активно розвивається і тести не фіксуються
- Коли цілі наступної ітерації тестування міняються в залежності від результату попередньої ітерації.
- Коли всі інші підходи себе вичерпали
PairWise(попарне зрівняння)
PairWise - техніка формування наборів тестових данних
(використовується якщо є різні enviroment на яких треба перевірити однакові дії)
States & Transitions(стани і переходи)
Тестування станів і переходів
(State & transitions testing)- техніка тестування орієнтована на пошук помилки в переходах між станами програми(додатку).
Стан(State)(представлено в вигляді кругу на диаграмі) - це стан додатку, в якому воно очікує одне або більше подій. Стан памятає вхідні данні отриманні до цього і показує як додаток буде реанувати на отримані події.
Подія(Event)(представлене ярликом над стрілочкою переходів)- подія, це те що заставляє додаток змінити свій стан.
Події можуть бути:
- зовнішні(те які поступили через інтерфейс(незавжди користувацький, ще може бути програмний) додатку)
- внутрішні(ті які система згенерувала сама)
Decision table(Таблиця прийняття рішень)
Таблиця приняття рішень(Decision table) - техніка тестування, при якій різні вхідні комбінації і їх відповідна поведінка системи(вихідні данні) фіксуються в табличній формі.
Error guessing(вгадування помилок)
Error guessing(вгадування помилки) - це спосіб запобігання помилкам, дефектам та відмовам, заснований на знаннях тестувальника, що включають:
* Історію роботи програми в минулому.
* Найбільш ймовірні типи дефектів, які допускаються під час
розробки.
* Типи дефектів, які були виявлені у подібних додатках.
У передбаченні помилок немає чіткої та логічної схеми, яка б
дозволила нам скласти тест-кейси. Навпаки, ця техніка ґрунтується
на досвіді тестувальника та на його вмінні думати креативно та
деструктивно.
Прикладами тестів для вгадування помилок є:
- Ділення на 0
- Вибір дати народження в майбутньому
- Вибір неіснуючої дати (30 лютого)
- Введення пробілів у текстові поля
- Натискання кнопки надсилання без введення значень
- Завантаження файлів, що перевищують максимальні
обмеження
Ad-hoc Testing
Ad-hoc Testing- повністю неформалізований підхід, у якому не передбачається використання ні тест-кейсів, ні чек-листів, ні сценаріїв. Тестувальник спирається на свою інтуїцію та досвід для спонтанного виконання з продуктом дій, які, як він вважає, що можуть виявити помилку.
Exploratory та Ad-hoc тестування - це різні техніки дослідження продукту з різним ступенем формалізації, різними завданнями.
Різниця між Ad-hoc та Exploratory тестуванням у тому, що, теоретично, Ad-hoc може провести будь-хто. А для проведення Exploratory необхідна майстерність та володіння певними техніками.
Можна сказати, що Ad-hoc тестуванням займаються бета- тестувальники, які добровільно зголосилися використовувати продукт та повідомляти про помилки. Вони саме поняття не мають ні про техніки тестування, ні про його методи та принципи.
Monkey Testing
Monkey Testing – це метод тестування ПЗ, при якому тестувальник вводить будь-які випадкові вхідні дані без заздалегідь визначених тестових випадків і перевіряє поведінку програми, незалежно від того, дає вона збій чи ні. Тобто, тестуємо без мети, без плану.
Просто тикаємося скрізь із наміром щось зламати.
Які є рівні тестування?
- Unit testing(тести які тестують кожну одиницю функціоналу кожен юніт(якусь маленьку логіку))
Модульне тестування: спрямоване на перевірку кожної частини програмного забезпечення шляхом її ізоляції а потім виконуутьсся тести, щоб продемонструвати, що кожен окремий компонент є правильним з точки зору виконання вимог і
бажаної функціональності.
[Виконується розробниками] - Integration testing (перевірка взаємодії двох або більше модулів між собою)
Інтеграційне тестування: має на меті перевірити різні частини системи в
комбінації, щоб оцінити, чи правильно вони працюють разом.
[Виконується розробниками] - System testing ( тестування всієї програми) до нього можна віднести: security testing, usability testing, recoverability testing, regression testing, performers testing, load testing, stability testing
Тестування системи: усі компоненти програмного забезпечення тестуються як одне
ціле, щоб гарантувати, що загальний продукт відповідає визначеним вимогам
[Виконується тестувальниками] - Acceptance testing
Приймальне тестування:це рівень у процесі тестування програмного забезпечення
де продукту дають зелене світло чи ні. Мета цього типу
тестування полягає в тому, щоб оцінити, чи відповідає система вимогам кінцевого користувача вимоги та готовність до розгортання
[Виконується користувачами]
Які є 3 види інтерфейсів?
-API (Application Programming Interface)Цей набір методів можна використовуватиме доступу до функціональності іншої програми.
-CLI (Command-line interface) Інтерфейс командного рядка там, де інструкція комп’ютеру дається шляхом введення з клавіатури текстових рядків, по-простому – це звичайний командний рядок у системі Windows.
-GUI (Graphical user interface) У ньому програмні функції надаються графічними. елементи екрану. Наприклад, це те, що ми бачимо у вікні браузера, коли відкриваємо сторінку в інтернеті.
Які принципи тестування (закони тесування)?
1.Вичерпне тестування неможливе
2.Кластеризація або скупчення дефектів (якщо знайшлась поимлка в одній функціональності, скоріше за все там будуть ще помилки)
3.Парадокс пестицидів (треба комбінувати види тестування)
4.Тестування підтверджує наявнісь дефектів
5.Відсутність помилок це омана
6.Раннє тестування(почнаємо тестування як найраніше,чим раніше знайдемо помилку тим менші ймовірність такі помилки знайти пізніше)
7.Тестування залежить від контексту( тестусання буде залежати від контексту використання додатку)
Які є види тестування?
Функціональне(Unit,Intergration,System)
Нефункціональне
Повязане з змінами(Smoke,Regression,Sanity)
Яка різниця між функціональним і нефункціональним тестуванням?
Функціональне тестування – це тип тестування, який перевіряє, що кожна функція програмного додатку працює відповідно до специфікації вимог. Віно перевіряє, що робить система.
Нефункціональне тестування – це тип тестування для перевірки нефункціональних аспектів (продуктивність, зручність використання, надійність тощо) програмного забезпечення. Віно перевіряє, наскільки добре працює система.
Приклад:
Під час функціонального тестування ми перевіряємо функціональність входу, чи працює вона, як очікувалося, чи ні?
Під час нефункціонального тестування ми можемо перевірити продуктивність системи, коли 100 користувачів увійшли одночасно.
Види функціонального тестування?
Юніт (модульне) тестування
Перший рівень тестування, який зазвичай виконується розробниками. Юніт, або модульне, тестування допомагає переконатися, що окремі компоненти ПЗ функціонують на рівні коду та поводяться очікувано. Такі тести можна проводити вручну, однак автоматизація процесу завжди економить час на розгортання та розширює тестове покриття.
Інтеграційне тестування
[Інтеграційне тестування перевіряє, чи правильно працюють незалежні компоненти ПЗ, коли об’єднуються. Треба з’ясувати, як поводяться окремі модулі програми під час взаємодії один з одним? Проведіть інтеграційне тестування. Тоді ви можете знайти такі помилки, як несумісність у форматах повідомлень чи даних, неприпустимі вхідні чи вихідні параметри тощо.
Системне тестування
[Системне тестування]— це тестування вже згаданим методом «чорного ящика», яке оцінює повний та інтегрований програмний продукт. Якщо треба перевірити, чи відповідає система заданим вимогам, проведіть системне тестування. Зазвичай його виконують команди тестувальників, перш ніж застосунок виходить в продакшен.
Види не функціонального тестування(як працє програма?)
- GUI(Graphic user interface)(перевірка вимог до інтерфейсу користувача, наскільки інтерфейс приємний оку коритувача, чи підгрузились всі стилі, чи сайт виглядає на на шаблоні від дизайнера а не біле полотно з чоним шрифтом,всі зображення , всі кнопочки, всі тексти відцентровані і вони знаходяться та тому місці де вони повинні знаходитиьсь, одним словом user frendly)
- Usability(UX) user experience (перевірка того, наскільки легко кінцевий
користувач може зрозуміти і освоїти інтерфейс.)(його проводять користувачі) - Perfomance(тестування продуктивності):
1.load (нагрузочне, визанченяя межі продуктивності)
2.stress(підвищення навантаження на додаток для отримання максимальної межі подуктивності)
3.recoverability (відновлювальності, наскільки система самовідновиться)
4.stability(стабільність роботи, при постійному високому навантаженні без втрати продуктивності) - Localization(відповідність ПЗ регіональним вимогам, (формат дати та часу,те що можна/неможна показувати в якомусь регіоні))
- Internalization(тестування підтримки багатомовних інтерфейсів)
- (Security testing) (Тестування безпеки)
- Compatibility testing(Тестування сумісності) - вимірює, як програмне забезпечення працює на різних платформах, операційних системах, браузерах та пристроях.
- Accessibility testing(Тестування доступності) - перевіряє, чи можуть користувачі з різними здібностями взаємодіяти з програмним забезпеченням.(наприклад вади зору)
- (Reliability testing) Тестування надійності - вимірює, наскільки надійно працює програмне забезпечення в різних умовах.
- Scalability testing – тестування програмного забезпечення для вимірювання можливостей масштабування.
- (Network Performance testing) Тестування продуктивності роботи в мережі - перевіряє, як програмне забезпечення працює в різних мережах
- Portabiblity (перевірка зміни системи) наприклад ОС
Повязане з змінами(Smoke,Regression,Sanity)
Тестування пов’язане із змінами проводиться після виправлення
виявлених у процесі тестування помилок та недоліків. Головне
завдання – підтвердити усунення проблеми.
-Re-testing або Confirmation testing - перевірка виправлено дефект чи ні.
- Regression Testing- чи не пошкодила зміна в коді інші функції продукту
- Smoke Testing - перевірка критично важливих функцій та стабільності системи загалом перед більш ретельним тестуванням. Smoke - націлене на тестування великої кількості функціонала за найкоротші терміни.
- Sanity Testing - загальний стан системи у деталях. Доказ працездатності конкретної функції. Часто використовують для перевірки внаслідок внесених змін. Sanity орієнтоване на глибинне дослідження певної функції.
- Build Verification Test - стабільність системи загалом, перевірка
критично важливих функцій конкретного складання.
Визначення відповідності версії ПЗ критеріям якості перед
початком тестування.
Що таке Usability(UX)( user experience)?
тестування, який виконується для оцінки того, наскільки простим і зручним є програмний продукт або веб-сайт у використанні для цільової аудиторії.
Основна мета тестування зручності використання — виявити будь-які проблеми або області вдосконалення в дизайні інтерфейсу користувача, навігації та загальному досвіді користувача.
Верифікація і Валідація, яка між нимим різниця? Що більш пріорітетно?
Верифікація - перевірка того що ми робимо продукт правильно,вона направлення на запобігання багів.(QA відповідає за верифікацію)
Це статичне тестування це тестування: документації, дизайн.
Валідація -перевірка того що написанйи софт (продукт), працює відновідно до очікувань користувача і і в умовах які потрібні користувачу, вона напрвлена на пошук багів в реальному софті.(QC відповідає за валідацію)
Це динамічне тестування(з запуском коду)
