I think every developer wants to write fewer bugs – but for all their wanting, I have still seen many, many bugs in my career. Even though the developers work carefully and do their best to prevent bugs, we still deliver too many bugs into Production.
If Conscientious Hard Work Doesn’t Prevent Bugs, Then How Can We?
We must start by understanding the causes of bugs – bugs come in two types:
Little-B bugs are those bugs where the code doesn’t do what the developer intended – the text entry box isn’t large enough, or sorting doesn’t work, or the wrong data is returned by a query. We can prevent these from getting to Production by careful code reviews, careful QA, or good test automation delivered early.
Big-B Bugs are the ones where the code does exactly what the developer intended – it just isn’t what the customer wanted. These are immensely costly; your developers may have spent two or three sprints writing really good, clean, highly maintainable code that does the wrong thing!
- Careful code reviews won’t prevent these; if the developers misunderstood what the customer wanted, then they will review the code to verify that it does what they mistakenly think the customer wanted.
- Careful QA won’t prevent these if the QA team has the same misunderstanding as the developers about what the customer wanted.
- Good test automation won’t prevent these if the QA team has the same misunderstanding as the developers about what the customer wanted.
The only way to prevent Big-B Bugs is to ensure that the Product Manager, Business Analyst, Developers, and QA all have exactly the same understanding of what the software is supposed to do. Misunderstandings about the purpose are caused by miscommunication around the requirements – so we must start there.
Preventing Both Types of Bugs
The only way to ensure that everyone has exactly the same understanding of what the software is supposed to do is to change the way we write the requirements. Specification by Example/BDD makes two fundamental changes in the requirements writing process:
- SBE/BDD says that the requirements must be written collaboratively – BA, PM, Developers, and QAs working together to define the terms they will use and then to write the requirements using carefully defined and consistent language. Done well, this can virtually eliminate Big-B Bugs (and there are multiple companies that have reported this).
- SBE/BDD says that requirements must be written using concrete examples – using concrete examples makes it much easier to think of other important examples, and to find all of the important examples (boundary conditions and corner cases, unhappy paths).
Done well, SBE/BDD lets us arrive at a collective understanding that looks more like this:
SBE/BDD also makes it possible to deliver test automation in-sprint, before the developers have finished writing the code. Having automated tests makes it easy for the developers to check their work before they even check code into the branch, and this can virtually eliminate Little-b bugs.
I have led teams through the transition from delivering too many bugs, to delivering so few bugs that they no longer needed a bug tracking system. I would be glad to share how we did that; please contact me if you would like to discuss it.
Nadhani kila developer anataka kuandika bugs chache <unk> lakini kwa wote wanataka yao, bado nimeona wengi, bugs nyingi katika kazi yangu. Hata ingawa watengenezaji kufanya kazi kwa uangalifu na kufanya bora yao ili kuzuia bugs, sisi bado kutoa bugs sana katika Uzalishaji. Ikiwa Kazi Nzito ya Uaminifu Haizuii Wadudu, Basi Twawezaje? "Kuna aina mbili za bugs: ""Little-B"" bugs ni wale bugs ambapo code haina kufanya kile developer lengo, ""text entry box si kubwa ya kutosha, au utaratibu haifanyi kazi, au data mbaya ni akarudi na query." Tunaweza kuzuia hizi kutoka kupata uzalishaji na uangalifu code mapitio, uangalifu QA, au nzuri mtihani automatisering zinazotolewa mapema. Big-B Bugs ni wale ambapo kanuni hufanya hasa nini developer lengo <unk> ni tu si <unk> nini mteja alitaka. Hizi ni gharama kubwa sana; watengenezaji wako inaweza kuwa alitumia mbili au tatu sprints kuandika kweli nzuri, safi, sana maintainable code kwamba anafanya kitu kibaya! - Makadirio ya code ya uangalifu hayatazuia hizi; ikiwa watengenezaji walielewa vibaya kile mteja alitaka, basi watakagua nambari ili kuthibitisha kwamba inafanya kile wanafikiri kimakosa mteja alitaka. - Careful QA si kuzuia hizi kama QA timu ina misunderstanding sawa kama watengenezaji kuhusu nini mteja alitaka. - Majaribio nzuri automatisering si kuzuia hizi kama QA timu ina misunderstanding sawa kama watengenezaji kuhusu nini mteja alitaka. Njia pekee ya kuzuia Big B Bugs ni kuhakikisha kwamba Product Manager, Business Analyst, Developer, na QA wote wana ufahamu sawa wa nini programu inapaswa kufanya. Kutokuelewana kuhusu kusudi husababishwa na kutokuelewana kuhusu mahitaji <unk> kwa hiyo lazima tuanze hapo. Kuzuia aina zote mbili za makosa Njia pekee ya kuhakikisha kwamba kila mtu ana ufahamu sawa wa nini programu inapaswa kufanya ni kubadilisha njia ya kuandika mahitaji. "Specification by Example (SBD) inatoa maelezo ya msingi ya mahitaji ya uandishi wa mahitaji (SBD) na inaelezea jinsi ya kuunda mahitaji ya uandishi wa mahitaji (SBD) kwa kutumia ""maelezo ya mahitaji"" (QA) na ""maelezo ya mahitaji"" (QA) kwa kutumia lugha iliyofafanuliwa kwa uangalifu na thabiti." Kufanywa vizuri, hii inaweza karibu kuondoa Big-B Bugs (na kuna makampuni mengi ambayo wameripoti hii). SBDE inaweka wazi kwamba mahitaji yanapaswa kuandikwa kwa kutumia mifano halisi, na kutumia mifano halisi hufanya iwe rahisi zaidi kufikiria mifano mingine muhimu na kupata mifano yote muhimu (hali za mpaka na kesi za kona, njia zisizofaa). SBE na BDD ni njia ya kuunda mfumo wa majaribio ya kawaida, ambayo inatoa uwezo wa kuendesha majaribio ya moja kwa moja katika sprint kabla ya watengenezaji kumaliza kuandika. Kuwa na vipimo automatiska hufanya iwe rahisi kwa watengenezaji kuangalia kazi yao kabla hata kuangalia code katika tawi, na hii inaweza karibu kuondoa kidogo-b bugs. """Nimeongoza timu kupitia mabadiliko kutoka kutoa bugs nyingi kupita kiasi hadi kutoa bugs chache sana hivi kwamba hazihitaji mfumo wa kufuatilia bug." Ningependa kushiriki jinsi tulivyofanya hivyo; tafadhali wasiliana nami ikiwa ungependa kujadili.