Позитивното мислене в света на отрицателен тест, webmart QA

Ние (не, че това е тайна) са много притеснен за качеството на своите продукти, и гледах с възхищение за obvalivaniem система. Това оправдава съществуването на тестери в света. Това ни кара да се чувствам като герои: голям тестер дойде и спаси своите потребители от ужасните критични грешки!

А нашите тестери никога не забравят за отрицателен тест, въпреки че не всички измамници е угодно. Но такива проверки не са прищявка на "зли тестери", те са причинени от необходимостта да се затвори уязвимостта и се застраховат срещу проникването на хакерите на системата и ботове, Dos / DDoS атаки.

Разбира се, тъй като това, което е призванието на експерти за изпитване? Трябва да намерим проблема. Проблемите, които обикновено никой не разполага с време, за да мисля, не иска да ги види и да се справят с тях. И ако установи не само правилното функциониране на системата, но ненормално нейното поведение, допълни напрежението в отбора.

Виждате ли, някои програмисти пишат софтуер, насочена към резултата, планираното освобождаване, лети на крилете на вдъхновението! И тук идва на сцената на тестване и многобройни поправки и редакции на "идеалния" код. И все пак, да се крият всички посоки, тестване на системата.

За да не се дразни, някои специалисти могат да забавят отрицателен тестване за по-късно или дори да го игнорират (ужас!) В полза на съкращаване на времето и бюджета. Е, какво да се провери, ако програмата не дори това, което трябва да бъде, нали? Не.

Положителни и отрицателни тестове

Но първо първите неща. При тестване на софтуера с помощта на тест случаи, има две групи от тестове: положителни и отрицателни. И второто е обикновено по-голям от първия.

Положителен резултат от тест - тест на системата за изпълнение на нейната нормална (рутина, което се очаква) поведение, според TK и документация. Това означава, че тук ние търсим в това дали софтуерът е това, което се очаква от него, дали прилагането на съвременните изисквания, независимо дали насока потребителски интерфейс поддържа и т.н.

Отрицателният тест - тест на системата за нестандартно поведение. Виж, ако в устойчивост на проникване на погрешните данни се обработват изключения, каква информация се показва в съобщенията за грешка, че е възможно да се наруши функционирането на продукта и / или да повлияе на изпълнението на решението, и така нататък.

Ние вече заяви, че някои експерти тръгват на отрицателен тест за по-късно, или дори да забравите за това, което е почти същото. Знаеш ли, отложено за по-късно, почти винаги остава неизпълнено.

Поради това, по наше мнение,

Отрицателни и положителни резултати от теста не е необходимо да бъдат разделени и разпределени във времето.

Защото, ако може да се каже, че системата работи както трябва, ако проверите нейната реакция само на правилните входните данни?

При тестване ох колко е важно интуиция, Чуйков, ловни инстинкти - Обади ми каквото си искате. И тук той седи така ни инженер, проверява формуляра за регистрация, например.

Проверки на всички на техническото задание и сценарий тестове, изглежда, как се обработват данните, които потребителят трябва да въведе в областта (не на факта, че ще се въведе, между другото), а след това е всичко - вдъхновение! Той смята, че ако се въведе тук, в тази област, за да влезете някои "adynadyn% >" вместо обикновен текст, а след това нещо определено ще се случи. Нещо тъмно и мрачно погрешно.

И какво? Той трябва да си каже: "Не. Сега трябва да се справят с положителен тест, и нищо друго. Тук съм назначен отрицателно през следващата седмица, а след това дойде време да adynadyn% >. Вероятно "?

Ние вярваме, че този подход към отрицателен тестване неефективно и ето защо:

  1. Ако се направи положителен и сам отрицателен тест, той ще бъде по-дълго. Като минимум, тъй като той ще има две тестови повторения.
  2. Тестери и програмисти, които живеят под срокове. И ако времето е строго ограничена, отлагането на отрицателна тестване след това увеличава риска за него изобщо в крайна сметка няма да бъде забравена. Всъщност, по-близо до точка Х, толкова по-бързо времето лети, скоро необходими за изпълнение на поставените задачи, с цел коригиране на дефекти, да прилагат окончателните бизнес изисквания (които могат да се променят) и все още да завършат много от случаите. Краен срок - докато е горещо!
  3. Разделянето на отрицателни и положителни теста, по наше мнение, е в противоречие с естеството на тестера! В крайна сметка, основната му задача - е да се провери системата за всички възможни действия за крайния потребител. И хората са най-вече нелогични, и могат да направят с разнообразие от софтуер за разврат;)

И така, какво изводи можем да се направи?