Процес QA тестування: Основні етапи, підходи та інструменти

Коли ви починаєте подумувати про те, щоб стати тестувальником, і читаєте щось на цю тему, нові терміни та поняття зустрічаються буквально у кожному реченні. Процес контролю якості, “чорна скринька”, “біла скринька”, модульні тести, регресійні тести, ручне та автоматичне тестування, BrowserStack, Jira. Все це звучить таке складно! Складається враження, що на те, щоби освоїти цю професію, у вас підуть роки.‍

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

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

Прочитавши її, ви дізнаєтесь:

• У чому різниця між процесом забезпечення якості (QA) та контролем якості (QС)
• Які основні етапи процесу QA при розробці програмного забезпечення
• У чому різниця між ручним та автоматичним тестуванням
• Які бувають види тестів та підходи до тестування
• Які інструменти допомагають оптимізувати процес
  

Що таке процес забезпечення якості (QA) та чим він відрізняється від контролю якості (QC)?

Процес забезпечення якості при розробці програмного забезпечення або QA (quality assurance) — це процес, який запобігає появі помилок у кінцевому продукті та гарантує, що компанія випустить по-справжньому якісну програму. Процес QA – це більше, ніж просто контроль якості та тестування.В той час як контроль якості (QC) зосереджений на перевірці кінцевого продукту, QA є частиною всіх етапів та стадій розробки програмного забезпечення. налаштований процес QA гарантує, що всі члени команди працюватимуть ефективно, час, необхідний розробки, скоротиться, а витрати знизяться.

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

Які основні етапи процесу QA?

Робота з вимогами

У сучасних компаніях процес QA починається на дуже ранніх етапах життєвого циклу розробки програмного забезпечення — прямо на етапі аналізу вимог.

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

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

Розробка тестових сценаріїв

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

Тестування програмного забезпечення

На цьому етапі все готове для пошуку помилок та дефектів. Команда QA спеціалістів починає виконувати різні типи тестів. Тестувальники повідомляють про всі виявлені помилки.

Повторне тестування

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

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

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

Які типи або види тестування використовуються в процесі QA?

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

Функціональні та нефункціональні тести

Основні категорії тестів - це функціональні та нефункціональні тести.

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

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

Знання вихідного коду

Якщо тестувальники знають вихідний код до тестування, йдеться про тестування "білої скриньки" (white box testing). Інакше ми маємо справу з тестуванням “чорної скриньки” (black box testing), коли тестувальники оцінюють лише поведінку програми, не знаючи її внутрішнього пристрою. Тестування “сірої скриньки” (grey box testing) є комбінацією цих двох підходів. Тестувальникам надається обмежена інформація про внутрішню структуру системи.

Підхід до виконання тестів

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

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

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

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

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

Фаза розробки програмного забезпечення

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

Ось ще кілька типів тестів, з якими ви часто зіштовхуватиметеся в публікаціях:

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

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

Навантажувальні тести (load tests) необхідні перевірки програми як за середньої, і при пікової навантаженні.

Кроссбраузерне/кросплатформне тестування допомагає аналізувати поведінку програми у різних браузерах та системах.

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

Інструменти тестування

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

Існує безліч таких сервісів і додатків. Ніхто не буде очікувати від тестувальника-початківця знання всіх цих продуктів.Але буде корисно ознайомитися з деякими з найпопулярніших, такими як Selenium, Jira чи BrowserStack.

Selenium – найпопулярніший інструмент тестування. Він не вимагає глибоких знань мов програмування та зручний для новачків.

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

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

Висновок

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

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

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

Тестування – це не пошук помилок!

Багато хто вважає, що тестування ПЗ – це пошук помилок. Іноді я кажу тестувальникам: «не намагайся знайти якнайбільше помилок, намагайся пропустити якнайменше!», і мене не розуміють: а в чому різниця?

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

Що таке пошук помилок?

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

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

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

Які тести я проводитиму в першу чергу? Конено, найнестандартніші. Ввести в поле логіна «Війну та мир», поділити на нуль, вставити у профіль фотографію у форматі .exe.

