Meny

Hur testar jag en ansökan utan krav?

how test an application without requirements

Prova Vårt Instrument För Att Eliminera Problem

Tekniskt sett finns det inga applikationer utan krav. Föreställ dig programvara som inte gör något specifikt men helt enkelt är rad efter rad kod som sträcker sig på. Det blir en trappa som inte leder någonstans.

All programvara har krav och är inriktad på en viss uppgift; specifikt är det en lösning på ett problem. Så kravfri programvara är inte en möjlighet.

Men programvara utan dokumenterade krav är en verklighet som tyvärr de flesta av oss möter oftare vi gillar. Det enda värre kan vara att dokumentationen är otillräcklig, felaktig eller fruktansvärt föråldrad. Tyvärr händer det också.

test utan krav

Ärligt talat, det finns egentligen inget substitut för ett väldokumenterat dokument för funktion / systemkrav med detaljerade användningsfall och mock up-skärmar. Även om vi måste erkänna att detta blir en sällsynthet i branschen på grund av snabba utvecklingscykler och ett paradigmskifte mot minimal eller ingen dokumentation.

Därför är den här artikeln ett försök till några metoder vi har följt när vi befann oss i dessa situationer.

Läs också:

den bästa gratis nedladdningsappen för musik för Android

Låt oss först titta på några anledningar till att det kanske inte finns dokumentation, till att börja med:

  1. Hyllaprojekt öppnas igen
  2. Dokumentation mindre format på arbetsprocessen
  3. Dokumentation kan finnas - men kanske inte detaljerad eller fullständig
  4. Kontinuerliga utgåvor och information om den äldre versionen har inte arkiverats vilket resulterar i ett gap i förståelsen för hur den befintliga funktionaliteten reagerar med den nya

Det här är alla hinder som vi testare måste tappa och korsa framgångsrikt. Hur exakt dock, eller hur?

Här är de tre bästa metoderna för att testa en applikation utan krav:

Metod nr 1:

Arbeta med den lilla dokumentationen du kan ta hand om. Det kan vara en enkel enkel eftersläpning (i agila projekt), en hjälpfil, ett e-postmeddelande, en äldre version av BRD / FRD eller gamla testfall (kolla efter dessa i dina ALM-verktyg och du kan hitta dem), etc.

Undersök, fråga runt och det finns alltid en dokumenterad rättegång även om den är tunn.

Om detta inte fungerar, rabattera inte din upplevelse som programvaruanvändare.Till exempel, om du måste testa en överföringsåtgärd för ett bankkonto, behöver ingen berätta för oss hur man gör det, eller hur? Eftersom vi som nätbanker vet alla att vi behöver från och till konton med ett antal tillgängliga medel att överföra.

Enades om att inte alla situationer kommer att bli lika enkla, men igen, de kan också vara.

Metod 2:

Använd den äldre / aktuella versionen av applikationen som referens för att testa den framtida utgåvan av en programvaruprodukt. Nu erkänner jag att detta strider mot regeln: ”Skriv aldrig testfall med applikationen som referens”. Men när vi arbetar i en mindre perfekt situation måste vi forma reglerna för att passa våra behov.

Det hjälper till att hålla följande aspekter i perspektiv när du gör det:

  • Applikationen kan innehålla buggar, så om systemet efter registrering tar dig direkt till Screen1 (en viss hypotetisk skärm för vårt exempel) - Antag aldrig att det är rätt beteende. Även om ett fält tar alfanumeriska tecken och är ett telefonnummer - en fråga som och se till att du inte tar applikationen som ett givet exempel för förväntad funktionalitet.
  • I ovanstående situationer använder du ditt omdöme och tar hjälp av applikationen för att ge dig en snabbstart, men var kritisk mot den för att ifrågasätta att den fungerar.

Metod # 3:

Prata med projektgruppens medlemmar:

  • Erbjud dig att delta i deras möten.
  • Fråga om du kan delta i teststegen för enheten och integrationen.
  • Om inte, fråga om dev-teamet kan dela sina enhets- och integrationstestresultat.
  • Ordna en tid för kunskapsöverföring vid en lämplig tidpunkt.

Nu ska vi tillämpa metoderna i ett exempel:

Låt oss anta att det finns en shoppingplats där du kan lägga till varor i kundvagnen. Helst om det fanns dokumentation måste det berätta för oss hur man lägger till artiklar i det, hur många artiklar kan det ha vid en given tidpunkt, vad händer när artikeln som du har lagt till plötsligt slut i lager, vad är det maximala antalet av samma föremål som du kan köpa samtidigt, etc. Vår situation är att INGEN av det är tillgängligt just nu.

Använd metod nr 1:

Hitta eventuell dokumentation. Fråga ditt dev-team om de har mock-up-skärmar / titta i ALM-verktyget eller något alls. Om du hittar något skulle det vara en bra utgångspunkt. Men om den här metoden inte visar något, kan du använda din testarens bedömning / intuition.

Vi vet alla hur kundvagnar fungerar så gör dina antaganden och kom fram till några grundläggande scenarier som:

  • Objekt kan läggas till i kundvagnen efter att ha bläddrat eller sökts
  • När jag har lagt till varor i kundvagnen bör listan med artiklar uppdateras
  • Användaren ska kunna fortsätta handla även efter att ha lagt till några artiklar i kundvagnen
  • Om du lägger till samma objekt två gånger kommer antalet tillagda poster att ökas
  • Objekten kan uppdateras
  • Föremålen kan tas bort
  • Summan ska motsvara summan av alla tillagda priser
  • Skatterna ska beräknas utifrån det angivna postnummer
  • Fraktkostnader måste läggas till i enlighet med detta

Vi kan fortsätta, men jag är säker på att du får bilden.

Använd metod nr 2:

Om det finns en äldre version av applikationen tillgänglig, kan det vara till hjälp när du skriver dina testfall, eftersom du måste skriva de exakta stegen för var du ska klicka, var du ska ange inmatning, vad du ska kontrollera etc. Skärmbilder / mockups / tråd- ramar - om tillgängliga kan också vara bra ersättare.

Som du kan se från skärmen nedan är dessa saker uppenbara - fältnamnen, knapparna eller andra element som finns etc. (klicka på bilden för förstorad vy)

test utan krav

Nu har testare några frågor som:

  1. Vad händer när jag ger en röding i rutan för belopp?
  2. När lägger jag till för många artiklar?
  3. Vad är det maximala nej. av föremål som detta kan ta? Etc.

Använd metod nr 3 :

Ta din lista med frågor till BA, utvecklare eller till och med klienten och sök förtydligande. När metod 3 är klar bör du i stort sett vara utrustad med all information du behöver för att skriva detaljerade testfall och utföra dina tester med lika mycket självförtroende som du skulle göra när detaljerad dokumentation fanns tillgänglig.

Enades om att det är mycket fler steg och mycket mer uppföljning men för att säkerställa kvalitetstester är dessa steg oundvikliga.

Sammanfattningsvis, allt går inte förlorat när dokumentation inte finns eller är otillräcklig. Det finns fortfarande hopp! Dela dina erfarenheter i liknande situationer.

Om författaren: Detta hjälpsamma inlägg är skrivet av vår STH-teammedlem Swati S.

Som alltid är dina kommentarer, frågor och förslag mycket välkomna.

Rekommenderad läsning

^