Словник термінів до курсу  QA Manual з нуля

Інформаційні технології (IT) — це сукупність методів і засобів, що використовуються для збору, зберігання, обробки та поширення інформації.

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

Розробка програмного забезпечення для носимих пристроїв (wearables),  як-от розумних годинників, фітнес-браслетів тощо. Тут потрібні ті ж знання, що і для embedded-розробки, але додатково слід розібратися і в апаратному забезпеченні для носимих пристроїв.

Розробка вебдодатків (web-applications) — це розробка сайтів, інтернет-магазинів, нативних та гібридних мобільних додатків для таких операційних систем, як iOS, Android, Windows. Така розробка вимагає розуміння особливостей операційних систем.

Розробка програм для настільних персональних комп’ютерів — у цій підгалузі знадобиться загальне розуміння структури операційних систем, а також базові знання про мережі.

Проєкти з галузі «Інтернету речей» (IoT = Internet of Things) — такі проєкти передбачають тісну взаємодію між пристроями. Концепція «розумного будинку» є яскравим прикладом «Інтернету речей». Тут крім володіння мовами програмування потрібні ще базові знання мереж та їхнього апаратного забезпечення, розуміння мережевих моделей і мережевих протоколів.

Якість програмного забезпечення (Software Quality) — сукупність мінімально допустимих вимог до продукту, що обумовлюють його придатність до задоволення користувацьких потреб згідно із призначенням. Це ступінь, з якою програмне забезпечення здатне відповідати заданим вимогам та задовольняти потреби користувачів.

Забезпечення якості (Quality Assurance; QA) — це сукупність заходів, що охоплюють всі технологічні етапи розробки, випуску й експлуатації ПЗ інформаційних систем на різних стадіях життєвого циклу для забезпечення необхідного рівня якості продукту, який випускається.

Контроль якості (Quality Control; QC) — це сукупність дій над продуктом у процесі розробки для отримання інформації про його актуальний стан, готовність продукту до випуску та відповідність зафіксованим вимогам і заявленому рівню якості продукту.

Тестування програмного забезпечення (Software Testing) — це одна з технік контролю якості, що включає активності з планування робіт (Test Management), проєктування тестів (Test Design), виконання тестування (Test Execution) й аналізу отриманих результатів (Test Analysis). Це процес аналізу програмного продукту з метою визначення, чи відповідає він заявленим вимогам і критеріям якості.

До основних цілей тестування належать:

Верифікація (verification) — підтвердження відповідності системи/програмного продукту заданим вимогам, доведене об’єктивними результатами досліджень. Verification — "is the system correct to specification?".

Валідація (validation) — підтвердження відповідності вимог до конкретного використання програми потребам кінцевого користувача. доведене об’єктивними результатами досліджень. Validation — "is this the right specification?".

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

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

3. Раннє тестування заощаджує час і гроші
Тестування на ранніх етапах життєвого циклу розробки програмного забезпечення допомагає скоротити або усунути дорогі зміни у ПЗ. Чим раніше дефект знайдений, тим дешевше його виправити.

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

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

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

7. Відсутність помилок оманлива
Деякі організації очікують, що тестувальники зможуть виконати всі можливі тести і знайти всі можливі дефекти, але наведені вище принципи 1 і 2 говорять нам, що це неможливо. Крім того, помилково очікувати, що виявлення великої кількості дефектів забезпечить успіх системи. Можливо й таке, що ретельне тестування всіх встановлених вимог і виявлення всіх можливих дефектів призведе до створення системи, яку буде важко використовувати і яка не відповідатиме потребам й очікуванням користувачів.

ISTQB (International Software Testing Qualification Board) — міжнародна некомерційна організація, заснована у 2002 році та офіційно зареєстрована у Бельгії, що займається визначенням ключових принципів розвитку галузі тестування програмного забезпечення.

Життєвий цикл розробки програмного забезпечення (Software Development Life Cycle) — це структура, яка визначає кроки в розробці програмного забезпечення на кожному етапі й охоплює детальний план побудови, розгортання та обслуговування програмного забезпечення. SDLC визначає повний цикл розробки, тобто всі завдання, пов'язані з плануванням, створенням, тестуванням та розгортанням програмного продукту.

1. Збір та аналіз вимог (Requirement gathering and analysis) — це процедура проведення всебічного аналізу висунутих замовником вимог до створюваного ПЗ, щоб визначити ключові цілі та завдання кінцевого продукту. У рамках цієї стадії відбувається максимально ефективна взаємодія клієнта і співробітників компанії-розробника. Результатом проведеного аналізу є формування основного регламенту, на який спиратиметься виконавець у своїй роботі — специфікації (Software Requirement Specification). SRS має повністю описувати поставлені перед розробником завдання та описати кінцеву мету проєкту у розумінні замовника.

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

3. Впровадження або кодування (Implementation or coding) — після отримання проєктної документації системи, робота поділяється на модулі/блоки й починається фактичне кодування. Розробники зосереджуються на написанні коду всіх функцій програми. Це найдовша фаза життєвого циклу розробки програмного забезпечення.

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

5. Розгортання (Deployment) — після успішного тестування продукт доставляється/розгортається замовнику для використання

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

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

Життєвий цикл тестування програмного забезпечення (STLC, Software Testing Life Cycle) — це послідовність конкретних дій, що проводяться під час процесу тестування для забезпечення досягнення цілей якості програмного забезпечення. STLC включає як верифікацію, так і валідацію. Він складається з низки заходів, які проводяться методично, щоб допомогти сертифікувати програмний продукт.

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

2. Аналіз (Test Analysis) ПЗ та вимог до нього потрібен для визначення функцій, які необхідно буде протестувати, та встановлення відповідних тестових умов. Загалом тест-аналіз вирішує «що тестувати?».

3. Tecт-дизайн (Test Design) — це процес формування тестових випадків (кейсів) на основі вимог з етапу тест-аналізу, які будуть тестуватись. Тест-дизайн відповідає на запитання «як тестувати?».

4. Реалізація (Test Implementation) містить такі заходи: розробка тестових випадків та розставлення їх пріоритетності, створення автоматизованих сценаріїв тестування, налаштування тестового середовища та підготовка необхідних тестових даних. 

5. Виконання тестування (Test execution) — це запуск та виконання тестових сценаріїв, заведення на аналіз знайдених дефектів, а також формування звітності за результатами виконаних робіт.

6. Завершення тестування (Test closure) — це формування звітності про завершення тестування, щоб визначити стратегії для реалізації в майбутньому та усунути проблеми процесу для майбутніх циклів тестування.

Моніторинг та контроль тестування (Test monitoring and control) — це процес спостереження за всіма показниками, потрібний для гарантії, що проєкт працює добре, за графіком і не виходить за рамки бюджету. Моніторинг — це процес збору, реєстрації та надання інформації про діяльність проєкту, яку необхідно знати менеджеру проєкту та замовнику. Контроль передбачає виконання дій, необхідних для досягнення цілей плану тестування, на основі даних моніторингу. Моніторинг та контроль відбуваються під час усіх етапів тестування.

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

