SDLC: моделі розробки ПЗ

Що таке SDLC і які фази він включає?

SDLC (software development lifecycle, життєвий цикл розробки ПЗ) — набір фаз, через які проходить будь-який продукт: збір і аналіз вимог, проєктування, реалізація, тестування, впровадження, підтримка. Ключовий момент, який вирізняє сильну відповідь: фази є в кожній моделі, а моделі відрізняються тим, у якому порядку і скільки разів ці фази проходяться. Один довгий прохід — послідовні моделі (waterfall, V-модель), багато коротких — ітеративні й інкрементні, включно з Agile. Тому питання «назви фази» майже завжди продовжується питанням «а де в них тестування» — і на нього треба мати відповідь глибшу, ніж «четверта фаза».

Тестування — це окрема фаза SDLC чи щось більше?

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

Що таке каскадна модель (waterfall) і які її сильні та слабкі сторони?

Waterfall — послідовна модель: фази йдуть строго одна за одною, наступна починається після повного завершення попередньої, результат кожної фази — затверджений документ, а повернення «проти течії» не передбачено. Сильні сторони: передбачуваність (обсяг, бюджет і терміни зафіксовані на старті — зручно для контрактів із фіксованою ціною), документація і простота управління. Головна плата — пізній зворотний зв'язок: працюючий продукт з'являється наприкінці, і помилка у вимогах знайдеться тоді, коли все вже спроєктовано й написано, тобто коштуватиме максимально дорого. Цікава деталь для сеньйорної відповіді: уже Вінстон Ройс, який описав схему 1970 року, вважав її в чистому вигляді ризикованою.

Що waterfall означає для роботи тестувальника на практиці?

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

Чим V-модель відрізняється від waterfall?

Відповідь «там тестування є, а там немає» — червоний прапорець; суть V-моделі — у парності. Ліва гілка «V» — ті самі послідовні фази розробки, права — рівні тестування, і кожен рівень парний конкретній фазі: приймальні тести проєктуються на фазі вимог, системні — на фазі системного дизайну, інтеграційні — на архітектурному, модульні — на детальному. Поки розробка спускається лівою гілкою, тестувальники вже працюють: аналізують вимоги на тестопридатність, пишуть кейси, готують дані. Виконання тестів усе ще пізнє, але проєктування — раннє, і воно саме по собі знаходить дефекти вимог і дизайну, коли їх виправлення майже безкоштовне. Це і є головна відмінність: V-модель виправляє основну ваду waterfall щодо тестування, лишаючись послідовною моделлю.

Як V-модель ілюструє різницю між верифікацією і валідацією?

Верифікація відповідає на питання «чи будуємо ми продукт правильно» — тобто чи відповідає результат специфікаціям; валідація — «чи правильний продукт ми будуємо», тобто чи відповідає він потребам користувача. У V-моделі це видно геометрично: ліва гілка й нижні рівні правої (модульне, інтеграційне, системне тестування) — переважно верифікація, перевірка проти специфікацій, а приймальне тестування нагорі — валідація, перевірка проти реальних потреб. Практичний сенс розрізнення: продукт може ідеально відповідати специфікації і бути непотрібним користувачу — верифікація пройдена, валідація провалена.

Де сьогодні реально застосовують waterfall і V-модель — вони не застаріли?

Ні, і питання «коли waterfall доречний» на співбесіді перевіряє саме розуміння цього. Послідовні моделі — стандарт у доменах із жорсткою регуляторикою і високою ціною помилки: медичне ПЗ, авіоніка, автомобільні системи, банківський core. Там регулятор вимагає простежуваності «вимога → тест → результат», тож послідовна модель із повною документацією — не архаїзм, а вимога середовища. Додатковий аргумент — контракти з фіксованою ціною і обсягом: коли все зафіксовано на старті, передбачуваність waterfall стає перевагою.

Чим ітеративна розробка відрізняється від інкрементної?

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

Що таке спіральна модель і в чому її ключова ідея?

Спіральна модель Баррі Боема — представник ітеративної родини, де кожен виток спіралі включає аналіз ризиків. Ключова ідея: спершу будуємо те, що найризикованіше, щоб дорогі сюрпризи спливли якомога раніше, а не наприкінці проєкту. Поруч у цій родині — прототипування (швидка чорнова версія заради уточнення вимог) і RUP (Rational Unified Process). Спільне в них одне: замість одного довгого проходу фаз — цикли, кожен із яких дає зворотний зв'язок.

Що фундаментально змінюється для тестування, коли команда переходить на цикли?

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

Agile — це модель розробки?

Строго кажучи, ні: Agile — не окрема модель, а сімейство ітеративно-інкрементних підходів, об'єднаних цінностями Agile-маніфесту 2001 року. Цінностей чотири: люди і взаємодія важливіші за процеси й інструменти; працюючий продукт — за вичерпну документацію; співпраця із замовником — за узгодження контракту; реакція на зміни — за дотримання плану. Важливий нюанс, який вирізняє сильну відповідь: це пріоритети, а не заперечення — праві частини теж мають цінність, просто ліві більшу. Практично Agile виглядає як робота короткими циклами (у Scrum — спринти, зазвичай 1–4 тижні) з працюючим інкрементом наприкінці кожного.

Як змінюється робота тестувальника в Agile порівняно з waterfall?

Сильна відповідь іде через наслідки, а не означення. Перше: QA всередині команди — немає окремого «відділу тестування», якому передають білд; тестувальник залучений від обговорення вимог до релізу. Друге: тестування безперервне — аналіз user story, перевірка фічі щойно вона готова, регресія перед закриттям спринту, усе в межах одного циклу. Третє: легша документація — замість багатосторінкових специфікацій user story з acceptance criteria, тест-дизайн частіше на чеклистах, ніж на детальних кейсах. Четверте: регресія щоспринту, обсяг постійно росте, тому автоматизація критична. При цьому ядро професії незмінне: аналізувати, проєктувати перевірки, виконувати і звітувати — модель змінює коли, як формально і як часто, але не що саме робить тестувальник.

«Agile — це коли без документації». Що не так із цим твердженням?

Маніфест каже «працюючий продукт важливіший за вичерпну документацію», а не «замість неї» — це пріоритет, а не заборона. Документація в Agile нікуди не зникає, вона стає легшою: user story з acceptance criteria замість багатосторінкових специфікацій, чеклисти замість детальних тест-кейсів. Для регульованих доменів або складних інтеграцій команда цілком може тримати й формальнішу документацію — Agile це не забороняє. На співбесіді відповідь «в Agile документи не пишуть» звучить як ознака, що кандидат читав заголовки, а не маніфест.

«В Agile тестувальники не потрібні, бо тестують усі». Як відповісти?

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

Коли waterfall кращий за Agile?

Питання «яка модель найкраща» — некоректне; коректне — «найкраща для яких умов», і саме вміння міркувати критеріями тут перевіряють. До послідовних моделей тягнуть: стабільні й зафіксовані вимоги, критична ціна помилки (медицина, авіація), регуляторика з вимогою документованих фаз і простежуваності, недоступний після підписання контракту замовник, контракт із фіксованою ціною і обсягом. До ітеративних і Agile — розмиті мінливі вимоги, можливість швидко виправити помилку наступним релізом, замовник, готовий дивитися демо щоциклу. Чесне застереження для сеньйорної відповіді: критерії часто суперечать один одному (регульований домен із мінливими вимогами — буденність), тож рішення — завжди компроміс, а не вибір із каталогу.

Яка модель була на твоєму проєкті і як вона впливала на твою роботу?

Це питання перевіряє, чи бачив кандидат процес зсередини, тому теорія тут програє конкретиці. Пастка — назвати «канонічний Scrum»: чисті моделі в природі майже не трапляються, реальні процеси — гібриди на кшталт «Scrum усередині, але релізи раз на квартал із формальною регресією». Фраза «у нас був гібрид: ось що з чого» звучить достовірніше і показує розуміння, чому процес склався саме так. Далі — наслідки для власної роботи: коли підключався до фічі, як виглядала регресія, що автоматизували й чому («регресію ганяли останні два дні спринту, тому ми автоматизували смоук»). Ланцюжок «модель → момент початку тестування → вартість дефекту → роль автоматизації» — каркас, на якому будь-яка відповідь цього блоку звучить на рівень вище.

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

Кейс 1. Один дефект вимог — три моделі

Вимога в специфікації інтернет-магазину: «Знижка за промокодом застосовується до суми замовлення». Замовник мав на увазі суму товарів без доставки; аналітик записав як записав; розробник чесно реалізував знижку на все, включно з доставкою. Дефект народився на фазі вимог — подивимось, коли він знайдеться в різних моделях.

Waterfall. Вимоги затверджено, дизайн затверджено, код написано. Тестувальник вперше бачить систему на фазі тестування, читає вимогу — «до суми замовлення» — і перевіряє рівно це: знижка на все, тест зелений. Дефект пливе на прод, де його знаходить фінансовий відділ замовника наприкінці кварталу. Виправлення тягне за собою зміну вимоги, перерахунок дизайну знижок, код, повторне тестування і незручну розмову про бюджет.

V-модель. Приймальні тести проєктуються на фазі вимог — тестувальник аналізує вимогу на тестопридатність ще до першого рядка коду. Пишучи кейс «замовлення 1000 грн + доставка 100 грн, промокод −10%», він упирається в питання: очікуваний результат 990 чи 1000 зі знижкою на доставку? Формулювання неоднозначне — питання летить аналітику, вимогу уточнюють. Код іще не написано: виправлення коштує один коментар у документі.

Agile. Story «як покупець, я хочу застосувати промокод» потрапляє у спринт. Навіть якщо неоднозначність не зловили на обговоренні, наприкінці спринту — демо працюючого інкремента: замовник бачить знижку на доставку і каже «не так». Виправлення потрапляє в наступний спринт. Дорожче, ніж у V-моделі на фазі вимог, але незрівнянно дешевше, ніж на проді після повного проходу waterfall.

Що з цього взяти:

• Дефект один і той самий — різниться момент виявлення. Модель не змінює природу помилок, вона змінює довжину петлі зворотного зв'язку, а разом із нею — вартість виправлення.
• Раннє проєктування тестів — це і є тестування вимог. У V-моделі дефект зловив не прогін, а спроба написати тест-кейс: неоднозначна вимога не дає однозначного очікуваного результату. Цей ефект працює в будь-якій моделі, де тестувальника пускають до вимог.
• Демо — теж перевірка. В Agile валідація («чи правильний продукт будуємо») вбудована в кожен цикл: замовник дивиться на працюючий інкремент, а не на документ.

Кейс 2. Таблиця рішень: три проєкти — три моделі

Три вакансії — три проєкти. Прикладемо до кожного критерії вибору з глави.

Помпа → V-модель. Усі критерії тягнуть в один бік: стабільні вимоги, критична ціна помилки, регулятор вимагає простежуваності «вимога → тест → результат». Для QA це формальні тест-плани, докладні кейси за затвердженими вимогами і раннє проєктування тестів на кожному рівні.

Маркетплейс → Agile (Scrum). Вимоги — гіпотези, фідбек потрібен щоциклу, помилка недорога. Для QA: робота від user story з acceptance criteria, тестування фіч у міру готовності, автоматизований смоук із перших спринтів — бо регресія почне рости одразу.

Банківський core → гібрид. Критерії суперечать один одному: регуляторика й фіксована ціна тягнуть до послідовної моделі, бажання замовника бачити прогрес — до ітерацій. Реалістичне рішення — «waterfall по фазах, але з проміжними демо» або «Scrum усередині, релізи раз на квартал із формальною регресією». Для QA це означає подвійне навантаження: легкі перевірки щоітерації плюс формальний регресійний цикл із документованими результатами перед кожним релізом.

Що з цього взяти:

• Рішення приймається критеріями, а не модою. «Agile — це добре» — не аргумент; аргумент — стабільність вимог, ціна помилки, регуляторика, доступність замовника, контракт.
• Конфлікт критеріїв — норма, а не виняток. Третій проєкт — найтиповіший: саме тому в природі живуть гібриди, і на співбесіді опис гібрида звучить достовірніше за «канонічний Scrum».

Кейс 3. Арифметика регресії: чому спринти без автоматизації не замикаються

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

Спринт 1:  нове 2 дні + регресія 0 днів  = 2 дні тестування
Спринт 3:  нове 2 дні + регресія ~4 дні  = 6 днів
Спринт 5:  нове 2 дні + регресія ~8 днів = 10 днів  ← спринт має 10 робочих днів

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

Типовий перший крок — автоматизований смоук, який ганяється на кожен білд, поки повна регресія лишається рідшою і глибшою. У Playwright мінімальна механіка — теги і фільтр:

