Tooge näiteid, kuidas testimisprotsess algab.

Testimise protsess võib alata erinevatel tarkvaraarendusel elutsükli etappidel, sõltuvalt valitud metoodikast ja projekti spetsiifikast.

Näited:

• Varajane testimine (või Shift-Left Testing):

  • Algab enne koodi kirjutamise etappe: nõuete kogumine ja analüüs, arhitektuuri ja kasutajaliidese disain.
  • QA osaleb dokumentatsiooni (nõuded, spetsifikatsioonid) ülevaatuses, tuvastades ebaselgusi, vastuolusid ja potentsiaalseid probleeme juba varases staadiumis.
  • Testjuhtumite, kontrollnimekirjade kirjutamine ja testimisstrateegia koostamine paralleelselt arendusega.
  • Rakendatav Agile ja DevOps lähenemistes.

• Testimine arendusfaasis (Unit Testing, Integration Testing):

  • Alustatakse, kui arendajad hakkavad koodi kirjutama.
  • Arendajad kirjutavad unit-teste, et kontrollida üksikuid mooduleid või funktsioone.
  • QA võib osaleda integratsioonitestimise planeerimises, testjuhtumite kirjutamises või isegi integratsioonitestide kirjutamises, kui nad kasutavad samu raamistikke nagu arendajad (Automation QA).

• Testimine pärast juurutamist (System Testing, Acceptance Testing, Regression Testing):

  • Alustatakse pärast vastava funktsionaalsuse või mooduli arenduse lõpetamist ja nende ühendamist.
  • Teostatakse terviklik süsteemi testimine.
  • Kasutajad või tellija esindajad teevad vastuvõtutestid.
  • Muudatuste tegemise järel teostatakse regressioonitestid, et veenduda, et uued muudatused ei ole rikkunud olemasolevat funktsionaalsust.

• Vea avastamise testimine tootmises:

  • Testimisprotsess võib alata, kui kasutaja või jälgimisvahendid avastavad töötab süsteemis vea.
  • QA analüüsib viga, taasalustab selle reprodutseerimise, lokaliseerimise ja vea aruande koostamise.
  • Algab paranduste tsükkel ja järgneva parandatud versiooni testimine.

# Näide QA osalemisest varajases testimises (nõuete ülevaatus)
def review_requirements(requirements_doc):
    """
    Pseudo-kood funktsioon nõuete dokumendi ülevaatamiseks QA spetsialistina.
    """
    issues_found = []
    # Täpsuse kontroll
    if not all_requirements_are_clear(requirements_doc):
        issues_found.append("Mõned nõuded on ebaselged või kaheldavad.")
    # Vastuolude kontroll
    if has_conflicting_requirements(requirements_doc):
        issues_found.append("Leitud vastuolulisi nõudeid.")
    # Testitavuse kontroll
    if not are_all_requirements_testable(requirements_doc):
        issues_found.append("Mõned nõuded on raskesti või võimatu testida.")
    
    return issues_found

# Eeldatavad abifunktsioonid
def all_requirements_are_clear(doc):
    pass # Kontrolli loogika
def has_conflicting_requirements(doc):
    pass # Vastuolude kontrolli loogika
def are_all_requirements_testable(doc):
    pass # Testitavuse kontrolli loogika

Testimise alguspunkti valik sõltub projekti strateegiast, kuid tendents testimise nihutamiseks vasakule poole (varajane testimine) muutub üha populaarsemaks, et parandada kvaliteeti ja vähendada defektide parandamise kulusid.