Найти!

Введеня у тестування

Забезпечення якості та тестування програмного забезпечення - основні поняття та визначення

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

Якість програмного забезпечення (Software Quality) - це сукупність показників програмного забезпечення, які стосуються його здатність задовольняти встановлені і передбачувані потреби.

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

Контроль якості (Quality Control - QC) - це сукупність дій, які проводяться над продуктом у процесі розробки для отримання інформації про його актуальний стан у розрізах: "готовність продукту до випуску", "відповідність зафіксованим вимогам", "відповідність заявленому рівню якості продукту".

Тестування програмного забезпечення (Software Testing) - це одна з технік контролю якості, що включає активності з планування робіт (Test Management), проектування тестів (Test Design), виконання тестування (Test Execution) і аналізу отриманих результатів (Test Analysis).

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

Валідація (validation) - це визначення відповідності розроблюваного ПЗ очікуванням та потреб користувача, вимогам до системи.

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

Тест дизайн (Test Design) - це етап процесу тестування ПЗ, на якому проектуються та створюються тестові випадки (тест-кейси), відповідно до визначених раніше критеріїв якості та цілей тестування.

Тестовий випадок (Test Case) - це артефакт, що описує сукупність кроків, конкретних умов і параметрів, необхідних для перевірки реалізації функції або її частини, що тестується.

Баг/Дефект Репорт (Bug Report) - це документ, що описує ситуацію або послідовність дій, що призвела до некоректної роботи об'єкта тестування із зазначенням причин та очікуваного результату.

Тестове Покриття (Test Coverage) - це одна з метрик оцінки якості тестування, що представляє собою щільність покриття тестами вимог або виконуваного коду.

Деталізація Тест-Кейсов (Test Case Specification) – це рівень деталізації опису тестових кроків та необхідного результату, при якому забезпечується розумне співвідношення часу проходження до тестового покриття.

Час проходження Тест Кейса (Test Case Pass Time) - це час від початку проходження кроків тест-кейсу до отримання результату тесту.


Якість програмного забезпечення

Щодня у своїй роботі ми стикаємося з досить абстрактним поняттям «якість ПЗ» і якщо поставити запитання тестувальнику чи програмісту «що така якість?», то у кожного знайдеться своє тлумачення. Розглянемо визначення "якості ПЗ" у контексті міжнародних стандартів:

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

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

Характеристики якості ПЗ

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

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

Зручність використання (Usability) – можливість легкого розуміння, вивчення, використання та привабливості ПЗ для користувача.

Ефективність (Efficiency) – здатність ПЗ забезпечувати необхідний рівень продуктивності, відповідно до виділених ресурсів, часу та інших зазначених умов.

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

Портативність (Portability) – характеризує ПЗ з погляду легкості його перенесення з одного оточення (software/hardware) до іншого.

Модель якості програмного забезпечення

На даний момент найбільш поширена і використовується багаторівнева модель якості програмного забезпечення, представлена ​​в наборі стандартів ISO 9126. На верхньому рівні виділено 6 основних характеристик якості ПЗ, кожну з яких визначають набором атрибутів, що мають відповідні метрики для подальшої оцінки. Рис.1. Модель якості програмного забезпечення (ІSO 9126-1)


Хто такий тестувальник і що він робить

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

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

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

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

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

  1. Знання іноземних мов. Так, це не технічна навичка. Проте він йде під номером «нуль». Можете вважати це аксіомою: "немає знання англійської - немає кар'єри в IT". Інші іноземні мови теж вітаються, але англійська первинна.
  2. Впевнене володіння комп'ютером на рівні по-справжньому просунутого користувача та бажання постійно розвиватися у цій галузі. Чи можете Ви уявити професійного кухаря, який не може посмажити картоплю (не «не зобов'язаний», а «не вміє в принципі»)? Виглядає дивно? Не менш дивно виглядає «IT'шник» (саме так, у лапках), нездатний набрати розумно відформатований текст, скопіювати файл по мережі, розгорнути віртуальну машину або виконати будь-яку іншу повсякденну рутинну дію.
  3. Програмування. Воно на порядок спрощує життя будь-якому ІТ-шнику, а тестувальнику — насамперед. Чи можна тестувати без знання програмування? Так можна. Чи можна це робити по-справжньому добре? Ні. І зараз найголовніше (майже релігійно-філософське) питання: яку мову програмування вивчати? C/C++/C#, Java, PHP, jаvascript, Python, Ruby і т.д. - Починайте з того, на чому написаний ваш проект. Якщо проекту поки що немає, починайте з jаvascript (на даний момент найуніверсальніше рішення).
  4. Бази даних та мова SQL. Тут від тестувальника теж не потрібна кваліфікація на рівні вузьких фахівців, але мінімальні навички роботи з найбільш поширеними СУБД та вміння писати прості запити можна вважати обов'язковими.
  5. Розуміння принципів роботи мереж та операційних систем. Хоча б на мінімальному рівні, що дозволяє провести діагностику проблеми та вирішити її самотужки, якщо це можливо.
  6. Розуміння принципів роботи веб-додатків та мобільних додатків. У наші дні майже все пишеться саме у вигляді таких програм, і розуміння відповідних технологій стає обов'язковим для ефективного тестування.

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

Також відзначимо особисті якості, що дозволяють тестувальнику швидше стати відмінним фахівцем:

  1. Підвищена відповідальність та старанність;
  2. хороші комунікативні навички, здатність ясно, швидко, чітко висловлювати свої думки;
  3. терпіння, посидючість, уважність до деталей, спостережливість;
  4. хороше абстрактне та аналітичне мислення;
  5. здатність ставити нестандартні експерименти; схильність до дослідницької діяльності.

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

Звідки беруться помилки у ПЗ?

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

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

