1. Testitakse igat funktsiooni eraldi
2. uuendamise käigus installeeritakse uus versiooni süsteemist, kohandamine on samuti süsteemi muutmine, kuid põhjuseks on peamiselt muudatuse kliendipoolses keskkonnas.
3. Testimise üldreegel
3.1. Testimisega saab näidata vigade esinemist, kuid mitte vigade puudumist.
4. Funktsiooni testimine
5. Testimise eesmärgid
5.1. Vigade leidmine
5.1.1. Otsitakse tootest vigu
5.1.2. Testimise käigus leida olukordi kus tarkvara ei vasta spetsifikatsioonile
5.2. Et programm vastaks kasutaja nõuetele
5.3. Verifitseerimise
5.3.1. Eesmärk on kinnitada, et protsessi või projekti iga tulem vastab spetsifitseeritud nõuetele.
5.3.2. "Kas me teeme tarkvarasüsteemi õigesti?" (2+2=4)
5.4. valideerimine
5.4.1. Tarkvara süsteem vastab tellimusele - teeb seda, mida tellija oli kirja pannud
5.4.2. "Kas me teeme õiget tarkvarasüsteemi?" (Telliti kalkulaator, tehti kalkulaator)
6. Autoriseerimine
6.1. Toode toetab kasutajate hierarhiat
7. Paigaldus
7.1. Toote ülesseadmine
8. Avalikustamine
9. Tarkvara installeerimine ja aktiveerimine
10. Testimise tüübid
10.1. Mooduli testimine
10.1.1. Testitakse igat moodulit eraldi
10.1.2. Otsitakse vigu, mitte vastavust kasutaja nõuetele
10.1.3. Tüüpiliselt kasutatakse "Valge kast"-i meetodit - testija tunneb testitava mooduli sisemist ülesehitust ja tööloogikat
10.1.4. testitakse andmetepõhiselt: õigete, puudulike ja vigaste andmetega
10.1.5. tarkvara vastab püstitatud nõuetele. Tellija saab seda, mida oli tellinud.
10.2. Integratsioonitestimine
10.2.1. Toote osade (moodulite) koostöö testimine
10.2.2. testija on üldjuhul sõltumatu (ei ole panustanud koodi kirjutamisse)
10.3. Süsteemi testimine
10.3.1. Toote tervikuna testimine (kõik moodulid koos)
10.3.2. Testitakse funktsionaalsust
10.3.3. Testjuhtumid koostab testija (peamiselt kasutuslugude põhjal), kes testid ka läbi viib
10.3.4. Kasutatakse "must kast" meetodit - vaadeldakse kastuajaliidese poolt, koodi ei uurita, ei nähta.
10.3.5. Testijaid peab olema nii tellija kui täitja poolel
10.4. Regressioontestimine
10.4.1. on igat tüüpi tarkvara testimine, mida kasutatakse peale koodi/süsteemi viidud muudatusi.
10.4.2. Regressioontestimise eesmärk on veenduda, et muudatused ja veaparandused pole tekitanud süsteemi uusi vigu.
10.4.3. on kasulik automatiseerida üldise töökoormuse vähendamiseks
10.4.4. Peamiseks meetodiks on juba kasutatud testide taaskäivitamine veendumaks, et süsteem toimib, vanad vead ei avaldu uuesti ja ei ole tekkinud uusi
10.5. Jõudlus testimine
10.5.1. Testitakse toote jõudlust/tootevõimet
10.5.2. ei testita funktsionaalsust (Mida toode teeb?) vaid jõudlust (Kuidas toode teeb?)
10.5.3. Jõudlustesti eesmärk on tuvastada kriitilisemad kohad, kus võib tekkida ülekoormus ja nende kohtade optimeerimine
10.6. Kasutatavuse testimine
10.6.1. kasutaja liidese ja -tegevuste juures vigade leidmine
10.6.2. Testimiseks peab inimene täitma konkreetseid ülesandeid ja sel teel selguvad tarkvarasüsteemis või ka veebilehel halvasti arusaadavad kohad.
10.7. Koodi läbivaatus
10.7.1. erinevalt eelnevalt käsitletud testi tüüpidest, koodi läbivaatuse puhul koodi ei käivitata vaid koodi inspekteeritakse testija poolt.
10.8. Vastuvõtu test
10.8.1. kliendi poolt läbiviidav test valminud toote hindamiseks ja vastuvõtmiseks
10.8.2. Vastuvõtutesti testijuhtumid kirjeldavad üheselt projekti üleandmise ja vastuvõtmise kriteeriumid ning testijuhtumid peavad olema konkreetsed ja mõõdetavad ning nendes lepivad tellija ja teostaja projekti realiseerimise eel kokku
11. Nõuded tarkvara omadustele
11.1. Funktsionaalsus
11.1.1. Toote omadus väljendamaks tema sobivust seatud ülesannete täitmiseks, st tarkvaraga saab teha seda, mida klient vajab
11.2. Turvalisus
11.2.1. Toote omadus piirata äriloogikale/andmetele ligipääsu autoriseerimata isikute poolt
11.3. Tõrkekindlus
11.3.1. toote omadus väljendamaks võimet tagada teatud jõudluse ja funktsionaalsuse tase veaolukorra tekke või liidese väärkasutamise puhul
11.4. Taastuvus
11.4.1. Kui edukalt toode vigadest taastub
11.4.2. toote omadus väljendamaks võimet taastada normaalne töörežiim ja jõudlus peale veaolukorra tekkimist
11.5. Taastatavus
11.5.1. toote omadus väljendamaks keerukust ja vajaminevat töö hulka ning aega süsteemi põhifunktsionaalsuse taastamiseks avariiolukorra puhul
12. Arendaja
13. Testimine, mille teostab isik(ud) kes ei ole toote arendamisega otseselt seotud
14. Jõudlus
14.1. kuluv aeg andmete reageerimiseks ja töötlemiseks
15. Porditavus
15.1. Toote omadus väljendamaks aja- ja töökulu toote kohaldamisel teistesse keskkondadesse, platvormidele.
16. Stabiilsus
16.1. Toote omadus väljendamaks muudatustejärgsete ootamatute nähtuste tekkimise riski suurust;
17. Testijad
17.1. Arendaja Kolleeg
17.2. Testimis osakond
17.3. Spetsialiseerunud ettevõte
18. Optimaalsus
18.1. Toote kõrge jõudlus tase
19. Sõltumatu osapoole testimine
20. Süsteemitestimise
20.1. korral testitakse süsteemi kui terviku töötamist.
21. Vigade dokumenteerimine testimises
21.1. Testimise käigus kõik vead dokumenteeritakse. Need aitavad programmeerijale anda tagasisidet.
21.2. Taastatavus
21.2.1. Võimalus taastada toote põhifunktsiooni
22. Tarkvaratoote levitamine
22.1. installeerimine riistvarale. Keerukamate, hajutatud süsteemide on abiks UML levitusskeemid millised kirjeldavad tarkvara paiknemist erinevatel riistvara sõlmedes, sealhulgas:
22.1.1. Avalikustamine (release). Avalikustamine järgneb arendusprotsessile. See sisaldab kõiki tegevusi, et süsteem ette valmistada assembleerimiseks (masinkoodi viimiseks) ning kliendi juurde üleviimiseks. Selle tegevuse käigus määratakse ka ressursid, mis on vajalikud töötamiseks kliendi poolel.
22.1.2. Tarkvara installeerimine ja aktiveerimine - käivituvad komponendid paigutatakse arvutitele-serveritele, kus nad edasipidi töötama peavad. Keerulisemad süsteemid vajavad lisaks ka muu toetava tarkvara installeerimist (nt andmebaasimootori uus versioon jms). Tihti installeeritakse suurem süsteem mitmesse keskkonda - näiteks lisaks ka testserverile, mida saab hiljem kasutajakoolituseks ja muudeks katsetusteks kasutada.
22.1.3. Kohandamine ja uuendamine - uuendamise käigus installeeritakse uus versiooni süsteemist, kohandamine on samuti süsteemi muutmine, kuid põhjuseks on peamiselt muudatuse kliendipoolses keskkonnas.
22.1.4. andmeülekanne vanast süsteemist - varem kasutatud süsteemis on reeglina andmed, mida tuleb ka edaspidi kasutada. Soovitav on automaatülekandevahendi loomine, milline käivitatakse ühekordselt andmete ülekandeks vanast süsteemist uude. Ülekandemehhanism võib olla päris keerukas, eriti kui vana süsteemi ja uue süsteemi andmestruktuurid on oluliselt erinevad. Kui andmete kogus on väike ja/või automaatteisenduse algoritmi väljatöötamine liigselt keerukas, on võimalik andmeid ka käsitsi üle kanda. Sellisel juhul võib olla vajalik luua raportid vanast süsteemist andmete väljavõtmiseks ja sisestusvormid vm vahendid andmete käsitsi sisestamiseks kasutuselevõetavasse süsteemi;
22.1.5. muudatuste tegemine teistesse rakendustesse, millised peavad töötama koos ja/või kasutatakse koos arendatava tarkvaratootega;
22.1.6. koolituse ettevalmistamine ja läbiviimine tarkvaratootega kokkupuutuvatele inimestele, sh järgmistele rollidele:
22.1.6.1. Igapäevased kasutajad
22.1.6.2. Administraatorid
22.1.6.3. Kasutajatoe pakkujad.