Test Engineer “checklist” — практики розвитку.

[Про автора: Сергій Горошко 4+ років досвіду в IT, а також 4+ років у Hardware Engineering. Працює у сфері e-Healthcare, e-Commerce. Живе за принципом “back to community”.]

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

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

📌00-software-development-process

Якщо ми говоримо про розробку програмного забезпечення або роботу на підрозділ який займається розробкою (ПЗ) то “процес розробки програмного забезпечення” має бути один із перших у вашому “checklist”.

Перш ніж почати працювати потрібно розуміти за якими правила працює команда, яким процесам вона слідує в кожній ітерації роботи, та задати питання, яка галузь знань чи стандарт закріплений цим процесом (e.g. ISO 9001:2000, ITIL, SWEBOK).

Програма — алгоритм який розв’язує поставлену задачу за правилами мови програмування. Передбачувано і послідовно, чи не так? Так само процес організації має свої “алгоритми”, найбільш розповсюджений приклад - це модель водоспаду, де процеси побудовані один за одним.

📌01-software-development-life-cycle

1. Аналіз вимог
2. Проектування
3. Розробка (програмування)
4. Верифікація (тестування)
5. Випуск та подальший супровід

Або ще SDLC Models. Вибір процесу базується на відповідній методології. Інколи процеси можуть бути змінені відповідно до специфіки проєкту.

Наразі окреслюють 6 базових моделей:

1. Гнучка розробка програмного забезпечення, Agile модель (Agile software development)
2. Модель неперервна інтеграція , Continuous integration модель, CI model (DevOps модель)
3. Інкрементна модель та Ітераційна модель
4. Швидка розробка застосунків, RAD модель (rapid application development)
5. Спіральна модель
6. Водоспадна модель

Також слід виділити інші high-level методології яких теж не мало (e.g. V-Model, Модель Великого вибух, etc.). Cлід знати що кожна модель може нести за собою переваги та недоліки, які будуть помітні в ході роботи.

Плюси та мінуси Agile

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

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

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

Один із важливих відмінностей Agile — отримання продукту, який можна використовувати якомога раніше — (MVP) Minimum Viable Product, звідси можна швидко роботи оцінку продукту на поточному рівні та потенційно відслідковувати витрати і приймати рішення про подальший його розвиток.

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

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

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

📌02-english (draft)

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

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

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

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

Четвертий крок. Постійно вдосконалюйте рівень своєї англійської використовуючи всі можливі засоби. Повторюйте граматику самостійно.

📌03-quality-assurance-engineer

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

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

Цілі тестування

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

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

• Функціональне тестування — тестування, основане на аналізі специфікацій функціональності компонента або системи (functional testing, GUI testing, security and access control testing, interoperability testing)
• Нефункціональне тестування — тестування атрибутів компонента або системи, які не відносяться до функціональності, тобто надійність, ефективність, практичність, супроводження і підтримка (Performance and Load Testing, Stress Testing, Stability / Reliability Testing, Volume Testing, Installation testing, Usability Testing, Failover and Recovery Testing, Configuration Testing)
• Тестування структури — тестування, основана не аналізі внутрішньої структури компонента або системи (White box testing або Glass box testing)
• Тестування змін — тестування, яке використовується підтвердження того що система працює після вирішення проблеми (Smoke testing, regression testing, re-testing, sanity testing, build verification )

Атрибути характеристик якості

• Functionality (Функціональні можливості)
• Reliability (Надійність)
• Usability (Практичність)
• Efficiencies (Ефективність)
• Maintainability (подальша підтримка)
• Portability (Мобільність)

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

Boundary Value Analysis (Аналіз граничного значення) — тестування з використанням крайніх граничних значень класів еквівалентності, прийнятих як тестовий вхід. Для прикладу це можуть бути мінусові значення, значення які використовують спеціальні символи, значення які більші за максимально допустимий діапазон.

Найпростіший алгоритм використання техніки:

• Визначити класи еквівалетності
• Визначити граничні значення
• Зрозуміти до якого класу буде відноситися кожна границя
• Провести перевірки значень до границі, на границі, відразу після границі

Класичний приклад: Вартість товару враховуючи оптову роздрібну ціну.

• від 1 до 9= 5$
• від 10 до 19 = 3$
• від 20 до 100 = 1$

Аналіз граничних значень в таку випадку буде включати: (-1, 0, 1) (9, 10, 11) (19, 20, 21) (99, 100, 101)

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

Найпростіший алгоритм використання техніки:

• Визначити класи еквівалетності
• Вибрати одне значення з кожного класу

Класичний приклад: поел з діапазоном допустимих значень від 1 до 10. Виходячи з того що всі числа від 1 до 10 можуть впливати на поле однаково то їх будемо вважати еквівалетними. З іншого боку всі недопустимі значення повинні однаково впливати на поле (систему). Таким чином маємо вже декілька еквівалетних класів. Допустимі і недопустимі значення. Мінімальна кількість тестів в такому випадку буде дорівнювати п'яти.

1. Допустимі значення
2. від мінус нескінченності до 0 (набір від'ємних чисел)
3. від 11 до плюс нескінченності (набір додатніх чисел)
4. Спеціальні символи
5. Літери

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

State Transition Testing (Перевірка станів і переходів) — це техніка тестування чорного ящика, в якій зміни, внесені в умови введення, спричиняють зміни стану або зміни вихідних даних у програмі, що тестується Application under Test(AUT). Тестування переходу станів допомагає аналізувати поведінку програми для різних умов введення. Тестери можуть надавати позитивні та негативні вхідні тестові значення та записувати поведінку системи.

Use Case Testing (Сценарії тестування) — це техніка тестування програмного забезпечення, яка допомагає визначити тестові випадки, які охоплюють всю систему на основі транзакції за транзакцією від початку до кінця. Тестові випадки — це взаємодія між користувачами та програмним додатком. Use case testing допомагає виявити прогалини в програмному додатку, які можна не виявити шляхом тестування окремих програмних компонентів.

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

Cause/Effect graph (Графік причинно-наслідкового впливу) — техніка тестування, яка відображає вхідні дані (причину) і відповіді системи (наслідок) у комбінації. Цей метод використовує різні оператори, котрі відображають взаємозв’язки між AND, OR, NOT etc., а умови привидуть до виводу.

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

Pairwise Testing (Метод парного тестування) —це техніка тестування чорного ящика, яка перевіряє один або кілька параметрів у комбінації.

Software Testing Life Cycle

З самого пачатку слід виділити і прояснити що собою являє STLC (Software Testing Life Cycle) процес для кожного інженера (не плутати з SDLC хоч вони можуть здаватися схожими)

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

1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure

Варто проговорити, що кожна сходинка визначає свої критерії входу та критерії виходу в ході активностей SDLC процесі.

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

ETVX — Entry, Task, Verification/Validation and Exit

Verification of the output to documented specification and Validation of output to perceived requirement — один із важливіших єтапів. Той момент коли всі мають бути “на одній хвилі”.

Verification — доведене об’єктивними результатами дослідження підтвердження того, що конкретні вимоги були виконані (Are we building the product right?).

Validation — доведене об'єктивними результатами дослідження підтвердження того, що вимоги призначені для конкретного використання або застосування було виконано (Are we building the right product?). What Is It, Why Does It Matter, and How Should It Be Done?

Тестові артефакти — це набір документів, які відносяться до тестування в ході STLC.

• Test Strategy — високорівневий опис рівнів тестування, які повинні бути виконані, а також тестування, яке входить в ці рівні, для організації чи програми з одного або більше проектів. Раджу детальніше розібратися з базовими типами, які в собі включають тестові стратегії в ISTQB CTFL Syllabus.
• Test Plan — документ який описує цілі, підходи, ресурси і графік запланованих тестових активностей. Він визначає об’єкти тестування, властивості для тестування, завдання, степінь незалежності кожного тестувальника, тестове середовище, методи проектування тестів, критерії входу та критерії виходу і причини їх вибора, описує ризики, які потрібно спланувати на випадок надзвичайних обставин. Відповідно до стандарту IEEE 829, наступні розділи присвячені створенню тест плану:

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

1. Test plan identifier — ідентифікує проект і може містити інформацію про версію. У деяких випадках компанії можуть дотримуватися конвенції щодо ідентифікатора плану тестування, містить інформацію про тип плану тестування. Існують наступні типи планів тестування: Master Test Plan — єдиний план високого рівня для проекту або продукту, який поєднує всі інші плани тестування. Testing Level Specific Test Plans — план тестування може бути створений для кожного рівня тестування, тобто unit level, integration level, system level та acceptance level. Testing Type Specific Test Plans — слідубчи по аналогії, тест план для основних типів тестування, таких як Performance Testing та Security Testing.
2. Introduction — короткий зміст, який встановлює мету, обсяг, цілі та завдання, також містить ресурси та бюджетні обмеження, визначає будь-які обмеження.
3. Test items — список артефактів, які будуть перевірені. Це може бути один або кілька модулів проекту/продукту разом з їхньою версією.
4. Features to be tested — детально перераховані всі features та functionalities, які потрібно перевірити. Повинен містити посилання на документи зі специфікаціями вимог, які містять детальну інформацію про характеристики, що підлягають тестуванню.
5. Features not to be tested — вказуються features та functionalities, які не підлягають тестуванню. Розділ повинен містити причини, чому ці features та functionalities не будуть перевірені.
6. Approach — розділ де визначено підхід до тестування, містить детальну інформацію про те, як буде проводитися тестування, джерела тестових даних, вхідні та вихідні дані, методи тестування та пріоритети. Цей підхід визначатиме вказівки щодо аналізу вимог, розроблятиме сценарії, визначатиме критерії прийняття, побудовує та виконує тестові випадки.
7. Item pass/fail criteria — описано критерії оцінки результатів тесту, описані критерії для кожної функціональності, яку потрібно перевірити.
8. Suspension criteria and resumption requirements — опис критерії, які можуть призвести до призупинення діяльності з тестування, а згодом і вимоги для відновлення процесу тестування.
9. Test deliverables — це документи, які буде надано групою тестування в кінці процесу тестування. Це може включати тестові приклади, зразки даних, звіт про тестування, журнал проблем (logs).
10. Testing tasks — описує залежності між будь-якими завданнями, необхідними ресурсами та estimate. Можуть включати: test scenarios, test cases, test scripts, bug reporting, issue log.
11. Environmental needs — включає в себе апаратне забезпечення, програмне забезпечення або будь-які інші вимоги до тестування. Розділ визначає, яке тестове обладнання вже є, а що необхідно придбати.
12. Responsibilities — ролі та обов’язки які розподіляються на команду тестування
13. Staffing and training needs — потреби в навчанні персоналу для успішного проведення запланованих заходів тестування.
14. Schedule — призначення дат для тестування. Цей графік має узгоджуватися з графіком розробки, щоб створити реалістичний план тестування.
15. Risks and contingencies — дуже важливо визначити ризики, ймовірність і вплив ризиків. Тест план повинен містити методи пом’якшення виявлених ризиків, також мають бути включені непередбачені обставини.
16. Approvals — підписи схвалення від зацікавлених сторін (stakeholders)

• Test Scenario — документ, описуючий послідовність дій при виконанні теста.
• Test Case — документ, описуючий набір вхідних значень, передумов виконання, очікуваних результатів, та післяумов виконання, розроблений для визначення цілі або тестової умови, таких як виконання визначеного шляху програми або для перевірки відповідності зазначеній вимозі.
• Use Cases — послідовність операцій при ввзаємодії користувача і системи із визначеним результатом.
• Test Data — данні, які існують на початку виконання теста і впливають на роботу (для прикладу, в базі данних), або ж відчувають вплив із сторони тестуємої системи або компонента.
• Requirements Traceability Matrix — документ який зв’язує вимоги продукта до тестових сценаріїв
• Test Coverage — рівень, зазначений у відсотках, на який визначенний елемент покриття був перевірений тестовим набором.
• Defect Report (Bug report) — документ, який містить в собі звіт будь якого недоліку в компоненті або системі, який може привести компонент або систему до неможливості виконати відповідну функцію, яка описана у вимогах до програмного продукту.
• Test Suite — комплект тестових наборів до досліджуваного компонента або системи в якому післяумова одного теста використовується в якості передумови для наступного.
• Test Report — документ, вказує підсумок задачам і результатам тестування, також містить в собі оцінку відповідних об'єктів тестування відносно критеріїв виходу.
• Check list —(інструмент), документ який використовують для зазначення того що має бути протестовано, використовується для збору данних в місці де ці ж данні генеруються.
• test specification, test case specification, test design specification etc. Документів в тестуванні програмного забеспечення досить велика кількість і всі вони є індивідуальними в залежності від побудованих процесів та вимог на проекті та в компанії в цілому.

Defect Report (Bug report)

Вміння написати хороший репорт про помилку — це мистецтво. Будь який bug report має таку структуру (в залежності від проетку поля bug tracking system можуть бути змінені, розташовані в різному порядку чи відсутні взагалі):

• Summery або Title — короткий опис проблеми, який явно зазначає на причину та тип помилкової ситуації компонента чи системи
• Component — Назва частини чи певного функціоналу продукту який тестується
• Version — версія системи чи компоненту де була знайдена помилка
• Severity (серйозність) — важливість впливу конкретного дефекта на розробку чи функціональність компонента або системи, як правило встановлюється тест інженером, ступені серйозності бувають (можуть відрізнятися відповідно до процесів): trivial — не значна, малопмітна проблема / помилка, яка не стосується бізнес логіки. minor — не значна помилка яка не порушує бізнес логіку, яка тистується в компонеті або системи, очевидна проблема користувацького інтерфейсу. major — помилка яка стосується частини бізнес логіки яка працює некоректно. critical — критична помилка, яка стосується ключової бізнес логіки. blocker — помилка яка блокує компонент чи систему в цілому в результаті чого подальша робота з середовищем та його ключовими компонентами яке тестується неможливе.
• Priority (пріорітет) — степінь важливості, який вказує на послідовність виконання завдання або усунення дефекту, як правило встановлюється менеджером, team lead або замовником. Ступені серйозності бувають (можуть відрізнятися відповідно до процесів): Low (помилка повинна бути виправленою, наявність її в системі чи в компоненті є критичною але не вимагає термінового рішення), Medium (помилка повинна бути виправленою, наявність її в системі чи в компоненті є критичною і вимагає обов'язкового вирішення), High (помилка має бути виправлена якомога швидше є критичною для проекту)
• Status — статус в якому знаходиться дефект, залежить від життєвого циклу дефекту на проекті
• Author — поле в якому зазначається автор репорту
• Assignee — поле в якому зазначено ім'я відповідального за проблему
• Environment — середовище, яке включає в собі апаратне забеспечення, вимірювальне обладнання, симулятори, програмне забеспечення та інші інструменти, які необхідні для проведення тесту
• Description — загальний опис який включає в себе: Precondition — умови середовища і стану, які повинні бути виконані перед початком виконання конкретного тесту або процесу тестування. Steps to reproduce — кроки, які описують ситуацію, яка призводить до помилки. Actual result — спостережуване або згенерована поведінка компонента або системи під час тестування. Expected result — поведінка компонента або системи при встановлених умовах, які визначені специфікацією або іншим джерелом.
• Evidence or Attachments — відео, screenshot, файл з логами чи будь який інший документ який зможе допомогти з вирішенням проблеми або вказати на спосіб вирішення проблеми.

Життєві цикли дефектів (можуть відрізнятися відповідно до процесів)

Рівні тестування —об'єднана і спільно керована група завдань тестування. Рівні тестування пов'язані з областями відповідальності на проекті Прикладами рівнів тестування можуть служити:

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

Підходи в тестуванні (Testing approaches)

Основні підходи Unit testing

• AAA (Arrange, Act, Assert) Arrange — блок коду який використовується для налаштування тестового середовища тестового юніту. Act — виконання або виклик тестуючого сценарію. Assert — перевірка, що тестуючий виклик веде себе відповідним чином.
• Driven approach — код, який ви пишете повинен мати причину свого існування. Важливо, що б причина була існуюча, а не передбачувана, і ця причина повинна мати в кінцевому підсумку зв’язок з бізнесом
• AAS (Act, Assert, Setup) патерн — схожина на AAA патерн, але із зміненим порядком частин, відсортованих з врахуванням Driven approach і перейменованим Arrange частиною в Setup щоб відрізняти їх по назві
• Принцип SOLID — складається з двох дуже важливих складових. Single Responsibility principle — дозволяє знизити кількість тест-кейсів для юніта. Dependency Inversion principle — дозволяє легко створювати і управляти складними середовищами для тестування через IoC-контейнери

Основні підходи Integration Testing

• Bottom Up Integration — низькорівневі модулі, процедури або функції збираються воєдино
• Top Down Integration — спочатку тестуються всі високорівневі модулі, і поступово один за іншим додаються низькорівневі
• «Big Bang» Integration — всі або майже всі розроблені модулі збираються разом у вигляді закінченої системи або її основної частини

Основні підходи System Testing

• Requirements based (на основі вимог) — тестування проводиться відповідно до функціональних або нефункціональних вимогам, для кожного з яких пишеться тестовий випадок (test case)
• Use case based (на основі випадків використання) — тестування відбувається відповідно до варіантів використання продукту, на основі яких створюються тестові користувацькі сценарії (use case)

Основні підходи Acceptance Testing

• Тестування замовником
• Тестування (Аудит) третьою стороною
• Спільне тестування за сценаріями із замовником

Безпека, важлива тема яка потребує окремого розгляду.

Security testing — тестування з ціллю оцінити захищеність програмного продукту.

Security — властивості програмного продукту, відбиваючі його властивості не допускати неавторизованого доступу, випадковами або навмисно, до програми і данним.

Тако ж слід не забувати про OWASP Top 10

📌04-estimate-and-forecast

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

1. How long will this testing take?
2. How much will it cost?

Види оцінки

1. Work Breakdown Structure
2. 3-Point Software Testing Estimation Technique
3. Wideband Delphi technique
4. Function Point / Testing Point Analysis
5. Usу-Case Point Method
6. Percentage distribution
7. Ad-hoc method

📌05-risk-and-metrics (draft)

Досить важлива тема яку я хочу винисти окремим пунктом в нашому “checklist”. Ви можете навіть не помічати, але кожного дня працювати з ризиками та метриками.

📌06-computer-programming-and-algorithmization-basics (draft)

Programming skills (according to the project): JavaScript, Java or Python

📌07-unix-shell-and-terminal (draft)

📌08-vcs-git (draft)

📌09-sql (draft)

DDL — Data Definition Language
DML — Data Manipulation Language
DCL — Data Control Language
TCL — Transactional Control Language

📌10-web-application-architecture (draft)

• Idempotent

ідемпотентні методи: GET, HEAD, PUT, DELETE, OPTIONS, TRACE

• HTTP Status Codes

Різниця між автентифікацією та авторизацією

Аутентифікація — це перевірка відповідності суб’єкта та того, за кого він намагається себе видати, за допомогою певної унікальної інформації

• Client error: 401 UNAUTHORIZED — If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials.

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

• Client error: 403 FORBIDDEN — If authentication credentials were provided in the request, the server considers them insufficient to grant access.

HTTP/HTTPS protocol strong knowledge with Postman is preferred

📌11-virtualization-docker (draft)

📌12-mobile-platforms (draft)

mobile platforms (Human Interface Guidelines)

📌13-tools (draft)

📌14-devops-basics (draft)

📌15-architecture-basics (draft)