Привіт друзі! Вітаємо вас на курсі тестування програмного забезпечення! Все безкоштовно, без реєстрацій та смс 😁
Ми, автори QA Mania, маємо майже 10-річний досвід навчання тестуванню і ось нарешті оформили всі наші уроки у серії зручних та коротких роликів по принципу: одна тема – одне відео. Ми й самі не взахваті від годинних відео одразу про все на світі, тож зробили той контент, який нам самим дуже подобається ❤️
Найбільший вклад у створення курсу та адаптацію його до сучасного вигляду зробили: Льоша Остапов, Міша Чуб, Люба Монсар ⭐
Всі відео загалом – менше двох годин! Але дають гарне уявленя про те, що і як роблять тестери. Вагаєтесь, чи варто вчитись? Подивіться відео, пройдіть кілька практичних завдань, щоб зрозуміти, чи цікаво це саме вам!
Окрім, власне, відео – в курсі є ще й різноманітна практична робота, посилання на яку ви зможете знайти нижче. Успіхів та приємного навчання!
Якщо хочете, можете переглядати весь курс на нашому Youtube каналі – посилання на список відтворення: QA Shorts
Ми розробляли та адаптували наш курс багато разів, щоб зробити його цікавим та корисним широкій авдиторії: від студентів ВНЗ до людей, що захотіли змінити професію та почати працювати в IT.
✅ Технічна освіта – буде плюсом, але не є обов’язковою. Відмазатись тим, що ви “гуманітарій” не вийде
✅ Англійська мова – деякі матеріали для практики ми надаємо англійською мовою. Це мова, якою розмовляють пишуть та читають майше всі IT фахівці у світі. Якщо не впевнені, з чого почати – почніть саме з мови!
✅ Бажання та хороший настрій – ця версія курсу розроблялась для самостійного опрацювання, тож мотивувати себе доведеться самостійно 😁
✅ Якщо є питання, скарги, пропозиції – пишіть нам!
Для чого потрібні тестери?
Програми вирішують проблеми користувача чи пришвидшують їх вирішення. Калькулятор дає змогу швидше робити обчислення, ніж я б зробив ручкою на папері. Твітер – дізнатись новини швидше, ніж сходити й купити газету. Авіасимулятор дозволить мені пілотувати реактивний винищувач, навіть якщо мене укачує та я боюсь висоти.
В ідеальному світі, де поні стрибають через веселку, я б на цьому і закінчив. Нажаль, в реальному світі, програми, випадково чи навмисно, працюють не так, як того хочуть користувачі – багують, глючать, туплять…
І для того, щоб програми менше глючили і приносили більше щастя користувачам – потрібні тестери. Ми беремо на себе перший удар – знаходимо баги до того як вони встигнуть заподіяти шкоди користувачам
Що таке тестування?
Тестування – це процес. Офіційне визначення за ISTQB ви можете зараз бачити на екрані. Але що по суті? Тестування починається з ідеї створити програму і закінчується тоді, коли вже програмою перестають користуватись. Цей процес включає в себе експлуатацію програми чи її частини – поки руками не поклацаєш, не дізнаєшся, як вона працює.
Але не тільки – в процес вкючається ще й підготовка до тестування, аналіз документації (так, тестери багато читають).
І все це задля того, що продемонструвати, що програма виконує свої функції
І впевнитись, що вона працює згідно вимог.
Нащо тестери тестують? Які в нас цілі?
Багато хто хибно думає, що головна мета – ламати, знаходити баги. Якби це було так, то чим більше багів знайшов, тим ти крутіший, а якщо не знайшов – ганьба сім’ї!
Насправді, головна мета тестування – впевнитись, що програма працює, і робить це згідно вимог, офіційної документації, оічкувань користувачів, промислових стандартів.
Додаткова мета – запобігти багам. Для цього ми як раз і читаємо документацію, щоб побачити там нелогічні чи неоднозначні речення та уточнити їх до того, як програмісти все запрограмують.
Ще одна мета – виміряти якість. Сказати, на скільки відсотків програма якісна. І вже як наслідок всього переліченого – пошук багів з метою їх виправлення.
Що треба тестувати?
Є типова помилка новачка в тестуванні – якщо дати завдання протестувати калькулятор, новачок почне ділити на нуль, брати корінь від’ємного числа, множити надвеликі числа… всі ці тести дійсно мають бути виконані і навіть мають назву – негативне тестування. Помилка в тому, що в першу чергу треба впевнитись, що калькулятор виконує свої функції, наприклад: додавання, віднімання, множення та ділення. Такі тести називаються позитивними і завжди мають бути виконані в першу чергу!
Нащо вчитись тестувати?
Раніше я ламав все, чого торкався, а мама мені казала, що я – рукожоп. Я і зараз не змінився, але тепер за це мені ще й гроші платять! Це – моя професія. Чому варто вчитись тестувати, навіть якщо маєте природній талант – все, чого ви торкаєтесь, починає глючити?
Щоб робити максимум користі за одиницю часу – тестувати ефективно. Щоб взаємодіяти з іншими інженерами – знання термінології, якою оперують інші інженери, процесів роботи, тобто що, хто та коли має робити. Щоб знати інструменти для роботи
Що таке баг?
Баг – це невідповідність очікуваного та отриманого результату роботи програми.
Очікували у подарунок новий телефон, сказали друзям і вже уявляєте, як тримаєте його в руках. Але друзі вас зрозуміли неправильно, тому отриманий подарунок не відповідає вашим очікуванням – це баг. Хотіли подивитись відео на ютуб, а браузер вилітає – баг. Не подобається дизайн сайту новин – теж баг.
Офіційна література налічує не менше дюжини слів, що означають баг: error, mistake, defect, anomaly, deviation, problem, fault, failure, incident, fail, crash. чи є різниця? Так!
Розрізняють три головні етапи багу – під час розробки люди роблять помилку (error), в результаті в коді програми з’являється дефект. І якщо цей дефект змінює очікуваний результат коричтувача, користувач бачить результат дефекту – Failure.
Що зазвичай роблять тестери окрім тестування?
7 принципів тестування
Чи потрібні тестерам soft skills?
Всі кажуть, що потрібні! Але не тільки тестерам – взагалі, вони потрібні всім. Тому варто подавати гарний приклад. Порада одна і вона дуже проста – не бути засранцем. Ставтесь до людей як до людей. Але в літературі зазвичай радять:
Кооперація з командою, а не боротьба – не варто тикати розробникам в обличчя кожним знайденим багом і доводити, що програмісти пишуть код погано – всі можуть помилятись, ваша робота в тому і є, щоб не пропустити ці помилки
Якщо хтось зробив помилку – не варто кидатись звинуваченнями, варто проаналізувати причини та розробити план дій, щоб помилки не повторювались
Робота на результат – вся команда, і тестери, і розробники працюють заради спільного результату і не можуть існувати окремо одне від одного
Що таке тест?
Це перевірка, що аспект роботи програми відповідає очікуванням, вимогам, стандартам.
Давайте розберемо на прикладі.
Тест – це інструкція для інженера. Він дуже схожий на кулінарний рецепт – інструкцію для кухаря.
Мінімально він має мати
Що варто знати про тести для початку?
Що таке якість?
Якість – міра відповідності очікуваного та отриманого результатів.
Поняття якості – ключове для розуміння, як правильно тестувати будь-що. Це основа ваших тестів!
Якість – як здоров’я: Саме по собі в природі не зустрічається. В кожного своє. Є загальні практики, що можуть як покращити, так і погіршити його.
Сама по собі, якість – суб’єктивна. Комусь більш за все до вподоби айфон, комусь – андроід, комусь – взагалі кнопочний телефон. І це не означає, що інші телефони гірше зроблені, ніж той, що потрібен вам.
Для вимірювання якості розроблено низку міжнародних стандартів. Наразі тестування пз спирається на ISO 25010:2011
Які є характеристики якості?
Для того, щоб легше було виміряти якість програм, стандарт iso 25010 виділяє 8 її характеристик та низку підхарактеристик, кожну з яких можна виміряти об’єктивно – тобто будь-хто має мати змогу взяти інструменти для виміру та перевірити, наскільки програма відповідає заявленим характеристикам.
До кожного пункту можна додати ‘за заданих умов’. Умови – важливі, і чим більше їх визначено заздалегідь – тим краще.
Як визначити характеристики якості випадкового предмету чи програми?
Чому ми взагалі вивчаємо характеристики якості ПЗ на прикладі пральної машинки? Бо програми бувають різні – для різних платформ, з різнимим інтерфейсами. Ніколи не знаєш заздалегідь, з чим матимеш справу. Тому ми даємо всім нашим слухачам абстрактне завдання: визначити характеристики якості цеглини, стола, повітряної кульки.
Самостійне завдання №1 – визначте та запишіть собі об’єктивні характеристи якості “Німбус-2000” згідно ISO 25010:2011.
Як створюються програми?
В наш час програми все рідше створюються однією людиною – щоб розробка не тягнулась роками і програма мала різноманітні функції, люди об’єднуються в команди. А якщо є команда, мають бути створені правила, за якими ця команда має працювати і взаємодіяти. Для цього етапи роботи були формалізовані в процеси, які ми називаємо життєвими циклами розробки або англійською SDLC,
а корисні рекомендації – в методології.
Ось аналогія – життя людини, це процес. Ми народжуємось, ідемо в школу, потім працюємо, сім’ю заводимо і так далі.
А методологія – це рекомендації – лягати спати вчасно, мити руки після туалету, спортом займатись. Ці рекомендації не змінюють процес, але роблять його приємнішим, а результати кожного етапу якіснішими.
Нащо нам ця інформація?
Що таке Водоспад?
Водоспад – найстаріший, формально описаний процес, що описує наступні фази розробки програм: планування, збір вимог, дизайн, розробка, тестування, експлуатація.
На прикладі це виглядає так: вирішили ви побудувати будинок.
Мінуси: всі дії строго послідовні, якщо на етапі будівництва ви розумієте, що хотіли більше кімпат – повернутись, переробити проєкт буде дорого і важко.
Ще мінус – пізнє тестування (хоча це швидше контроль якості) – якщо будинок побудували погано, ви дізнаєтесь про це, коли будівельники вже поїдуть
Звучить не дуже, так? Чи можукть бути тут плюси? Так. Якщо ви робите типову задачу і всі чітко знають свої ролі (побудували вже ціле місто типових будинків) – водоспад у вас працює. Наразі, багато великих компаній все ще успішно використовують таку модель, наприклад – у військовій чи космічній сфері.
Що має робити тестер в проєкті, що працює за водоспадом? Згідно з принципами тестування (я робив окреме відео на цю тему, посилання в описі) – ми маємо починати тестування якомога раніше, бо тестування, це не просто контроль якості.
Що таке В-модель?
V модель – покращений водоспад. Для кожного, вже знайомого нам етапу ми заздалегідь придумуємо критерії відповідності. Якщо результат етапу нас не влаштовує, ми його перероблюємо. Нереалістичний план – продумати і запланувати ще раз! Потім ще подякуєте! Ця перевірка називається валідація.
Для кожного кроку моделі до розробки ми маємо створити відзеркалений рівень тестів. Поки аналітики готують вимоги – ми готуємо тести, що зможуть перевірити ці вимоги,
Поки розробники придумують дизайн, ми готуємо тести для нього.
А коли програма буде готова, ми почнемо ці тести виконувати в порядку від тестів дизайну до рівня вимог. Ці тести називається верифікацією
Власне, В-модель формалізує активності тестерів, які ми і самі робили б згідно принципів тестування і в водоспаді, і дає нам більще можливостей впливати на фінальну якість продукту.
Ітеративні життєві цикли
На відміну від водоспаду та В-моделі, які є послідовними, в наш час популярними стали ітеративні життєві цикли. Назв ви можете знайти багато – спіральні, інкрементальні, але суть одна – за невеликий проміжок часу: тиждень, два, місяць, треба запланувати невелику частину роботи і виконати її. По суті – кожну ітерацію циклу команда розробки проходить маленьку V-модель. В чому плюси такого підходу? Планувати невеликі задачі на короткий проміжок часу – легше. Точніше – складніше помилитись. В кінці кожної ітерації ми маємо готову частину роботи, яку можна продемонструвати замовнику програми чи користувачам, отримати він них хвалу чи зауваження, врахувати їх в роботі в наступних ітераціях. Чіткого кінця роботи в таких життєвих циклах може не бути – робимо стільки ітерацій, скільки хоче замовник, додаючи в продукт нові функції. В будь-який момент замовник може запропонувати нову ідею, відмовитись від старої, і, на відміну від послідовних життєвих циклів, зазвичай це не буде коштувати йому надто дорого. Звісно, якщо концепція змінюється кардинально, і роботу треба починати спочатку – різниці нема
Що таке методології?
Як вже було сказано в попередніх відео – це сталі рекомендації, як зробити розробку програм зручнішою, а результат – якіснішим. Методологій сформульовано багато, багато рекомендацій є загальними для більшості з них. Наприклад – зберігайте написаний код і документи в системах версійного контролю, таких як гіт. Просто здоровий глузд? Ні – методологія!
Більшість проєктів з розробки, що існують в Україні, стверджують, що вони використовують Agile методології, точніше, їх більш деталізовані варіанти: Scrum, Kanban, XP
Що таке аджайл? По суті – маніфест, що можна сформулювати всього в 5 реченнь (що і зробили його автори):
хоча, цінності, що справа важливі, ми все ж цінуємо більше те, що зліва.
Посилання на маніфест я залишу в описі. І там же на сторінці є 12 принципів аджайл розробки. Я пропоную вам ознайомитись з ними самостійно!
Наче нічого особливого? Але вся геніальність саме в простоті. Використовуйте здоровий глузд – це вже половина успіху!
Процеси для людей!
Зазвичай далі я розказую про специфіку конкретних методологій, зокрема – scrum, як найпопуляршіної. Сценарій я саме так і планував.
Але! Давайте повернемось до скраму пізніше – він точно не втече.
Зараз я хочу застерегти вас від типової помилки багатьох інженерів.
Не виконуйте сліпо всі рекомендації методології
Часто процес розробки перетворюється в карго-культ – люди не розуміють, нащо вони виконують якісь дії. В методології написано, значить треба. І роблять навіть те, що шкодить процесу розробки. Будь-яка методологія – це в першу чергу – рекомендації, а не чітка інструкція. Робіть лише те, що вам зрозуміло і корисно. А якщо розумієте, що треба робити щось, не передбачене методологією – робіть!
Коли в тому ж скрамі команду змушують працювати по незручному процесу, це порушує перший пункт аджайл маніфесту
Значить, у вас вже не аджайл і не скрам.
Завжди використовуйте здоровий глузд, навіть якщо це не рекомендовано методологією
Процеси для людей!
Курс про тестування був би не повний, якби я не розповів вам про одну з найпопулярніших методологій розробки ПЗ. Сама назва походить від футбольного терміну, коли всі гравці команди кидаються на м’яч.
Що вам треба знати про скрам?
Що таке СІ/СD?
Що таке вимоги?
Це опис того, що хоче людина, щоб вирішити свою проблему. Вони можуть бути в різній формі – просто текст, діаграма, схема. Суть – одна. Це лише здається, що написати вимоги – легко. Насправді, щоб написати зрозумілі, послідовні, повні вимоги …., треба мати талант. Тому в процесі розробки існує окрема роль – аналітик. Людина, що слухає вимоги замовника, задає уточнюючі питання та може написати вимоги, зрозумілі команді розробки та тестування, та контекст, як ці вимоги зрозуміти однозначно.
Якщо не вірите, що це складно, спробуйте пояснити вашій бабусі, що таке мем (тролфейс).
Зазвичай, одна вимога не може описати всю проблему та очікування користувача, тому групу логічно пов’язаних функціональних та нефункціональних вимоги описують у вигляді фічі (особливості).
Наші головні задачі, як тестерів – вміти аналізувати вимоги, знаходити в них неточності та потенційні баги, та на їх основі створювати наші тести.
Ми з Мішою вже записали відео по вимогам – воно все ще не втратило актуальність, дуже круте, рекомендую подивитись!
Практика! Аналіз вимог за 5 хвилин
✅ Документ з вимогами для аналізу
Чек ліст можна використовувати з будь-якими вимогами! Як маєте зауваження – пишіть!
Самостійне завдання №2 – Пройти чекліст. Додати в документ правки, коментарі, можна структурувати. Виписати список питань, щоб отримати повні, точні, однозначні вимоги до ПЗ
Вимоги vs Дизайн
Вимоги висувають замовники чи користувачі програми. Вислухавши їх, команда розробки може запропонувати рішення, з яких замовник може обрати те, що йому більше подобається, і відповідно команда почне працювати. Хоче калькулятор застосунком з кнопочками – ок, зробимо. Це і є дизайн – спосіб досягнення цілі. Включає в себе мову програмування, принципи розробки, зовнішній вигляд.
Звісно, замовник може висунути обмеження, як частину вимог – сказати, наприклад, що розраховує на веб застосунок, але як команда його зробить, все одно його не має стосуватись. Головне – результат.
Важливий момент! Дизайн, на відміну від вимог – не може бути гарним джерелом для наших тестів. Ніколи не питайте в розробника, як працює написаний ним застосунок, створюючи тести – читайте вимоги!
Що таке Артефакт?
В IT це не крутий меч і не священний грааль. Це слово придумане, шоб узагальнити все, що створються в рамках проєкту розробки ПЗ і для його користі. Вимоги – артефакт, тести – артефакт, код – артефакт, білд – артефакт.
Є 3 ознаки артефакту:
Нажаль, словом артефакт зараз користуються рідко, але розуміти, що це таке – важливо.
Яка є тестова документація?
Що таке тест план?
Це документ, що зазвичай пишуть тест менеджери, коли планують, як будуть проводити тестування, його частину чи проводити конкретний вид тестування, наприклад автоматизацію чи тестування навантаження.
Якщо ви думаєте – я новачок, нащо мені знати, що таке тест план? – ви маєте знати, що в цьому документі можна прочитати корисного саме для вас.
Документ має містити:
Що таке чек ліст?
Це список перевірок, які тестер має зробити. На відміну від тест кейсу, чек ліст не містить кроків та окремо прописаних очікуваних результатів. По суті – назва тест кейсу може бути перевіркою чек лісту.
Які ж плюси є у використанні чек лістів? Їх писати швидше, і оскільки тексту менше, самих перевірок можна написати більше.
Але є і мінуси – тест кейс – детальна інструкція. Якщо ви дасте гарно написаний тест кейс будь-якому інженеру, він зможе його виконати. А от чекліст вимагає від інженера розуміння контексту, тобто, як працює застосунок. І щоб будь-хто зміг пройти чек ліст, йому треба почитати вимоги чи пройти навчальний тренінг.
Тож маємо класичну дилему – або швидко написана документація, що описує більше перевірок, чи менше тестів, але набагато якісніших і деталізованих.
Якщо ви не впевнені – яку тестову документацію вам пистати – все залежить від застосунку, що розроблюється та від умов розробки. Вимоги змінюються раз на місяць – пишіть чек лісти, не витрачайте час. Все одно за місяць вони застаріють.
Застосунок критичний для життя людей – безпека, медицина – пишіть тест кейси, важливо забезпечити найкращу якість.
Які є види тестування?
Є багато різних способів класифікувати ваші тести. Навіщо? Щоб згрупувати їх потім за певною ознакою – їх же пишуть більше за один. Ми пропонуємо класифікацію вище ↑
Один і той самий тест можна класифікувати за різними типами, в наших прикладах тести будуть періодично повторюватись і це нормально – ви маєте змогу згрупувати тести так, як вам це зручно. Абсолютно нормально мати позитивний функціональниий ручний системного рівня динамічний смоук тест методом чорного ящика
Цю класифікацію ми розробили і запропонували ще років 8 тому. Вона лишається актуальною і досі, але точно не повною. За цим посиланням можете переглянути класифікацію, де видів тестування більше 100!
⚠️ До речі, це не перше наше відео з розбором видів тестування 😉
Що таке тест дизайн?
Це підходи, що дозволяють проводити тестування ефективно – тобто зробити максимум перевірок за мінімум часу. Стандарт ISO 29119 налічує аж 17 загальновживаних технік тест дизайну, які поділяють на 3 групи:
Класи еквівалентності та граничні значення
Класи еквівалентності – техніка тест дизайну чорного ящику, яка рекомендує розбивати вхідні чи вихідні дані програми на групи, в яких поведінка програми має бути однакова згідно документації.
Уявіть собі, що ви тестуєте програму для обрахунку податків за прогресивною системою.
Якщо користувач вказує свій дохід за рік від 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 – Прочитати вимоги. Зробити аналіз вимог та заповнити чек ліст. Доробити тест дизайн. Написати тест кейси та чек лісти для тестування системи продажу білетів до цирку
Що таке баг репорт?
Нащо реєструвати баги?
Що має мати баг репорт?
Які можуть бути життєві цикли багів? Залежить від процесу роботи вашої команди. Найпростіший варіант: баг може бути відкритий та закритий. Може мати додаткові статуси – в розробці, готовий до тестування…Головне – життєвий цикл має бути зручний для вас!
Ми з Мішою вже записували детальне відео про реєстрацію дефектів. Посилання ви просто зараз бачите на екрані. Тестування ПЗ. Реєстрація дефектів
Що таке серйозніть та пріоритет? (Severity & Priority)
Серйозність – параметр, що вказує, наскільки руйнівні наслідки має баг. Цей параметр має встановлювати тестер. Зазвичай, критерії серйозності для кожного окремого проєкту можуть бути написані в тест плані. А типово:
Пріоритет – параметр, що вказує, як швидко треба виправити баг. Від П1 – тобто якнайшвидше, до П5 – виправити тоді, коли іншої роботи не буде. Цей параметр зазвичай має встановлювати менеджер проєкту.
А тепер вишенька на торті – те, що люблять питати на співбесідах – чи маєть співпадати серйозність та пріоритет багів? Зазвичай – так. Але іноді трапляється, що дуже критичний баг отримує низький пріоритет просто тому що функцією ніхто не користується. Програма вилітає кожний високосний рік 29 лютого? Критично, але не пріоритетно. Мало хто взашалі дізнається про такий баг.
А тепер уявіть – запускаю я новий сайт qa maina, а роблю малесеньку помилку в назві – на функції сайту цей баг не впливає, але я захочу виправити його якнайшвидше
Цирк! – Те, на чому ви будете практикувати тестування
💡 Вимоги до цирку CircusTicketApp SRS 2.1
✅ Код цирку на github https://github.com/Ypurek/Circus-Ticket-App
✅ Цирк онлайн http://circus.qamania.org
⚠️ як встановити пайтон та гіт
Практика – тестова сесія
Це запис дій, що має робити тестер, коли тестує додаток без заздалегідь написаних тестів і навіть без вимог.
Нащо це записувати?
Давайте запишемо коротку тестову сесію для цирку. Уявімо, що жодних вимог ми не читали, і тестів не писали
Самостійне завдання №4 – Провести тестування та записати тестову сесію для сторінки персональних даних користувача цирку
Практика – Реєстрація дефектів (Bug Reporting)
В нас чергова практика – вчимось працювати з багами! Мало просто побачити щось неочікуване і одразу відкривати баг трекер, щоб описати. Спочатку треба розібратись. В інтернеті можна знайти ось таку милу картинку про почуття багів. Може поставити на павзу і рздивитись самостійно, я ж розкажу суть, а ще – ваш порядок дій, якщо ви помітили баг.
На прикладі багу, поміченого в попередніх відео.
Окремо хочу поговорити про контекст! В інтернеті є фейкова псевдофілософська цитата, яку приписують багатьом відомим людям: Безумство — це точне повторення однієї й тієї ж дії, сподіваючись на різний результат. Картинка Тестери з тест кейсами косять очі.
Це повна маячня. І я це кажу не тільки тому, що я тестер і повторюю одні і тіж тести раз за разом, перевіряючи, чи не змінилась поведінка програми. Будь-яка дія, яку ми робимо – завжди має якийсь контекст, що постійно змінюється і може змінити результат. Інший білд, інший комп’ютер, інша швидкість інтернету, інший час чи місце. Якщо дії не змінні, а результат змінюється – ви щось не врахували – аналізуйте ще
Самостійне завдання №5 – Провести тестування цирку та зареєструвати мінімум 5 дефектів
Що таке тестові метрики?
Практика – тестова звітність
Самостійне завдання №6 – Після проведеного вами тестування напишіть тестовий звіт
Jira
Тестові метрики
Тестова звітність