Написання тестових справ про прийняття

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

• Тестові приклади повинні бути короткими: візьміть приклад CMS. Короткі тестові приклади легко підтримувати та визначати входи та виходи. Але що робити, якщо я хочу протестувати довгу серію операцій (наприклад, додавання документа, відправлення повідомлення іншому користувачеві, відповідь іншого користувача, документ змінює стан, користувач отримує повідомлення). Мені здається, тестові випадки повинні представляти цілісні сценарії. Але я бачу, як це створить надмірно складні тестові документи.

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

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

• Тестові приклади повинні бути легко задокументовані: Цей принцип є специфічним для Agile проектів. То чи маєте ви поради, як реалізувати цей принцип?

Хоча я вважав, що написання тестових випадків прийому буде простим, я був переповнений кожним рішенням, яке я повинен був прийняти (FYI: Я розробник, а не професійний тестер). Отже, моє головне питання: які кроки чи поради для написання тестових справ про прийняття для складних програм. Дякую.

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

У своїх пакетах прийняття я тримався подалі від використання специфічних технологій управління, тобто для веб-додатків не використовуйте css, не використовуйте html-елементи, якщо вам потрібно заповнити форму, виконайте специфіку в кроках, щоб встановити SUT, а не фактичні тести прийняття

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

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

цей приклад повертається веб-додатком, але я все ще можу використовувати тест для тестування на настільному додатку, оскільки кроки використовуються для налаштування SUT не тестів прийняття

цей тест знаходиться в кінці покупки, яка проходить

Створити -> Підтвердити -> Оплата -> Квитанція про друк

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

Спочатку потрібно визначити Тестування прийняття .

Здається, ви описуєте інтеграцію або тестування системи .

Тому, хоча я не на 100% згоден з визначеннями у вікіпедії, вони все ще в основному справедливі.

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

Питання, яке потрібно задати, «як використовується система?». Тож давайте перевіримо його так, як слід використовувати. Звичайно, тепер ви надягаєте інженерну шапку і релігійно проходите бізнес-вимоги, щоб отримати випробування. Це передбачає, що у вас добре написані ділові вимоги.

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

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

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

Те саме з програмним забезпеченням.

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

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

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

HTH, і удачі!

КМ

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