Regression — ano ito, bakit ito nangyayari at paano ito i-test

Ano ang regression sa pag-develop

Regression — ay isang sitwasyon kung saan ang functionality na gumagana sa nakaraang bersyon ay humihinto sa paggana pagkatapos gumawa ng mga pagbabago. Ang pagbabago ay maaaring kahit ano: pag-aayos ng bug, pagdaragdag ng bagong feature, refactoring, pag-update ng library, o kahit pagbabago ng configuration. Ang regression ay ang pangunahing kaaway ng katatagan: bawat pagbabago ay may panganib na masira ang isang bagay na nasuri at nailabas na.

Ang termino ay nagmula sa pag-test: regression testing — ay ang muling pagpapatakbo ng mga umiiral na test pagkatapos ng bawat pagbabago. Kung ang isang test na dati ay pumasa ay bumagsak — nangangahulugan ito na may regression na naganap. Sa mas malawak na kahulugan, ang regression ay hindi lamang pagkabigo ng test, kundi pati na rin anumang pagkasira ng pag-uugali na napansin ng user o QA. Ayon sa Tricentis State of Testing 2023, ang regression ay bumubuo ng 35–45% ng lahat ng bug na natagpuan sa production.

Ang regression ay naiiba sa ordinaryong bug sa pamamagitan ng konteksto ng oras: ang bug ay maaaring palaging umiral, samantalang ang regression ay palaging resulta ng isang pagbabago. Ito ay isang mahalagang pagkakaiba, dahil ang paghahanap ng sanhi ng regression ay nagsisimula sa pagsusuri ng mga pagbabago: ano ang nagbago sa pagitan ng “gumagana” at “huminto sa paggana”. Git bisect — ang karaniwang kasangkapan para sa paghahanap ng commit na nagdulot ng regression.

Mga uri ng regression at halimbawa

Lokal na regression — pagbabago sa module A ay sumisira ng functionality sa parehong module A. Halimbawa: muling isinulat ng developer ang sorting function, at huminto ito sa tamang pagproseso ng walang laman na array. Ang lokal na regression ay pinakamadaling matukoy at ayusin, dahil ang sanhi at epekto ay magkalapit.

Malayong regression — pagbabago sa module A ay sumisira ng functionality sa module B, na hindi direktang konektado sa code, ngunit konektado sa data o oras. Halimbawa: pagbabago ng schema ng database sa module “Mga User” ay sumisira ng ulat sa module “Analytics” na gumagamit ng parehong table. Ang malayong regression ay ang pinaka mapanlinlang: hindi pinaghihinalaan ng developer na ang kanyang pagbabago ay makakaapekto sa ibang module.

Regression ng side effect — pagbabago ng side effect (pag-log, pag-cache, pagpapadala ng notification) ay sumisira ng inaasahang pag-uugali. Halimbawa: nagdagdag ang developer ng caching para mapabilis ang trabaho, ngunit dahil sa lumang cache, nakikita ng mga user ang lumang data. Ang regression ng side effect ay mahirap mahuli ng automated tests, dahil ang mga side effect ay madalas hindi sakop ng tests.

Regression ng performance — ang code ay patuloy na gumagana nang tama functionally, ngunit mas mabagal kaysa dati. Halimbawa: ang bagong encryption algorithm ay nagbibigay ng parehong resulta, ngunit ang oras ng pag-execute ay tumaas mula 2 ms hanggang 200 ms. Ang regression ng performance ay hindi natutukoy ng ordinaryong unit tests — kailangan ang mga benchmark at profiling.

Bakit nangyayari ang regression

Unang sanhi — pagkakaugnay ng code (coupling). Kung mas malakas ang pagdepende ng modules sa isa't isa, mas mataas ang posibilidad na ang pagbabago sa isa ay magdulot ng regression sa isa pa. Klasikong antipatterns: God Object (bagay na gumagawa ng lahat), Shotgun Surgery (pagbabago ng isa ay nangangailangan ng pag-aayos sa dose-dosenang lugar), Circular Dependency. Ang pagbawas ng coupling — gawain ng arkitektura: SOLID principles, Dependency Injection, hexagonal na arkitektura.

Ikalawang sanhi — kakulangan ng tests para sa binagong functionality. Kung ang code ay hindi sakop ng tests, ang developer ay malalaman lamang ang tungkol sa regression mula sa QA o mga user. Ayon sa Google Testing Blog, ang mga proyektong may test coverage >75% ay may 5 beses na mas kaunting regression kaysa sa mga proyektong may coverage <25%. TDD (Test-Driven Development) ay ginagarantiyahan na ang tests ay isinulat bago ang code, hindi “kapag may oras”.

Ikatlong sanhi — salik ng tao. Ang developer ay hindi alam ang pagkakaroon ng katabing functionality, hindi nauunawaan ang lahat ng dependency, o nagmamadali lamang. Sanhi — hindi sapat na pagbabahagi ng kaalaman sa codebase. Mga solusyon: code review na may partisipasyon ng mga developer mula sa ibang modules, pair programming, dokumentasyon ng arkitektura. Ang Bus factor ng proyekto ay inversely proportional sa bilang ng mga dokumentadong desisyon sa arkitektura.

Regression testing at ang papel nito

