Глосарій лекції №4 «Життєвий цикл тестування ПЗ» з курсу «Основи тестування ПЗ»

Елементи програмного забезпечення (Product Elements) – те, з чого складається продукт. У моделі HTSM дається корисна мнемоніка SFDPOT для того, щоб структурувати підхід до вивчення елементів продукту.
San Francisco Depot (SFDPOT):
S – Structure;
F – Function;
D – Data;
P – Platform;
O – Operations;
T – Time. 

(Див. також складові продукту, компоненти продукту)

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

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

Оточення проєкту (Project Environment) – все, що оточує продукт: команда, графік релізів, ресурси, артефакти, звіти.

Планування тестування (Test Planning) – дії з підготовки до тестування, спрямовані на визначення основних цілей тестування і завдань, виконання яких необхідне для досягнення цих цілей.

Результат стратегії (Perceived Quality) – це результат роботи тестової стратегії. Те, чого вийшло досягти після застосування визначених у моделі технік тестування.

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

(Див. також вимоги)

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

(Див. також план тестування)

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

Водоспадна або Каскадна модель (Waterfall Model) – передбачає послідовне виконання різних етапів діяльності, включаючи аналіз вимог, проєктування, кодування і тестування окремих модулів (компонентів), тестування збірок та інтегроване тестування всього кінцевого продукту. Таким чином, кожен вид діяльності виконується на якійсь одній фазі життєвого циклу ПЗ, рух у зворотний бік по цьому ланцюжку неможливий.

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

Гнучка модель (Agile Model) – являє собою сукупність різних підходів до розробки ПЗ. Включає серії підходів до розробки програмного забезпечення, орієнтовані на використання ітеративної розробки, динамічне формування вимог і забезпечення їх реалізації в результаті постійної взаємодії всередині самоорганізованих робочих груп, що складаються з фахівців різного профілю. Окрема ітерація являє собою мініатюрний програмний проєкт. Однією з основних ідей Agile – є взаємодія всередині команди та з замовником обличчя до обличчя, що дозволяє швидко приймати рішення і мінімізує ризики розробки програмного забезпечення.

(Див. також Аgile-метод, гнучка розробка, гнучка модель.)

Інкрементна модель (Incremental Model) – у цій моделі повні вимоги до системи діляться на різні збірки. Термінологія часто використовується для опису поетапної збірки ПЗ. Мають місце кілька циклів розробки, і разом вони складають життєвий цикл «мульти-водоспад». Цикл розділений на більш дрібні легко створювані модулі. Кожен модуль проходить через фази визначення вимог, проєктування, кодування, впровадження та тестування. Процедура розробки по інкрементній моделі передбачає випуск на першому великому етапі продукту в базовій функціональності, а потім вже послідовне додавання нових функцій, так званих «інкрементів». Процес триває до тих пір, поки не буде створена повна система.

Ітеративна або ітераційна модель (Iterative Model) – особливістю даної моделі є розбиття проєкту на відносно невеликі проміжки (ітерації), кожен з яких в загальному випадку може включати в себе усі класичні стадії, які властиві водоспадній і V-подібній моделям. Ітераційна модель життєвого циклу не вимагає для початку повної специфікації вимог. Замість цього, створення починається з реалізації частини функціоналу, що стає базою для визначення подальших вимог. Цей процес повторюється. Версія може бути неідеальна, головне, щоб вона працювала та була працездатною, а кожен крок був результативним.

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

Скрам (Scrum) – це одна з методологій гнучкої розробки ПЗ (Agile). Це набір принципів, на яких будується процес розробки, що дозволяє в жорстко фіксовані невеликі проміжки часу (спринти від 2 до 4 тижнів) надавати кінцевому користувачеві працююче ПЗ з доданими можливостями, для яких визначено найбільший пріоритет.

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

(Див. також резерв продукту)

Власник продукту (Product Owner) – представляє інтереси кінцевих користувачів та інших зацікавлених в продукті сторін.

(Див. також замовник, представник замовника)

Покер планування (Planning Poker, Scrum poker) – інструмент планування в гнучкій розробці. Техніка оцінки, яка використовується для оцінки складності майбутньої роботи або відносного обсягу вирішуваних завдань при розробці програмного забезпечення.

Скрам-команда (Scrum Team) – крос-функціональна команда розробників проєкту, що складається з фахівців різних профілів: тестувальників, архітекторів, аналітиків, програмістів та ін. Розмір команди становить 7±2 людини.

(Див. також команда розробників проєкту, команда фахівців проєкту)

Скрам-майстер (Scrum Master) – проводить наради (Scrum meetings), стежить за дотриманням всіх принципів скрам, вирішує протиріччя та захищає команду від відволікаючих чинників.

(Див. також лідер, тімлід)

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

(Див. також клієнт, Product Owner)

Керівник команди (Team Lead) – це IT-фахівець, який керує своєю командою розробників, володіє технічною стороною, бере участь в роботі над архітектурою проєкту, займається рев'ю коду, перевіркою або складанням планів тестування, а також розробкою деяких особливо складних завдань на проєкті.

(Див. також тімлід, лідер команди, лід)

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

(Див. також керівник, PM, проєктний менеджер)

Архітектор (Architect) – це IT-фахівець, який приймає рішення щодо внутрішнього устрою і зовнішніх інтерфейсів програмного комплексу з урахуванням проєктних вимог і наявних ресурсів.

Розробник (Developer) – фахівець, який займається розробкою, написанням і коригуванням програм, тобто програмуванням.

(Див. також програміст, девелопер, кодер)

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

(Див. також техлід, Tech Lead)

Керівник команди тестування (QA Lead) – керує групою QA-інженерів та відповідає безпосередньо за тестування та забезпечення якості програмного забезпечення.

(Див. також тімлід тестувальників, лід, QA-менеджер)

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

(Див. також тестувальник-автоматизатор)

QA інженер (QA Engineer) – це фахівець із забезпечення якості, діяльність якого спрямована на поліпшення процесу розробки ПЗ, запобігання дефектів і виявлення помилок у роботі продукту.

(Див. також спеціаліст із забезпечення якості, тестувальник ПЗ)

Бізнес аналітик (Business Analyst) – це фахівець, який досліджує проблему замовника, шукає рішення та оформлює його концепцію в формі вимог, на які в подальшому будуть орієнтуватися розробники при створенні продукту.

Технічний письменник (Technical Writer) – це фахівець, який займається написанням різної документації як внутрішнього призначення, так і призначеної для кінцевих користувачів ПЗ (наприклад: керівництво користувача, довідкові системи тощо).

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

(Див. також тестувальник-аналітик)