Тестування ПЗ

Привіт друзі! Вітаємо вас на курсі тестування програмного забезпечення! Все безкоштовно, без реєстрацій та смс 😁

Ми, автори QA Mania, маємо майже 10-річний досвід навчання тестуванню і ось нарешті оформили всі наші уроки у серії зручних та коротких роликів по принципу: одна тема – одне відео. Ми й самі не взахваті від годинних відео одразу про все на світі, тож зробили той контент, який нам самим дуже подобається ❤️

Найбільший вклад у створення курсу та адаптацію його до сучасного вигляду зробили: Льоша Остапов, Міша Чуб, Люба Монсар ⭐

Всі відео загалом – менше двох годин! Але дають гарне уявленя про те, що і як роблять тестери. Вагаєтесь, чи варто вчитись? Подивіться відео, пройдіть кілька практичних завдань, щоб зрозуміти, чи цікаво це саме вам!

Окрім, власне, відео – в курсі є ще й різноманітна практична робота, посилання на яку ви зможете знайти нижче. Успіхів та приємного навчання!

Якщо хочете, можете переглядати весь курс на нашому Youtube каналі – посилання на список відтворення: QA Shorts

Розділ 0 – Що треба знати перед початком?

Ми розробляли та адаптували наш курс багато разів, щоб зробити його цікавим та корисним широкій авдиторії: від студентів ВНЗ до людей, що захотіли змінити професію та почати працювати в IT.

✅ Технічна освіта – буде плюсом, але не є обов’язковою. Відмазатись тим, що ви “гуманітарій” не вийде

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

✅ Бажання та хороший настрій – ця версія курсу розроблялась для самостійного опрацювання, тож мотивувати себе доведеться самостійно 😁

✅ Якщо є питання, скарги, пропозиції – пишіть нам!

Розділ 1 – Загальна інформація

Для чого потрібні тестери?

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

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

І для того, щоб програми менше глючили і приносили більше щастя користувачам – потрібні тестери. Ми беремо на себе перший удар – знаходимо баги до того як вони встигнуть заподіяти шкоди користувачам

Що таке тестування?

Тестування – це процес. Офіційне визначення за ISTQB ви можете зараз бачити на екрані. Але що по суті? Тестування починається з ідеї створити програму і закінчується тоді, коли вже програмою перестають користуватись. Цей процес включає в себе експлуатацію програми чи її частини – поки руками не поклацаєш, не дізнаєшся, як вона працює.

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

І все це задля того, що продемонструвати, що програма виконує свої функції 

І впевнитись, що вона працює згідно вимог. 

Нащо тестери тестують? Які в нас цілі?

Багато хто хибно думає, що головна мета – ламати, знаходити баги. Якби це було так, то чим більше багів знайшов, тим ти крутіший, а якщо не знайшов – ганьба сім’ї!

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

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

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

Що треба тестувати?

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

Нащо вчитись тестувати?

Раніше я ламав все, чого торкався, а мама мені казала, що я – рукожоп. Я і зараз не змінився, але тепер за це мені ще й гроші платять! Це –  моя професія. Чому варто вчитись тестувати, навіть якщо маєте природній талант –  все, чого ви торкаєтесь, починає глючити?

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

Що таке баг?

Баг – це невідповідність очікуваного та отриманого результату роботи програми

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

Офіційна література налічує не менше дюжини слів, що означають баг: error, mistake, defect, anomaly, deviation, problem, fault, failure, incident, fail, crash. чи є різниця? Так!

Розрізняють три головні етапи багу – під час розробки  люди роблять помилку (error), в результаті в коді програми з’являється дефект. І якщо цей дефект змінює очікуваний результат коричтувача,  користувач бачить результат дефекту – Failure.

