Как да тествате приложение без изисквания?

how test an application without requirements

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

Целият софтуер има изисквания и е насочен към определена задача; по-конкретно, това е решение на проблем. Така без изисквания софтуерът не е възможен.

Софтуерът без документирани изисквания обаче е реалност, с която за съжаление повечето от нас се сблъскват по-често с това ние харесваме. По-лошото може да бъде, че документацията е недостатъчна, неточна или ужасно остаряла. За съжаление и това се случва.

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

Следователно, тази статия е опит за някои практики, които сме следвали, когато сме попаднали в тези ситуации.

Прочетете също:

какъв е най-добрият музикален изтеглящ за android

• Как да тествате спецификацията на софтуерните изисквания (SRS)?
• Как да създадете матрица за проследяване на изискванията
• Как да прегледате SRS документа и да създадете тестови сценарии

Нека първо разгледаме няколко причини, поради които може да няма документация, за начало:

1. Проектът за рафтове се отваря отново
2. Документация по-малко формат на работа- Процес
3. Документацията може да съществува, но може да не е подробна или пълна
4. Непрекъснатите версии и свързаната с по-старата версия информация не са архивирани, което води до пропуск в разбирането за това как съществуващата функционалност реагира с новата

Това са всички препятствия, които ние, тестерите, трябва смело да преодолеем и да се появим успешно. Как точно обаче, нали?

Ето топ 3 метода за тестване на приложение без изисквания:

Метод # 1:

Работете с каквато и малка документация да получите. Това може да бъде основно просто изоставане (в гъвкави проекти), файл за помощ, имейл, по-стара версия на BRD / FRD или стари тестови случаи (проверете за тях в инструментите си за ALM и може да ги намерите) и т.н.

Проучете, попитайте и винаги има документирано проучване, дори и да е тънко.

Когато това не се получи, не отстъпвайте опита си като потребител на софтуер.Например, ако трябва да тествате операция за превод за банкова сметка, никой не трябва да ни казва как да направим това, нали? Защото като клиенти за онлайн банкиране всички знаем, че се нуждаем от и към сметки с редица налични средства за прехвърляне.

Съгласни са, че не всички ситуации ще бъдат толкова ясни, но отново може и да са.

Метод # 2:

Използвайте по-старата / текущата версия на приложението като справка, за да тествате бъдещата версия на софтуерен продукт. Сега признавам, че това е в отрицание на правилото „Никога не пишете тестови случаи, използвайки приложението като справка“. Когато обаче работим в по-малко перфектна ситуация, трябва да формираме правилата, за да отговарят на нашите нужди.

Помага да се запазят следните аспекти в перспектива при това:

• Приложението може да съдържа грешки - така че ако след регистрацията системата директно ви отведе до Screen1 (определен хипотетичен екран заради нашия пример) - Никога не приемайте, че това е правилното поведение. Също така, ако полето приема буквено-цифрови символи и е телефонен номер - въпрос, който се уверете, че не приемате приложението като предоставен пример за очакваната функционалност.

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

Метод # 3:

Говорете с членовете на екипа по проекта:

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

Сега, нека приложим методите в пример:

Да предположим, че има сайт за пазаруване, където можете да добавяте артикули в пазарската количка. В идеалния случай, ако е имало документация, трябва да ни каже как да добавим елементи към нея, колко елемента може да има в даден момент от времето, какво се случва, когато елементът, който сте добавили внезапно изчезва на склад, какъв е максималният брой на едни и същи артикули, които можете да закупите едновременно и т.н. Нашата ситуация е, че понастоящем НИКОЙ от тях не е наличен.

Приложи метод №1:

Намерете всякаква документация, която можете. Попитайте вашия екип за разработчици дали имат макетни екрани / погледнете инструмента ALM или нещо такова. Ако все пак намерите нещо, това би било добра отправна точка. Но ако този метод не окаже нищо, тогава можете да използвате вашия преценка / интуиция на тестера.

Всички знаем как работят количките за пазаруване, така че направете вашите предположения и стигнете до няколко основни сценария като:

• Артикулите могат да се добавят към пазарската количка, след като бъдат разгледани или търсени
• След като добавя артикули в пазарската количка, списъкът с артикули трябва да се опресни
• Потребителят трябва да може да продължи да пазарува дори след добавяне на няколко артикула в количката
• Добавянето на един и същ елемент два пъти ще доведе до увеличаване на броя на добавените елементи
• Елементите могат да бъдат актуализирани
• Елементите могат да бъдат премахнати
• Общата сума трябва да бъде еквивалентна на сумата от всички добавени цени
• Данъците трябва да се изчисляват въз основа на въведения пощенски код
• Разходите за доставка трябва да бъдат добавени съответно

Можем да продължаваме, но съм сигурен, че схванахте картината.

Прилагане на метод №2:

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

Както можете да видите от екрана по-долу, тези неща са очевидни - имената на полетата, бутоните или други налични елементи и т.н. (кликнете върху изображението за увеличен изглед)

В този момент тестерите имат някои въпроси като:

1. Какво се случва, когато дам знак в полето за количество?
2. Кога да добавя твърде много елементи?
3. Колко е максималното не. от предмети, които това може да отнеме? И т.н.

Приложете метод №3 :

Занесете списъка си с въпроси на BA, разработчика или дори на клиента и потърсете разяснения. След като метод 3 бъде приключен, трябва почти да сте снабдени с цялата информация, която ще ви е необходима, за да напишете подробни тестови случаи и да извършите тестването си с толкова увереност, колкото бихте имали, когато беше налице сложна документация.

Съгласни сме, че има много повече стъпки и много повече последващи действия, но за да се гарантира тестване на качеството, тези стъпки са неизбежни.

В заключение, всичко не се губи, когато документацията не съществува или е недостатъчна. Все още има надежда! Моля, споделете своя опит в подобни ситуации.

За автора: Тази полезна публикация е написана от нашия член на екипа на STH Swati S.

Както винаги вашите коментари, въпроси и предложения са най-добре дошли.

Препоръчително четене

• Урок за деструктивно тестване и безразрушително тестване
• Как да тествате спецификацията на софтуерните изисквания (SRS)?
• Какво е тестване на маймуни при тестване на софтуер?
• Тестване на приложения - в основите на софтуерното тестване!
• Какво е тестване на софтуерна съвместимост?
• Най-добри инструменти за тестване на софтуер 2021 г. (Инструменти за автоматизация на QA теста)
• Картографиране на ума при тестване на софтуер - начини да направим тестването по-забавно!
• Топ 20 практични съвета за тестване на софтуер, които трябва да прочетете, преди да тествате приложение