Тестувальник та легенда двох кілець

Вступ

Однією з найпопулярніших вимог в описі вакансій для QA-фахівців, особливо для початківців, є розуміння SDLC та STLC. За моїми спостереженнями, дана вимога винесена окремим пунктом лише у 60% вакансій, а у решті передбачається, що фахівець і так знайомий із цими поняттями. Так, SDLC (Software Development Lifecycle) та STLC (Software Testing Lifecycle) належать до підвалин теорії, їх першими розповідають на всіляких курсах і здавалося б, що вже кожен собака про них чув, але чути – то одне, а розуміти та вміти застосовувати – то зовсім інше.

Безумовно, існує безліч теоретичних статей, де розглядаються вищезазначені поняття, але, по-перше, досі немає єдиної концепції й, в залежності від автора, кількість етапів в обох циклах варіює від 5 до 7, що ще більше заплутує початківців, а, по-друге, мені так і не вдалось знайти дійсно цікавого матеріалу, такого, щоб читаєш і складалось враження, що це не технічна стаття, а казка: і тему зрозумів, і щось цікаве дізнався, і від нудьги не помер. Тому дана стаття – це спроба виправити поточну ситуацію. Сподіваюсь, цей матеріал не тільки допоможе розібратись початківцям, а й більш досвідчені фахівці знайдуть щось цікавеньке.

Частина 1: Марвелівська назва та розгляд життєвого циклу розробки ПЗ

Як вже могли помітити спостережливі й не дуже читачі, титульне зображення та назва статті не аби як пов’язані із відносно свіжим фільмом всесвіту Marvel «Шан-Чі та легенда десяти кілець». Звичайно, основна причина, з якої було обрано саме цей фільм, — ключовий артефакт, бо вже за назвою зрозуміло, що без якихось десяти кілець діла не буде. Але тут може з’явитись запитання, а чим в такому випадку не догодив «Володар перснів», адже і фільм популярніший, і персні є? Річ у тім, що ключові артефакти вищезазначених фільмів мають принципово різні конструкції та функціональність, що досить добре видно на ілюстрації:

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

Як на мене, кільця Шан-Чі – чи не точна копія архітектури наших циклів, а, враховуючи дату виходу фільму, можливо, що на їх основі цей магічний артефакт і зробили, тільки кількість ланок до 10 збільшили. Отже, обираючи таку назву, я мав за мету зайвий раз нагадати шановним читачам загальний вигляд схеми життєвих циклів розробки та тестування ПЗ і, сподіваюсь, мені це вдалось.

Однак, повертаючись до основної теми, пропоную розглядати наші цикли по черзі й почати з більш популярного – Software Development Lifecycle (життєвий цикл розробки програмного забезпечення). За визначенням, SDLC – це процес, що складається з конкретних етапів, який починається в момент ухвалення рішення про необхідність створення ПЗ і закінчується в момент припинення підтримки ПЗ розробниками. Саме завдяки цьому концепту ми можемо:

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

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

1. Ідея

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

2. Визначення вимог

На цьому етапі «ідея» набуває більш конкретного вигляду. Для визначення початкових вимог до продукту залучаються експерти з різних галузей: замовники, клієнти, фахівці різних відділів (продажів, розробки, аналітики, тестування тощо), експерти зі схожих продуктів. Бізнес-аналітики опрацьовують отриману інформацію, деталізують її та перетворюють на технічні вимоги до системи. По-розумному ці вимоги називаються Software Requirement Specification, а по-простому — спека. Крім спеки на цьому етапі:

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

3. Дизайн (архітектура) системи

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

Високорівневий дизайн (взагалі по загалям):

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

Низькорівневий дизайн (деталі реалізації):

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

Різницю між документами добре зображено на малюнку:

4. Розробка

На цій стадії життєвого циклу здійснюється безпосередня робота зі створення та складання продукту відповідно до специфікацій. За наявності деталізованого й організованого дизайну написання коду зазвичай не викликає серйозних труднощів. У розробці застосовуються такі засоби програмування, як компілятори, інтерпретатори, відладчики тощо. Код пишеться різними мовами програмування високого рівня — наприклад C, C++, Pascal, Java і PHP. Його вибір залежить від типу розроблюваного ПЗ.

5. Тестування

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

6. Розгортання

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

7. Підтримка

Основна увага на цьому етапі приділяється забезпеченню того, щоб потреби продовжували задовольнятися і щоб система продовжувала працювати згідно зі специфікацією, згаданою раніше. Після того, як систему розгорнуто і клієнти починають використовувати розроблену систему, відбувається 3 види діяльності:

