Pasakyt, kad šio pranešimo tikslas yra supažindinti testuotojus su galbūt dar nežinomomis juodosios dėžės testavimo metodikomis. Kad šis pranešimas yra informacinis, paliečiantis pačius pagrindus, bet neinantis labai giliai
Ekvivalenčios klasės negali persidengti. Negali būti tuščios klasės. Reikia įtraukti ir negatyvių particijų. Testai būtų - skaičiai paimti iš šių klasių, nesvarbu kokie. Pasakyt, kad jei dropdown’as yra, tai galima tiesiog susinumeruot
Ribinių reikšmių analizė. Mažiausios ir didžiausios reikšmės. Ar žinojot, kad worde šrifto dydį galima pasirinkt nuo 1 iki 1638, o Excelyje į vieną laukelį įrašyti 32198 (10 wordo puslapių)
Sprendimų lentelės
Pasakyt, kad rule 4 galima naikint todėl, kad tas pats veiksmas gaunasi, kai žmogus turi/neturi pinigų ir nenori pirkti namo
Naudojant visokius decision table mažinimo įrankius yra labai svarbu neištrinti svarbių stulpelių.
Ką su kuo galima kombinuoti, ko negalima, kokius stulpelius galima apleist, o kuriems reiktų skirti didesnį dėmesį
Būsenų ir jų pasikeitimų testavimo metodas
Yra du validus scenarijai, bet galima mėginti testuoti ir nevalidų – going to the user group -> answering questions
Būsenų ir jų pasikeitimo lentelės sudarymo taisyklės. Išrašomos visos būsenos, tada išrašomi visi įvykiai/sąlygos/veiksmai, tuomet sukuriam lentelę, kurioje būtų po eilutę kiekvienai būsenai su kiekvienu įvykiu/sąlyga.
Lietuviškai versčiau būsenų persijungimo padengiamumo technika.
0-switch apima vieną seką
1-switch apima dvi
Galima ir n-switch turėt
http://istqbexamcertification.com/what-is-use-case-testing-in-software-testing/
Pasitelkiamos use case diagramos. Labiau naudojama biznio kalba, o ne techniniai terminai.
Porinis testavimas. Efektyvus testavimo būdas, kai galvojama, kad dauguma klaidų atsiranda dėl dviejų faktorių susikirtimo. Šiuo būdu sugeneruoti testavimo atvejai apima visas porų kombinacijas.
Jei norime stipriau testuoti kažkokį tai funkcionalumą, dažniau jį įtraukti į testus, arba pavyzdžiui ne visi su visais faktoriai egzistuoja ir reikia daryti tam tikras išimtis, tokiu atveju porinis metodas nelabai tiks. Štai čia į pagalbą ateina klasifikacijų medžiai.
Yra acceptance kriterijai, testai gali būti generuojami iš jų, taip pat ir neigiami testai.
galvoji, kokius bugus gali padaryt developeriai, ilgainiui gal net galima susidaryti sąrašą vietų, kurias galima iškart patikrint ir tikėtina, kad bus rastas vienas ar keli bugai. Jei tai yra skaičiavimai, tai dažniausiai surandama dalyba iš nulio, neteisingai įvesti parametrai arba nullpointeriai kokie.
Kontroliniu sąrašu paremtas testavimas. Dažniausiai sąrašas yra suorganizuotas pagal kažkokią tai temą. Tai gali būti kokybės metrikos, vartotojo sąsajos kažkokie tai standartai. Šis sąrašas yra labai aukšto lygio, neturi būti detalizuojama.