Regression testing — ay ang proseso ng muling pagpapatakbo ng mga umiiral na test pagkatapos ng bawat pagbabago upang suriin kung ang lumang functionality ay hindi nasira. Ito ang tanging paraan upang garantiyahan na ang bagong pagbabago ay hindi nakagambala sa paggana ng umiiral na code. Kung walang regression testing, ang bawat release ay isang loterya: umaasa ang developer na wala siyang sinira, ngunit hindi niya ito makumpirma.

Manu-manong regression testing — pinakamahal at hindi epektibong approach. Habang lumalaki ang proyekto, ang bilang ng regression test scenarios ay lumalaki nang linear, at ang oras para sa manu-manong pagpapatakbo — exponentially. Pagkatapos ng 2–3 taon ng pag-develop, ang manu-manong pagpapatakbo ng regression ay maaaring tumagal ng 2–3 linggo, na ginagawang imposible ang madalas na release. Ang tanging paraan ay automation.

Automated regression testing ay nahahati sa mga antas ayon sa testing pyramid:

• Unit tests — mabilis, izolated, sumasaklaw sa indibidwal na function at method
• Integration tests — sinusuri ang interaksyon sa pagitan ng modules, DB, external services
• E2E tests — sinusuri ang kumpletong user scenarios sa pamamagitan ng UI o API
• Snapshot tests — ikinukumpara ang kasalukuyang output ng component sa reference

Ayon sa Google Testing Blog, ang optimal na ratio: 70% unit tests, 20% integration, 10% E2E. Ang paglihis mula sa ratio na ito ay nagbabawas ng epektibidad ng regression testing: ang sobrang E2E tests ay nagpapabagal ng pipeline, ang kakulangan ng unit tests ay nag-iiwan ng microbugs na hindi napapansin.

Mga estratehiya sa automation ng regression testing

Unang estratehiya — Full Regression. Lahat ng tests ng proyekto ay pinapatakbo. Ang pinaka maaasahan, ngunit pinakamabagal na approach. Angkop para sa maliliit na proyekto (hanggang 10,000 tests, oras ng pagpapatakbo <30 minuto). Para sa malalaking proyekto, ang buong regression ay maaaring tumagal ng oras, na ginagawang hindi praktikal ang CI/CD pipeline.

Ikalawang estratehiya — Selective Regression. Tanging ang tests na nauugnay sa binagong code ang pinapatakbo. Para sa pagtukoy ng mga koneksyon, ginagamit ang dependency graph ng code. Mga kasangkapan: Bazel (Google), Nx (JavaScript), sbt (Scala). Selective regression ay nakakatipid ng 60–80% ng oras ng pagpapatakbo, ngunit nangangailangan ng tumpak na pagbuo ng dependency graph — ang mga pagkakamali ay humahantong sa mga napalampas na regression.

Ikatlong estratehiya — Prioritized Regression. Lahat ng tests ay niraranggo ayon sa priority: critical path (pinakamahalagang user scenarios), high risk (code na may kasaysayan ng bug), changed code (code na apektado ng pagbabago). Una, ang mga tests na may pinakamataas na priority ay pinapatakbo — kung pumasa sila, ang developer ay makakakuha ng mabilis na feedback. Time-boxed na pagpapatakbo: sa loob ng 10 minuto, sinusuri ang mga kritikal na tests, ang iba — sa background.

Paano maiwasan ang regression sa proyekto

Una at pinakamahalagang hakbang — kultura ng pagsulat ng tests. Ang bawat pagbabago ay dapat may kasamang test na sumusuri na ang pagbabago ay gumagana at test na sumusuri na walang nasira. TDD (Test-Driven Development) ay nagbibigay ng pinakamahusay na resulta: ang developer ay unang sumulat ng bagsak na test, pagkatapos ay ang code na nagpapasa nito. Ito ay ginagarantiyahan na ang test ay umiiral bago ang code.

Ikalawang hakbang — CI/CD pipeline na may mandatoryong pagpapatakbo ng tests. Ang pull request ay hindi maaaring i-merge hanggang ang lahat ng tests ay pumasa. Hindi maaaring “laktawan” ang tests dahil sa urgency — ang mga agarang pagbabago ay dumadaan sa isang pinabilis ngunit mandatoryong set ng tests. Ayon sa Google DevOps Research, ang mga team na may mandatoryong CI/CD ay may 3 beses na mas kaunting regression sa production.

Ikatlong hakbang — monitoring sa production. Kahit ang pinakamahusay na tests ay hindi ginagarantiyahan ang 100% proteksyon laban sa regression. Ang mga kasangkapan sa observability (Sentry, Datadog, New Relic) ay dapat subaybayan ang mga pangunahing metrik pagkatapos ng bawat deployment: error rate, latency, throughput. Awtomatikong rollback kapag lumampas sa thresholds — isang safety net kung ang regression ay pumasok pa rin sa production.

Ikaapat na hakbang — code review na may regression mindset. Ang reviewer ay dapat magtanong: “Ano pang ibang modules ang maaaring masira ng pagbabagong ito?”. Hindi sapat na suriin na ang code ay tama — kailangan suriin na hindi nito maaabala ang katabing functionality. Ang checklist para sa code review ay dapat magsama ng punto “pagsusuri ng regression sa mga katabing modules”.