Виправлення помилок
Оновлення
Покращення

8. Закриття

Закриття — останній етап життя ПЗ. На ньому відбувається виведення продукту з експлуатації, його заміна на сучасні аналоги або нові версії. Як приклад, можна згадати браузер Internet Explorer (його замінили на Edge) або Windows XP (замінили на Windows 7).

Отже, якщо зобразити усі вищезазначені процеси в одній схемі, то вийде десь так:

На цьому моменті, скоріш за все, у найдопитливіших читачів з’явиться цілий ряд запитань: «Чому на більшості схем SDLC 6 етапів, а тут 8? А де ж тоді цикл? Уся попередня інфа — брехня?». Одразу всіх заспокою, ніхто нікого не обманював, зараз усе з’ясуємо.

Насправді 1й та 8й етап відбувається всього лиш раз, тому їх зазвичай не зображають на малюнках, а ось 2й-7й крок повторюються дуже багато разів, аж до поки продукт не буде ідеальним, чи десь поруч. А ще 6 етапів набагато простіше малювати, ніж 7 або 8. Ось і вийшло, що там скоротили, тут спростили, так малювати простіше і все – народ в омані.

Якщо представити вищезазначену схему у більш традиційній манері, то вийшло б так:

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

Частина 2: Життєвий цикл тестування ПЗ та точка дотику кілець

З’ясувавши усі секрети одного «кільця тестувальника», нам вже час переходити до другого, менш популярного, але не менш важливого – Software Testing Lifecycle (життєвий цикл тестування ПЗ).

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

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

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

1. Аналіз (оцінювання) вимог

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

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

Визначення типів тестування (що і чим будемо перевіряти)
Збір інформації про пріоритети в тестуванні (послідовність виконання)
Підготовка матриці відстеження вимог (чи всі вимоги покриті тест-кейсами)
Визначення тестового оточення (де будемо перевіряти)
Аналіз можливості автоматизації тестування (чи все будемо робити руками, чи ні)

Стосовно критеріїв завершення, то обов’язково повинна вийти матриця відстеження вимог (Requirement Traceability Matrix) та, за потреби, звіт про можливість автоматизації.

2. Планування тестування

На етапі планування керівник команди QA визначає стратегію тестування та оцінює трудовитрати, спираючись на вимоги та матрицю покриття вимог. Також оцінюються ресурси, тестове оточення, можливі обмеження і графік тестування, на цьому ж етапі готується і план тестування. Загальний перелік дій, які зазвичай роблять на цьому етапі виглядає так:

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

Після завершення етапу ми повинні мати на руках стратегію тестування та звіт з оцінювання ресурсів.

3. Створення тест-кейсів

Етап планування передбачає використання ручного й автоматизованого тестування для досягнення повного охоплення функціональності програмного забезпечення. Для початку планування ми повинні мати вимоги та тестову стратегію.

Найчастіше тест-кейси для автоматичного тестування пишуть окремо, оскільки кейси для ручного тестування описано у вигляді шпаргалок (cheat sheets). Загальний перелік дій, які зазвичай роблять на цьому етапі виглядає так:

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

Як всі вже зрозуміли, без тест-кейсів, скриптів для автоматизації та тест-дати етап завершитись не може.

4. Налаштування тестового середовища

У плані тестування чітко вказано, яке тестове середовище слід використовувати, як і за допомогою яких даних варто його. На цьому етапі STLC налаштовуються операційні системи й віртуальні машини, розгортаються інструменти тестування, як-от Selenium, Katalon Studio, а також тестове середовище і бази даних проєкту.

Ми також звертаємося із запитами до DevOps і адміністраторів, якщо потрібна підтримка. Загальний перелік дій, які зазвичай роблять на цьому етапі виглядає так:

Підготувати список вимог до харду і софту (що хочемо бачити)
Налаштувати тестове оточення і тестові дані (будування особистого майданчика для QA)
Провести smoke-тест оточення (визнати майданчик придатним)

По завершенню етапу нам треба мати налаштоване оточення для проведення тестування та результати smoke-тестування того оточення.

5. Виконання тестів

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

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

Загальний перелік дій, які зазвичай роблять на цьому етапі:

Виконання тестування відповідно до плану (перевіряємо те, що планували)
Отримання результатів тестування (що працює, а що — ні)
Оновлення RTM-матриці (тест-кейси з RTM-матриці пов’язуються зі знайденими багами)
Повторне тестування виправлених багів (вже після фіксів)