V-модель — це покращена версія класичної каскадної моделі. Тут на кожному етапі відбувається контроль чинного процесу, щоб переконатись у можливості переходу на наступний рівень. У цій моделі тестування починається ще на стадії написання вимог. До того ж для кожного наступного етапу передбачений свій рівень тестового покриття.

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

Інкрементна модель має в основі принцип, що передбачає розширення можливостей, вдосконалення модулів і функцій програми. Буквальний переклад слова інкремент — «збільшення на один». Це «збільшення на один» застосовується також для позначення версій продукту. Якщо у каскадній моделі є два стани продукту: «нічого» і «готовий продукт», то з появою ітераційних та інкрементних моделей з’являється версіювання продукту. Кожна ітерація позначається цифрою: 1,2,3 — і відповідно продукт після кожної ітерації має нову версію (інкремент) з відповідним номером: v.1, v.2, v.3.

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

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

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

Власник продукту (Product owner) — людина, яка безпосередньо зацікавлена у якісному кінцевому продукті та розуміє, як цей продукт повинен виглядати/працювати. Product owner зазвичай працює на стороні замовника/клієнта та розставляє пріоритети для задач.

Scrum-майстер — це людина, яка допомагає команді слідувати скрам-процесам та втілює цінності Agile у повсякденному житті команди.

Scrum-команда — це команда, яка приймає всі принципи Scrum і готова з ними працювати.

Спринт — відрізок часу, відведений на виконання визначеного (обмеженого) списку завдань. Зазвичай це період від 1 до 4 тижнів.

Беклог (backlog) — це список усіх завдань проєкту.

Спринт-беклог (sprint backlog) — це список завдань, який команда визначила та узгодила з власником продукту на найближчий звітний період (спринт).

Планування спринту (sprint planning) — це зустріч, де вся скрам-команда (команда розробників та QA, Scrum-майстер, Product owner) визначають пріоритетні задачі, оцінюють час та ресурси, необхідні для виконання спринту. З цього формується список робіт, які команда має виконати протягом наступної ітерації (спринту).

Daily Scrum Meeting (Daily standup/daily meeting) — це щоденна коротка зустріч, де кожен член команди коротко звітує про свою роботу у форматі відповіді на запитання: Що було зроблено вчора? Що буде зроблено сьогодні? Які проблемами виникли?  Це допомагає команді самоорганізовуватись і розуміти, що відбувається із проєктом.

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

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

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

Бізнес-вимоги (business requirements) виражають мету, заради якої розробляється продукт (навіщо він потрібен, яка від нього очікується користь, як замовник за його допомогою отримуватиме прибуток). Результатом виявлення вимог на цьому рівні є загальне бачення (vision and scope) — документ, який, як правило, представлений простим текстом та таблицями. Тут немає деталізації поведінки системи та інших технічних характеристик.

Користувацькі вимоги (user requirements) описують завдання, які користувач зможе виконувати за допомогою системи, що розробляється (реакцію системи на дії користувача, сценарії роботи користувача). Оскільки тут з'являється опис поведінки системи, вимоги цього рівня можна використовувати для оцінки обсягу робіт, вартості проєкту, часу розробки тощо. Користувацькі вимоги оформлюються у вигляді варіантів використання (use cases), користувацьких історій (user stories), користувацьких сценаріїв (user scenarios).

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

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

Аналіз вимог — частина процесу розробки програмного забезпечення, що включає збирання вимог до програмного забезпечення (ПЗ), їх систематизацію, виявлення взаємозв'язків, а також документування. У процесі збору вимог важливо брати до уваги можливі протиріччя вимог різних стейкхолдерів, таких як замовники, розробники чи користувачі. Аналіз вимог є важливою фазою SDLC.

Специфікація вимог програмного забезпечення (англ. Software Requirements Specification, SRS) є повним описом поведінки системи, яка буде створена. Вона включає ряд сценаріїв використання, які описують всі види взаємодії користувачів із програмним забезпеченням. Сценарії використання (Use Case) також відомі як функціональні вимоги. У доповненні до сценаріїв використання, у специфікації програмного забезпечення також містяться нефункціональні (або додаткові) вимоги. Рекомендованим підходом до специфікації вимог програмного забезпечення є стандарт IEEE 830—1998.

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

2. Питання
Будь-які запитання, що виникають в процесі перегляду вимог, уточнюються у представників замовника та досвідчених колег.

3. Тест-кейси та чек-листи
Усі вимоги мають бути перевіреними. Для цього можна використовувати чек-листи або повноцінні тест-кейси.

4. Дослідження поведінки системи
Необхідно змоделювати процес роботи користувача з системою, створеною за вимогами, та після цього визначити неоднозначні варіанти поведінки системи.

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

6. Прототипування
Зробивши прототип інтерфейсу користувача, легко оцінити застосування тих чи інших користувацьких рішень.

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

Варіант використання (англ. Use Case) — техніка ведення документації потенційних вимог для створення нової системи або зміни наявної. Кожен варіант описує один або кілька способів взаємодії системи з кінцевим користувачем або іншою системою для досягнення певної мети. Use Case описує сценарій взаємодії учасників (як правило - користувача та системи). Учасників може бути два чи більше. Користувачем може бути як людина, так і інша система.

Історія користувача (англ. User Story) — це опис функціональної можливості ПЗ простими, загальними словами, складений з точки зору кінцевого користувача. Вона пишеться з метою пояснити, яку користь розроблений функціонал принесе клієнту або користувачу. User Story — одна з базових складових agile-підходу.User Stories часто представлені у вигляді простого речення з такою будовою:«Як [тип клієнта], [хочу щось], [щоб робити щось]». Наприклад: “Як студент Beetroot Academy, я хочу зайти в LMS, щоб завантажити домашнє завдання.”

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

Тест-план (Test plan) — це документ, що описує весь обсяг робіт із тестування, від опису об'єкта, стратегії, розкладу, критеріїв початку та закінчення тестування до необхідного в процесі роботи обладнання, спеціальних знань, а також оцінки ризиків з варіантами їх вирішення. Найчастіше при написанні тест-плану використовується стандарт IEEE 829.

За призначенням та деталізацією розрізняють такі види тест-планів:

Чек-лист (Check list) — список із перевірок, які необхідно провести в процесі тестування системи. Пункти чек-листа містять лише назву перевірки, яку потрібно виконати, але без детального опису, як саме це зробити. Чек-лист, найчастіше, є звичним для нас списком, як-от:

Тестовий випадок/тест-кейс (Test Case) — це артефакт, що описує сукупність кроків, конкретні умови та параметри, необхідні для перевірки реалізації функції або її частин.

Високорівневий тест-кейс (high level) — це тест-кейс без конкретних вхідних даних і очікуваних результатів. Як правило, обмежується загальними ідеями та операціями, схожими з детально описаним пунктом чек-листа. Часто зустрічається в інтеграційному тестуванні та системному тестуванні, а також на рівні димового тестування. Може служити відправною точкою для проведення дослідницького тестування або для створення низькорівневих тест-кейсів.