Скажу по секрету — іноді на співбесідах тестувальники у відповідь на прохання «протеструйте калькулятор» перераховують цікаві та слушні тести, але серед перших тридцяти ні тесту «перевірити складання» та інші базові операції.

Саме так виглядає пошук помилок, що не має нічого спільного з тестуванням.

Що таке випробування?

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

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

Що буде, якщо я зіткнуся з труднощами? Наприклад, зі складновідтворюваним дефектом, чи нерозумінням бізнес-процесу користувача, чи браком вимог? Якщо це важливий функціонал, то я з'ясовуватиму «що не так», «як правильно». На заклад дефекту в результаті може піти чимало часу, і з точки зору баг/час результат ефективності тестування буде не дуже високий, зате у мене з'являться більш глибокі знання про продукт, архітектуру, користувачів.

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

Результати тестування та пошуку помилок

У разі пошуку помилок, у короткостроковій перспективі результати вищі: багів заводиться більше і відразу.

• через відсутність глибоких знань про продукт поступово починає зростати % пропущених дефектів
• команда розробки зайнята виправленням жахливих-немислимих багів, отриманих шляхом кліку на одну і ту ж кнопку 144 рази під IE в повний місяць
• у реліз потрапляють деякі жахливо неприємні та очевидні для користувача баги
• кількість помилок, що знаходяться в ДОВГОТЕРКОВІЙ перспективі, падає

Як перейти від пошуку помилок до тестування?

Щоб тестування було ефективним та корисним у довгостроковій перспективі, необхідно дотримуватися простих правил та використовувати ключові інструменти тестування:

1. Аналіз продукту та документування тестів

Клацаючи на кнопки, можна завести багато багів - але не можна сказати, що було перевірено. Єдине рішення – документування тестів. Детальні тест-кейси, що обтяжують тестувальників і забирають багато часу, бувають потрібні дуже рідко.А ось чек-листи із переліком «що потрібно перевірити» — необхідні.

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

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

2. Оцінка тестування

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

ЗАВЖДИ є що покращувати, і відсутність безперервного процесу вдосконалення — неминуче болото.

3. Обговорення цілей тестування з командою

Багато хто вважає, що тестування має якісь міфічні цілі. І що вони завжди однакові.

У кожному проекті, компанії, команді цілі свої власні. Чи всі їх розуміють однаково? Чи ви промовляли їх вголос?

Щоб приносити максимум користі, треба добре розуміти, в чому ця користь полягає. І не дивуйтеся, якщо думка РМів та розробників не буде відповідати вашій. Треба не переконувати їх, а підлаштовуватись під поточні проектні цілі!

4. Розуміння користувачів та їх бізнес-процесів

• Як використовується цей продукт?
• Навіщо він взагалі потрібний, які проблеми вирішує?
• Яка середня кваліфікація у користувачів?
• За яких умов працюють користувачі? На яких оточеннях, устаткуванні?

5. Технічна кваліфікація та розуміння архітектури

Для ілюстрації наведу баг, який на мене нещодавно завели у баг-трекері:
Зайти на сайт тестованого продукту http://****.ru у браузері Firefox
Ввести логін та пароль
Зайти з того ж комп'ютера у браузері Opera
Просить повторно ввести логін та пароль, автоматично не логіниться.

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

Висновки

Дуже багато розробників не люблять тестувальників. І правильно роблять!

Натомість добрих тестувальників люблять і цінують усі. Але тестувальників, а не клікерів та багозаводільців!

Вчитеся дізнаватись, що не так, що не подобається іншим учасникам команди розробки. Обов'язково досліджуйте пропущені помилки та робіть все для того, щоб більше їх не пропускати. Не женіться за закладом багів — вашою мантрою повинні бути «щастя користувача», «якісний продукт» і «успішний проект», а не «завести якомога більше багів» — ДУЖЕ часто ці дві цілі виявляються надто далекі одна від одної.

І нехай буде з вами сила!

Процес управління дефектами під час тестування програмного забезпечення