// критичний шлях позначаємо тегом — це і є смоук-набір
test('промокод застосовується до суми без доставки', { tag: '@smoke' }, async ({ page }) => {
  // ...
});

# на кожен білд — тільки смоук; повна регресія — перед закриттям спринту
npx playwright test --grep @smoke

Що з цього взяти:

• Регресія росте лінійно, а спринт — ні. Кожен інкремент додає що перевіряти, а часу в циклі стільки ж; момент, коли ручна регресія перестане влазити, — питання кількох спринтів, і його видно заздалегідь простою арифметикою.
• Автоматизація починається з пріоритетів, а не з «автоматизувати все». Смоук на критичний шлях щобілда + повна регресія рідше — типова перша конфігурація, яка знімає найгостріший біль.
• Це аргумент для співбесіди. «Регресію ганяли останні два дні спринту, тому автоматизували смоук» — конкретика, яка показує, що ти бачив наслідки моделі на власному розкладі, а не в підручнику.

Фази SDLC і місце тестування

• Можу назвати шість фаз SDLC: вимоги, проєктування, реалізація, тестування, впровадження, підтримка.
• Розумію, що фази однакові в усіх моделях, а моделі відрізняються порядком і кількістю проходів: один довгий (послідовні) чи багато коротких (ітеративні).
• Знаю три хороші практики ISTQB для будь-якої моделі: кожній активності розробки — тестова активність; у кожного рівня тестування власні цілі; аналіз і проєктування тестів починаються під час відповідної фази розробки, а не після.
• Можу пояснити зв'язок моделі з вартістю дефекту: що пізніше модель дає зворотний зв'язок, то дорожча помилка.

Послідовні моделі: waterfall і V-модель

• Знаю сильні сторони waterfall (передбачуваність, документація, простота управління) і головну плату — пізній зворотний зв'язок.
• Розумію, чому у waterfall тестування — окрема фаза в кінці, і чому саме її стискають першою, коли розробка з'їла терміни.
• Можу пояснити суть V-моделі через парність: кожен рівень тестування парний конкретній фазі розробки, і тести для нього проєктуються під час цієї фази.
• Знаю різницю «виконання тестів» vs «проєктування тестів» і чому раннє проєктування само по собі ловить дефекти вимог і дизайну.
• Розрізняю верифікацію («чи будуємо продукт правильно», відповідність специфікаціям) і валідацію («чи правильний продукт будуємо», відповідність потребам) на прикладі гілок V-моделі.
• Знаю, де послідовні моделі досі стандарт: медицина, авіоніка, автомобільні системи, банківський core — регуляторика вимагає простежуваності «вимога → тест → результат».

Ітеративність, інкрементність, Agile

• Знаю різницю ітеративної (повторні проходи з уточненням) та інкрементної (нарощування продукту частинами) розробки і що це різні осі, які Agile поєднує.
• Можу назвати класику ітеративної родини: прототипування, RUP, спіральна модель Боема з аналізом ризиків на кожному витку.
• Розумію головний наслідок циклів для QA: тестування перестає бути фазою і стає повторюваною активністю, обсяг регресії росте щоітерації — тому автоматизація перетворюється з бонуса на умову виживання (без неї команда сповільнюється або релізить наосліп).
• Знаю чотири цінності Agile-маніфесту і можу пояснити, що це пріоритети, а не заперечення правих частин.
• Можу перелічити, як Agile змінює роботу QA: тестувальник усередині команди, тестування безперервне, документація легша (user story + acceptance criteria), регресія щоспринту.

Вибір моделі і співбесіда

• Можу назвати критерії вибору моделі: стабільність вимог, ціна помилки, регуляторика, доступність замовника, терміни, тип контракту.
• Розумію, чому «яка модель найкраща» — некоректне питання, і що чисті моделі майже не трапляються: реальні процеси — гібриди.
• Можу відтворити словами порівняння «waterfall/V-модель vs Agile» для QA: коли підключається, фаза vs активність, формальність документації, регресія, автоматизація, роль у команді.
• Знаю, що незмінне в будь-якій моделі: аналізувати, проєктувати перевірки, виконувати і звітувати — модель змінює лише «коли, як формально і як часто».
• Готовий описати модель свого проєкту як гібрид із конкретними наслідками для тестування, а не назвою з підручника.