Що зазвичай роблять тестери окрім тестування?

  1. Планують тестування – щоб заздалегідь знати, що і в якому порядку робити
  2. Тестують вимоги – тобто, читають, аналізують та перевіряють, чи нема в тексті логічних помилок
  3. Готуються до тестування – до початку тестів треба написати тести, підготувати дані, створити умови для тестування
  4. Звітують про результати тестування – надають список виконаних тестів, їх статус, опис знайдених багів
  5. Аналізують результати тестування, щоб виміряти якість програми
  6. І найголовніше – надають резолюцію, чи готова протестована програма до експлуатації

7 принципів тестування

  1. Тестування показує присутність дефектів, а не їх відсутність. Тобто, якщо в результаті тестування ви не знайшли жодного багу, це не означає, що їх там нема
  2. Вичерпне тестування неможливо – просто уявіть, що при тестуванні калькулятора треба ввести ВСІ числа – від мінус нескінченності до плюс нескінченності 
  3. Раннє тестування заощаджує час та гроші – попередити баг простіше, ніж потім виправляти. Це легше уявити на реальному прикладі – в 1999 році НАСА запустило до Марсу супутник – Mars Climate Orbiter вартістю більш ніж 300 мільйонів доларів. Він 9 місяці летів, а коли долетів… розбився об поверхню. Досліджуючи проблему, виявилось, що одна з команд розробки використовувала імперську систему величин – фути, унції. Інші команди – метричну. В результаті прогама польоту мала некоректні дані. Якби тестували уважніше, зекономили б купу часу і грошей
  4. Дефекти часто знаходяться поруч – якщо знайшли один, пошукайте, десь поруч має бути ще
  5. Зважайте на парадокс пестициду – якщо часто повторювати одні й ті самі тести, вони перестануть знаходити помилки. Тому час від часу їх треба оновлювати
  6. Тестування завжди залежить від контексту – програми керування літаками чи медичним обладнанням варто тестувати ретельніше, ніж черговий інтернет-магазин
  7. Омана відсутності помилок – навіть якщо програма працює згідно вимог та тестування не знайшло жодного багу, це не означає, що вона задовільнить очікування користувачів

Чи потрібні тестерам soft skills?

Всі кажуть, що потрібні! Але не тільки тестерам – взагалі, вони потрібні всім. Тому варто подавати гарний приклад. Порада одна і вона дуже проста – не бути засранцем. Ставтесь до людей як до людей. Але в літературі зазвичай радять:

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

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

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

Що таке тест?

Це перевірка, що аспект роботи програми відповідає очікуванням, вимогам, стандартам. 

Давайте розберемо на прикладі.

Тест – це інструкція для інженера. Він дуже схожий на кулінарний рецепт – інструкцію для кухаря.

Мінімально він має мати

  • Назву, щоб ми точно знали, що тест робить
  • Кроки виконання, зроби це, потім це, потім це
  • Очікуваний результат – що має відбутись, коли ми виконаємо всі кроки

Що варто знати про тести для початку?

  • Один тест перевіряє одну вимогу за раз.Він не має перевірити всю програму. Якщо вимога складна, краще навіть кілька тестів написати. 
  • Всі тести мають містити конкретні дані, щоб бути повторюваними і об’єктивними, як характеристики якості. Ввів в калькулятор 2+2 = отримав чотири, а не “перевірити додавання”
  • Кожна дія має наслідок. Кожен тест має очікуваний результат. Мінімум один

Розділ 2 – Якість ПЗ

Що таке якість?

Якість – міра відповідності очікуваного та отриманого результатів.

Поняття якості – ключове для розуміння, як правильно тестувати будь-що. Це основа ваших тестів!

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

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

Для вимірювання якості розроблено низку міжнародних стандартів. Наразі тестування пз спирається на ISO 25010:2011

Які є характеристики якості?

