Scribd
Upload
293 views11 pages

Practica Testing Levels TM14

The document describes a small delivery business that charges different rates for brick deliveries depending on distance from the office and whether stairs are involved. Rates are 10 euro for deliveries under 8km, 20 euro for over 8km, and an extra 10 euro for stairs. Weekend deliveries are a fixed 60 euro regardless of distance or stairs. The tasks are to design test scenarios to verify the billing functionality without UI testing, and clarify or correct any issues with the feature.

Uploaded by

MihaiLeonte
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
293 views11 pages

Practica Testing Levels TM14

The document describes a small delivery business that charges different rates for brick deliveries depending on distance from the office and whether stairs are involved. Rates are 10 euro for deliveries under 8km, 20 euro for over 8km, and an extra 10 euro for stairs. Weekend deliveries are a fixed 60 euro regardless of distance or stairs. The tasks are to design test scenarios to verify the billing functionality without UI testing, and clarify or correct any issues with the feature.

Uploaded by

MihaiLeonte
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

1.

We have a small delivery business where bricks are shipped to customers (1


brick = 1 kg). These are the rates we charge:
1. If the delivery is < 8km from our office, the cost is 10euro
2. If the delivery is > 8km from our office, the cost is 20euro
3. If there are stairs involved in delivery, we ask for extra 10euro
4. If the delivery is during weekend, then the price is fixed at 60euros, regardless
of the distance or stairs.

We want to test the billing side of the application, no UI testing involved.

Questions
a) What are the scenarios you would suggest to be verified? How would you imagine
the UI side for this calculation?
b) What clarifications or corrections would you make to this feature?
2. Ne imaginam urmatorul filtru:

Ce teste ati pregati (si cum ajungeti la ele) astfel incat


orice optiuni de filtrare voi pune, sa ma asigur ca mi se
afiseaza rezultatele corecte? Cum vom verifica daca
intr-adevar cele afisate vor fi chiar rezultatele corecte?
3. Please describe the test scenarios that you would execute
in order to verify the search functionality (CTRL + F) in a Chrome browser.
4. A Web application for hotel booking takes as input the number of people
that need the room (min 3), the arrival date, the departure date (must be
after at most 15 days) and the room type (smoking/non-smoking).

• Dates must be entered in the dd/mm/yy format.


• Codes for smoking is “s”, code for non-smoking is “ns”.

Design test cases for such functionality based on black box testing
technique. Indicate what techniques are used and the identified equivalent
classes.
5. O banca acorda credite persoanelor intre 18 si 64 ani, inclusiv. Campul de
intrare corespunzator 'Varsta' accepta numai numere pozitive, 2 cifre.

Cerinte:
• Construim tabele corespunzatoare pentru a identifica valorile valide si
invalide pentru Equivalence Partitions si Boundary Values.
6. O banca oarecare acorda credit ipotecar pentru persoane cu venituri intre
$1,000/luna si $83,333/luna. Orice venit sub $1,000/luna nu se califica. Voi
sunteti testerii care verifica softul ce va fi folosit de aceasta banca pentru
aceste operatiuni/functionalitati.

Cerinte:
• stabiliti clasele de echivalenta (equivalence partitioning), atat cazuri valide
cat si cazuri invalide
• stabiliti boundary values
7. Sunt reduceri la un magazin de imbracaminte. In magazin exista mai multe
tipuri de articole vestimentare. Vor fi puse la reducere doar pantalonii,
bluzele si fustele care sunt de mai mult de 3 luni in magazin. Pantalonii vor
beneficia de o reducere de 20%, bluzele de 30% si fustele de 50%.

Cerinte:
• Cream un tabel de decizie pentru a evalua cazurile de test si expected
results.
8. Consideram un sistem software pentru un magazin online ce va accepta
intr-un text-box numele unui aliment urmat de o lista a marimilor in care
acel item poate fi comercializat, marime specificata in grame.

In SRS se specifica faptul ca:


• fiecare nume de aliment trebuie sa fie reprezentat de o secventa de litere
de lungime minima 2 si maxima 15.
• fiecare marime trebuie sa fie un numar intre 1 si 48, doar numere intregi
• marimile trebuie sa fie ordonate crescator, cele mai mici la inceput
• se poate seta un numar maxim de 5 marimi (le putem numi gramaje),
pentru fiecare aliment.

Format:
• nume aliment, urmat de virgula, apoi urmat de lista de gramaje, fiecare
gramaj fiind separat prin virgula
• spatiile vor fi ignorate

Cerinte:
• Realizati clasele de echivalenta valide si invalide
9. Intr-un sistem ce calculeaza taxele salariale, avem urmatoarele situatii:
• pentru primii 4000$ nu se plateste nici o taxa
• pentru urmatorii 1500$ se plateste 10% taxa
• pentru urmatorii 28000$ se taxeaza 22%
• orice depaseste aceasta suma se taxeaza cu 40%

Cerinte:
• realizati clasele de echivalenta si boundary values
• alegeti un set de valori pe care le considerati relevante pentru a fi testate
10. Realizati equivalence partition si boundary analysis pentru un camp unde se
introduce ziua din luna.
11. Realizati equivalence partition si boundary value analysis pentru un camp
unde se introduce numarul de telefon.

Note:
• Un numar de telefon valid este format din 10 cifre.
• Campul accepta maxim 14 caractere.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy