Părțile comune — ce moștenește un proiect fără să ceară

Acest conținut nu este încă disponibil în limba selectată.

Trei fișiere care există ca nimeni să nu le rescrie. Un caiet care repetă anexa tehnică nu e mai complet — e mai lung, și divergent de restul companiei la prima modificare.

Fișier	Ce conține	Cine îl moștenește
`reference/anexa-tehnica-comuna.md`	NFR, securitate, logare, roluri, cache, integrări, storage, deployment, Kubernetes, audit, search	toate caietele de sarcini
`reference/biblioteca-cazuri-test-comune.md`	cazurile `TC-COM-`, legate 1:1 de `CU-`	toate planurile de testare
`reference/strategie-testare-comuna.md`	nivelurile de testare: unit, integrare, contract, E2E, non-funcțional, smoke, UAT	toate planurile de testare

Modelul de moștenire — regula de aur

Caietul specific NU rescrie partea tehnică. Completează un tabel de conformitate (§13 din template-ul de business) care marchează, per domeniu: Aplicabil · Parțial · N/A.

N/A fără motiv scris e eroare, nu alegere. Asta e singura verificare care împiedică tabelul să devină o coloană de bifat. Un domeniu tăiat cu justificare e o decizie de arhitectură; unul tăiat în tăcere e o cerință pierdută care reapare la recepție.

Planurile de testare

Planul specific moștenește strategia comună și include cazurile TC-COM-* aplicabile — implicit, toate cele ale domeniilor marcate „Aplicabil” în tabelul de conformitate. Apoi adaugă doar cazurile de business proprii, cu ID-uri TC-<APP>-NN.

Astfel acoperirea transversală e gata-făcută: nu se testează de la zero securitatea, autentificarea sau semnătura la fiecare proiect — se testează businessul.

Ordinea corectă

tabelul de conformitate în caiet → decide ce domenii sunt aplicabile
domeniile aplicabile → decid ce TC-COM-* intră în planul de testare
businessul din caiet → decide ce TC-<APP>-* se adaugă

Dacă faci planul de testare înainte de tabelul de conformitate, alegi cazurile pe intuiție. Se vede.