По закінченню на руках маємо завершену RTM-матрицю, тест-кейси з оновленими результатами, знайдені та описані баги.

6. Завершення тестування

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

Загальний перелік дій, які зазвичай роблять на цьому етапі виглядає так:

Оцінка критеріїв завершення циклу (ґрунтується на часі, трудовитратах, покритті тестами)
Підготовка документа з висновками, зробленими під час тестування
Підготовка звіту про завершення тестування
Підготовка звіту для клієнта з кількісними та якісними характеристиками протестованої системи
Аналіз результатів тестування

В кінці маємо отримати фінальний звіт про завершення тестування із підбиттям підсумків.

Зобразивши усі вищезазначені етапи на одній схемі, ми отримаємо таке:

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

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

А на останок пропоную відповісти на питання із зірочкою — як же ці два «кільця тестувальника» пов’язані між собою? Одні кажуть, що SDLC і STLC – незалежні процеси, інші стверджують, що STLC проводиться виключно в межах етапу тестування SDLC, а де ж правда?

Для встановлення справедливості пропоную згадати одну з аксіом тестування (їх ми вже розбирали раніше), яка радить залучати тестувальників якомога раніше, щоб виявляти помилки ще на стадії зародків. Виходить, що SDLC і STLC мають приблизно однаковий початок, а що стосовно завершення?

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

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

Отже, оскільки цикли нерозривно пов’язані й SDLC трохи раніше починається і трохи пізніше завершується, то можна сказати, що STLC якби входить до SDLC, тобто є його підмножиною. Якщо спробувати це зобразити, то вийде десь так:

Як на мене, нічого складного в цих «кільцях тестувальника» немає, навпаки, все досить чітко і ясно, сподіваюсь, шановні читачі, що й у вас не залишилось білих плям з цієї теми!

Підсумок

Сьогодні ми розглядали поняття, що відомі кожному IT-фахівцю – SDLC (життєвий цикл розробки ПЗ) та STLC (життєвий цикл тестування ПЗ).

На початку мова йшла про причини вибору саме цієї теми (пряма згадка у 60% вакансій) та мету написання статті (і тему зрозуміти, і щось цікаве дізнатись, і від нудьги не померти). Також було згадано досить слушний вираз Елберта Хаббарда («Щоб виконати велику та важливу працю, необхідні дві речі: ясний план та обмежений час»).

Перша частина почалась з аргументування вибору марвелівських обкладинки та назви (кільця Шан-Чі – чи не точна копія архітектури наших циклів), але досить швидко ми дійшли до розгляду SDLC. З’ясувавши мету створення концепту (можливість візуалізації процесу, планування доставлення продуктів, керування ризиками та швидкого визначення поточного стану), перейшли до індивідуального розгляду кожного етапу, яких всього є 8:

Ідея («Еврика!»)
Визначення вимог (що робимо та як робимо)
Дизайн системи (взагалі по загалям та деталі реалізації)
Розробка (картинка цифр з фільму «Матриця»)
Тестування (100 шляхів не зробити)
Розгортання (- Як іде деплой? – Все під контролем!)
Підтримка (мор стартапів)
Закриття (Internet Explorer та Windows XP)

Нагадали, що до циклу входять лише 2й-7й етапи (створити ідею та закритись можна лише раз) та поговорили про строк розробки різних проєктів (1-3 місяці, 6-8 років, до 15 років).

Другу частину зачали з розгляду другого «кільця тестувальника» – STLC, з’ясувавши особливості концепту (критерії початку і критерії завершення). Далі окремо розглянули кожний з 6 етапів:

Аналіз вимог (креатив та вимоги до вимог)
Планування тестування (хто за що відповідальний)
Створення тест-кейсів (повне охоплення вимог)
Налаштування тестового середовища (особистий майданчик для QA)
Виконання тестів (перевіряємо те, що запланували)
Завершення тестування (робимо загальний звіт)

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

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

У випадку із SDLC та STLC – це якісний продукт, розробка якого вклалась в терміни та бюджет, у випадку із цариною QA – це якнайвища якість продукту, яка досягається копіткою розумовою працею, а у випадку із початківцями у сфері ІТ – це перша робота, щоб отримати яку треба запастися терпінням та щоденно займатись саморозвитком, не опускаючи рук до кінця. Тож, бажаю шановним читачам дійти до бажаної мети попри всі складнощі!

Поширюй: