Prima Bug Istorica - sebiboga/testlink-upgraded GitHub Wiki

Prima Bug din Istorie — 9 septembrie 1947 🦋

Pe 9 septembrie 1947, în timp ce echipa lui Grace Hopper lucra la calculatorul Harvard Mark II din Cambridge, Massachusetts, un operator a găsit un fluture într-un relay — și l-au prins, l-au lipit cu banda adezivă în pagina de jurnal a mașinii și au scris cuvintele care au intrat în istoria informaticii:

"Found actual case of first bug being made." („Am găsit un caz real în care a fost făcută prima bug" — traducere)

Aceasta este prima bug de calculator documentată vreodată și originea povestei care a transformat cuvântul bug — un termen vechi de secole pentru un defect mecanic — în simbolul internațional al bug tracking-ului. TestLink trăiește din asta: gestiunea defectelor, rezultatele de execuție și jurnalul de evenimente (Event Viewer) sunt descendenții direcți ai acelei pagini de jurnal.

Pagina: Home · Ce este TestLink · Event Viewer · Gestionarea Bug-urilor

Cuprins

  1. Cronologia zilei de 9 septembrie 1947
  2. Jurnalul original
  3. Nu doar fluturele: diagnosticul real
  4. De ce contează pentru testare și QA
  5. Cuvântul „bug" este mai vechi decât fluturele
  6. De la Mark II la TestLink 2.0.1
  7. Cronologie: de la primul bug la TestLink
  8. Cum înregistrezi o bug reală în TestLink
  9. Surse și lectură suplimentară

1. Cronologia zilei de 9 septembrie 1947

Moment Eveniment
9 septembrie 1947 Un moth este găsit blocat într-un relay al calculatorului Harvard Mark II (calculator cu relee, construit de Howard Aiken la Harvard School of Applied Research and Computer Science, funcționând 1945–1947).
Imediat după Fluturele este îndepărtat cu o pensetă și lipit cu banda adezivă în pagina de jurnal a mașinii, alături de notarea despre defect.
În zilele următoare Echipa lui Grace Hopper nu se oprește la îndepărtarea fluturelui: își propune un diagnostic propriu („de ce s-a întâmplat?") — caută releul, îl verifică, găsește o cauză mecanică reală și o repară.
~69 de ore mai târziu Mașina este repusă în funcțiune completă (durată citată în relatările echipei despre incident).

Punctul esențial: fluturele a fost simptomul, cauza era altceva. Fluturele s-a blocat într-un contact de relay deja slăbit — adică defectul real era o problemă de fixare (rigidizare) mecanică, nu un „animal în calculator". Iar povestea devine relevantă pentru QA abia în acel pas în care echipa nu s-a mulțumit cu „am scos insecta și gata".

Notă de corectitudine: numele de „prima bug de calculator" este atribuită în mod obișnuit acestui incident, însă nu există o înregistrare anterioară a unui defect de software catalogat astfel. Există însă defecte documentate înainte de 1947 (vezi secțiunea 5) — de aceea spunem „prima bug de calculator documentată ca atare".

2. Jurnalul original

Harvard Mark II nu avea afișaj: mașina trăia pe fișe de hârtie găurite (punched cards), iar operațiile erau scrise de mână în jurnalul de funcționare, cu observații și corecții scrise direct de operatori. Pagina din 9 septembrie 1947 conține:

  • notarea în limba engleză cu pricina (Found actual case of first bug being made),
  • desenul schematic al circuitului de relee implicat, cu „X" pe poziția defectă,
  • fluturele propriu-zis, uscat și lipit cu bandă adezivă pe marginea hârtiei.

Perechea fluture + text + circuit este cea mai veche înregistrare modernă a unui proces de debugging: observare → notare → diagnostic → reparare → repunere în funcțiune. Fluturele și pagina de jurnal se află astăzi la Smithsonian — National Museum of American History (Washington, D.C.), expuse ca „prima bug din istoria calculatoarelor".

Event Viewer — cel mai apropiat descendent modern al jurnalului de funcționare al Mark II

3. Nu doar fluturele: diagnosticul real

Povestea populară se oprește la „au găsit un fluture". Ce a urmat este partea care contează pentru testare:

  1. Simptom — calculatorul se bloca intermitent, cu erori nonexplicite.
  2. Observație — un operator observă un corp străin într-un relay.
  3. Izolare — defectul este asociat unui anumit relay, nu mașinii întregi.
  4. Verificare — se verifică toate șuruburile contactelor/panoului de relee; se găsește o șurubă nefixată la masă (ground) pe releul respectiv.
  5. Reparare — se strânge șurubă și se reia funcționarea; circa 69 de ore până la repunerea completă în funcțiune.
  6. Lecție — „hardware-ul are și el bug-uri" devine un fapt verificabil și începe să fie tratat ca atare.

Această secvență este, punct cu punct, un test plan: simptom → pas reproducibil → cauză → fix → retest. Diferența față de TestLink este doar că în 1947 „planul de test" era o pagină de hârtie.

4. De ce contează pentru testare și QA

  • Bug tracking are o origine documentată. Nu este o convenție de marketing, ci o practică de atelier: descoperă → notează → izolează → repară → verifică.
  • Defectele hardware și software nu se tratează diferit ca metodă, diferă doar localizarea. Bug-ul de releu are un „stack trace" analog: circuitul desenat în jurnal.
  • Auditul contează. Jurnalul Mark II era un log de incident; astăzi echivalentul este tabelul events din Event Viewer, unde fiecare acțiune (cine, când, ce) este păstrată și poate fi filtrată, exportată și auditată — vezi pagina Event Viewer.
  • Lecția rămâne: „am eliminat simptomul" ≠ „am reparat cauza". În TestLink aceasta se traduce prin verificarea efectului real al unui fix (retest), nu doar prin marcarea defectului ca Resolved.

5. Cuvântul „bug" este mai vechi decât fluturele

Nu cumperi? — Sigur, e o glumă; dar e o confuzie frecventă. Cuvântul „bug" în sensul de defect este mult mai vechi decât 1947:

  • Edison folosea deja termenul pentru un defect al fonografului său, cu zeci de ani înainte.
  • „Buggy" desemna o mașină cu părți mobile expuse, supuse prafului și insectelor — adică „are bug-uri" în sens mecanic.
  • Ada Lovelace și alți autori din secolul XIX au descris defecte de programare, dar cu termenii de epocă (error, glitch — termenul glitch încă se folosește).

Ceea ce face incidentul din 9 septembrie 1947 special este că este primul caz în care un defect mecanic dintr-o mașină electronică programabilă a fost catalogat, desenat, păstrat fizic și legat de un diagnostic — de aici expresia „debugging", rămasă în toate limbaje de programare.

6. De la Mark II la TestLink 2.0.1

1947 — Harvard Mark II 2.0.1 — TestLink Upgraded
Fișe de hârtie găurite BFF REST API în PHP (api/**)
Jurnal de funcționare pe hârtie Event Viewer — tabel events, filtru, chart-uri, export
Defect catalogat cu text + circuit Execution status: Passed / Failed / Blocked + link către bug
„Bug" de hardware Custom fields pe test case: prioritate, severitate, Execution type
Verificarea unei reparații Retest în același test plan, cu istoric complet
Echipă: operator + inginer Echipă: Tester / Manager / Admin (vezi Utilizatori și Roluri)

Ideea de bază nu s-a schimbat în 79 de ani: un defect netestat este un defect necunoscut.

7. Cronologie: de la primul bug la TestLink

An Eveniment
1878 Edison folosește termenul bug pentru un defect mecanic.
1945–1947 Funcționează Harvard Mark II (calculator cu relee, programat cu fișe perforate).
9 septembrie 1947 Prima bug de calculator documentată: fluturele din relay, notat și păstrat în jurnal.
1949 Primele calculatoare cu tuburi vid (fără relee mecanice) — defectele devin exclusiv electronice.
1952 Grace Hopper demonstrează primul „compilator" (A-0) — programele devin portabile, iar bug-urile devin defecte de logică.
1957 Lansarea limbajului FORTRAN — codul sursă devine un artefact întreținut și versionat.
1971 Primul microprocesor (Intel 4004) — testarea software-ului devine predominantă.
1981 IBM PC — apar bug-uri care ajung la milioane de utilizatori; începe nevoia de trasabilitate.
1999 Primul defect de "milionime" și dezvoltarea masivă a bug tracking-ului open-source.
2004 TestLink este lansat pe SourceForge — planuri de test, rezultate, defecte.
1.9.20 Ultima versiune legacy (Smarty).
2.0.1 TestLink Upgraded: UI Dashio, ecrane HTML moderne, BFF REST API în PHP.

8. Cum înregistrezi o bug reală în TestLink

Legătura practică cu produsul, în 5 pași:

  1. Execuția Testelor — rulezi testul și alegi rezultatul: Passed / Failed / Blocked. Pentru un defect: Failed.
  2. Link către defect — din rezultatul de execuție poți crea sau atașa o înregistrare în Gestionarea Bug-urilor (vezi pagina dedicată).
  3. Severitate și prioritate — setezi Importance × Urgency, care determină prioritatea (vezi Bug Severity).
  4. Transparență pentru echipă — orice acțiune e înregistrată în Event Viewer (cine a schimbat rezultatul, când).
  5. Retest după fix — după reparare, re-execuziile se păstrează ca istoric, ca să fie vizibil dacă fix-ul chiar a rezolvat cauza (lecția din Mark II).

9. Surse și lectură suplimentară

  • Wikipedia — Grace Hopper, Harvard Mark II, Software bug
  • Smithsonian, National Museum of American History — exponatul „first computer bug" (fluturele și pagina de jurnal)
  • Computer History Museum — materiale despre Harvard Mark II și programarea cu relee
  • În arhiva acestui proiect: pagina de CHANGELOG 2.0.1 și suitele de teste din tmp/TLU_Test_Cases.md, care urmează aceeași disciplină: observație → documentare → verificare

Pagina documentată în cadrul issue-ului #1288 („first bug ever found on Sept 9, 1947"). Proiectul TestLink Upgraded 2.0.1 — vezi și Home.