Однак програми розробляються і створюються людьми, які також можуть припускатися (і припускаються) помилок. Це означає, що недоліки є й у програмному забезпеченні. Вони називаються дефектами або багами (обидва позначення рівносильні). Тут важливо пам'ятати, що програмне забезпечення – щось більше, ніж код.

Дефект, Баг (Defect, Bug) – недолік компонента чи системи, що може призвести до відмови певної функціональності. Дефект, виявлений під час виконання програми, може викликати відмову окремого компонента чи всієї системи.

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

Збій (failure) – невідповідність фактичного результату (actual result) роботи компонента чи системи очікуваного результату (expected result).

Збій у роботі програми може бути індикатором наявності дефекту.

Таким чином, баг існує при одночасному виконанні трьох умов:

  • відомий очікуваний результат;
  • відомий фактичний результат;
  • фактичний результат відрізняється від очікуваного результату.

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

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

Усього існує кілька джерел дефектів і, відповідно, збоїв:

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

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

Якість (Quality) – ступінь, у якій сукупність властивих показників відповідає вимогам.

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

Вимога (Requirement) – потреба чи очікування, яке встановлено. Зазвичай передбачається чи є обов'язковим.

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

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

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

У четвертому випадку дефекти було закладено ще етапі формування вимог; вся подальша розробка і навіть тестування пішли спочатку неправильним шляхом. Під час тестування ми не знайдемо багів – програма пройде всі тести, але може бути забракована замовником.

Умовно можна виділити п'ять причин появи дефектів у програмному коді .

  1. Недолік чи відсутність спілкування у команді . Найчастіше бізнес-вимоги просто не сягають команди розробки. Замовник має розуміння того, яким він хоче бачити готовий продукт, але, якщо належним чином не пояснити його ідею розробникам і тестувальникам, результат може виявитися не таким, як передбачалося. Вимоги мають бути доступні та зрозумілі всім учасникам процесу розробки ПЗ.
  2. Складність програмного забезпечення . Сучасне програмне забезпечення складається з безлічі компонентів, які об'єднуються в складні програмні системи. Багатопотокові додатки, клієнт-серверна та розподілена архітектура, багаторівневі бази даних – програми стають все складнішими в написанні та підтримці, і тим важчою стає робота програмістів. А чим важче робота, тим більше помилок може допустити людина, яка її виконує.
  3. Зміни вимог. Навіть незначні зміни вимог на пізніх етапах розробки потребують великого обсягу робіт із внесення змін до системи. Змінюється дизайн та архітектура програми, що, у свою чергу, вимагає внесення змін до вихідного коду та принципів взаємодії програмних модулів. Такі поточні зміни часто стають джерелом важких дефектів. Тим не менш, вимоги, що часто змінюються в сучасному бізнесі – скоріше правило, ніж виняток, тому безперервне тестування та контроль ризиків у таких умовах – прямий обов'язок фахівців відділу забезпечення якості.
  4. Погано документований код. Складно підтримувати та змінювати погано написаний та слабо документований програмний код. У багатьох компаніях існують спеціальні правила щодо написання та документування коду програмістами. Хоча практично часто буває так, що розробники змушені писати програми в першу чергу швидко, а це позначається на якості продукту.
  5. Засоби розробки програмного забезпечення. Засоби візуалізації, бібліотеки, компілятори, генератори скриптів та інші допоміжні інструменти розробки – це теж часто погано працюючі та слабо документовані програми, які можуть стати джерелом дефектів у готовому продукті.

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

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

1. Тестування показує наявність дефектів

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

2. Вичерпне тестування неможливе

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

3. Раннє тестування

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

4. Скупчення дефектів

Різні модулі системи можуть містити різну кількість дефектів, тобто щільність накопичення дефектів у різних елементах програми може відрізнятися. Зусилля з тестування повинні розподілятися пропорційно до фактичної щільності дефектів. В основному, більшість критичних дефектів знаходять в обмеженій кількості модулів. Це прояв принципу Парето: 80% проблем містяться у 20% модулів.

5. Парадокс пестицидів

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

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

6. Тестування залежить від контексту

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

7. Помилка про відсутність помилок.

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

І ще кілька важливих принципів:

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

Верифікація та підтвердження

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

Верифікація (verification) – це процес оцінки системи чи її компонентів з метою визначення, чи задовольняють результати поточного етапу розробки умовам, сформованим на початку цього етапу. Тобто чи виконуються завдання, цілі та терміни розробки продукту.

Валідація (validation) – це визначення відповідності розроблюваного ПЗ очікуванням та потребам користувача, вимогам до системи.

Наступна таблиця допоможе виділити ключові відмінності між цими поняттями:

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

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

На практиці відмінності верифікації та валідації мають велике значення:

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

QA, QC та тестування

То в чому ж різниця між QA та тестуванням і що таке Quality Control?

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

Можна оформити їхнє співвідношення у вигляді таблиці:

Отже, ми можемо побудувати модель ієрархії процесів забезпечення: Тестування – частина QC. QC – частина QA.

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

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

  • За допомогою тестування ми можемо визначити, чи працюють усі деталі та сам велосипед загалом так, як ми очікуємо. Чи з правильних матеріалів він зроблений, із застосуванням потрібних методик та інструментів чи ні. Тобто мається на увазі, що об'єкт, що тестується, вже існує.
  • Завданням QA є забезпечення відповідності всіх етапів конструювання нашого велосипеда певним стандартам якості, починаючи з планування та створення креслень та закінчуючи складанням вже готового велосипеда. Тобто якості об'єкта увага приділяється ще до створення об'єкта.
Добавить комментарий
Інформація
Відвідувачі, які знаходяться у групі Гости, не можуть залишати коментарі до цієї публікації.