Для того, щоб легше було виміряти якість програм, стандарт iso 25010 виділяє 8 її характеристик та низку підхарактеристик, кожну з яких можна виміряти об’єктивно – тобто будь-хто має мати змогу взяти інструменти для виміру та перевірити, наскільки програма відповідає заявленим характеристикам.

  • Функціональна відповідність – міра відповідності заявлених функцій програми до реальних. Найголовніша характеристика. 80% всіх тестів, що ви робитимете – саме перевірка функцій. 
  • Ефективність – продуктивність програми відносно використаних ресурсів за одиницю часу
  • Надійність – міра, в якій система спроможна продовжувати виконувати свої функції заданий проміжок часу
  • Зручність користування – міра, в якій програма допомагає вказаним користувачам досягати поставлених цілей
  • Безпека – міра, в якій програма здатна захистити дані користувача
  • Підтримуваність – міра легкості ремонту, модифікації чи покращення програми
  • Портативність – міра простоти переносу програми в інше середовище
  • Сумісність – міра відповідності виконання програмою функцій під час використання з іншими програмами в тому ж середовищі

До кожного пункту можна додати ‘за заданих умов’. Умови – важливі, і чим більше їх визначено заздалегідь – тим краще.

Схема – Атрибути якості згідно стандарту ISO 25010:2011

Як визначити характеристики якості випадкового предмету чи програми?

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

Самостійне завдання №1 – визначте та запишіть собі об’єктивні характеристи якості “Німбус-2000” згідно ISO 25010:2011.

Розділ 3 – як створюються програми?

Як створюються програми?

В наш час програми все рідше створюються однією людиною – щоб розробка не тягнулась роками і програма мала різноманітні функції, люди об’єднуються в команди. А якщо є команда, мають бути створені правила, за якими ця команда має працювати і взаємодіяти. Для цього етапи роботи були формалізовані в процеси, які ми називаємо життєвими циклами розробки або англійською SDLC,

а корисні рекомендації – в методології.

Ось аналогія – життя людини, це процес. Ми народжуємось, ідемо в школу, потім працюємо, сім’ю заводимо і так далі.

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

Нащо нам ця інформація?

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

Що таке Водоспад?

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

На прикладі це виглядає так: вирішили ви побудувати будинок.

  • Планування – ви вибираєте місце, бюджет, будівельну фірму, час, за який будинок має бути збудований
  • Вимоги – виписуєте все, що хочете мати в будинку – кількість кімнат, тип опалення, колір шпалер та інше
  • Дизайн – базуючись на ваших вимогах архітектор малює макет, обирає матеріали для будинку, цеглу чи дерево, наприклад
  • Розробка – будівельники будують
  • Тестування – будинок готовий, ви ходите зі своїм списком вимог та перевіряєте, чи всі вони виконані і в якій мірі
  • Експлуатація – живете в будинку – як щось зламалось – телефонуєте будівельникам, щоб приїхали та полагодили

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

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

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

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

  • На етапі формування вимог – проводити аналіз вимог, чи вони все описують повністю? Чи не суперечать вони одне одному? Чи можна їх протестувати?
  • На етапі дизайну – готувати тести
  • На етапі розробки – контролювати процес, наприклад – чи пишуть розробники юніт тести?
  • І тоді на етапі контролю якості тестувати нам буде знайно легше

Що таке В-модель?

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

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

Поки розробники придумують дизайн, ми готуємо тести для нього.

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

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

Ітеративні життєві цикли

На відміну від водоспаду та В-моделі, які є послідовними, в наш час популярними стали ітеративні життєві цикли. Назв ви можете знайти багато – спіральні,  інкрементальні, але суть одна – за невеликий проміжок часу: тиждень, два, місяць, треба запланувати невелику частину роботи і виконати її. По суті – кожну ітерацію циклу команда розробки проходить маленьку V-модель. В чому плюси такого підходу? Планувати невеликі задачі на короткий проміжок часу – легше. Точніше – складніше помилитись. В кінці кожної ітерації ми маємо готову частину роботи, яку можна продемонструвати замовнику програми чи користувачам, отримати він них хвалу чи зауваження, врахувати їх в роботі в наступних ітераціях. Чіткого кінця роботи в таких життєвих циклах може не бути – робимо стільки ітерацій, скільки хоче замовник, додаючи в продукт нові функції. В будь-який момент замовник може запропонувати нову ідею, відмовитись від старої, і, на відміну від послідовних життєвих циклів, зазвичай це не буде коштувати йому надто дорого. Звісно, якщо концепція змінюється кардинально, і роботу треба починати спочатку – різниці нема