Низькорівневий тест-кейс (low level) — тест-кейс із конкретними вхідними даними та очікуваними результатами. Це найбільш класичний вид тест-кейсів, повністю готовий до виконання. Тестувальників-початківців найчастіше вчать писати саме такі кейси, адже прописати всі дані докладно набагато простіше, ніж зрозуміти, якою інформацією можна знехтувати, не знизивши цінність тест-кейсу та якість тестування.

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

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

Тестовий сценарій (тест-скрипт, специфікація процедури тестування) — документ, що описує послідовність дій із виконання тесту.

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

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

Набір тестів (Test Suite) — це контейнер, який містить тести, що допомагають тестувальникам виконувати та повідомляти про стан виконання тестування. Інакше кажучи, тест-кейси, згруповані за певною логікою.  Наприклад: Загалом для тестування додатка написано 500 тест-кейсів. Для перевірки критичних функцій потрібно створити набір тестів із найвищим пріоритетом. Цей набір тестів охоплює 100 тест-кейсів.

Defect (bug), error, mistake — людина може припуститися помилки (error, mistake), що призводить до дефекту (до несправності, багу) у коді, програмі, системі чи документі. Якщо дефект у коді виконується, система не зможе виконати потрібну дію (або зробить те, що не потрібно) — і це викличе збій. Дефекти у програмному забезпеченні, системах або документах, можуть викликати збої, але не обов’язково викличуть.

Баг репорт/звіт про дефект (bug report) — це документ, що описує ситуацію або послідовність дій, які призводять до некоректної роботи об'єкта тестування, зі вказанням причин та очікуваного результату.

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

Компонентне (модульне) тестування (Component or Unit Testing) стосується тестів, які перевіряють функціональність певного розділу коду, зазвичай на функціональному рівні. В об'єктноорієнтованому програмуванні, це, як правило, тестування на рівні класу чи функції. Такі типи тестів зазвичай пишуться розробниками під час роботи над кодом (white box), щоб переконатися, що дана функція працює як очікувалося. Одна функція може мати кілька тестів, щоб переглянути всі випадки використання коду. Модульне тестування як таке не може перевірити функціонування частини програмного забезпечення, а використовується, щоб гарантувати, що основні блоки ПЗ працюють незалежно один від одного.

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

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

Приймальне тестування (User Acceptance testing) — це формальний процес тестування, який перевіряє відповідність систем вимогам (валідація) і проводиться з метою визначення, чи відповідає система приймальним критеріям, та винесення рішення замовником або іншою уповноваженою особою щодо випуску продукту для користування.

Тестування встановлення (Installation testing) спрямоване на перевірку успішної інсталяції та налаштувань, а також оновлення чи видалення програмного забезпечення.

Тестування зручності використання (Usability Testing) — це метод тестування, спрямований на встановлення ступеня зручності, зрозумілості та інтуїтивності використання, а також привабливості для користувачів.

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

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

Тестування на основі вимог (Requirement-based testing): у цьому типі тестування вимоги пріоритизовані залежно від критеріїв ризику (що важливіше та більш критичне наразі) — і відповідно визначається пріоритет виконання тестів.

Тестування на основі бізнес-процесів або сценаріїв використання (Business-process-based testing): у цьому типі тестування описуються сценарії, пов’язані з повсякденним бізнес-використанням системи. На основі цих сценаріїв формуються тест-кейси.

Димове тестування (Smoke testing) — короткий цикл тестів, який виконується для підтвердження того, що після збірки коду (нового чи виправленого) програмне забезпечення запускається та виконує основні важливі функції.

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

Повторне тестування (Re-test) — тестування, яке перевіряє, що дефект виправлений та змінений функціонал працює як треба.

Тестування збірки (Build Verification Test) — тестування, направлене на визначення, чи відповідає випущена версія критеріям якості для початку тестування. За цілями є аналогом smoke testing.

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

Проєктний менеджмент — це набір інструментів для планування, організації і реалізації роботи зі створення програмного продукту (конкретного проєкту).

Project Manager (проєктний менеджер) — людина, яка веде проєкт від стадії планування до готового результату. Її обов’язки передбачають організацію, координацію, контроль і результат. Project Manager може працювати на аутсорсі або штатно. Чимало компаній нині надають перевагу аутсорсу як зручному варіанту залучення фахівця під конкретний проєкт.

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

Trello — інструмент для упорядкування робочих завдань працює за принципом канбан-дошки, яка зазвичай складається із трьох стовпчиків: «Зробити» (То do), «В роботі» (In progress) та «Зроблено» (Done).

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

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

Atlassian Jira — система відстеження помилок та задач, призначена для організації спілкування з користувачами й управління проєктами. Розроблена компанією Atlassian у 2002 році, вона доступна у двох версіях: «хмарній» і серверній. Зараз Jira охоплює три проєкти: Jira Software (для розробників), Jira Service Desk (підтримка проєкту), Jira Core (управління проєктами), кожен з яких можна придбати окремо. Наразі Jira є однією з найпопулярніших систем управління проєктами.

Azure DevOps (Test Plans) — це продукт Microsoft, який забезпечує контроль версій, звітування, управління вимогами, проєктами, автоматизовані збірки, тестування та можливості управління випусками. Це просте у використанні рішення для керування тестуванням на основі вебу, необхідне для запланованого ручного, приймального та дослідницького тестування, а також збору відгуків за результатами від стейкхолдерів.

Тестовий запуск (Test Run) — це виконання набору тестів на певній версії тестового об’єкта.

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

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

