Теоретичні питання Flashcards
(144 cards)
1
Q
Що таке тестування?
A
Перевірка відповідності між реальною та очікуваною поведінкою.
2
Q
Якість ПЗ (Software Quality) це?
A
Якість ПЗ (Software Quality)
— це сукупність показників програмного забезпечення, які стосуються його здатності задовольняти встановлені і передбачувані потреби.
3
Q
Чи потрібно тестування?
A
Так, Однією з основних мет тестування є виявлення дефектів в програмному забезпеченні перед його випуском. Це дозволяє забезпечити якість продукту та зменшити ризики.
4
Q
Чи можа тестуванням знехтувати?
A
Ні, тестування не можна знехтувати, оскільки воно є необхідною частиною процесу розробки програмного забезпечення. Тестування допомагає виявляти помилки та дефекти в програмному забезпеченні та переконується в тому, що програма працює належним чином.
5
Q
Цілі тестування:
A
- Перевірка того чи продукт відповідає вимогам і чи задовільняє кінцевого користувача
- Виявити дефект
- Тестування дозволяє визначити умови, за яких програма поводиться некоректно
- Запобігти дефекти
- Підвищення якості ПЗ
- Надання актуальної інформації про стан продукту зараз.
6
Q
Коли ми повинні почати тестування в нашому проекті?
A
Тестування програмного забезпечення має починатися на початку життєвого циклу розробки програмного забезпечення.
Це допомагає виявити та усунути дефекти на ранніх стадіях SDLC, тобто на етапі збору вимог і проектування. Ранній початок тестування допомагає зменшити кількість дефектів і, зрештою, вартість переробки.
* Один із семи принципів тестування програмного забезпечення: «Раннє тестування економить час і гроші».
7
Q
Баг- це
A
- Баг – це відхилення фактичного результату від очікуваного.
- Головне джерело очікуваного результату - це специфікація(вимоги).
- Специфікації самі не без гріха, і в цьому випадку, як і у випадку
повної їх відсутності, у нас є здоровий глузд, усталені
стандарти, досвід роботи, статистика, авторитетна думка та ін.
8
Q
Яка різниця між bug, failure, error?
A
Bug (defect)– помилка програміста (або дизайнера або ще кого, хто бере участь у розробці), тобто коли в програмі щось йде не так як планувалося і програма виходить з-під контролю. Наприклад, коли відсутня валідація полів і в результаті неправильні дані викликають краші або інші збої у роботі програми. Або всередині програма побудована так, що від самого початку не відповідає тому, що від неї очікується.
Failure– збій (причому не обов’язково апаратний) у роботі компонента, всієї програми чи системи. Збій у роботі програми може бути індикатором наявності дефекту.
Error– помилка користувача, який намагається використовувати програму іншим способом. Наприклад, вводить літери в поля, де потрібно вводити цифри (вік, кількість товару тощо). У якісній програмі передбачені такі ситуації та видаються повідомлення про помилку.
9
Q
Цикл житття багу
A
New- вперше знайдено баг і внесено до системи.
Open- взято в роботу.
Assigned- назначено розробника, який буде виправляти баг.
Rejected (Not a bug) - розробник відхилив баг або не зміг відтворити. Ми маємо перевірити, чи баг відтворюється, і якщо так, то показати це розробнику.
Deferred - перенесено на наступні спринти через брак часу і низький пріоритет.
Fixed - розробник виправив баг і чекає на перевірку QA.
Verified - тестувальник перевірив баг.
Reopened- якщо баг не виправлено і він відтворюється, його перевідкривають.
Closed - якщо баг виправлено, його закривають.
Duplicate(Дублікат) (такий баг вже існує, або знаходиться в роботі)
10
Q
Типи (багів)дефектів:
A
Functional (непраццює якийсь функціонал напр кнопка)
Security(наприклад якщо хтоссь може зламати пароль)
Usability (дефект зручності використання апр кнопка вилізна нап іншу кнопку)
User interface ( незавантажені стилі,, шрифт, картинки…)
Localization (частково не перекладений текст основного функціоналу і кнопок)
Spelling (помилки в правописі)
Perfomance (напр довге завантаження сторінки)
11
Q
Що таке SDLC і йог етапи?
A
💡 (SDLC) — це процес розробки ПЗ з різними етапами та кроками, щоб перенести програмне забезпечення від ідеї до створення, впровадження та обслуговування.
- Requirements (Збір і аналіз вимог від клієнта або кінцевих користувачів.)
- Planning (Планування всього проекту розробки програмного забезпечення, включаючи обсяг проекту, часовий графік, бюджет, ресурси та управління ризиками.)
- Design (Проектування архітектури програмного продукту, модулів та інтерфейсу користувача на основі зібраних вимог)
- Development (Розробка програмного продукту з використанням відповідної мови програмування, фреймворку та системи керування базами даних)
- Testing (Тестування програмного продукту для виявлення та усунення будь-яких помилок або проблем, перш ніж він буде випущений для кінцевих користувачів)
- Deployment (Впровадження в цій фазі готову версію програми “віддають” клієнту в користування або “деплоять”в мережу
- Maintenance( Підтримка програмного продукту після його впровадження, виправляють існуючі баги та створюють нові версії програми.)
12
Q
Яка різниця між SDLC і STLC?
A
Життєвий цикл розробки програмного забезпечення (SDLC) – це процес, який використовується індустрією програмного забезпечення для проектування,
розробляти та тестувати високоякісне програмне забезпечення. SDLC прагне створювати високоякісне програмне забезпечення, яке
відповідає або перевершує очікування клієнта, досягає завершення в терміни та кошториси.
Життєвий цикл тестування програмного забезпечення STLC — це послідовність різних дій, які виконує команда тестувальників
для забезпечення якості програмного забезпечення або продукту. STLC є невід’ємною частиною програмного забезпечення
Життєвий цикл розробки (SDLC). Але STLC займається лише фазами тестування.
13
Q
Тестова документація -це?
A
Тестова документація – це набір документів, що створюється протягом усього циклу тестування. Документація допомагає команді однозначно трактувати кроки, терміни тестування, результати, звертатися до цієї інформації у спірних моментах.
14
Q
Види тестової документації
A
Test strategy
Test plan
Чек лісти
Test Suite(Тест комплект)
Test case
Bug report
Test report
15
Q
Test strategy - це?
A
Це не деталізований план дій
Стратегія тестування - відносно невеликий статичний(незміннй) докумет, який описує підходи до проведення тестування в рамаках компанії в цілому або її окремих департаментів.
Тест Стратегія:
- Створює Project Manager
- Високорівневий (не детальний) документ з інструкціями про те, як буде проходити тестування
- Поверхньо описує техніки, що будуть використовуватись,
систему для тестування тощо - Тест стратегію зазвичай не змінюють
- Описує загальні підходи та методології
16
Q
Test plan - це?
A
Тест план(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>
17
Q
Чек ліст- це?
A
Чек-лист можна порівняти зі списком покупок: це перелік того, що потрібно перевірити. Якщо представити тестування деяких сценаріїв користувача в Нетфлікс у вигляді чек-листа, вийде наступне:
1. Оформити передплату.
2. Перегляд вітрини фільмів.
3. Запуск продовженого перегляду.
Статуси існують наступні: Passed, Failed, Blocked, In progress,
Skipped, Not run
18
Q
Test Suite(Тест комплект)
A
(документ який містить набір тестів призначених для перевірки одної або суміжної функціональності)
19
Q
Test case
A
(документ який описує набір кроків (інструкцію з описом дій) які потріно виконати для перевірки ОДНОГО очікуваного результату)
Один тест-кейс перевіряє одну конкретну функцію або сценарій користувача. Тест-кейс складається з інформації про те, що має бути перевірено, покрокової інструкції, як це перевірити, а також даних та умов, за яких потрібно проводити цю перевірку.
Тест-кейси та чек-лист складаються до тестування, це план того, як воно проходитиме. Тому в тест-кейсі може бути тільки очікуване значення, фактично ще невідомо. Якщо у процесі тестування виявляється невідповідність, його заносять у баг-репорт.
20
Q
Bug report
A
Баг-репорт (Bug Report – звіт про помилку) – це технічний
документ, тому він створюється за певними правилами.
(документ який описує дефект додатку) в ньому описано:
- де і коли робити? (preconditions)
- що робили? (steps to reproduse)
- що отримали? (actual result)
- що очікували(expected result)
21
Q
Test report
A
Тест-репорт (Test report)– звіт про виконання тест-кейсів, у ньому
зазвичай зображена загальна статистика, кількість виконаних тест-
кейсів та кількість знайдених помилок, висновок щодо релізу.
22
Q
Назвіть характеристики хорошого тест-кейсу?
A
Хороший тест-кейс покриває як позитивні, так і негативні сценарії і виконує тільки одну дію за один раз та не перетинається з іншими.
Характеристики хорошого тесту-кейсу:
- набір тестів не повинен бути надмірним – повинен бути мінімальним і достатнім; рекомендовано використовувати розбиття на класи еквівалентності;
- тест-кейс не повинен бути надто простим чи, навпаки, складним;
- тест-кейс повинен бути точно визначеним;
- тест-кейс повинен бути уніфікованим;
- тест-кейс повинен бути однозначним і зрозумілим.
23
Q
Яка різниця між тестовим випадком і тестовим сценарієм?
A
Test scenarioвизначається як будь-яка функціональність, яку можна протестувати. Його також називають тестовою умовою або тестом
можливість.
Приклад: Перевірте функціональність входу
Example: Test the login functionality
Test case — це набір дій, які виконуються для перевірки певної функції або функції вашого програмного забезпечення
додаток. Тестовий приклад містить тестові кроки, тестові дані, передумову та постумову, розроблені для конкретного
тестовий сценарій для перевірки будь-якої вимоги.
Приклад: тестовий вхід із дійсним іменем користувача та дійсним паролем
Example: Test login with a valid username and a valid password
- Тестовий сценарій можна протестувати за допомогою кількох тестів
24
Q
Баг репорт складається з:
A
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:( на кого назначений баг)
25
Різниця між сереверіті і пріоріті?
Priority - наскільки важлива помилка з бізнесової точки зору(репутація компанії)(пріоріті важливіше виправиляти вшвидше)
Низьки:граматична помилка
Високий:помилка в лого
Severity- наскільки складна помилка
Блокер:не працює реєстрація/незавантажується основнап сторінка
Низький/косметичний: не перекладений тест
26
Приклади з різими северіті і пріоріті
Високий пріоритет і низька серйозність
Приклад 1
Кнопки трохи перекривають одна одну. (вони виконують свою функцію але візуально псують враження)
Приклад 2
Логотип компанії на головній сторінці містить орфографічну помилку. З точки зору функціональності, це ні на що не впливає, але це впливає на досвід користувача. Цей баг необхідно усунути з високим пріоритетом,навіть якщо він мінімально впливає на продукт.
Висока серйозність і низький пріоритет
Приклад 1
наприклад помилка яка виникла в такому функціоналі ПЗ яка рідко коли використовується
27
Тест кейси бувають
Позитивні — показують, що за коректних даних та очікуваних сценаріїв система виконує те, що має. Наприклад, якщо поле пароля дозволяє вписати цифри та символи, позитивний тест-кейс – перевірка на введення пароля, що складається з цифр та символів.
Негативні – показують, що з некоректних вхідних даних система відреагує правильно. Наприклад, виведе вікно з підказкою чи попередженням.
28
Чому помилки знайдені пізніше будуть коштувати дорожче?
Тут все просто: чим раніше ми знайдемо дефект, тим дешевше нам буде коштувати його виправлення. Зрозуміло, що виправити рядок в специфікації або коді простіше та дешевше, ніж вносити зміни в готовий продукт. Не кажучи вже про ситуацію, коли дефект знаходить замовник або кінцевий користувач – тут може постраждати репутація компанії-розробника, а такі збитки важко підрахувати.
Легше аиправити помилку в вимогах наранньому етапі ніж випарвляти вже готовий код.
29
Що таке вимоги (Специфікація)?
Це опис того як має працювати ПЗ, його вигляд.
Документ який описує якою буде система
Специфікація- це детальний опис того, як має працювати ПЗ.
Функціональні вимоги(набір функціональностей які потрібні для ПЗ яке розробляється, описують що система буде робити)
Нефункціональні вимоги (набір характеристик який описує як система буде рацювати)
Вимоги обговорюються на мітингу на якому присутні (developer, tester, busines analys)
30
Вимоги можна взяти з:
Документаціїї
Досвід користування аналогічнимими системами
Здоровий глузд, логічне використання
Статистичні данні (наприклад, що в середньому користувач втрачає терпіння впродовж 5 секун якщо сторінка не завантажитлась )
Спілкування (іноді вимоги треба уточнювати)
31
Рівні вимог:
Бізнес вимоги (business requirements):
1.Навіщо створюється
2. Яка користь з продукту
3. Як отримати прибуток
Користувацькі вимоги (user requirements)
1. Що користувач може робти задопомогою цього продукту
Продуктові вимоги (product requirements)
1. Функціональні(Що система повинна робити)
2. Нефункціональні (Як система повитнна працювати) наскільки продуктивно, наскільки задокументовано все має бути, в якому системному середовищі)
32
Критерії вимог?
1. Повнота – Вимога повністю визначена і вся необхідна
інформація присутня.
1. Несуперечливість – Вимога не суперечить іншим вимогам
2. Атомарність – Вимога не може бути розбита на ряд більш детальних вимог
без втрати завершеності.
3. Відслідковуваність – Вимога відповідає діловим
потребам як заявлено зацікавленими особами і задокументовано.
4. Актуальність – Вимога не стала застарілою з часом.
5. Реалізовуваність– чи вимога взагалі технічно може бути виконана
6. Недвозначність –відсутність двозначності вимоги; вимога описана чітко, зрозуміло і коротко;
7. Важливість (пріоритетність)– не всі вимоги є однаково важливими, тому потрібна проріттеризація
8.Досяжність — чи реалізація вписується в часові й фінансові обмеження проекту
9. Вимірюваність — вимога має в чомусь вимірюватись (напр: заванатження сторінки має бути менше секунди)
33
Що таке (STLC)?
Життєвий цикл тестування програмного забезпечення (STLC)
- це послідовність кроків що проводяться в процесі тестування для забезпечення щоб забезпечити якість ПЗ
34
Фази STLC
1. Аналіз вимог (аналізуємо вимоги, пріорітезуємо, перевіряєми чи одна дній не суперечать)(артефакт: RTM)
2. Планування тестів (готуємо план тестуванння, співставляємо кошторис, графік, визначаємо ссередовище випрбування)(артефакт: Test plan)
3. Розробка кейсів ( пишуться тест кейси)(артефакт: тест кейс)
4. Налаштування тестового середовища( перерраховуються вимоги до обладнання та програмного забезпечення для тестового середовища)(проводиться смок тестування ПЗ в тестотвому середовищі) (артефакт: результати тесту на смок тестування)
5. Виконання тесту(артефакти: оновлені тест кейси з результтатом, баг репорти)
6. Закриття тестового циклу ( перревіряємо чи досягли критеріїв завршення тестування, якщо так то завершуємо його)(артефакти: звіт про закритття випробувань, тестові показники)
35
Що таке критерії входу та виходу в STLC?
Entry Criteria:Критерії входу— надають необхідні елементи, які необхідно мати перед початком нового етапу тестування.
Exit Criteria: Критерії виходу —визначають елементи, які необхідно мати перед тим, як етап може бути завершено
36
Що таке техніки тест дизайну? Для чого вони?
Тест дизайн- етап тестуванні ПЗ на якому плануються , проектуються і створюються тестові випадки(тест кейси) відповідно до визначених раніше критеріїв і цілей тестування.
37
Цілі тест дизайну?
Забезпечити покриття функціоналу додатку тестами.
В рамках чого небудь:
1. Тести повинні покривати весь функціонал
2. Тестів повинно бути мінімально достатньо
38
Техніки тест дизайну:
1. Еквівалентні класи (Equivalence class)
2. Граничні значення(Boundary Values)
3.Exploratory(дослідницьке)
4. PairWise(попарне зрівняння)
5.States & Transitions(стани і переходи)
6.Decision table(Таблиця прийняття рішень)
7.Error guessing(вгадування помилок)
8.Exhaustive testing(вичерпне тестування)
39
Еквівалентні класи (Equivalence class)
Підхід полягає в наступному: вхідні / вихідні дані розбиваються на класи
еквівалентності, за принципом, що програма веде себе однаково з кожним
представником окремого класу. Таким чином, немає необхідності тестувати всі
можливі вхідні дані, необхідно перевірити по окремо взятому представнику класу.
40
Граничні значення(Boundary Values)
Техніка граничних значень(Boundary Values Analysis) - техніка заключається в пошуку помилок на границях діапазонів еквівалентних класів
Граничні значення- це точки закінчення діапазонів еквівалентних класів на яких додаток міняє свою поведінку.
41
Exploratory(дослідницьке)
Explorary(тестування вільним пошуком)тестування методом вільного пошуку, або тестування без завчасно спроектованих тестів.
У дослідному тестуванні створюються неформальні тести, вони
виконуються, створюється звіт і все це робиться у процесі
тестування
Коли необхідно Exporatory:
1. Якщо вимог немає або часто міняються
2. Коли додаток активно розвивається і тести не фіксуються
3. Коли цілі наступної ітерації тестування міняються в залежності від результату попередньої ітерації.
4. Коли всі інші підходи себе вичерпали
42
PairWise(попарне зрівняння)
PairWise - техніка формування наборів тестових данних
(використовується якщо є різні enviroment на яких треба перевірити однакові дії)
43
States & Transitions(стани і переходи)
Тестування станів і переходів
(State & transitions testing)- техніка тестування орієнтована на пошук помилки в переходах між станами програми(додатку).
Стан(State)(представлено в вигляді кругу на диаграмі) - це стан додатку, в якому воно очікує одне або більше подій. Стан памятає вхідні данні отриманні до цього і показує як додаток буде реанувати на отримані події.
Подія(Event)(представлене ярликом над стрілочкою переходів)- подія, це те що заставляє додаток змінити свій стан.
Події можуть бути:
1. зовнішні(те які поступили через інтерфейс(незавжди користувацький, ще може бути програмний) додатку)
2. внутрішні(ті які система згенерувала сама)
44
Decision table(Таблиця прийняття рішень)
Таблиця приняття рішень(Decision table) - техніка тестування, при якій різні вхідні комбінації і їх відповідна поведінка системи(вихідні данні) фіксуються в табличній формі.
45
Error guessing(вгадування помилок)
Error guessing(вгадування помилки) - це спосіб запобігання помилкам, дефектам та відмовам, заснований на знаннях тестувальника, що включають:
* Історію роботи програми в минулому.
* Найбільш ймовірні типи дефектів, які допускаються під час
розробки.
* Типи дефектів, які були виявлені у подібних додатках.
У передбаченні помилок немає чіткої та логічної схеми, яка б
дозволила нам скласти тест-кейси. Навпаки, ця техніка ґрунтується
на досвіді тестувальника та на його вмінні думати креативно та
деструктивно.
Прикладами тестів для вгадування помилок є:
- Ділення на 0
- Вибір дати народження в майбутньому
- Вибір неіснуючої дати (30 лютого)
- Введення пробілів у текстові поля
- Натискання кнопки надсилання без введення значень
- Завантаження файлів, що перевищують максимальні
обмеження
46
Ad-hoc Testing
Ad-hoc Testing- повністю неформалізований підхід, у якому не передбачається використання ні тест-кейсів, ні чек-листів, ні сценаріїв. Тестувальник спирається на свою інтуїцію та досвід для спонтанного виконання з продуктом дій, які, як він вважає, що можуть виявити помилку.
Exploratory та Ad-hoc тестування - це різні техніки дослідження продукту з різним ступенем формалізації, різними завданнями.
Різниця між Ad-hoc та Exploratory тестуванням у тому, що, теоретично, Ad-hoc може провести будь-хто. А для проведення Exploratory необхідна майстерність та володіння певними техніками.
Можна сказати, що Ad-hoc тестуванням займаються бета- тестувальники, які добровільно зголосилися використовувати продукт та повідомляти про помилки. Вони саме поняття не мають ні про техніки тестування, ні про його методи та принципи.
47
Monkey Testing
Monkey Testing – це метод тестування ПЗ, при якому тестувальник вводить будь-які випадкові вхідні дані без заздалегідь визначених тестових випадків і перевіряє поведінку програми, незалежно від того, дає вона збій чи ні. Тобто, тестуємо без мети, без плану.
Просто тикаємося скрізь із наміром щось зламати.
48
Які є рівні тестування?
1. Unit testing(тести які тестують кожну одиницю функціоналу кожен юніт(якусь маленьку логіку))
Модульне тестування: спрямоване на перевірку кожної частини програмного забезпечення шляхом її ізоляції а потім виконуутьсся тести, щоб продемонструвати, що кожен окремий компонент є правильним з точки зору виконання вимог і
бажаної функціональності.
[Виконується розробниками]
2. Integration testing (перевірка взаємодії двох або більше модулів між собою)
Інтеграційне тестування: має на меті перевірити різні частини системи в
комбінації, щоб оцінити, чи правильно вони працюють разом.
[Виконується розробниками]
3. System testing ( тестування всієї програми) до нього можна віднести: security testing, usability testing, recoverability testing, regression testing, performers testing, load testing, stability testing
Тестування системи: усі компоненти програмного забезпечення тестуються як одне
ціле, щоб гарантувати, що загальний продукт відповідає визначеним вимогам
[Виконується тестувальниками]
4. Acceptance testing
Приймальне тестування:це рівень у процесі тестування програмного забезпечення
де продукту дають зелене світло чи ні. Мета цього типу
тестування полягає в тому, щоб оцінити, чи відповідає система вимогам кінцевого користувача вимоги та готовність до розгортання
[Виконується користувачами]
49
Які є 3 види інтерфейсів?
-API (Application Programming Interface)Цей набір методів можна використовуватиме доступу до функціональності іншої програми.
-CLI (Command-line interface) Інтерфейс командного рядка там, де інструкція комп'ютеру дається шляхом введення з клавіатури текстових рядків, по-простому – це звичайний командний рядок у системі Windows.
-GUI (Graphical user interface) У ньому програмні функції надаються графічними. елементи екрану. Наприклад, це те, що ми бачимо у вікні браузера, коли відкриваємо сторінку в інтернеті.
50
Які принципи тестування (закони тесування)?
1.Вичерпне тестування неможливе
2.Кластеризація або скупчення дефектів (якщо знайшлась поимлка в одній функціональності, скоріше за все там будуть ще помилки)
3.Парадокс пестицидів (треба комбінувати види тестування)
4.Тестування підтверджує наявнісь дефектів
5.Відсутність помилок це омана
6.Раннє тестування(почнаємо тестування як найраніше,чим раніше знайдемо помилку тим менші ймовірність такі помилки знайти пізніше)
7.Тестування залежить від контексту( тестусання буде залежати від контексту використання додатку)
51
Які є види тестування?
Функціональне(Unit,Intergration,System)
Нефункціональне
Повязане з змінами(Smoke,Regression,Sanity)
52
Яка різниця між функціональним і нефункціональним тестуванням?
Функціональне тестування – це тип тестування, який перевіряє, що кожна функція програмного додатку працює відповідно до специфікації вимог. Віно перевіряє, що робить система.
Нефункціональне тестування – це тип тестування для перевірки нефункціональних аспектів (продуктивність, зручність використання, надійність тощо) програмного забезпечення. Віно перевіряє, наскільки добре працює система.
Приклад:
Під час функціонального тестування ми перевіряємо функціональність входу, чи працює вона, як очікувалося, чи ні?
Під час нефункціонального тестування ми можемо перевірити продуктивність системи, коли 100 користувачів увійшли одночасно.
53
Види функціонального тестування?
Юніт (модульне) тестування
Перший рівень тестування, який зазвичай виконується розробниками. Юніт, або модульне, тестування допомагає переконатися, що окремі компоненти ПЗ функціонують на рівні коду та поводяться очікувано. Такі тести можна проводити вручну, однак автоматизація процесу завжди економить час на розгортання та розширює тестове покриття.
Інтеграційне тестування
[Інтеграційне тестування перевіряє, чи правильно працюють незалежні компоненти ПЗ, коли об'єднуються. Треба з'ясувати, як поводяться окремі модулі програми під час взаємодії один з одним? Проведіть інтеграційне тестування. Тоді ви можете знайти такі помилки, як несумісність у форматах повідомлень чи даних, неприпустимі вхідні чи вихідні параметри тощо.
Системне тестування
[Системне тестування] — це тестування вже згаданим методом «чорного ящика», яке оцінює повний та інтегрований програмний продукт. Якщо треба перевірити, чи відповідає система заданим вимогам, проведіть системне тестування. Зазвичай його виконують команди тестувальників, перш ніж застосунок виходить в продакшен.
54
Види не функціонального тестування(як працє програма?)
1. GUI(Graphic user interface)(перевірка вимог до інтерфейсу користувача, наскільки інтерфейс приємний оку коритувача, чи підгрузились всі стилі, чи сайт виглядає на на шаблоні від дизайнера а не біле полотно з чоним шрифтом,всі зображення , всі кнопочки, всі тексти відцентровані і вони знаходяться та тому місці де вони повинні знаходитиьсь, одним словом user frendly)
2. Usability(UX) user experience (перевірка того, наскільки легко кінцевий
користувач може зрозуміти і освоїти інтерфейс.)(його проводять користувачі)
3. Perfomance(тестування продуктивності):
1.load (нагрузочне, визанченяя межі продуктивності)
2.stress(підвищення навантаження на додаток для отримання максимальної межі подуктивності)
3.recoverability (відновлювальності, наскільки система самовідновиться)
4.stability(стабільність роботи, при постійному високому навантаженні без втрати продуктивності)
4. Localization(відповідність ПЗ регіональним вимогам, (формат дати та часу,те що можна/неможна показувати в якомусь регіоні))
5. Internalization(тестування підтримки багатомовних інтерфейсів)
6. (Security testing) (Тестування безпеки)
7. Compatibility testing(Тестування сумісності) - вимірює, як програмне забезпечення працює на різних платформах, операційних системах, браузерах та пристроях.
8. Accessibility testing(Тестування доступності) - перевіряє, чи можуть користувачі з різними здібностями взаємодіяти з програмним забезпеченням.(наприклад вади зору)
9. (Reliability testing) Тестування надійності - вимірює, наскільки надійно працює програмне забезпечення в різних умовах.
10. Scalability testing – тестування програмного забезпечення для вимірювання можливостей масштабування.
11. (Network Performance testing) Тестування продуктивності роботи в мережі - перевіряє, як програмне забезпечення працює в різних мережах
12. Portabiblity (перевірка зміни системи) наприклад ОС
55
Повязане з змінами(Smoke,Regression,Sanity)
Тестування пов'язане із змінами проводиться після виправлення
виявлених у процесі тестування помилок та недоліків. Головне
завдання – підтвердити усунення проблеми.
-Re-testing або Confirmation testing - перевірка виправлено дефект чи ні.
- Regression Testing- чи не пошкодила зміна в коді інші функції продукту
- Smoke Testing - перевірка критично важливих функцій та стабільності системи загалом перед більш ретельним тестуванням. Smoke - націлене на тестування великої кількості функціонала за найкоротші терміни.
- Sanity Testing - загальний стан системи у деталях. Доказ працездатності конкретної функції. Часто використовують для перевірки внаслідок внесених змін. Sanity орієнтоване на глибинне дослідження певної функції.
- Build Verification Test - стабільність системи загалом, перевірка
критично важливих функцій конкретного складання.
Визначення відповідності версії ПЗ критеріям якості перед
початком тестування.
56
Що таке Usability(UX)( user experience)?
тестування, який виконується для оцінки того, наскільки простим і зручним є програмний продукт або веб-сайт у використанні для цільової аудиторії.
Основна мета тестування зручності використання — виявити будь-які проблеми або області вдосконалення в дизайні інтерфейсу користувача, навігації та загальному досвіді користувача.
57
Верифікація і Валідація, яка між нимим різниця? Що більш пріорітетно?
Верифікація - перевірка того що ми робимо продукт правильно,вона направлення на запобігання багів.(QA відповідає за верифікацію)
Це статичне тестування це тестування: документації, дизайн.
Валідація -перевірка того що написанйи софт (продукт), працює відновідно до очікувань користувача і і в умовах які потрібні користувачу, вона напрвлена на пошук багів в реальному софті.(QC відповідає за валідацію)
Це динамічне тестування(з запуском коду)
58
Статичне та динамічне тестування?
Статичне тестування – під час статичного тестування код не виконується (програма не запускається).
Перевіряються:
* Документи (вимоги, тест-кейси, описи архітектури, схеми баз
даних тощо).
* Графічні зразки (дизайн).
* Код програми (виконується програмістами в рамках code review.
* Параметри (налаштування) середовища виконання програми.
Статичне тестування починається на ранніх етапах життєвого циклу і є, відповідно, частиною процесу верифікації.
Динамічне тестування – тестування із запуском коду виконання, як всього додатку цілком (системне тестування), так і кількох взаємозалежних частин (інтеграційне тестування), окремих частин (модульне тестування) і навіть окремі ділянки коду.
Динамічне тестування включає тестування ПЗ в режимі реального часу шляхом надання вхідних даних і вивчення результату поведінки ПЗ. Перевірка здійснюється за допомогою попередньо підготовленого набору тестів. Є частиною процесу валідації програмного забезпечення.
59
Чим відрізняється процес тестування QC від QA?
QA) запобігаєте виникненню дефектів,процес верифікації відноситься сюди, на різних етапах розробки
(QC) зосереджується на виявленні дефектів, валідація сюди відноситься, присутній на стадії тестування ПЗ
60
Автоматизація потрібна для того, щоб:
Замінити трудомістке ручне тестування робочих процесів і безлічі сценаріїв
Виключити помилки внаслідок «людського фактора»
Забезпечити прозорий контроль над процесом тестування
Скоротити витрати на скриптах завдяки їх повторному використанню
Отримати точні та надійні результати випробувань
Скоротити час виходу готового продукту на ринок
Поліпшити процес розробки (Continues Integration)
61
В яких випадках виконується автоматизоване тестування, а в яких ні?
Автоматизоване тестування робимо коли:
- Сценарії регулярно повторюються
- Сценарії трудомісткі, складні й не підходять для ручної перевірки
- Перевірка тест-кейсів займає багато часу
- Сценарії для високонавантажених додатків (High-load applications)
Автоматизоване тестування НЕ робимо коли:
- Якщо сценарії тестів нові й не тестувалися вручну
- Якщо тести вимагають постійних змін
- У випадку, коли запустити сценарій тестування потрібно тільки один раз.
- В UX/UI тестуванні
62
Які процеси чи функціонал можна автоматизувати?
Back-end процеси та сервіси
API
Запис логів
Роботу баз даних
Опції та інструменти сайту, додатку, ресурсу, що часто використовуються: форми реєстрації, системи онлайн-оплат і т.п.
Автоматизацію заповнення полів, збереження і перевірку
Валідацію даних, що вводяться
Зберігання та цілісність даних
63
Які типи тестування можна автоматизувати?
1. Performance testing (load, stress) Тестування продуктивності (навантажувальне, стресове)
(проводиться з метою перевірки працездатності продукту в умовах, максимально наближених до реальних, з очікуваними навантаженнями та обсягом даних. Наприклад, потрібно перевірити роботу сайту при великому трафіку користувачів, який може вплинути на швидкість завантаження і роботу окремих модулів.)
2. Regression testing(Регресивне тестування)
(Завдання RТ — переконатися, що нові зміни, внесені в код, не порушили роботу ПЗ. Автоматизація РТ звільняє тестувальника від частого ручного запуску одних і тих самих тест-кейсів перед кожним новим оновленням додатка або ПЗ.)
3. Configuration testing (Конфігураційне тестування)
(Автоматизація КТ не вимагає багато часу на впровадження, але при цьому значно прискорює процес тестування шляхом паралельного запуску тестів з різним поєднанням конфігурацій (браузер — операційна система — система управління базами даних — сервер).)
3. Localization testing (Тестування локалізації)
(Автоматизація ТЛ значно скоротить час на перевірку можливих помилок через адаптації продукту під різні версії.)
4. Integration testing (Інтеграційне тестування)
(Наприклад, потрібно перевірити як взаємодіє модуль кошика і платіжний модуль в інтернет-магазині.)
64
На що можна повпливати щоб покращити якість продукту?
Щоб покращити якість продукту, можна звернути увагу на наступні аспекти:**
1. Процес розробки:Вибрати найбільш підходящу модель розробки для нашого ПЗ
2. Тестування: Розробіти ефективні тести, використовувати автоматизовані тести, щоб зменшити час та зусилля, необхідні для виконання тестів.
3. Комунікація та співпраця: Забезпечити ефективну комунікацію та співпрацю між членами команди розробки, тестування та замовниками продукту. Це дозволить забезпечити згоду на вимоги та очікування та вирішувати проблеми та питання у реальному часі.
4. Оцінка ризиків: Оцініть ризики та знайдіть способи зменшити їх вплив на продукт. Виявлення ризиків може допомогти попередити проблеми та зменшити вартість їх виправлення.
5. Постійне вдосконалення: Постійно покращуйте продукт, оновлюючи функціонал та виправляючи помилки, які виявляються в процесі експлуатації. Виходьте на зв'язок з користувачами та знайомтеся
65
Чи чула я про підхід коли спочатку створюються тести, а потім під тести створюється код?(TDD)
test driven development - це розробка через тестування
Це техніка розробки ПЗ яка базується на повторенні дуже кокротких циклів в розробці:
1. Зпочатку пишеться тест який покриває бажану зміну
2. Потім пишенться код який дозволить пройти цей тест
TDD суть -це спочатку пишуться тести на неіснуючу логіку, відповіно вони фейляться а потім підтягується логіка під тести, для того шоб тести виконувались. Коли ми написали всі тести ми повинні перейти до імплементації(реалізації, виконання)
66
Приклад коли юніт тест проходить а інтеграційне - ні?
Коли сформували замовлення але на оплату не переходить
67
Які види інтеграційного тестування?
Існує декілька підходів до інтеграційного тестування:
- Знизу вгору. Спочатку збираються і тестуються модулі найнижчих рівнів, а потім по зростанню до вершини ієрархії. Даний підхід вимагає готовності усіх зібраних модулів на всіх рівнях системи
- Зверху вниз. Даний підхід передбачає рух з модулів високого рівня вниз. При цьому використовуються заглушки для тих модулів, які знаходяться нижче за рівнем, але включення яких до тесту ще не відбулося.
- Великий вибух. Всі модулі всіх рівнів збираються разом, а потім тестується. Даний метод економить час, але вимагає ретельного опрацювання тест кейсів.
68
Які можуть виникнути проблеми при вокристанні підходу Великий вибух?
"Великий вибух" - це підхід до розробки програмного забезпечення, який передбачає швидке створення мінімально необхідної функціональності та випуск продукту в короткі терміни. Цей підхід може призвести до наступних проблем:
1. Недостатня якість продукту: у зусиллях надати функціональність користувачам якомога швидше, команда розробки може пропустити деякі важливі тести та перевірки, що може призвести до помилок та неполадок в продукті.
2. Проблеми з масштабованістю: якщо архітектура продукту не була ретельно продумана на етапі розробки, то в подальшому можуть виникнути проблеми з масштабованістю та продуктивністю при збільшенні обсягів даних та навантаження на систему.
3. Необхідність постійного оновлення: якщо продукт був випущений у короткі терміни з мінімальною функціональністю, то можуть виникнути потреби у постійному оновленні та розширенні продукту, що може призвести до збільшення витрат на розробку та підтримку продукту.
4. Проблеми зі сумісністю: якщо підхід "Великий вибух" передбачає випуск продукту на різних платформах та пристроях, то можуть виникнути проблеми зі сумісністю продукту з різними системами та пристроями.
Отже, при використанні підходу "Великий вибух" можуть виникнути проблеми з якістю продукту, масштабованістю, підтримкою та сумісністю.
Великик йобєм роботи
більша кількість багів
більша кількість часу
69
Коли доречно використати підхід великого вибуху?
Такий підхід доречно використати до прототипу, а не фінального продукту, наприклад коли відбувається теднер (хакатон), коли немає часу спочатку тестувати один модуль потмі інший, а потмі взаємодію між ними.
70
Відповідно до якого документу ми вирішуємо що система готова до випуску?
Відповідно до документів:
- Definition of ready
- Definition of done
71
Що таке Alpha, Beta, Gamma тестування?
Alpha-testing- тестування всередині компанії командою розробки
(програмісти, тестувальники, бізнес аналітики).Продукт вже можна періодично показувати зовнішнім користувачам алевін ще сирий,тому основне тестування виконується тестувальником-розробником.
Beta-testing – тестування потенційними користувачами.Виконується позаорганізацією з активним залученням кінцевих користувачів,замовників. Продукт вже можна показувати зовнішнім користуванам, віндосить стабільний але все ще можуть прблеми і для їх виявлення потрібен зворотній звязок від реальних користуваічв.
Gamma-testing - фінальна стадія тестування пред випуском продукту спрямовне на виправлення незначних дефектів знайдених в бета тестуванні. Продукт вже майже готовий, фідбек від реальних користувачів використовується для усунення останніх недоробок.
72
Чим тестування прийомочне відрязняється від системного тестування?
Прийомочне тестування та системне тестування є двома типами тестування програмного забезпечення, які спрямовані на перевірку того, що система відповідає вимогам та працює коректно. Однак, між ними є кілька різниць.
Прийомочне тестування зазвичай виконується кінцевими користувачами або замовниками, щоб перевірити, що програмне забезпечення відповідає їх потребам і очікуванням. Воно фокусується на перевірці здатності системи відповідати бізнес-вимогам, функціональним вимогам та іншим специфікаціям, затвердженим до розробки. Прийомочне тестування може бути виконано вручну або за допомогою автоматизованих скриптів, а також може включати тестування системи в середовищі, подібному до середовища продукції.
Системне тестування, з іншого боку, зазвичай виконується інженерами з якості або тестувальниками, щоб переконатися, що програмне забезпечення відповідає всім вказаним вимогам та працює коректно. Воно фокусується на оцінці системи в цілому, включаючи її інтеграцію з іншими системами, продуктивність та здатність обробляти різні сценарії використання користувача. Системне тестування зазвичай виконується в середовищі тестування, яке симулює середовище продукції, але знаходиться окремо від нього.
Таким чином, приймальне тестування виконується, щоб переконатися, що система відповідає потребам і очікуванням користувача, тоді як тестування системи виконується, щоб переконатися, що система відповідає всім заданим вимогам і функціонує правильно. Приймальне тестування зазвичай виконується кінцевими користувачами або клієнтами, тоді як тестування системи зазвичай виконується інженерами з якості або тестувальниками.
73
Тестування доступності (Accessibility testing)
Тестування доступності – це тип тестування, який виконується, щоб переконатися, що програмний продукт доступні для користувачів з обмеженими можливостями.
Основною мета: виявлення будь-яких проблем або перешкод, які заважають користувачам з обмеженими можливостями отримати доступ і використовувати програмний продукт або веб-сайт.
Перевірка доступності є важливою, оскільки вона допомагає переконатися, що програмний продукт або веб-сайт доступні для всіх користувачів, незалежно від їхніх обмежень або недоліків.
74
Регресійне тестування це?
Регресійне тестування – це тип тестування, який виконується для того, щоб переконатися, що зміни або оновлення системі не створюють нових дефектів або проблем, які можуть вплинути на наявну функціональність.
Регресійне тестування - це повторне виконання набору раніше виконаних тестів на модифікованому програмному продукті, щоб переконатися, що він все ще працює належним чином і що зміни не вплинули негативно на будь-яку існуючу функціональність. Тест кейси можуть охоплювати як функціональні, так і нефункціональні вимоги.
Регресійне тестування є важливим, оскільки воно допомагає переконатися, що програмний продукт або система залишаються стабільними та надійними після внесення змін або оновлень. Це допомагає мінімізувати ризик появи нових дефектів або проблем у програмному продукті чи системі та може допомогти гарантувати, що це не вплине негативно на роботу користувача.
Retesting використовується для:
- перевірки конкретної помилки чи проблеми, на яку був створений [bug report]
- для підтвердження від тестувальника для розробника, що проблема дійсна та її можна відтворити повторно;
- або, навпаки, для підтвердження від розробника, що дефект був виправлений;
- і навіть Retesting використовується для тестування всього модуля або компонента з метою підтвердження роботи очікуваної функціональності.
75
Retesting(Confirmation) це?
Тестування підчас якого переперевіряємо виправлений баг.
Знайшли дефект, зарепортили, девелопер виправив, перетестували.
Коли необхідно проводити Regression testing:
- коли до наявної програми додається нова функція;
- при зміні середовища тестування;
- або коли внутрішній код перенесено на іншу платформу;
- якщо на етапі тестування було виявлено багато критичних помилок;
- основні проблеми з продуктивністю та збої у роботі програми усунуті розробниками;
- додані виправлення, які зачіпають більшу частину функціональності системи;
- інтерфейс програми було змінено для покращення взаємодії з користувачем;
- додане покращення бізнесового характеру, яка впливає на основний фукціонал системи.
76
Різниця між ретестом і регресійним тестуванням?
Підчас час ретестінгу перевіряється виправлений баг, а підчас регресійного тестування перевіряємо чи внесені зміни або виправлені помилки не поламали або не вплинули на інші функціонал.
77
Smoke testing це?
Це перевірка найважливішого функціоналу, не дуже детально, поверхнево.Перевірка по самому головному.(чи логінниться користувач, якщо це про інтернет магазин)
78
Різниця між smoke sanity testing?
Smoke testing- перевірка роботи найбільш важливих, критичних функцій в системі. Результат цього тестування використовується для визначення того, чи досить стабільна збірка, щоб продовжити подальше тестування.
Sanity testing– це дуже коротка поглиблена перевірка певної функціональності, яка проводиться з метою переконатися, що система працює належним чином. Цей вид тестування часто виконується до початку повного циклу регресійного тестування, але після проведення димового тестування.
Sanity тестування, як правило, проводиться, коли виправлена яка-небудь незначна помилка в системі або є невелика зміна у функціональності.
79
Які є тестування по знанню коду?
BLACK BOX(нам невідомо нічого, окрім того що нам треба надати на вході і що отримати на виході)перевірка бізнес вимог
GREY BOX (дозволяє розібратись в причинах помилки) Наприклад, є доступ до
API та бази даних, але нема доступу до коду.
WHITE BOX(тестується код а не вимоги)unit test
80
Позитивне і негативне тестування:
Позитивне тестування – це тестування, в якому вводимо правильні дані, очікуємо хороший результат.
Негативне тестування – це тестування, в якому вводимо невірні дані, очікуємо повідомлення про помилку. Всі негативні випадки протестувати неможливо, але пара ключових тестів - must have.
Спочатку виконуємо позитивне тестування, а потім негативне.
81
Яке буває тетсування по способу виконання?
Automatic Автоматизоване тестування використовується **регресії, в навантажувальному тестуванні(наприклад для імітування великої калькості коритувачів),секюріті тестування(але частково)**
Manualad-hoc або дослідницьке тестування можуть бути виконані тільки вручну
82
Різниця між атоматичним і мануальним тестуванням?
Автоматизація зберігає час, сили та гроші. Одного разу автоматизований тест можна запускати знову і знову, докладаючи мінімум зусиль.
Вручну можна протестувати практично будь-який додаток, в той час як автоматизувати варто тільки стабільні системи. Автоматизоване тестування використовується головним чином для регресії. Крім того, деякі види тестування, наприклад, ad-hoc або дослідницьке тестування можуть бути виконані тільки вручну.
Мануальне тестування може бути повторюваним та нудним. У той же час, автоматизація може допомогти цього уникнути – за вас все зробить комп’ютер.
83
User stories
User story - це "неформальні вимоги", які допомагають зрозуміти
потреби користувача і складаються з 3х частин:
Як (роль користувача), я (хочу щось отримати), для того
щоб (причина)
**As a ...I want to..so that**…
(Як Адміністратор,я хочу додавати людей в бан, щоб
уникнути образ та спаму.)
84
Acceptence creteria
Вимоги які являються найголовнішими вимогами, без них релізу небуде
**Given…When…Then…(мова Gherkin в програмі Cucumber)**
**Given** Вік реєстравції **When** коли користувачц менше 18 років**Then** реєстрація завершується повідомленням про помилку
85
Traceability matrix
Таблиця яка співставляє два базові документи
таблиця покриття тестами
1. Перевірити чи покривіавються вимоги тест кейсами
2. Перевірити вимоги на противоріччя
3. Перевірити що баги покриті тест кейсами
86
Типи Traceability matrix
1. Froward traceability
2. Backward or reverse traceability
3. Bi-directional traceability (Froward +Backward)
87
Що таке ризики?
Ризик (risk):
– фактор, який може призвести до негативних наслідків в майбутньому; як правило, виражається через вірогідність виникнення таких наслідків та їх впливу на систему.
– те, що ще не відбулось, і може взагалі не відбутися; потенційна проблема.
88
Яка з критерій якості найважливіша? Правильна послідовність
Функціональна придатність (Functional)
Ефективність виконання (Performance)
Сумісність (Compatibility)
Легке використання( Usability)
Надійність(Reliability)
Безпека (Security)
Можливість підтримки (Maintainability)
Портативність (Portability)
89
Що в собі описують не функціональні вимоги?
Те як має працювати ПЗ, як швидко завантажуватись сторінка, як має виглядати,
90
Що таке тестові артефакти?
Це такі документи які стосуютьсся тестування:
1. Software Specification
2. Test Plan
3. Сhecklist
4. Test Case
5. Bug Report
91
Що таке тест кейс? З чого складається тест кейс?
Тест кейс -це документ в якому описується послідовність кроків, для перевірки чи функціонал працює як задумано.
Основні атрибути Test Case:
1. ID (номер)
2. Name (ім’я)
3. Preconditions (умови і параметри)
4. Steps (кроки до відтворення)
5. Expected result (очікуваний результат)
6. Postconditions (постумови)
92
Як обирається пріорітет для тесткейсу?
Пріоритет тест-кейсу може корелювати з:
важливістю вимоги, сценарію користувача або функції, з якими пов'язаний тест-кейс;
потенційною важливістю дефекту, на пошук якого спрямований тест-кейс;
ступенем ризику, пов'язаного з тест-кейсом, що перевіряється вимогою, сценарієм або функцією.
93
В мене є дебітова карта якою оплачуюю покупки, якщо оплачую покупку від 1000 і вище має вводитись пінкод,як буду тестувати?
1. проведу тестування на 1001 грн чи буде праццюватти введення пін коду
2. 1000
3. 999
4. поділю на класи, протестую діапазон від 0 до 1000
5. від 1000 до 1500 (візьму якесь скреднє значення з цих класів і простестую)
93
попарне тестування це?як таблиця виглядає?
Це методика тестування з допомогою якої можна прибрати надлишкові перевірки, забезпечити гарне покриття тестами і виявитти більшу кільбкістть багів з меншою кількісю тестів
94
Який інстумент можна використати якщо є дуже багато параметрів?
попарне тестуваня (Pairwise testing)
94
Що таке естемація?
Естімація завдань визначає, скільки зусиль, ресурсів та часу знадобиться для створення конкретної системи чи продукту.
Скільки зусиль потрібно витратити на завдання? В умовах невизначеності та складності відповідь краще дати не в годинах. Набагато зручніші відносні одиниці, з яких найвідоміші — сторі поінти (Story Points).
Естімейт залежить:
1. Від складності завдання
2. Кількості документації доступної для виконання завдання
3. Збору інформації, необхідноої для виконання
4. Кі-сть спілкування для виконання завдання
5. Блокерів
В чому можна оцінити завдання:
1. В часі (хвилинах, годинах, днях)
2. Сторі пойнтах (числа фібаначі) 1,2,3,5,8,13,21….
3. Розмір футболок
Способи оцінювання:
1. Порівняння з попередніми завданнями (з попереднім досвідом)
2. Стороння експертиза(спитаи наприклад ліда)
3. Bottom-up (розбиваємо на дрібні, оцінюємо знизу)
4. Top down
5. PERT (program evaluation and review technique)
6. Scrum poker
94
Техніки естімацій(як будете оцінювати задачі)?
спочатку пошукаю дублікат цього багу
якщо немає то заводжу багу
95
Підходи вимірювання ефективності тестів
Є 2 підходи вимірювання ефектиіності тестів:
1. Code coverage =(code covered with tests/code total*100%)
2. Requirements coverage = (requirements covered with tests/requirements total)*100%
96
Методології які є?
Waterfall модель (вона ж Каскадна)
"Incremental Model" (інкрементна модель)
"Iterative Model" (ітеративна або ітераційна модель)
"Agile Model" (гнучка методологія розробки)
"Spiral Model" (спіральна модель)
"V-Model" (V-подібна модель)
97
Які є каскадні методолігії?
водопадна, і v подібна моделі
98
V подібна модель (що відповідає за верифікацію і за валідацію?)
За верифікацію відповідають самі етапи розробки.
За валідацію відповідає тестування кожного етапу.
99
Основіні 4 цінності Agile?
Agile - це гнучкий ітеративний підхід до розробки програмного забезпечення, який базується на чотирьох основних принципах Agile Manifesto:
1. Люди та взаємодія важливіші за процеси та інструменти
2. Працездатність ПЗ важливіша за вичерпну документацію
3. Співпраця з замовником важливіша за умови контракту
4. Готовність до змін важливіше за дотримання плану
100
Різниця між Scrum i Canban?
Scrum і Kanban - це два різних підходи до розробки програмного забезпечення.
Scrum - це ітеративний інкрементальний фреймворк для розробки програмного забезпечення, в якому розробка відбувається через набір ітерацій, відомих як Спринти. Кожен Спринт - це фіксований період (зазвичай від 2 до 4 тижнів), під час якого команда розробляє ітерацію продукту. Scrum використовує ролі, які включають Product Owner, Scrum Master та Development Team, а також різні збори, включаючи Daily Scrum, Sprint Planning, Sprint Review і Sprint Retrospective.
У Kanban замість ітерацій використовується візуальна дошка Kanban, на якій завдання відображаються як картки. Кожна картка містить інформацію про завдання, стан завдання та інші важливі деталі. Канбан також використовує обмеження робочого процесу, щоб забезпечити потік роботи, що допомагає уникнути перевантаження і підвищити продуктивність.
Отже, різниця між Scrum і Kanban полягає у тому, що Scrum використовує ітераційні спринти, ролі та збори, тоді як Kanban використовує візуальну дошку, обмеження робочого процесу та зосередженість на потоці роботи. Обидва підходи можуть бути ефективними для розробки програмного забезпечення, і вибір залежить від конкретних потреб проекту і команди розробки.
101
Що таке ітерація?
Часовий проміжок за який має бути зроблена робота
102
В чому гнучкість скраму?
швидкий зворотній звязок, щоб покращити продукт і культуру розробки
Можливість доступу до прегляду продукту на різних еттапах розробки
можливість повертатиссь до попередніх етапів
103
Ролі в скрам
Product Owner
Product Owner фокусується на тому, щоб команда розробників забезпечувала максимальну цінність для бізнесу. Вони розуміють мінливі потреби кінцевих користувачів та клієнтів та розставляють пріоритети.
Успішні PO роблять таке:
- Надають команді чіткі вказівки, які функції слід впроваджувати далі.
- Подолають розрив між тим, що потрібно компанії та тим, що розуміє команда.
- Вирішують, коли та як часто мають відбуватися релізи.
Scrum Master
Scrum Master - це лідер у своїй команді. Він відповідає за ефективність роботи команди Scrum. Scrum Master також наглядає за дотриманням командою дедлайнів, якістю взаємодії між всіма її членами, можливим виникненням конфліктів всередині команд та їх невідкладним попередженням тощо.
Однак Scrum Master не є суворим контролером чи авторитарним лідером. Його діяльність, скоріше, менторська, ніж лідерська. Він має переконати команду, надихнути, підштовхнути до того, аби команда побачила нові ідеї там, де раніше не бачила, і змогла їх застосувати в роботі.
Team
Це команда яка працює над продуктом:
Developer
QA
Designer
104
Які є івенти в скрамі(ритуали)?
1. Sprint planning
Зустріч проводиться на початку спринту, на якій команди визначають, що можна досягти в спринті та як ця робота буде досягнута. Відбувається обговорення завдань які поставлені на найближчий спринт.
Учасники: команда розробників, scrum master, product owner
2. Daily stand-up
Коротка 15-хвилинна щоденна зустріч для обговорення прогресу та визначення блокерів в роботі.
- Що я закінчив учора?
- Над чим я сьогодні буду працювати?
- Я чимось заблокований?
Учасники: команда розробників, scrum master, product owner
3. Sprint review
На цій зустрічі відбувається огляд спринту – це час для демонстрації роботи команди. Вони можуть проводитися у невимушеному форматі, як-от «демо-п’ятниці», або у більш офіційній структурі зустрічі зі скраму. Це час для команди, щоб відсвяткувати свої досягнення, продемонструвати роботу, виконану в рамках ітерації, і отримати негайний відгук від зацікавлених сторін проекту. Відбувається наприкінці спринту.
4. Sprint retrospective
Це зустріч, на якій обговорюється що вдалося під час спринту та що можна покращити. Обговорюються плани для покращення способу роботи команди.
105
Артефакти скрам
Команди Scrum використовують інструменти, які називаються артефактами Scrum, для вирішення проблем та управління проектами. Артефакти Scrum надають членам команди та заінтересованим сторонам важливу інформацію про планування та завдання. Існує три основні артефакти:
- Product Backlog
Продукт Backlog – є списком вимог, історій, функціональності, які впорядковані за рівнем важливості.
- Sprint Backlog
Це список завдань взятих з Product Backlog і розбитий на менші підзавдання на час спринту.Беруться завдання і їх потрібно виконати підчас спринту.
- Increment
Це те що ми отримуємо по завершенню спринту, наприклад якась нова фіча, щось що буде цінним і відчутним для кристувача.
106
Що таке інтернет і як він працює?
Інтернет— це глобальна мережа комп’ютерів, з’єднаних один з одним, які спілкуються за допомогою стандартизованого набору протоколів.
Інтернет працює шляхом з’єднання пристроїв і комп’ютерних систем за допомогою стандартизованих протоколів, таких як IP і TCP.
Packet (Пакет): невелика одиниця даних, яка передається через Інтернет.
Router (Маршрутизатор): пристрій, який спрямовує пакети даних між різними мережами.
IP-adress:унікальний ідентифікатор, призначений кожному пристрою в мережі, який використовується для маршрутизації даних до правильного пункту призначення.
Domain Name (Доменне ім’я): зрозуміле ім’я, яке використовується для ідентифікації веб-сайту, наприклад google.com.
DNS: система доменних імен відповідає за перетворення доменних імен в IP-адреси.
HTTP: протокол передачі гіпертексту використовується для передачі даних між клієнтом (наприклад, веб-браузером) і сервером (наприклад, веб-сайтом).
HTTPS: зашифрована версія HTTP, яка використовується для забезпечення безпечного зв’язку між клієнтом і сервером.
SSL/TLS: протоколи Secure Sockets Layer і Transport Layer Security використовуються для забезпечення безпечного зв’язку через Інтернет.
ISP (Internet Service Provider) провайдер високого рівня, від таких провайдерів отимують досступ до інтернету провайдери (київстар,нетіа) а від них клієнт.
107
Інтернет протоколи
Протоколи відіграють важливу роль у забезпеченні зв’язку та обміну даними через Інтернет, дозволяючи пристроям і системам від різних виробників і постачальників безперебійно спілкуватися між собою.
(IP) Internet Protocol (відповідає за маршрутизацію пакетів до правильного місця призначення)
(TCP) Transmission Control Protocol (протокол керування передачею гарантує, що пакети передаються надійно та в правильному порядку)
(RTP) Real-time Transport Protocol (використовується при передачі аудіо і відеоданих через IP мережі в режимі реального часу)
(DNS) Domain Name System систему доменних імен
(HTTP) Hypertext Transfer Protocol протокол передачі гіпертексту
(SSL/TLS) Sockets Layer/Transport Layer Security безпечний Протокол
(UDP) User Datagram Protocol протокол дейтаграм користувача
108
Що таке HTTP?
HTTP — це протокол, в якому описано правила передачі даних в інтернеті.Він допомагає браузеру завантажувати ссторінки а серверу оттримати інформаццію яку клієнт ввів наи сайті.
109
Що API (Application Programming Interface)?
API (Application Programming Interface – програмний інтерфейс програми, спеціальний протокол для взаємодії комп'ютерних програм, який дозволяє використовувати функції однієї програми всередині іншої.
API повсюдно використовують для взаємодії програм та програм з операційними системами або інтернет-сайтами. Якби Application Programming Interface відключилися, майже всі сервіси в інтернеті і більшість комп'ютерних програм перестали б працювати.
За допомогою API програмісти можуть використовувати можливості різних програм, не замислюючись про те, як ці програми обробляють запити і який код.
110
Що таке HTTPS?
HTTPS — це більш безпечна версія HTTP, яка шифрує дані, що передаються між клієнтом і сервером, за допомогою шифрування SSL/TLS (Secure Sockets Layer/Transport Layer Security). Це забезпечує додатковий рівень безпеки, допомагаючи захистити конфіденційну інформацію, таку як облікові дані для входу, платіжну інформацію та інші особисті дані.
Коли вводимо щось на сайті який праццює на HTTPS, перед надсиланням на сервер інформація шифрується, розшифрувати і прочитати її можна тільки за допомогою ключа який є тільки на ссервері, таке шифрування називається криптографічним.
Під час використання SSL/TLS для захисту Інтернет-зв’язку слід розуміти кілька ключових понять:
Certificates (Сертифікати): сертифікати SSL/TLS використовуються для встановлення довіри між клієнтом і сервером. Вони містять інформацію про особу сервера та підписані довіреною третьою стороною (сертифікаційним центром) для перевірки їх автентичності.
Handshake (Рукостискання): під час процесу рукостискання SSL/TLS клієнт і сервер обмінюються інформацією для узгодження алгоритму шифрування та інших параметрів безпечного з’єднання.
Encryption (Шифрування):після встановлення безпечного з’єднання дані шифруються за допомогою узгодженого алгоритму та можуть безпечно передаватись між клієнтом і сервером.
111
URI ,URL ,URN
URI (Uniform Resource Identifier) ресурсний ідентифікатор
URL (Uniform Resource Locator) описує адрес знаходження в мережі
URN (Uniform Resource Name) описує імя ресурссу
112
Маска підмережі і шдюз по замовчуванню
Компютери обєднуються в локальні мережі. В локальній мережі компютери на пряму виходять тільки один на одного.Локальні мережі зєднуються один з одним через шлюзи (роутери,маршрутезатори).
Маска підмережі потібна для визначення чи належить компютер-отримувач до цієї ж локальної мережі чи ні. Якщо належить то пакет передаєтьсся йому на пряму, в іншому випадку пакет відправляється на шлюз по замовчуванню, який далі по відомим йому маршрутам передає пакети в іншу мережу.
113
TCP/IP модель
TCP/IP - набір мережевих протоколів, має 4 рівні
1. Мережевий інтерфейс, тобто. у цьому випадку передаються якісь
фізичні імпульси, тобто. сюди можна зарахувати, наприклад, оптоволокно
2. IP Protocol - це протокол мережевого рівня. Задача його рівня, доставка пакетів від відправника до отримувача.Крім власних данних пакети цього рівня мають IPадреси відправника і отримувача.Номери портів на цьому рівні не використовуються, також не цьому рівні невідомо чи був доставлений пакет.
3. TCP і UDP- протокли транспортного рівня. Він знаходиться над мережевим. На ньому до пакету добавляються порти, відправника і отримувача.
TCP - протокол з становленим зєднанням і гарантованою доставкою пакету. Тобто, спочатку відбувається обмін пакетами для встановлення зєднання (типу рукостискання) далі по цьому зєднанню туди і назад посилаються пакети(тобто відбувається спілкування), з перевіркою чи дійшов пакет до отримувача, і якщо пакет не дійшов, то його посилають повторно.(викорисстовується для переписски між користувачами, банківські операції,відправка фото)
UDP - це пакет без вставновлення зєднання і без перевірки доставки пакетів.(використовується для передачі потокового відео, або ссспілкування в голоссовому форматі : зідзвон в скайп, стрім на твіччі)
4. Над транспортним рівнем знаходться прикладний рівень на якому працюють протоколи HTTP, FTP…
Наприклад, HTTP i FTP працюють через надійний протокол TCP, а DNS server працює через UDP.
114
Що таке Cache та Cookie?
Кеш (Cache) – це копії завантажених веб-сторінок. Якщо повторно заходити на сайт, його завантаження відбувається не з інтернету, а з жорсткого диска, де зберігаються тимчасові файли. Це пришвидшує роботу браузера. Веб-сторінки можуть відображатися некоректно через те, що в них були внесені зміни, а браузер продовжує використовувати застарілі дані з кешу. Щоб забезпечити коректність відображення веб-сторінок перед проведенням тестування, потрібно обов'язково очищати кеш браузера.
Cookie – тимчасові файли, що зберігаються на жорсткому диску комп'ютера користувача. Куки зберігають налаштування сайтів, які відвідував користувач. Найпоширеніша функція – збереження паролів, що дозволяє не вводити комбінацію логін + пароль щоразу при вході на сайт.
115
Які існують основні HTTP методи передачі данних?
1️⃣ Метод GET: Отримує дані з сервера.
2️⃣ Метод POST: Надсилає дані на сервер для створення чогось нового.
3️⃣ Метод PUT: Змінює щось, що вже є на сервері.
4️⃣ Метод PATCH: Змінює частину чогось на сервері.
5️⃣ Метод DELETE: Видаляє щось з сервера.
6️⃣ Метод HEAD: Отримує інформацію про щось на сервері.
7️⃣ Метод OPTIONS: Розповідає, як ви можете взаємодіяти з чимось на сервері.
8️⃣ Метод TRACE: Показує шлях зв'язку між вами і сервером.
9️⃣ Метод CONNECT: Створює спеціальний тип з'єднання з сервером.
116
Що таке CRUD? Який метод відповідає за яку функцію?
CRUD — 4 основні діїї які можна робити з данними в таблиці «створення, читання, оновлення і вилучення».
POST (HTTP метод)
Read- GET (HTTP метод)
Update - PUT (HTTP метод)
Delete - DELETE (HTTP метод)
117
Основні відмінності GET і POST?
118
Чи можливо методом GET передавати данні?
через параметри які будуть вказуватись в URL
119
Відмінності POST і PUT?
120
Статус коди в API? (Які існують коди відповідей сервера?)
100 - Інформаційні
200 - Успіх
300 -Перенаправлення
400 - Помилка на рівні клієнта (клієнт неправильно звертається до сервісу)
(404 page not found )
500 - Помилк ана рівні сервера
121
Архітектура клієнт -сервер
122
Які бувають за рівнями архітектура клієнт-сервер
Дворівнева (Клієнт і сервер)
Трирівнева (Клієнт, сервер, база данних)
Багаторівнева (Клієнт, багато серверів, кожен робить свою частину роботи, запити обробляються одночасно)
123
Чому клієнт на пряму неможе звертатись до бази данних?
Бо різнi протоколи.Сервер і система керування баз данних працюють по іншому,використовують мову SQL
124
HTML
Мова HTML (HyperText Markup Language) - це мова гіпертекстової розмітки тексту. Вона потрібна, щоб розміщувати на веб-сторінці елементи: текст, зображення, таблиці та відео.
HTML складається з:
HTML-теги – це спеціальні команди для браузера. Вони кажуть,
наприклад, що слід вважати заголовком сторінки, а що абзацом.
()
Атрибути - спеціальні команди, які розширюють дію тега. Атрибути
розміщуються всередині тега, в такому форматі:
src=(атрибут тегу ![]()
)
значеня атрибуту
вміст елемента
125
CSS
Cascading Style Sheets «Каскадні Таблиці Стилів».
Мова CSS – це мова розмітки, яка використовується для візуального оформлення веб-сайтів, вона розширює можливості HTML.
CSS дозволяє швидко змінити візуальне оформлення сайту, не вдаючись до більш складних мов програмування. З його допомогою можна змінити кольори, шрифти, фон.
На відміну від HTML, який служить для визначення структури та семантики вмісту сайту, CSS відповідає за його зовнішній вигляд та відображення.
126
База даних (database)
База даних (database) - це впорядкований набір структурованої інформації або даних.
127
Система управління базами даних (Database Management System)
Система управління базами даних (Database Management System) – програма в якій ми працюємо з базою данних.
MySQL, MsSQL, PostgreSQL, Oracle
128
Реляційна БД
Реляційна БД – це набір даних звязаних між собою. Реляційна база даних складаєтья з таблицць які мають звяски між собою.
Таблиця складається з впорядкованого набору рядків і товбчиків. Перетином цього рядка і стовбчика є клітинка.
Стовбчик- поле
Рядок - запис
NULL - пороржній запис
129
Для чого потрібні бази данних
- За допомогою БД можна швидко знайти потрібну інформаціію
- Велика кількіссть людей може одночасно оновлювати данні
- Точність данних (БД не дасть ввести числові значення в поле ім’я)
- Високий ступінь захисту
- БД просто керувати
130
Ключ СУБД /Primary key /Foreign key це?
Ключ СУБД – це атрибут чи набір атрибутів, що допомагає ідентифікувати рядок у таблиці.
Primary key – поле, кожен елемент якого однозначно визначає запис таблиці. Використовується для визначення об'єкта.
Foreign key – це стовпець чи поєднання стовпців, яке застосовується для примусового встановлення зв'язок між даними однієї БД
131
Команди, що працюють зі структурою БД:
CREATE – створити. Наприклад: CREATE TABLE – створити таблицю або CREATE USER – створити користувача.
ALTER – модифікувати. Цей запит використовується при внесенні змін до самої БД або її частини.
DROP – Видалити. Запит відноситься до БД та її частин.
132
Команди, що працюють з даними:
SELECT *FROM – вибір даних.
INSERT INTO – вставлення нових даних.
UPDATE SET WHERE– оновлення даних.
ALTER TABLE - редагувати таблицю
ADD/DROP COLOMN/TABLE - додати/видалити стовчик/таблицю
DELETE – видалення даних.
GROUP BY групувати за чимось (якщо вказуємо уточнення то використовуємо **HAVING** замість WHERE)
MERGE – злиття даних.
AND (означає і)
OR (або)
<>(не дорівнює)
AS (використовується длля перейменовування колонки)
ORDER BY** (відсортувати по якомусь признаку,в цьому випадку по імені клієнта (**DESC** (сортування в зровотньому порядку))
LIMIT 5(обмежити вивід данних наприклад першими 5 корисстувачами)
OFFSSET 2(це означає що пенрших 2 пропускаємо і починаємо читати з наступного піля них)
133
Яка найпростіша структура запиту?
SELECT* FROM
134
Які бувають SELECT запити:
SELECT* FROM hotelsDB.Clients (показати табличку Clients з бази данних hotelsDB)
SELECT clientName, clientNNumber FROM hotelsbd.clients;
SELECT clientName, clientNNumber FROM hotelsbd.clients WHERE clientName = 'Nastia’
SELECT clientName, clientNNumber FROM hotelsbd.clients WHERE clientName LIKE 'N%’ (починається на N)
SELECT clientName, clientNNumber FROM hotelsbd.clients WHERE clientName LIKE '%a’ (закінчується на ‘а’)
SELECT clientName, clientNNumber FROM hotelsbd.clients WHERE clientName LIKE '%as%’(показати ‘as’ байдуже сскільки ссимволів на початку слов а і в кінці)
135
Агрегатні функції в MySQL
SELECT COUNT(*) FROM hotelsbd.cities (показує кількість всього записів в таблиці cities)
SELECT COUNT(clientName) FROM hotelsbd.clients WHERE clientName LIKE 'N%’ (показує скільки є записів які починаються на ‘N’)
SELECT MIN(creationDate) FROM [hotelsbd.hotels](http://hotelsbd.hotels) (показує найнижче значення( в цьому випадку найстаріший готель))
SELECT MAX(creationDate) FROM [hotelsbd.hotels](http://hotelsbd.hotels) (показує найбільше значення, в цьому випадку найновіний готель)
SELECT AVG(clientAge) FROM hotelsbd.clients (рахує середнє арифметичне, в цьому випадку середній вік клієнтів)
SELECT SUM(clientAge) FROM hotelsbd.clients (рахує суму всіх значень які вкажуться в душках, в цьому випадку сума всіх років клієнтів)
136
Типи данних в SQL
Iteger/int:
Ціле число (без крапки) 21,4,0,2048
Varchar(20):
Будь який текст (Надiя, Shehda)
Date:
Date - Дата що скаладєтьсся з дати місяця і року
Decimal:
Числа з плаваючою крапкою
137
Обмеження в SQL
**Auto increment**- збільшує число на одиницю
**Not null** - неможливо залишити пустим
**Unique** - неможна повторювати
138
Primary Key & Foreign Key
Primary Key (первинний ключ) штучно створений ідентифікатор(номер) який не може повторуватись, він унікальний.
Foreign Key (зовнішній ключ який посилається на елемент іншої таблиці) можемо зєднувати між ссобою таблиці щоб н6е сстворювати одну веллику таблицю.
foreign key (cityID це назва стовбчику який має бути спільним для двох таблиць, ) references (назва ішної таблички в якій є тойже стовбик) Cities (cityID)
139
Типи звясків в базах данних:
One-to-one ( наприклад: в кожної людини є власний номер паспорту, і закордонного і українського, зробити треба 2 колонки і в кожній де є сповбичк номер паспорта зробити unique, тобто персональний номер людини буде primary key і unique , а номери паспортів будуть просто юнік, тоді буде звязок 1:1)
One-to-many (наприклад: одна людина і багато номерів телефону в неї)
Many-to-many (наприклад: в одного сситудента є багато викладачв, і в одного викладача є багато студентів)
140
JOIN(джойни)
INNER JOIN (дає в результаті тільки ті рядки які є спільними в двох таблицях)
LEFT JOIN (дає результат всі рядки з лівої таблиці і спільні рядки з проавої таблиці)
RIGHT JOIN (дає результат всссі рядки з правої таблиці і спільні рядки з лівої таблиці)
FULL JOIN( дає всі рядки з двох таблиць)
141
DevTools (як відкрити ?)