Що таке методології?

Як вже було сказано в попередніх відео – це сталі рекомендації, як зробити розробку програм зручнішою, а результат – якіснішим. Методологій сформульовано багато, багато рекомендацій є загальними для більшості з них. Наприклад – зберігайте написаний код і документи в системах версійного контролю, таких як гіт. Просто здоровий глузд? Ні – методологія!

Більшість проєктів з розробки, що існують в Україні, стверджують, що вони використовують Agile методології, точніше, їх більш деталізовані варіанти: Scrum, Kanban, XP

Що таке аджайл? По суті – маніфест, що можна сформулювати всього в 5 реченнь (що і зробили його автори):

  • Люди та співпраця важливіші за процеси та інструменти
  • Працюючий продукт важливіший за вичерпну документацію
  • Співпраця із замовником важливіша за обговорення умов контракту
  • Готовність до змін важливіша за дотримання плану

хоча, цінності, що справа важливі, ми все ж цінуємо більше те, що зліва.

Посилання на маніфест я залишу в описі. І там же на сторінці є 12 принципів аджайл розробки. Я пропоную вам ознайомитись з ними самостійно!

Наче нічого особливого? Але вся геніальність саме в простоті. Використовуйте здоровий глузд – це вже половина успіху!

Процеси для людей!

Зазвичай далі я розказую про специфіку конкретних методологій, зокрема – scrum, як найпопуляршіної. Сценарій я саме так і планував.

Але! Давайте повернемось до скраму пізніше – він точно не втече.

Зараз я хочу застерегти вас від типової помилки багатьох інженерів.

Не виконуйте сліпо всі рекомендації методології

Часто процес розробки перетворюється в карго-культ – люди не розуміють, нащо вони виконують якісь дії. В методології написано, значить треба. І роблять навіть те, що шкодить процесу розробки. Будь-яка методологія – це в першу чергу – рекомендації, а не чітка інструкція. Робіть лише те, що вам зрозуміло і корисно. А якщо розумієте, що треба робити щось, не передбачене методологією – робіть!

Коли в тому ж скрамі команду змушують працювати по незручному процесу, це порушує перший пункт аджайл маніфесту 

  • Люди та співпраця важливіші за процеси та інструменти

Значить, у вас вже не аджайл і не скрам.

Завжди використовуйте здоровий глузд, навіть якщо це не рекомендовано методологією

Що таке СІ/СD?

Розділ 4 – Вимоги

Що таке вимоги?

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

Якщо не вірите, що це складно, спробуйте пояснити вашій бабусі, що таке мем (тролфейс). 

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

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

Ми з Мішою вже записали відео по вимогам – воно все ще не втратило актуальність, дуже круте, рекомендую подивитись!

Практика! Аналіз вимог за 5 хвилин

Документ з вимогами для аналізу

Чек ліст для аналізу вимог

Чек ліст можна використовувати з будь-якими вимогами! Як маєте зауваження – пишіть!

Самостійне завдання №2 – Пройти чекліст. Додати в документ правки, коментарі, можна структурувати. Виписати список питань, щоб отримати повні, точні, однозначні вимоги до ПЗ

Вимоги vs Дизайн

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

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

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

Що таке Артефакт?

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

Є 3 ознаки артефакту:

  1. Він створений членом команди та приносить користь. Тому план робіт – це артефакт, а повідомлення в чаті – ходімо на пиво – ні.
  2. Кожний артефакт має власника – людину, що створила чи відповідає за артефакт. За вимоги – аналітик, за код – розробник, за тест – тестер. 
  3. Кожен артефакт гарантовано збережено – лист – на поштовому сервері, вимоги – в конфлюенсі, код – в гіті. Якщо ви на листочку намалювали алгоритм – це не артефакт, бо листочок може загубитись

Нажаль, словом артефакт зараз користуються рідко, але розуміти, що це таке – важливо.

Розділ 5 – Тести та інші корисні артефакти

Яка є тестова документація?

Що таке тест план?

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

Якщо ви думаєте – я новачок, нащо мені знати, що таке тест план?  – ви маєте знати, що в цьому документі можна прочитати корисного саме для вас.

Документ має містити:

  • Стратегію – як конкретно команда має тестувати, які види тестів – використовувати
  • Об’єм робіт – що ми тестуємо, а що ні
  • Умови початку тестування – наприклад, необхідний мінімум: в нас мають бути написані тести, білд застосунку та працююче середовище
  • Умови закінчення тестування – наприклад, ми тестуємо, поки не залишиться відкритих багів рівня major та вище
  • Люди – хто буде тестувати? До кого можна звернутись за допомогою?
  • Ресурси – комп’ютери, програми, середовища, в яких можна робити тести
  • Час – це ж план! До якого числа ми маємо виконати тести? Коли дедлайн?
  • Ризики – це перелік подій, що можуть трапитись під час тестування і вплинути на його перебіг та що ми будемо робити, якщо такі події трапляться. Наприклад. Якщо в тестера зламається комп’ютер – ми дамо йому новий, який купимо заздалегідь
Шаблон тест плану у вигляді діаграми

Що таке чек ліст?

Це список перевірок, які тестер має зробити. На відміну від тест кейсу, чек ліст не містить кроків та окремо прописаних очікуваних результатів. По суті – назва тест кейсу може бути перевіркою чек лісту.

Які ж плюси є у використанні чек лістів? Їх писати швидше, і оскільки тексту менше, самих перевірок можна написати більше. 

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

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

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

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

Які є види тестування?

Наша класифікація видів тестування

Є багато різних способів класифікувати ваші тести. Навіщо? Щоб згрупувати їх потім за певною ознакою – їх же пишуть більше за один. Ми пропонуємо класифікацію вище ↑

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

Цю класифікацію ми розробили і запропонували ще років 8 тому. Вона лишається актуальною і досі, але точно не повною. За цим посиланням можете переглянути класифікацію, де видів тестування більше 100!

⚠️ До речі, це не перше наше відео з розбором видів тестування 😉

Розділ 6 – Тест дизайн

Що таке тест дизайн?

Це підходи, що дозволяють проводити тестування ефективно – тобто зробити максимум перевірок за мінімум часу. Стандарт ISO 29119 налічує аж 17 загальновживаних технік тест дизайну, які поділяють на 3 групи:

  1. На основі вимог (також відомі як техніки чорного ящику). Коли ми знаємо, що програма має робити, але не знаємо, як вона влаштована зсередини
  2. Структурні (також відомі як техніки білого ящику). Коли ми знаємо, як програма влаштована і можемо написати тест на кожен цикл, кожну умову всередині програми
  3. На основі досвіду. Коли ми вже протестували 10 інтернет магазинів, і якщо нам дати на тестування 11 – ми навіть без вимог знатимемо, що з ним робити

Класи еквівалентності та граничні значення

класи еквівалентності
граничні значення

Класи еквівалентності – техніка тест дизайну чорного ящику, яка рекомендує розбивати вхідні чи вихідні дані програми на групи, в яких поведінка програми має бути однакова згідно документації

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

Якщо користувач вказує свій дохід за рік від 0 до 10 000 грн включно, ставка податоку – 0

Якщо від 10 000 до 100 000 включно – 10 %

Якщо від 100 000 – 30 %

Техніка тест дизайну радить – якщо поведінка програми в кожному діапазоні однакова для будь-якого числа – то ці діапазони є класами еквівалентності. І для їх тестування необхідно і достатньо вибрати лише по 1 представнику кожного класу. Не треба проводити тести з суммами 10, 20, 30, 100 – результат той самий. Тому і тест має бути лише один. 

В результаті, маємо 3 позитивні тести для кожного класу, наприклад – 100 грн 42 коп, 50 000, 200 000 тис. 

Але це ще не все – окрім позитивних тестів, ми можемо створити негативні – наприклад, перевірити поведінку програми, якщо ввести значення менше 0. Чи букви? Кирилицю? Спец символи? Залишити порожнім?

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

З попереднього прикладу – маємо 3 границі, які варто перевірити – 0, 10 000, 100 000

Кожна границя перевіряється з 2 сторін, тому тестів матимемо аж 5:

0 – 10000, 10000 1 коп, 100 000 та 100 000 та 1 коп. 

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

Перехід між станами / State Transition

Таблиці рішень / Decision Table

Практика з Тест Дизайну

✅ Вимоги, що можна аналізувати: CircusTicketApp SRS 2.1

✅ Вже знайомий нам чек ліст, що допоможе з аналізом вимог: Requirements checklist for QA v1.3

✅ Тест дизайн, що я робив у відео: Test Design

✅ Наше старе відео з практикою тест дизайну: Тестування ПЗ. Техніки тест дизайну – практикум

Самостійне завдання №3 – Прочитати вимоги. Зробити аналіз вимог та заповнити чек ліст. Доробити тест дизайн. Написати тест кейси та чек лісти для тестування системи продажу білетів до цирку

Розділ 7 – Баг репорт

Що таке баг репорт?

Нащо реєструвати баги?

  • Щоб інформувати команду та замовників про наслідки та обставини проблеми з якістю
  • Щоб пріоритезувати проблеми для подальшого виправлення
  • Щоб допомогти розробникам в локалізації та виправленні дефекту

Що має мати баг репорт?

  • Унікальний номер, щоб відрізняти баги
  • Назва – коротка і змістовна. Має давати відповідь на питання що? Де? Коли? сталось
  • Кроки для відтворення багу. Як в тест кейса
  • Очікуваний результат. Бажано з посиланням на вимоги, як додатковий доказ
  • Отриманий результат
  • Серйозність, англійською северіті – параметр, що вказує, наскільки руйнівні наслідки має баг
  • Пріоритет – параметр, що вказує, як швидко треба виправити баг
  • Додатково, якщо це допоможе у виправленні дефекту, ви можете вказати номер білда програми, в якому ви знайшли дефект.
  • Скріншоти, логи
  • Оскільки баг репорт, це артефакт – в нього обов’язково має бути власник – його автор, чи розробник, що його виправляє, чи тестер, що буде перевіряти його після виправлення
  • Статус – місце багу в своємому життєвому циклі

Які можуть бути життєві цикли багів? Залежить від процесу роботи вашої команди. Найпростіший варіант: баг може бути відкритий та закритий. Може мати додаткові статуси – в розробці, готовий до тестування…Головне – життєвий цикл має бути зручний для вас! 

Ми з Мішою вже записували детальне відео про реєстрацію дефектів. Посилання ви просто зараз бачите на екрані. Тестування ПЗ. Реєстрація дефектів

Що таке серйозніть та пріоритет? (Severity & Priority)

Серйозність – параметр, що вказує, наскільки руйнівні наслідки має баг. Цей параметр має встановлювати тестер. Зазвичай, критерії серйозності для кожного окремого проєкту можуть бути написані в тест плані. А типово:

  • Blocker – баг блокує використання функцій програми. Якщо в калькуляторі не натискаються цифри, ви не зможете протестувати арифметичні функції
  • Critical – конкретна функція працює неправильно чи не працює, без можливості обійти цей баг. Наприклад, в текстовому редакторі не працює збереження тексту у файл. Ні через меню, ні через натискання комбінації Ctrl+S
  • Major – конкретна функція працює неправильно чи не працює, але є можливість обійти цей баг. Наприклад, в текстовому редакторі не працює збереження тексту через натискання комбінації Ctrl+S
  • Minor – функція програми працює частково. Чи є проблеми з користувацьким інтерфейсом
  • Trivial – баг не впливає на досвід користування програмою. Зазвичай це незначні проблеми з інтерфейсом чи баги, які тестери бачили раз , але відтворити не змогли

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

А тепер вишенька на торті – те, що люблять питати на співбесідах – чи маєть співпадати серйозність та пріоритет багів? Зазвичай – так. Але іноді трапляється, що дуже критичний баг отримує низький пріоритет просто тому що функцією ніхто не користується. Програма вилітає кожний високосний рік 29 лютого? Критично, але не пріоритетно. Мало хто взашалі дізнається про такий баг.

А тепер уявіть – запускаю я новий сайт qa maina, а роблю малесеньку помилку в назві – на функції сайту цей баг не впливає, але я захочу виправити його якнайшвидше

Розділ 8 – Практика тестування та звітність

Цирк! – Те, на чому ви будете практикувати тестування

💡 Вимоги до цирку CircusTicketApp SRS 2.1

✅ Код цирку на github https://github.com/Ypurek/Circus-Ticket-App

✅ Цирк онлайн http://circus.qamania.org

API документація

⚠️ як встановити пайтон та гіт

Практика – тестова сесія

Це запис дій, що має робити тестер, коли тестує додаток без заздалегідь написаних тестів і навіть без вимог. 

Нащо це записувати?

  1. Якщо ви знайдете баг – у вас буде список дій, що до нього привели
  2. Тестова сесія дозволяє оцінити, які функції програми ви перевірили, а які пропустили
  3. Якщо ваш безпосередній керівник спитає – що ви сьогодні робили, замість невизначеного “ну я тестував” ви відповісте, що саме ви тестували і тестова сесія стане чудовим доказом вашої роботи

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

Записана нами тестова сесія

Самостійне завдання №4 – Провести тестування та записати тестову сесію для сторінки персональних даних користувача цирку

Практика – Реєстрація дефектів (Bug Reporting)

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

На прикладі багу, поміченого в попередніх відео.

  1. Не поспішати. Тестування, це про аналіз, а не про поспіх. Типова помилка новачка – одразу спробувати відтворити баг ще раз, не вивчивши контекст. А що як другий раз баг не відтвориться? Обдумаємо кроки – на екрані написано одне, а робить інше. Або форма в браузері відправляє невірні дані, або застосунок неправильно обробляє дані. 
  2. Вивчити баг. Цей процес називається root cause analysis – аналіз причини багу. Це має допомогти розробникам в його вирішенні, особливо, коли продукт великий і різні розробники пишуть різні частини програми. Відкриємо дев тулз, дивимось мережеві запити, робимо фільтр по запиту, що нас цікавить. Дивний час. Напевне в хвилинах. Спробуємо змінити… це воно! Причина – баг фронтенду програми, і виправляти його буде фронтенд розробник.
  3. Записати список дій, що призвели до багу, поки добре пам’ятаєте (пишемо баг репорт)
  4. Робимо скріншот
  5. Аналізуємо схожий функціонал – може і він містить помилки

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

Це повна маячня. І я це кажу не тільки тому, що я тестер і повторюю одні і тіж тести раз за разом, перевіряючи, чи не змінилась поведінка програми. Будь-яка дія, яку ми робимо – завжди має якийсь контекст, що постійно змінюється і може змінити результат. Інший білд, інший комп’ютер, інша швидкість інтернету, інший час чи місце. Якщо дії не змінні, а результат змінюється – ви щось не врахували – аналізуйте ще

Самостійне завдання №5 – Провести тестування цирку та зареєструвати мінімум 5 дефектів

Що таке тестові метрики?

Практика – тестова звітність

Самостійне завдання №6 – Після проведеного вами тестування напишіть тестовий звіт

Розділ 9 – інструменти і корисна інформація

Jira