Управління дефектами - це систематичний процес виявлення та виправлення помилок. Цикл управління дефектами складається з наступних етапів: 1) Виявлення дефекту, 2) Категоризація дефекту, 3) Виправлення дефекту розробниками, 4) Перевірка тестувальниками, 5) Закриття дефекту, 6) Звіти про дефекти наприкінці проекту.

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

Крок 1) Відкриття

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

У наведеному вище сценарії тестери виявили 84 дефекти на сайті Guru99.

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

Що ви робитимете в такому випадку як менеджер з тестування?

А) Погодьтеся з командою тестування, що це дефект.

Б) Менеджер із тестування бере на себе роль судді, який вирішує, чи є проблема дефектом чи ні.

В) Погодитись з командою розробників, що це не є дефектом

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

Крок 2) Категоризація

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

Дефекти зазвичай класифікуються менеджером із тестування:

Давайте виконаємо невелику вправу, як показано нижче.

Перетягніть пріоритет дефекту нижче

Ось рекомендовані відповіді

Робота сайту надто повільна

Помилка продуктивності може завдати користувачеві величезних незручностей.

Функція входу на сайт не працює належним чином

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

Графічний інтерфейс веб-сайту відображається неправильно на мобільних пристроях.

Дефект стосується користувача, який використовує смартфон для перегляду веб-сайту.

Веб-сайту не вдалося запам'ятати сеанс входу користувача.

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

Деякі посилання не працюють

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

СТАТТІ ЗА ТЕМОЮ

Крок 3) Дозвіл дефектів

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

Щоб виправити дефект, можна виконати такі кроки.

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

Крок 4) Перевірка

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

Наприклад, у наведеному вище сценарії, коли команда розробників повідомила, що вони вже виправили 61 дефект, ваша команда проведе повторне тестування, щоб переконатися, що ці дефекти справді виправлені чи ні.

Крок 5) Закриття

Після усунення та перевірки дефекту статус дефекту змінюється на закрито. Якщо ні, ви надішліть повідомлення розробникам, щоб вони знову перевірили дефект.

Крок 6) Звіт про дефекти

Звіт про дефекти У тестуванні програмного забезпечення - це процес, в якому менеджери з тестування готують і надсилають звіт про дефекти команді управління для отримання зворотного зв'язку про процес управління дефектами та статус дефектів. Потім команда управління перевіряє звіт про дефекти та надсилає відгук або за необхідності надає додаткову підтримку. Звіти про дефекти допомагають краще спілкуватися, відстежувати та докладно пояснювати дефекти.

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

Навіщо вам потрібний процес управління дефектами?

Ваша команда виявила помилки під час тестування проекту Guru99 Banking.

Через тиждень розробник відповідає

Наступного тижня тестер відповість

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

Важливі показники дефектів

Поверніться до наведеного вище сценарію. Команди розробників та тестувальників перевіряють виявлені дефекти. Ось результат цього обговорення

Як виміряти та оцінити якість виконання тесту?

Це питання, яке кожен Test Manager хоче знати. Є 2 параметри, які можна розглядати як такі:

У наведеному вище сценарії ви можете розрахувати коефіцієнт відхилення дезертирства (СРБ) – це 20/84 = 0.238 (23.8 %).

Інший приклад, припустимо, що на сайті банку Guru99 є всього 64 дефекти, але ваша команда тестування виявляє тільки 44 дефекти, тобто. вони пропущені 20 дефекти. Отже, можна розрахувати коефіцієнт витоку дефектів (DLR), що дорівнює 20/64 = 0.312 (31.2%).

Висновок: якість виконання тесту оцінюється за двома параметрами.

Чим менше значення DRR та DLR, тим вища якість виконання тесту. Який діапазон співвідношень, який прийнятний? Цей діапазон може бути визначений і прийнятий як основа для мети проекту або ви можете використовувати показники аналогічних проектів.

У цьому проекті рекомендоване значення прийнятного співвідношення становить 5 ~ 10%. Це означає, що якість виконання тестів низька. Вам слід знайти контрзаходи для зменшення цих співвідношень, наприклад:

• Вдосконалювати Навички тестування учасника.
• Проводь більше часу для виконання тестування, особливо перегляду результатів виконання тесту.

Часті питання

Помилка – це наслідок/результат помилки кодування.