Відмова (Failure) — збій (не обов'язково апаратний) у роботі компонента, всієї програми або системи. Тобто існують такі дефекти, які призводять до збоїв, і такі, які не призводять до них (наприклад, UI-дефекти). Але апаратний збій, ніяк не пов'язаний із програмним забезпеченням, теж є failure.

Баг (Bug, Defect) — дефект у програмі або системі, через яку програма видає неочікувану поведінку і неочікуваний результат. Більшість багів виникають через помилки, які допущені розробниками програми в її початковому коді або дизайні. Також причиною виникнення дефекту можуть бути неякісні вимоги, які некоректно трактовані розробниками або іншими стейкхолдерами. Деякі дефекти виникають через некоректну роботу інструментів розробника.

Статус “Новий” (New). Тестувальник знайшов проблему, дефект успішно занесений в баг-трекінгову систему.

Статус “Відкритий” (Opened). Після того, як тестувальник відправив помилку, вона або автоматично, або вручну призначається людині, яка повинна її проаналізувати.

Відкладений (Postponed). Виправлення дефекту може бути відкладене, бо він не є критичним на чинному етапі розробки або з інших причин.

Відхилений (Rejected). З різних причин дефект може і не вважатися помилкою. Як кажуть, “не баг, а фіча”.

Дублікат (Duplicated). Якщо описана помилка вже раніше була занесена в баг-трекінгову систему.

Призначений (Assigned). Якщо помилка актуальна і повинна бути виконана у наступній збірці (build), необхідно призначити цю задачу розробнику, який повинен виправити помилку.

Виправлений (Fixed). Розробник виправив дефект. Це означає, що необхідно провести ретест.

Перевірений (Verified). Тестувальник перевіряє, чи справді дефект виправлений та чи не впливають зміни на інший функціонал системи.

Повторно відкритий (Re-opened). Якщо цей самий дефект виникає знову — завдання відкривається знову.

Закритий (Closed). Якщо в результаті виконання певного набору тестів дефект вважається виправленим — тоді він закритий.

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

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

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

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

Задача в Jira — об'єкт (сутність) системи управління проєктами, де зберігається інформація про зміст і виконання робіт певного типу. У документації цьому поняттю відповідає термін <issue> (не плутати з <task> — як правило, під цим терміном мається на увазі один із типів задач Jira, створених у системі). Для пошуку та фільтрації задач використовується JQL (Jira Query Language) — мова запитів у розширеному пошуку Jira.

Батьківські (Parent) та дочірні (child) задачі — це терміни, які описують тип відносин між задачами: батьківська задача може включати інші дочірні підзадачі. Існує певна ієрархія в типах таких задач:

Epic — задача вищого рівня, може включати інші користувацькі історії (User story) дефекти (Bug) та підзадачі (Task). Для команди розробки ПЗ епік може описувати нову функцію або модуль.

Story, Task, Bug — звичайні стандартні задачі залежно від їхнього типу. У Jira стандартними є задачі, де щоденна робота обговорюється та виконується членами команди.

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

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

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

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

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

Тестування методом білого ящика (White Box), також тестування методом прозорого, відкритого, скляного ящика; засноване на коді або структурне тестування — метод тестування програмного забезпечення, який передбачає, що внутрішня структура/пристрій/реалізація системи відомі тестувальнику. Ми обираємо вхідні значення, ґрунтуючись на знанні коду, який буде їх обробляти. Так само ми знаємо, яким повинен бути результат цієї обробки. Знання всіх особливостей тестованої програми та її реалізації — обов’язкові для цієї техніки. Тестування методом білого ящика — це заглиблення у код системи, за межі її зовнішніх інтерфейсів.

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

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

Statement Testing and Coverage — розробка тестів методом білого ящика, де тестові сценарії проєктуються для перевірки покриття операторів у коді.

Decision Testing and Coverage — розробка тестів методом білого ящика, де тестові сценарії проєктуються для перевірки покриття рішень у коді.

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

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

Error Guessing — метод проєктування тестів, коли досвід тестувальника використовується для передбачення дефектів, які можуть бути у тестованому компоненті або системі в результаті помилок, а також для розробки тестів спеціально для виявлення дефектів.

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

Checklist-based Testing — метод створення тестів, який ґрунтується на досвіді, коли досвідчений тестувальник використовує високорівневі списки. Перелік містить пункти, які потрібно зазначити або запам'ятати, або складається з низки правил чи критеріїв, згідно з якими верифікується програмний продукт.

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

Equivalence Partitioning — розробка тестів методом чорного ящика, у якій тестові сценарії створюються для перевірки елементів еквівалентної області. Зазвичай тестові сценарії розробляються для покриття кожної області мінімум один раз. 

Boundary Value Analysis — розробка тестів методом чорного ящика, коли тестові сценарії проєктуються на підставі граничних значень на кожному із класів еквівалентності. Аналіз граничних значень може використовуватися на будь-якому рівні тестування.

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

Decision Table Testing — це техніка тест-дизайну, що передбачає створення таблиці, яка зображає комбінації вхідних даних та/або причин із відповідними вихідними даними та/або діями (наслідками). Вона може використовуватися для проєктування тестових сценаріїв.

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

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

Діаграма переходу станів (UML) — діаграма, що визначає зміну станів об'єкта у часі, одна з діаграм моделювання поведінки в UML. 

UML (англ. Unified Modeling Language) — уніфікована мова моделювання, що використовується у парадигмі об'єктноорієнтованого програмування. Вона є невіддільною частиною процесу розробки програмного забезпечення. UML була створена для визначення, візуалізації, проєктування й документування програмних систем.

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

Перехід (Transition) — означає перехід з теперішнього стану в новий у результаті виконання якоїсь дії. Зображується стрілкою.

Дія (Action) — операція, ініційована в результаті зміни стану. Часто це певна відповідь системи. Варто пам’ятати, що дія відбувається під час переходу між станами системи. Стан сам по собі статичний.

Подія (Event) — подія, що стала причиною зміну стану. Зазвичай подія надходить у систему з зовнішнього світу у вигляді певного інтерфейсу. Іноді подія ініціюється всередині системи. Події можуть бути як незалежними, так і пов'язаними. Коли трапляється подія, система може змінити стан або залишитись у попередньому стані та/чи ініціювати певну дію. Подія може мати пов'язані з нею параметри. На схемі зображується як підпис до стрілки переходу.

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

QA effort estimation — це оцінка часу, потрібного QA-інженеру для завершення певної задачі, і часу, необхідного для всіх активностей, у яких спеціаліст братиме участь, виконуючи задачу. Для того, щоб проводити оцінювання, нам потрібні певні інструменти — техніки естимації. Глобально їх поділяють на Accurate (точні) та Rough (грубі).

Rough (грубі) техніки застосовуються, якщо у нас недостатньо інформації про тестований продукт (неповна специфікація або не всі вимоги погоджені, неповні user stories тощо).

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

Experience Based техніка. Оцінюємо час на задачі, базуючись на нашому досвіді на попередніх проєктах. 

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

T-Shirt sizes використовують для оцінювання великих беклогів наперед. Ми отримуємо невелику юзер-сторі та визначаємо її «розмір» як size S. Це знов-таки про складність. Ми призначаємо мірило S і відповідно до складності цієї юзер-сторі естимуємо всі подальші й теж призначаємо їм «розміри» — наприклад, XS або М. Після оцінювання маємо визначену складність задач, які надалі можемо планувати в спринт-беклог згідно з пріоритетами, виставленими Product Owner’ом.

Work Breakdown Structure (WBS) — це підхід до естимації, сутність якого полягає в декомпозиції. Складну задачу ділимо на підзадачі доти, доки не зможемо максимально ефективно й точно її оцінити. Підхід надає можливість дати більш точну оцінку, адже ми бачимо весь обсяг робіт, і це допомагає при подальшому їх плануванні та виконанні. Ми майже на 100% можемо бути впевнені, що не пропустили жодної функціональності.

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

Three-Point estimation (метод 3-х точок) — це методика, яка використовує оптимістичну та песимістичну оцінку для визначення ідеальної оцінки виконання проєктного завдання.
‍
На основі цього складають 3 варіанти оцінки (оптимістичний, реалістичний та песимістичний) та використовують формулу: E = (a + m + b) / 3
‍
‍Де: E = estimated cost (оцінка часу)
a = optimistic value (оптимістичне значення)
m = most likely value (реалістичне значення)
b = pessimistic value (песимістичне значення)

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

Web, або Всесвітня мережа (англ. World Wide Web) — глобальний інформаційний простір, заснований на фізичній інфраструктурі Інтернету і протоколі передачі даних HTTP.  HTTP (англ. Hypertext Transfer Protocol) — протокол, що забезпечує взаємодію користувача, який запитує доступ до web-документів, із сервером, який надає можливість такого доступу.  Всесвітня мережа спричинила справжню революцію в інформаційних технологіях і бум в розвитку Інтернету. Говорячи про Інтернет, часто мають на увазі саме Всесвітню мережу. Для позначення Всесвітньої мережі також використовують слово веб (англ. web) і абревіатуру «WWW».

HTML (англ.  Hypertext Markup Language) — мова розмітки гіпертексту, що дозволяє за допомогою тегів визначати структуру і зовнішній вигляд web-сторінки при показі в браузері. Посилання, параграфи, форми та інші елементи вебсторінки створюються за допомогою HTML.

Об'єктна модель документа (англ. Document Object Model, DOM) — специфікація прикладного програмного інтерфейсу для роботи зі структурованими документами (як правило, документами XML). Ця специфікація визначається консорціумом W3C.

CSS (англ. Cascading Style Sheets, укр. Каскадні таблиці стилів) — спеціальна мова, яка використовується для опису зовнішнього вигляду сторінок, написаних мовами розмітки даних. Найчастіше CSS використовують для візуальної презентації сторінок, написаних мовами HTML та XHTML, але формат CSS може застосовуватись і до інших видів XML-документів.Специфікації CSS були створені і розвиваються Консорціумом Всесвітньої павутини (W3C).

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

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

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

Unicode — універсальний набір символів, тобто стандарт, що визначає в одному місці всі символи, необхідні для написання більшості наявних у світі мов, які використовуються на комп'ютерах. Unicode прагне бути, і значною мірою вже є, розширенням всіх інших наборів закодованих символів. В Unicode є кілька способів кодування одного і того ж символу. Форми кодування, які можуть використовуватися з Unicode називаються UTF-8 (наразі найпопулярніше представлення Юнікоду у світі), UTF-16, та UTF-32.

UI (User Interface) перекладається як «призначений для користувача інтерфейс». Інтерфейс являє собою графічну структуру програми. Він складається з кнопок, які натискають користувачі, текстів, які вони читають, зображень, полів введення тексту і всіх інших елементів, з якими користувачі взаємодіють. Крім того, він містить макет екрана, переходи, анімацію інтерфейсу і кожну мікровзаємодію.

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

Human Interface Guidelines (HIG) — це документ, який містить рекомендації для розробників програмного забезпечення та слугує для створення найбільш інтуїтивних, легких для сприйняття і логічних інтерфейсів взаємодії з користувачами. Зазвичай уніфікує зовнішній вигляд застосунків, а також вказує на необхідність використання технологій, що дозволяють робити програми доступними різними мовами і для людей з обмеженими фізичними можливостями.

Тестування Pixel Perfect — перевірка точної (піксель у піксель) відповідності зверстаного HTML-шаблону до оригіналу (макету/дизайну). Іншими словами, якщо накласти “картинку” зверстаного HTML-шаблону на картинку оригінального макета, то всі елементи тексту (шрифтів), зображень, графічних елементів, відступів мають збігатися. Для цього зручно використовувати додаток до Google Chrome PerfectPixel by WellDoneCode (pixel perfect).

UX, User Experience (дослівно «досвід користувача») — це користувацький досвід та враження, які отримує користувач від роботи з інтерфейсом програми. Чи вдається йому досягти мети і на скільки просто чи складно це зробити. Наприклад, якщо ми хочемо завантажити аватар до свого профілю та витрачаємо на пошуки цієї можливості пів години — це дратує нас як користувачів і користування системою не приносить задоволення. І навпаки — коли ми маємо інтуїтивно зрозумілий інтерфейс, це викликає позитивні емоції від використання.

UX-тестування (також юзабіліті-тестування, usability-testing) — комплекс заходів, спрямованих на виявлення будь-яких проблемних місць у програмному продукті: чи достатньо він зрозумілий, логічний, зручний, чи правильно працюють всі його технічні елементи. Usability-тестування виявляє великі й дрібні проблеми інтерфейсу, кожна з яких відсіює потенційних покупців в інтернет-магазинах, гравців комп'ютерних ігор та користувачів додатків.

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

Радіокнопка (Radio Button) — елемент, дуже схожий на чекбокси, але відрізняється тим, що можна  вибрати лише один із декількох варіантів. Зазвичай позначається кружечком.

Кнопка (Button) — найпростіший елемент, що дозволяє користувачу взаємодіяти з формами на сайті. Оскільки програмна кнопка є аналогом кнопки в техніці, вона зображується схожим чином, а також виконує аналогічні функції. При натисканні на кнопку відбувається програмно пов’язана з натисканням дія (наприклад, відправлення форми).

Перемикач (Toggle) — прапорець, який дозволяє обрати між опціями “Так” або “Ні”, або позначає, що якийсь функціонал вимкнено або ввімкнено.

Поле вводу (Input Field) — елемент, який дозволяє користувачу вводити текстову інформацію в один або більше рядків.

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

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

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

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

Повзунок (Slider Controls) — це загальний елемент користувацького інтерфейсу, що використовується для вибору значення або діапазону значень. Переміщуючи повзунок пальцем або мишкою, користувач може повільно і точно регулювати значення — наприклад, об’єм, яскравість або бажаний діапазон цін під час покупок.

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

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

Bento Menu, Döner Menu, Hamburger Menu, Kebab Menu, Alt-burger, meatball — типи іконок для меню на різних пристроях або платформах, названі на честь страв.

Карусель (Carousel) — елемент, який дає змогу користувачам переглядати  контент, а саме зображення чи картки, часто також гіперпосилання на велику кількість контенту або джерела. Карусель може прогортуватися як автоматично, так і примусово за допомогою стрілок. Найбільшою перевагою використання таких елементів у UI-дизайні є те, що вони дозволяють декільком фрагментам займати одну й ту саму область на сторінці або екрані.

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

Прогрес бар, або індикатор виконання (Progress Bar) — елемент, який  допомагає у візуалізації того, на якому кроці знаходиться користувач. Зазвичай відображається під час завантаження контенту, оформлення замовлення, завантаження застосунків, ігор тощо.

Підказка (Tooltip) — це невелике інформаційне повідомлення, яке допомагає користувачам зрозуміти елемент або процес в інтерфейсі.

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

Коментар (Comment) — текстове повідомлення, яке можна залишити під певним контентом. Зазвичай коментарі націлені на обговорення чи оцінку чого-небудь. Їх часто можуть залишати лише авторизовані на сайті або в застосунку користувачі.

Стрічка/фід (Feed) — елемент, без якого складно уявити соцмережі на кшталт Facebook, Twitter, Instagram тощо. Зміст стрічки варіюється від простого тексту до зображень та відео.

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

Лоудер (Loader) — елемент, основна мета якого відобразити індикатор завантаження, поки на фоні відбувається певна дія.

Бічна панель (Sidebar) — елемент для відображення додаткового контенту, меню чи налаштувань, які не призначені для основного блоку.

Панелі вкладок (Tab Bar) — елементи, що відображаються у нижній частині мобільного застосунку і дозволяють користувачам швидко переміщатись між його основними розділами.

Акордеон меню (Accordion menu) — меню, яке дозволяє групувати, розширювати та згортати розділи контенту. Воно допомагає користувачам швидко переміщатись контентом сайту, а дизайнерам дає змогу вмістити більший обсяг інформації в обмеженому просторі. Прикладом елемента такого типу може бути також мобільна версія сайту Вікіпедії.

Developer Tools — інструмент за замовчуванням у браузері Google Chrome та інших, призначений для розробників та тестувальників з метою налагодження коду. З його допомогою можна переглядати код сторінки, логи, завантаження сторінки, відображення в різних дозволах, помилки коду та багато іншого.

GameDev (game development) — це процес створення, розробки та релізу гри.Для тестування ігор в основному застосовуються ті ж методи, що і для будь-якого програмного забезпечення. Проте специфічним є тестування інтересу користувача до гри, якості гри, а також взаємодія зі специфічними девайсами (геймпад, мишка та клавіатура, nintendo switch). На відміну від традиційного ПЗ для вирішення бізнес-завдань, первинне значення має саме інтерес до гри, зокрема перше враження від ігрової програми.

Анімація (Animation) — покадрова зміна зображення для створення ефекту руху. У 3D-іграх — це покадрова зміна координат об'єктів або окремих його частин (можливо і точок) для створення ефекту руху.

Витік пам'яті (Memory Leak) — це виділена та не звільнена пам'ять, яка більше не використовується. Це призводить до все більшого виділення пам'яті та насамкінець до зниження продуктивності системи. Витік пам’яті, у випадку з iOS, може призвести до екстреного завершення роботи програми.

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

Затримка/Лаг (Lag) — короткочасне зависання/запізнення виведення зображення на екран.

Ігрові механіки (Game Mechanics) — це добірка правил та петель зворотного зв'язку, які призначені для створення приємного геймплею. Вони є будівельними блоками, які застосовуються і комбінуються з ігровим і неігровим контекстом (наприклад, квести, одиниці досвіду, досягнення).

Локалізаційне тестування (Localization Testing) — перевірка правильності відображення текстів додатка/гри підтримуваними мовами.

Механіка Point-and-Tap — спосіб керування об'єктами у грі, який реалізується шляхом вибору об'єкта або області, до якого необхідно застосувати (перемістити) цей об'єкт.

Колізії (Collision) — ігрові об'єкти, створені для реалізації функціонала виявлення зіткнень моделями між собою. Завдяки колізіям, персонаж не провалюється крізь підлогу.

Ретина (Retina) — загальна маркетингова назва ЖК-дисплеїв, що використовуються у пристроях Apple і відрізняються настільки високою щільністю пікселів, що людське око не здатне помітити, що зображення складається з них. Apple визначає різну щільність пікселів для різних пристроїв і ставить їх відповідно до типової відстані огляду для даного класу пристроїв — чим більша типова відстань, тим менша щільність пікселів потрібна для досягнення нерозрізненості. Спираючись на дослідження, що людське око може розрізнити тільки 300 ppi, виробник стверджує, що на таких дисплеях пікселізація зображення не помітна оку.

Розрив екрана (Screen Tearing bug) — помилка у відображенні текстур. У верхній частині екрана видно один кадр, а в нижній частині екрана — інший кадр. Також може бути горизонтальна лінія на екрані, де дві частини кадру з'єднуються.

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

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

Функціональний дефект у грі (Functional Game Defect) — дефект у роботі логіки або будь-якій іншій частині ігрового процесу («зависання», «уповільнення програвання», «несподівані дії», вихід за область тощо).

Мобільний застосунок або додаток (mobile application) — програмне забезпечення, призначене для роботи на смартфонах, планшетах та інших мобільних пристроях. Багато мобільних застосунків встановлені на самому пристрої або можуть бути завантажені на нього з онлайн-магазинів мобільних застосунків, як-от App Store, Google Play, Windows Phone Store та інших, безкоштовно або за плату.

Тестування зручності використання (Usability testing) — мобільний додаток повинен бути простий у використанні та забезпечувати задовільний рівень роботи для користувачів.

Тестування сумісності (Interoperability testing) — тестування програми на різних мобільних пристроях, версіях операційних систем, у різних браузерах відповідно до вимог.

Тестування інтерфейсу (GUI) — тестування опцій меню, кнопок, закладок, історії, налаштувань програми.

Тестування сервісів (Service testing) — тестування програми в режимі онлайн та офлайн.

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

Тестування продуктивності (Load testing) — тестування продуктивності програми шляхом зміни з'єднання з 2G, 3G на WiFi, спільного використання документів, споживання батареї тощо.

Тестування експлуатації (Exploitation and Destructive testing) — тестування резервних копій та плану відновлення, якщо акумулятор розряджається, або втрата даних під час оновлення програми з App Store/Play Market.

Тестування встановлення (Installation testing) — перевірка програми шляхом її встановлення/видалення на пристроях.

Тестування безпеки (Security and Access Control Testing) — тестування програми для перевірки захисту інформаційної системи.

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

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

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

Клієнт-серверна архітектура визначає такі типи компонентів:

API (Application programming interface), інтерфейс програмування додатків (іноді інтерфейс прикладного програмування, програмний інтерфейс додатків) — це набір готових класів, процедур, функцій, структур і констант, що надаються додатком (бібліотекою, сервісом) для використання у зовнішніх програмних продуктах. Застосовується для написання та взаємодії з додатками

Публічні API. Розробники створили API для своєї програми і дають дозвіл користуватися ним будь-кому. Такі API часто продають, щоб отримати додатковий дохід. Наприклад, так робить Google з API Google Maps.

Приватні чи внутрішні API. Розробники приховують ці API від інших. Наприклад, приватні API використовують корпоративні компанії для розробки свого продукту.

Партнерські API. Спеціальні API, які розробники компаній пишуть для партнерів та діляться лише з ними. Наприклад, API для зв’язку бази даних компанії та сторонньої CRM-системи чи email-сервісу.

HTTP — протокол передачі даних у вигляді гіпертекстових документів у форматі HTML, що лежить в основі обміну даних в інтернеті. HTTP є протоколом клієнт-серверної взаємодії, що означає ініціалізацію запитів до сервера самим отримувачем, зазвичай веббраузером (web browser).

SOAP (Simple Object Access Protocol) — це стандартизований протокол, що відправляє повідомлення з використанням таких протоколів, як HTTP. SOAP використовує лише мову кодування XML. Робота з API з цією архітектурою найскладніша: SOAP дуже структурований та строго контрольований формат. SOAP використовується, коли компанії потрібна підвищена безпека та чітко визначені правила для обміну даними.

JSON (JavaScript Object Notation) — текстовий формат обміну даними, заснований на JavaScript. Як і інші текстові формати, він легко читається людьми. Попри походження від JavaScript, формат вважається незалежним від мови програмування JS і може використовуватися практично з будь-якою мовою програмування. Для багатьох мов існує готовий код для створення і обробки даних у форматі JSON.

XML (eXtensible Markup Language) — розширювана мова розмітки. XML розроблялась як мова з простим формальним синтаксисом, зручним для створення й обробки документів програмами і водночас для читання та створення документів людиною.

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

TCP (англійською Transmission Control Protocol — протокол керування переда­ванням) відповідає за організацію сеансу зв'язку між двома комп'ютерами у мережі.

IP (англійською Internet Protocol — міжмережний протокол) відповідає за маршрутизацію, тобто за те, щоб пакет було доставлено за певною адресою. За допомогою протоколу TCP ПК перевіряє, чи всі частини отримано. Якщо отримані всі порції, TCP розміщує їх у потрібному порядку і збирає в одне ціле.

HTTP (HyperText Transfer Protocol) — протокол передачі гіпертексту. Використовують у пересиланні вебсторінок з одного комп'ютера на інший.

HTTPs (HyperText Transfer Protocol Secure) — це безпечна версія HTTP, де використовується порт №. 443 для передачі даних. Це дозволяє створити безліч безпечних транзакцій шляхом шифрування всього зв'язку за допомогою SSL (Secure Sockets Layer — рівень захищених сокетів) — криптографічного протоколу, який забезпечує встановлення безпечного з'єднання між клієнтом і сервером. HTTPS — це комбінація протоколів SSL / TLS і HTTP. Він забезпечує зашифровану і безпечну ідентифікацію мережевого сервера.

FTP (File Transfer Protocol) — протокол передачі файлів зі спеціального файлового сервера на комп'ютер користувача. Цей протокол дає можливість абоненту обмінюватися двійковими і текстовими файлами з будь-яким комп'ютером мережі.

SMTP (Simple Mail Transfer Protocol) — протокол, який задає набір правил для передавання пошти. Сервер SMTP повертає або підтвердження про прийняття, або повідомлення про помилку — або ще запитує додаткову інформацію.

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

Кешування (Cache) — це збереження певних даних для пришвидшення подальших запитів. Кожна відповідь повинна мати примітку, кешується вона чи ні, для запобігання повторного використання клієнтами застарілих або некоректних даних у відповідь на подальші запити.

Єдиний інтерфейс (Uniform Interface) визначає інтерфейс між клієнтом і сервером. Це спрощує і розділяє архітектуру, яка дозволяє кожній частині застосунку розвиватися самостійно.

Багаторівнева система/Шари абстракції (Layered System). У REST допускається розділення системи на ієрархію рівнів, але з умовою, що кожен компонент може бачити компоненти лише наступного рівня. Наприклад, якщо ми викликаємо службу PayPal, а він своєю чергою викликає службу Visa, ми про виклик Visa нічого не повинні знати.

Запитування коду (Code-On-Demand) (Опційно). У REST дозволяється завантаження і виконання коду програми на стороні клієнта. Сервери можуть тимчасово розширювати або кастомізувати функціонал клієнта, передаючи йому логіку, яку він може виконувати. Наприклад, це можуть бути скомпільовані Java-аплети або клієнтські скрипти на JavaScript. 

Postman — це HTTP-клієнт для тестування API.

Workspace (робочий простір) у Postman допомагає організувати роботу з API та співпрацювати з членами команди розробки всередині організації.

1. Personal workspaces — особистий робочий простір, що призначений для індивідуальної роботи і містить інструменти, необхідні для роботи з API. Особистий робочий простір синхронізується в режимі реального часу між настільною версією Postman та вебверсією (якщо користувач зареєстрований).

2. Team workspaces — командний простір, який дає можливість запросити членів команди до співпраці над роботою API в межах робочого простору. Учасники робочого простору можуть коментувати елементи, використовувати та змінювати елементи або навіть розділяти наявні елементи.

3. Public workspace — публічний робочий простір, що є загальнодоступним і дозволяє ділитися своїми API публічно з усім світом.

Postman collection (колекція) — це важливий основний компонент Postman, який дозволяє чітко керувати запитами та підтримувати їх, а також надає безліч інших функцій, як-от спільний доступ до колекцій, виконання цілих колекцій, додавання загальних властивостей, наприклад, заголовка Auth, до всіх запитів, що належать до певної колекції тощо.

Змінна — це певний осередок пам'яті, в який можна записати різні значення. Як правило, цьому осередку пам'яті дають якесь ім'я.

Середовище в Postman (Environment) — це набір пар ключ-значення. Середовище допомагає нам розрізняти запити в межах тестового середовища (наприклад Alpha та Beta).

SoapUI — це кросплатформний інструмент, який використовується як для функціонального, так і для нефункціонального тестування (переважно для тестування вебсервісів). Зазвичай використовується для тестування вебслужб та веб-API.

XML Schema Definition (XSD) — спосіб описання типу XML-документа, що, як правило, визначається шляхом введення обмежень на структуру та зміст документів заданого типу на додаток до базових синтаксичних обмежень самого формату XML. Схеми дають програмам змогу перевіряти дані. Вони забезпечують структуру даних і гарантують її зрозумілість для автора та інших користувачів.

WSDL-файл (Web Services Description Language) — це файл формату XML з описом доступу до функцій вебсервісу, необхідний для обробки запитів до відповідного API.

SOAP-повідомлення (request) — це звичайний XML-документ, що містить такі елементи:

Конверт (Envelope) — визначає початок та кінець повідомлення. Це обов'язковий елемент.

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

Тіло (Body) — дані XML, що містять повідомлення, яке надсилається. Це обов'язковий елемент.

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

Інтерфейс командного рядка (англ. command-line interface, CLI) — різновид текстового інтерфейсу користувача й комп'ютера, в якому інструкції комп'ютеру можна дати тільки введенням із клавіатури текстових рядків (команд). Також відомий під назвою консоль.

Bash (Bourne again shell або "відроджений" shell) — це модифікована версія програмної оболонки Bourne-shell (sh або "Оболонка Борна"). Вона є командним процесором, що працює інтерактивно у текстовому вікні. Bash необхідний для прийому команд користувача та їх відправлення операційній системі для подальшої обробки. Bash — це універсальний інструмент для виконання різноманітних завдань, який у деяких випадках дозволяє уникнути встановлення спеціалізованого програмного забезпечення. Водночас це скриптова мова програмування, що дозволяє створювати сценарії для автоматизації різних операцій. Для QA — це необхідний інструмент для роботи з логами або іншими операціями на серверній частині застосунку.

Система керування версіями (СКВ, англ. source code management, SCM) — програмний інструмент для керування версіями одиниці інформації: джерельного коду програми, скрипту, вебсторінки, вебсайту, 3D-моделі, текстового документа тощо. Система керування версіями — інструмент, який зазвичай використовується у розробці програмного забезпечення для відстеження, документування та контролю коду застосунків, над якими одночасно працюють кілька людей.

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

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

Репозиторій (repository) — це збірка файлів і тек, які ми використовуємо для відстеження git. Сховище складається з усієї історії змін даних нашої команди на проєкті.

Локальний репозиторій (local repository) — це репозиторій, розташований на локальному комп’ютері розробника. Саме в ньому відбувається розробка і фіксація змін, які відправляються на віддалений репозиторій.

Віддалений репозиторій (remote repository) — це репозиторій, що знаходиться на віддаленому сервері, тобто загальний репозиторій, в який приходять усі зміни і в якому збираються всі оновлення.

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

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

Коміт (Commit) — фіксація змін або запис змін до репозиторію. Коміт відбувається на локальній машині.

Клонування (Clone) — завантаження репозиторію з віддаленого сервера на локальний комп'ютер у певний каталог для подальшої роботи з цим каталогом як з репозиторієм.

Пулреквест (Pull Request) — запит на злиття копії репозиторію з основним репозиторієм. Пулреквест може бути прийнятий або відхилений власником репозиторію.

Мердж (Merge) — злиття змін будь-якої гілки репозиторію з будь-якою гілкою цього ж репозиторію. Найчастіше — злиття змін із гілки репозиторію з основною гілкою репозиторію.

Код-рев’ю (Code review) — процес перевірки коду на відповідність певним вимогам, завданням і зовнішньому вигляду.

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

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

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

Реляційна (від англ. relation) база даних — це тип бази даних, що зберігає інформацію в електронних таблицях і здійснює пошук даних в одній таблиці на підставі визначених ключових полів іншої таблиці.

SQL (structured query language — мова структурованих запитів) — декларативна мова програмування для взаємодії користувача з базами даних. SQL може формувати інтерактивні запити або вбудовуватись у прикладні програми й діяти як інструкції для керування даними.

Діаграми відносин сутностей (ERD, entity relationship diagram) — це візуальні представлення баз даних, які показують, як елементи в базі даних пов'язані один з одним. Інакше кажучи, це схема бази даних. ERD складається з двох типів об'єктів: сутностей і відносин.

Ключ (Key) — це стовпчик (може бути декілька стовпчиків), що додається до таблиці і дозволяє встановити зв’язок із записами в іншій таблиці.

Первинний ключ — це одне або кілька полів (стовпчиків), комбінація значень яких однозначно визначає кожен запис у таблиці. Первинний ключ не допускає значень Null і завжди повинен мати унікальний індекс. Первинний ключ використовується для зв’язування таблиці з зовнішніми ключами в інших таблицях.

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

Предикат порівняння — це два вирази, що з'єднуються оператором порівняння.
Є шість загальноприйнятих операторів порівняння: =, !=, >, <, >=, <=

Вкладений запит — це запит, вкладений всередині оператора SELECT, INSERT, UPDATE або DELETE, або всередині іншого підзапиту. Цей вид запитів використовується для повернення даних, які будуть застосовані в основному запиті як умова для обмеження результівних даних.

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

Віртуальний користувач (Virtual User) — програмний процес, що циклічно виконує операції.

Ітерація (Iteration) — це один повтор виконуваної в циклі операції.

Інтенсивність виконання операції (Operation Intensity) — частота виконання операції за одиницю часу, в тестовому скрипті задається інтервалом часу між ітераціями.

Навантаження (Loading) — сукупне виконання операцій на загальному ресурсі.

Продуктивність (Performance) — кількість виконуваних операцій за проміжок часу.

Масштабованість додатка (Application Scalability) — пропорційне зростання продуктивності за збільшення навантаження.

Профіль навантаження (Performance Profile) — це набір операцій із заданими інтенсивностями, отриманий на основі збору статистичних даних або певним шляхом аналізу вимог до тестованої системи.

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

1. Аналіз вимог.

2. Конфігурація тестового середовища для навантажувального тестування.

3. Розробка моделі навантаження.

1. Унікальність запитів. Під час складання сценарію слід враховувати реальні статистичні дані, вимоги, очікувану поведінку системи, час відгуку системи. Керуючи певною кількістю вимірів, можна визначити, до якого інтервалу часу потрапить той чи інший запит.

2. Розподіл системи залежить від часу відгуку. Цей факт варто врахувати під час складання вимог до продуктивності продукту.

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

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

The Grinder — відома програма для навантажувального тестування, заснована на Java. Для написання скриптів використовується мова Jython (спеціальна реалізація Java в Python). Цей інструмент надає більш потужний двигун сценаріїв з функцією їх запису.

OctoPerf — платформа для навантажувального тестування на основі JMeter. Вона забезпечує реалістичне та доступне тестування навантаження, спільну роботу в команді, використання хмарних та локальних серверів і середовищ.

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

Автоматизація тестування коду (Code-driven testing) — тестування на рівні програмних модулів, класів та бібліотек (фактично, автоматичні юніт-тести);

Автоматизація тестування графічного інтерфейсу користувача (Graphical user interface testing) — коли спеціальна програма (фреймворк автоматизації тестування) дозволяє генерувати користувацькі дії: натиснення кнопок, кліки мишкою — та відстежувати реакцію програми на ці дії; чи відповідає вона специфікації;

Автоматизація тестування API (Application Programming Interface, прикладного програмного інтерфейсу) — коли тестуються інтерфейси, призначені для взаємодії, наприклад, з іншими програмами або з користувачем.

KISS (англ. keep it short and simple — «роби коротше і простіше») — це процес і принцип проєктування програми (у нашому випадку тестів), за якого простота системи декларується як основна мета та/або цінність. Принцип KISS базується на твердженні, що більшість систем працюють краще, якщо вони прості в користуванні. Будь-який тест, незалежно від типу, повинен бути зрозумілим і простим.

Selenium — це масштабний open source проєкт, а точніше, browser automation framework, у межах якого розробляється серія програмних продуктів для автоматизованого тестування, які зазвичай використовуються для тестування вебдодатків.

Selenium WebDriver — це гнучкий інструмент для автоматизованого тестування вебпроєктів на базі набору бібліотек для різних мов програмування, як-от Java, .Net (C#), Python, Ruby, PHP, Perl, JavaScript. Цей інструмент підтримує роботу на базі Windows, macOS та Linux, а також найпоширеніші браузери Google Chrome, Firefox, Safari, Edge, Internet Explorer та навіть деякі браузери без графічного інтерфейсу. Selenium WebDriver найчастіше використовується з регресійним та функціональним тестуванням.

WebDriver — це найважливіша сутність Selenium WebDriver, яка відповідає за управління діями браузера.

Webelement — друга важлива сутність Selenium WebDriver, яка становить абстракцію над конкретним вебелементом (посиланням, кнопкою, полем для вводу та ін.).

Локатор — це тип вебелемента, який потрібно знайти та над яким виконуватиме дії вебдрайвер.

By — це абстракція над локатором вебелемента, клас, необхідний для ідентифікації вебелементів, який має такий синтаксис: By.локатор.

Selenium IDE — плагін до браузера Firefox та Chrome, який може записувати дії користувача, відтворювати їх, а також генерувати код для WebDriver, в якому виконуються ті самі дії. Загалом це «Selenium-рекордер».

XPath, або XML Path Language — це мова запитів для вибору вузлів з XML-документів або обчислення величин (наприклад, рядкових, числових або булевих) на основі вмісту XML-документа. XPath була розроблена World Wide Web Consortium (W3C). Мова XPath заснована на представленні XML-документа у вигляді дерева і надає можливість навігації деревом та вибору його вузлів за різними критеріями.

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