Тестування

1. Помилки в ПЗ

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

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

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

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

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

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

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

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

– відомий очікуваний результат;

– відомий фактичний результат;

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

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

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

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

– помилки в специфікації, дизайні, реалізації програмної системи;

– помилки у використанні системи;

– несприятливі умови навколишнього середовища;

– навмисне заподіяння шкоди;

– потенційні наслідки попередніх помилок, умов або навмисних дій.

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

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

Якість програмного забезпечення (Software Quality) – це сукупність характеристик програмного забезпечення, яка відображає його здатність задовольняти встановлені та допустимі вимоги. [ISO 8402:1994]

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

Для демонстрації залежності якості системи від дефектів, що привносяться в неї на різних рівнях процесу розробки, можна привести таку схему:

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

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

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

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

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

1. Брак або відсутність спілкування в команді

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

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

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

3. Зміна вимог

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

4. Погано задокументований код

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

5. Середовище розробки ПЗ

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

2. Тестування необхідне

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

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

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

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

Ризик (risk):

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

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

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

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

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

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

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

3. Психологія тестування

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

Всього виділяють чотири рівні незалежності – від низького до високого:

1. тести для програми розробляються і проводяться людиною, яка є її автором;

2. тести розробляються і проводяться іншими людьми (наприклад, іншим розробником);

3. тести розроблені представниками іншої організаційної групи (наприклад, з відділу тестування) або спеціалізованими тестувальниками (наприклад, спеціалістами з тестування продуктивності та безпеки);

4. тести розробляються і проводяться спеціалістами з іншої організації (наприклад, аутсорсингової або аудиторської).

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

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

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

Дослідження показали, що, якщо людина, яка тестує програму, сприймає її як таку, що працює правильно, вона знайде менше помилок, ніж той, хто буде впевнений в наявності багатьох недоліків. Тому тестувальник завжди має пам’ятати про те, що “Software has bugs”.

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

Ще декілька простих порад для покращення комунікації з колегами:

– пам’ятайте про те, що всі ви працюєте над одним проектом та йдете до однієї мети – створенню якісного та затребуваного продукту;

– оформляйте результати своєї роботи в нейтральному тоні, сфокусуйтесь на фактах;

– поставте себе на місце інших та спробуйте зрозуміти причини їх поведінки;

– завжди переконуйтесь в тому, що інша людина зрозуміла Вас, а Ви її.

4. Початок і закінчення тестування

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

На різних етапах життєвого циклу ПЗ тестування проводиться в різних формах:

– на етапі визначення вимог: їх аналіз та верифікація також можуть вважатися тестуванням;

– контроль процесу проектування на етапі розробки дизайну системи – це також форма тестування;

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

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

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

5. Процес тестування

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

• Планування та управління;
• Аналіз та проектування;
• Впровадження та реалізація;
• Оцінка критеріїв виходу і написання звітів;
• Дії по завершенню тестування.

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

1. Планування та управління

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

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

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

Тест-політика – високорівневий документ, що описує принципи, підходи і основні цілі компанії в сфері тестування.

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

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

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

Управління тестуванням – зіставлення поточної ситуації в процесі тестування із планом та складання звітності.

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

2. Аналіз та проектування

Аналіз та проектування тестів – це процес написання тестових сценаріїв і умов на основі загальних цілей тестування.

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

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

3. Впровадження та реалізація

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

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

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

4. Оцінка критеріїв виходу і написання звітів

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

При оцінці критеріїв виходу необхідно:

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

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

5. Дії після завершення тестування

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

Основні цілі цього етапу:

• Переконатися, що вся запланована функціональність дійсно була реалізована;
• Перевірити, що всі звіти про помилки, подані раніше, були, так чи інакше, закриті;
• Завершення роботи тестового забезпечення, тестового оточення та інфраструктури;
• Оцінити загальні результати тестування і проаналізувати досвід, отриманий в його процесі.

6. QA, QC і тестування

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

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

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

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

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

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

7. Професія - тестувальник

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

Модульне тестування (Unit testing) – тестування окремих компонентів програмної системи. В ролі таких компонентів зазвичай виступають функції або класи.

В більшості випадків, в процес тестування включені такі спеціалісти:

– Тестувальник ПЗ (Software tester);

– Розробник ПЗ (Software developer);

– Менеджер проекту (Project manager);

– Замовник (Product owner);

– Кінцевий користувач (End user).

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

8. Мета тестування

Можна визначити такі основні цілі тестування програмного забезпечення:

– Надання інформації про якість ПЗ кінцевому замовнику;

– Підвищення якості ПЗ;

– Попередження виникнення дефектів.

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

Головна ж задача тестування – пошук дефектів.

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

– процес дослідження ПЗ з метою отримання інформації про якість продукту;

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

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

В широкому сенсі, тестування – це одна із технік контролю якості (Quality Control), яка включає планування, складання тестів, безпосередньо виконання тестування та аналіз отриманих результатів.

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

– аналіз та планування;

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

– оцінку критеріїв закінчення тестування;

– написання звітів;

– рецензування документації (в тому числі і джерела коду);

– проведення статичного аналізу.

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

Чому важливий процес тестування?

– Процес розробки ПЗ неможливий без контроля якості продукту, що розробляється;

– Процес тестування ПЗ являє собою таку ж невід’ємну частину процесу розробки, як і проектування;

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