O instalație BSL-3/4 care intră în faza finală de testare generează o problemă specifică de decizie: care rezultate demonstrează performanța integrată și care demonstrează doar că echipamentul este prezent și alimentat cu energie. Greșirea acestei secvențe nu duce doar la pierderea de timp prin repetarea verificărilor. Ea generează un pachet de predare în care echipa de testare nu poate afirma, cu încredere, de ce un anumit rezultat rămâne valabil odată ce se produce o schimbare în etapele anterioare. Ordinea testelor este importantă deoarece izolarea de biosecuritate depinde de funcționarea coordonată a sistemelor în condiții de defecțiune, nu de faptul că fiecare componentă trece de propria verificare izolată.
Condiții prealabile care trebuie să fie îndeplinite înainte de testarea integrată
| Etapa de pregătire | Informații care trebuie verificate înainte de a continua | Limita de decizie |
|---|---|---|
| Completitudinea instalării | Instalarea sistemelor care intră în secvența de testare este finalizată | Rezultatele dinamice nu ar trebui utilizate ca dovezi ale performanței integrate înainte de îndeplinirea acestei condiții |
| Instrumente calibrate | Instrumentele utilizate pentru verificările programate dispun de certificate de calibrare valabile | Rezultatele depind de contextul de testare aplicabil și de protocolul proiectului |
| Servicii de utilitate publică verificate | S-a demonstrat necesitatea utilităților înainte de apariția provocărilor legate de echipamentele individuale și de cele la nivel de sistem | O dependență de probe care nu este stabilă poate invalida probele ulterioare |
| Funcționalitatea echipamentelor individuale a fost verificată | Au fost demonstrate funcțiile echipamentelor necesare pentru provocările integrate planificate | Provocările la nivel intersistemic urmează testării la nivel de echipament |
| Criterii de acceptare aprobate | Criteriile predefinite ale proiectului sunt convenite înainte de execuție | Cadrele menționate nu furnizează valori de acceptare specifice fiecărui amplasament |
Înainte de orice rezultatul testului integrat poate fi considerată o dovadă a performanței de izolare, echipa de testare trebuie să aibă certitudinea că starea inițială a elementelor fizice și a instrumentelor nu se va modifica pe parcursul secvenței. Finalizarea instalării este prima condiție, nu pentru că o instalare incompletă ar face imposibilă testarea, ci pentru că un rezultat dinamic înregistrat pentru un sistem încă în curs de finalizare nu poate fi diferențiat de un rezultat care reflectă configurația finală. Dacă după o verificare dinamică se adaugă conducte, feronerie pentru uși sau cablaj de control, acea verificare nu mai descrie sistemul care urmează să fie predat.
Instrumentele calibrate sunt la fel de importante ca și completitudinea instalației, dintr-un motiv legat de acestea. Precizia unei măsurători de presiune sau debit depinde în totalitate de calitatea instrumentului care o generează, iar un instrument cu calibrarea expirată sau neverificată transformă un rezultat aparent corect într-unul care nu poate fi verificat. Nu este vorba de o simplă formalitate; acest lucru schimbă semnificația reală a valorii numerice din raportul de testare. În cazul în care protocolul proiectului impune un context specific de testare, conform ISO 14644-3:2019, echipamentele și procedurile recomandate pentru parametrii de performanță ai camerelor curate și zonelor curate instalate produc rezultate comparabile numai atunci când contextul de testare aplicabil este definit în prealabil, întrucât în rezumatul standardului se menționează că acesta nu stabilește valori de acceptare specifice locației fără acest context.
Consecința practică pentru secvențierea etapelor este că o echipă de proiect nu poate sări peste etapele dintre “echipamentul este instalat” și “sistemul este pregătit pentru provocările la nivel inter-sistemic”. Fiecare etapă trebuie parcursă în ordine: instalarea, apoi calibrarea instrumentelor, apoi verificarea funcționării utilităților, apoi funcționarea individuală a echipamentelor și abia apoi provocările care depășesc limitele sistemului. Sărirea peste etape nu economisește timp dacă etapa omisă invalidează ulterior rezultatele obținute mai târziu, deoarece fiecare rezultat ulterior moștenește incertitudinea etapei de care depindea.
Ceea ce diferențiază această evaluare de la un proiect la altul este gradul de interdependență integrat în proiectarea instalației. În cazul în care sistemele sunt mai strâns interconectate, o condiție prealabilă instabilă se propagă mai departe înainte de a fi detectată. În cazul în care echipamentele funcționează mai independent, o condiție prealabilă instabilă rămâne localizată mai mult timp. În orice caz, întrebarea la care echipa de testare trebuie să răspundă înainte de a începe este aceeași: ce etapă am depășit efectiv și ce dovezi o închid, spre deosebire de simplul fapt că ceva a fost instalat sau pus în funcțiune.
Verificări ale instalării și funcționării care asigură calitatea rezultatelor ulterioare
Utilitarele reprezintă condiția prealabilă discretă care stă la baza aproape oricărui test ulterior; de aceea, testarea lor individuală, înainte de a se încerca orice provocare la nivel intersistemic, protejează integritatea tuturor etapelor următoare. Un utilitar care pare stabil în condiții statice se poate comporta diferit atunci când i se solicită să susțină un eveniment dinamic, intersistemic, iar dacă această diferență nu este detectată din timp, ea se manifestă ulterior ca o anomalie care pare mai degrabă o defecțiune a echipamentului decât o dependență de utilitar.
Raționamentul de aici este unul secvențial, nu aditiv. Demonstrarea funcționalității nu este pur și simplu încă un element de bifat pe o listă; este condiția care face ca fiecare rezultat ulterior, atât la nivel de echipament, cât și la nivel intersistemic, să poată fi interpretat. Dacă nu se confirmă stabilitatea unei dependențe de utilitate, o defecțiune survenită în timpul unei provocări ulterioare legate de interblocare sau de controlul presiunii devine ambiguă: a cedat echipamentul sau a cedat mai întâi utilitatea care îl susținea? Separarea acestor două moduri de defectare după ce s-a produs evenimentul este mai dificilă decât prevenirea ambiguității prin stabilirea corectă a secvenței încă de la început.
Tot aici trebuie demonstrate funcțiile individuale ale echipamentelor în condiții proprii, înainte ca acestea să fie solicitate să participe la o provocare care implică mai multe sisteme. Un sistem de blocare a ușilor, un clapet de evacuare sau un ciclu de decontaminare au fiecare o funcție care poate fi verificată izolat. Abia după ce acea funcție izolată este confirmată are sens să ne întrebăm cum se comportă echipamentul atunci când trebuie să se coordoneze cu răspunsul unui alt sistem. Inversarea acestei ordini înseamnă că o defecțiune care afectează mai multe sisteme nu poate fi urmărită cu certitudine până la originea sa.
Condiția care determină ponderea acordată acestei etape este complexitatea arhitecturii utilităților în sine. În cazul în care utilitățile sunt partajate între mai multe zone de izolare sau tipuri de echipamente, devine tot mai importantă testarea lor individuală înainte de integrare, deoarece o defecțiune a unei utilități partajate are un efect de undă mai amplu asupra întregii secvențe de testare. În cazul în care utilitățile sunt mai segmentate pe sisteme, lanțul de dependențe este mai scurt și mai ușor de izolat dacă, ulterior, apare o comportare neașteptată.
Funcțiile echipamentelor care trebuie verificate înainte de provocările între sisteme
Regula de bază în această etapă este simplu de formulat, dar ușor de încălcat sub presiunea termenelor: trebuie să se demonstreze ce poate face un echipament pe cont propriu înainte de a-i cere să participe la o provocare care depinde de răspunsul corect al unui alt sistem în același timp. Un sistem de blocare a ușilor, o secvență de control al presiunii, o reacție a sistemului de evacuare, un ciclu de decontaminare sau o secvență de tratare a deșeurilor au fiecare o funcție distinctă. Confirmarea acelei funcții în mod izolat stabilește un punct de referință cunoscut, în raport cu care poate fi evaluat orice comportament ulterior, mai complex.
Motivul pentru care această ordine este importantă este de natură diagnostică, nu procedurală. Atunci când s-a demonstrat deja că echipamentul își îndeplinește corect funcția individuală, o problemă care apare în timpul unui test de interacțiune între sisteme poate fi atribuită interacțiunii dintre sisteme, mai degrabă decât echipamentului în sine. Fără această bază de referință, o echipă de testare care se confruntă cu un rezultat neașteptat în timpul unei secvențe de interblocare sau decontaminare nu are cum să facă distincția între “mecanismul ușii a eșuat” și “nu s-a confirmat niciodată funcționarea mecanismului ușii, iar acesta eșuează acum pentru prima dată într-o condiție complexă”. Prima situație reprezintă o constatare la nivel de interacțiune între sisteme; a doua este o lacună în secvența de testare care ar fi trebuit remediată mai devreme.
Acest principiu unic se aplică tuturor tipurilor de echipamente implicate în secvență, deoarece mecanismul este același, indiferent de limita care este testată. Fie că sistemul implică dispozitive de blocare a ușilor și răspunsul la fluxul de aer, fie că este vorba de echipamente de decontaminare și secvențele de tratare a deșeurilor, întrebarea esențială este identică: s-a demonstrat că această funcție funcționează înainte de a i se cere să o facă în cadrul unui eveniment coordonat mai amplu? A amortizor de izolare pentru biosecuritate și un Ușă APR cu garnitură pneumatică fiecare îndeplinește o funcție distinctă în cadrul sistemului de izolare, iar pentru fiecare trebuie confirmată funcția sa înainte de a fi considerată o intrare cunoscută și fiabilă într-un test de provocare la nivel de sistem.
Ceea ce determină importanța practică a acestei etape este numărul de sisteme cu care interacționează un anumit echipament. Echipamentele care interacționează doar cu un singur alt sistem prezintă o problemă de diagnosticare mai restrânsă în cazul în care apare o defecțiune ulterior. Echipamentele care se află la intersecția mai multor sisteme, cum ar fi o ușă care influențează atât echilibrul fluxului de aer, cât și controlul accesului, au consecințe mai grave dacă funcționarea lor individuală nu a fost verificată în prealabil, deoarece o defecțiune care implică mai multe sisteme și la care este implicat echipamentul respectiv are mai multe cauze posibile care trebuie excluse.
Scenarii de defecțiune pentru fluxul de aer, alarme, dispozitive de interblocare și alimentare cu energie electrică
| Stare credibilă | Este necesar să se definească probele de răspuns înainte de execuție | Limita aplicabilă |
|---|---|---|
| Pierderea de putere | Măsura de siguranță recomandată în cazul unei întreruperi de curent | Protocolul proiectului trebuie să stabilească răspunsul preconizat și criteriile de acceptare |
| Pierderi la evacuare | Răspunsul preconizat al sistemului de control al emisiilor și al sistemului de alarmă | Cerințele privind fluxul de aer și alarmele depind de proiectarea instalației, de evaluarea riscurilor și de reglementările locale aplicabile |
| Conflictul legat de ușă | Răspunsul preconizat al sistemului de blocare a ușilor | Protocolul proiectului trebuie să definească situația de conflict în cauză și răspunsul preconizat |
| Confirmarea alarmei | Răspunsul de confirmare preconizat în timpul simulării unei defecțiuni | O verificare a confirmării de primire nu constituie, în sine, o dovadă a recuperării |
| Recuperare | Răspunsul preconizat pe măsură ce sistemul își revine din starea de eroare | Dovezile privind recuperarea trebuie evaluate în raport cu criteriile convenite pentru proiect |
Odată ce funcționarea echipamentelor individuale și a utilităților este verificată, secvența trece la testarea deliberată a sistemului în condiții credibile de defecțiune. Acesta este un tip de test diferit de orice altul efectuat anterior, deoarece nu se verifică dacă echipamentul funcționează în condiții normale, ci dacă sistemul reacționează în condiții de siguranță atunci când apare o defecțiune. Pierderea de alimentare, pierderea de evacuare, conflictul de uși, confirmarea alarmei și recuperarea reprezintă fiecare o stare de defecțiune distinctă, iar pentru fiecare dintre acestea este necesar ca răspunsul de siguranță așteptat să fie convenit și documentat înainte de rularea simulării, nu interpretat ulterior pe baza a ceea ce s-a întâmplat.
Această cerință privind ordinea apare deoarece testarea modurilor de defectare lipsa unui răspuns predefinit transformă fiecare rezultat într-o decizie luată a posteriori, ceea ce reprezintă tocmai genul de ambiguitate pe care un pachet de predare-preluare trebuie să o evite. Dacă răspunsul așteptat la o pierdere a gazelor de eșapament nu este stabilit în prealabil, atunci orice acțiune întreprinsă de sistem în timpul simulării pierderii devine standardul de facto, în loc să fie evaluată în raport cu un criteriu convenit. Acest CDC/NIH BMBL Ediția a 6-a abordează în mod direct aspectele legate de monitorizarea fluxului de aer pentru nivelul BSL-3 și de sistemele de blocare a ventilației pentru nivelul BSL-4, de alarmele de abatere, precum și de funcțiile de acces și decontaminare; cu toate acestea, conform bunelor practici recomandate de autoritățile din SUA, detaliile specifice fiecărei unități se conformează în continuare evaluării de risc aplicabile și normelor locale care reglementează proiectul respectiv.
Stările de defecțiune nu sunt interschimbabile în ceea ce privește elementele pe care le testează. Un test de pierdere a alimentării cu energie verifică modul în care se comportă sistemul atunci când sursa sa principală de energie este întreruptă, ceea ce are implicații simultane asupra tuturor funcțiilor alimentate din incinta de izolare. Un test de pierdere a fluxului de evacuare izolează o funcție specifică a fluxului de aer și verifică dacă pierderea acesteia este detectată și dacă se răspunde corect la aceasta. Un test de conflict al ușilor verifică dacă logica de interblocare rezolvă o stare specifică de conflict în modul prevăzut de proiect. Testarea confirmării alarmei verifică dacă sistemul înregistrează corect faptul că o persoană a răspuns la o alertă, ceea ce este o chestiune distinctă de faptul dacă situația care a generat alerta a fost efectiv rezolvată. Testarea recuperării verifică dacă sistemul revine la o stare sigură și cunoscută odată ce situația de testare încetează, iar acest lucru trebuie evaluat în conformitate cu aceleași criterii convenite ca și în cazul răspunsului inițial la defecțiune, fără a se presupune că răspunsul la defecțiune în sine a fost acceptabil.
Condiția care determină care scenarii de avarie sunt cele mai importante pentru un anumit proiect este evaluarea specifică a riscurilor și proiectarea sistemului de izolare a instalației. O instalație cu o configurație particulară a sistemului comun de evacuare care acoperă mai multe zone se confruntă cu consecințe diferite în cazul unei pierderi la nivelul sistemului de evacuare față de una cu o arhitectură de evacuare mai segmentată. Tocmai de aceea, răspunsul preconizat trebuie definit de protocolul proiectului, mai degrabă decât să fie dedus dintr-un principiu general: răspunsul corect și sigur depinde de caracteristicile specifice ale instalației, nu este un răspuns fix care se aplică în mod uniform.
Verificarea din nou a logicii după apariția unor abateri sau modificări de configurare
| Eveniment sau înregistrare | Problema pe care echipa de testare trebuie să o rezolve | Elemente de probă necesare pentru luarea deciziei |
|---|---|---|
| Abatere | Care rezultat al testului sau care dependență a fost afectată? | Abaterea înregistrată și relația acesteia cu secvența de testare |
| Modificare de configurare | Care dintre rezultatele anterioare rămân valabile după această modificare? | Configurația modificată și dependențele rezultatelor afectate |
| Decizia privind repetarea testului | Care dintre verificările afectate trebuie repetate? | Criteriile de acceptare aprobate și motivul documentat pentru domeniul de aplicare al retestării selectat |
| Reexaminare finalizată | Noul rezultat îndeplinește criteriile aprobate? | Rezultatul retestării, eventualele abateri rămase și concluzia raportată |
O abatere sau o modificare de configurație descoperită pe parcursul secvenței de testare ridică o întrebare care poate fi ușor subestimată: care dintre rezultatele anterioare sunt încă valabile și care trebuie repetate acum? Nu înseamnă automat “retestarea tuturor elementelor”, dar nici “retestarea doar a elementului care s-a modificat”. Domeniul de aplicare corect depinde de înțelegerea lanțului de dependențe stabilit de secțiunile anterioare ale secvenței.
Dacă o modificare de configurație afectează o utilitate de care depind mai multe funcții ale echipamentului, atunci fiecare rezultat care se baza pe stabilitatea acelei utilități este acum pus sub semnul întrebării, chiar dacă echipamentul în sine nu a fost modificat direct. Aceasta este consecința directă a logicii de secvențiere utilizate anterior: deoarece rezultatele ulterioare depind de închiderea porților anterioare, o modificare a unei porți anterioare pune din nou sub semnul întrebării validitatea tuturor elementelor construite pe baza acesteia. Sarcina echipei de testare este de a urmări acel lanț de dependențe în aval de la punctul de abatere sau modificare, nu doar de a rula din nou verificarea specifică în care a fost observată pentru prima dată abaterea.
EudraLex Volumul 4 Anexa 15 descrie cadrul de calificare relevant pentru acest raționament, acoperind relația dintre FAT și SAT, etapele IQ/OQ/PQ, criteriile predefinite, abaterile și concluziile raportate. În calitate de cadru de calificare GMP, acesta stabilește că protocoalele de proiect definesc etapele și limitele specifice echipamentului și că dovezile furnizate de furnizor necesită în continuare o evaluare a adecvării în raport cu criteriile specifice proiectului. Logica retestării descrisă aici funcționează în cadrul aceleiași structuri: se înregistrează o abatere, se clarifică relația acesteia cu secvența de testare, se stabilește domeniul de aplicare al retestării în raport cu criteriile de acceptare aprobate, iar rezultatul retestării este apoi evaluat pentru a confirma dacă concluzia inițială rămâne valabilă sau necesită revizuire.
Ceea ce diferențiază o abatere de o modificare de configurație este orientarea întrebării. O abatere se referă la rezultatul sau dependența care a fost afectată de un eveniment care nu s-a desfășurat conform așteptărilor în timpul testării. O modificare de configurație se referă la rezultatele anterioare care rămân valabile după ce ceva a fost modificat în mod deliberat. Ambele necesită aceeași disciplină de bază: identificarea dependenței, stabilirea domeniului de retestare în raport cu criteriile convenite și documentarea motivului pentru care noul rezultat îndeplinește sau nu aceste criterii. În cazul în care modificarea este izolată la un singur echipament fără dependențe comune, domeniul de retestare poate rămâne restrâns. În cazul în care modificarea afectează o utilitate sau o funcție de care depind alte sisteme, domeniul de retestare trebuie să urmeze acea dependență în exterior, indiferent de cât de limitată părea modificarea inițială.
Documente de predare care asigură păstrarea secvenței de testare și a trasabilității
| Element de predare | Întrebare privind trasabilitatea | Ce ar trebui să conțină dosarul |
|---|---|---|
| Secvența de testare | S-a verificat dacă instalarea a fost realizată în întregime și dacă instrumentele au fost calibrate înainte de utilizarea rezultatelor dinamice? | Ordinea verificărilor privind cerințele preliminare, echipamentele, interacțiunile între sisteme și scenarii |
| Dependențe | De ce utilități sau funcții stabile ale echipamentelor depinde fiecare rezultat integrat? | Legătura dintre fiecare rezultat și condițiile sale prealabile |
| Criterii de acceptare | Care au fost criteriile aprobate care au stat la baza testului? | Criteriile predefinite ale proiectului utilizate pentru evaluarea rezultatului |
| Deviații | Ce abatere a avut loc și asupra căror probe a avut efect? | Abaterea și efectul acesteia asupra secvenței sau rezultatului |
| Reexaminări | Ce s-a repetat după o abatere sau o modificare a configurației? | Domeniul de aplicare al retestării, rezultatul și criteriile aprobate aplicabile |
| Concluzia prezentată | De ce rezultatul rămâne valabil după modificări și repetarea testelor? | Baza documentară pe care se întemeiază concluzia privind predarea |
The pachetul de predare este momentul în care fiecare decizie anterioară privind secvențierea fie se confirmă, fie se dovedește eronată în urma unei analize amănunțite. Un responsabil cu biosecuritatea sau un inginer al unității care examinează dosarul ulterior nu este prezent la testare; aceștia se bazează în totalitate pe documentație pentru a răspunde la o întrebare specifică pentru fiecare rezultat: de ce este acesta încă valabil și de ce anume depinde? Dacă documentația nu păstrează acest lanț, rezultatul este un dosar plin de rezultate ale testelor care par plauzibile luate separat, dar fără o legătură demonstrată între ele.
De aceea, ordinea testărilor trebuie să fie vizibilă în procesul-verbal de predare, nu doar rezultatele. Un evaluator trebuie să poată constata că s-a verificat integritatea instalării și calibrarea instrumentelor înainte de generarea rezultatelor dinamice, că funcționarea utilităților și a echipamentelor individuale a fost verificată înainte de efectuarea testelor de interacțiune între sisteme și că scenariile de eșec au fost testate în raport cu răspunsurile predefinite așteptate, și nu evaluate abia după ce s-au produs. Fără această ordine vizibilă, pachetul nu poate distinge un program de testare cu secvențe corecte de unul în care etapele au fost executate în ordine greșită și au produs, întâmplător, rezultate care par acceptabile.
Dependențele sunt importante aici din același motiv pentru care au fost importante în cadrul logicii de retestare: fiecare rezultat integrat se bazează pe stabilitatea unor utilități specifice sau a funcțiilor echipamentelor, iar înregistrarea de predare-preluare trebuie să precizeze care au fost aceste dependențe. Acest lucru permite unui evaluator ulterior sau unei decizii ulterioare de retestare să urmărească înapoi, pornind de la orice rezultat dat, până la condițiile pe care acesta le-a considerat valabile la momentul respectiv. Rolul Qualia Bio într-un proiect de acest gen se leagă în mod direct de această cerință de trasabilitate, întrucât detaliile de configurare furnizate pentru un Laborator cu module BSL-3/4, clapetele de izolare sau ușile APR, identificate în timpul revizuirii proiectului, devin parte integrantă a tabloului de dependențe pe care documentația ulterioară de testare și predare trebuie să o menționeze cu acuratețe.
Abaterile și retestările trebuie tratate în registrul de predare-preluare exact așa cum au fost tratate în timpul testării propriu-zise: ce s-a abătut de la rezultatul așteptat, ce date a afectat, ce s-a repetat și în raport cu ce criterii aprobate. Un dosar de predare care omite o abatere pe motiv că aceasta a fost rezolvată în cele din urmă elimină informațiile de care un viitor evaluator are nevoie pentru a înțelege de ce rezultatul final este de încredere și nu doar convenabil. Concluzia raportată pentru fiecare rezultat ar trebui să precizeze clar de ce acesta rămâne valabil după orice modificări și retestări care au avut loc pe parcurs, aceasta fiind singura modalitate prin care dosarul susține decizii sigure privind repunerea în funcțiune, fără a fi necesară consultarea echipei de testare inițiale de fiecare dată când apare o întrebare ulterior.
Întrebări frecvente
Q: Cum ar trebui echipa să transforme secvența de testare integrată într-un program concret?
A: Elaborați programul pornind de la dependențe: mai întâi, verificarea completitudinii instalării și calibrarea instrumentelor, apoi utilitățile, funcțiile individuale ale echipamentelor, comenzile intersistemice și scenariile plauzibile de defecțiune și recuperare. Fiecare test ar trebui să identifice elementele anterioare pe care se bazează, astfel încât o condiție prealabilă neîndeplinită să poată fi urmărită până la fiecare rezultat afectat din aval.
Q: Se pot folosi rezultatele testelor efectuate în fabrică sau de către furnizor în locul rezultatelor obținute la locul de instalare?
A: Numai în cazul în care protocolul proiectului confirmă că au fost verificate dovezile referitoare la etapa respectivă și la compatibilitatea acesteia cu configurația instalată și dependențele aferente. Dacă nu se demonstrează utilitatea efectivă, controlul, interblocarea sau contextul scenariului, mențineți verificarea instalării deschisă, în loc să presupuneți că dovezile sunt echivalente.
Q: Este suficientă confirmarea alarmei pentru a încheia un test de mod de defect?
A: Nu. Confirmarea alarmei și recuperarea sistemului reprezintă părți distincte ale dovezii. Definiți răspunsul sigur așteptat, comportamentul de confirmare și răspunsul de recuperare înainte de execuție, apoi evaluați fiecare dintre acestea în raport cu criteriile convenite pentru proiect.
Q: Ce ar trebui să facă echipa de testare atunci când un standard menționat nu prevede o limită de acceptare specifică locației?
A: Aprobați criteriile de acceptare specifice proiectului înainte de începerea testării. Stabiliți-le în funcție de contextul de testare aplicabil, de proiectarea instalației, de evaluarea riscurilor și de cerințele locale, în loc să considerați un cadru general sau o metodă de testare ca fiind criteriul de acceptare al instalației.
Q: Rezultatele testelor anterioare pot rămâne valabile după o modificare de configurare?
A: Da, dar numai atunci când o evaluare documentată a dependențelor arată care rezultate au fost afectate și de ce celelalte rămân valabile. Repetați verificările afectate și consemnați în pachetul de predare domeniul de aplicare al retestării, rezultatul, criteriile aplicabile și concluzia.





















