Bug Driven Development

When a project backlog is turned into a repository where the majority of items are bugs, I like to think that we are then working under the premises of a Bug Driven Development process. Once this starts to happen you basically have 3 choices:

  • Review your user stories, trace them back to the original business requirements and ensure you have enough information to develop the work products.
  • Think about what caused the mess and try to fix it.
  • Start using Bug Driven Development.

Ideally we would go for the first option in order to have a clear view on the scope for the current Sprint. This could work when a) time permits, b) the team realizes about the problem and c) your options to further enhance the requirements definition through additional elicitation and analysis are good.

The second option proves to be the most reasonable idea when it comes to retrospectives. But it might cause a significant deviation (in money, time or quality) after having spent a whole Sprint building tentative components that are potentially useless, or would need an important rework.

And the only option left is Bug Driven Development (bDD); not to be confused with Behaviour Driven Development. I’m not trying to convince anyone that using bDD is a good idea, since reaching this status means that not only several aspects of the analysis have gone wrong, but also that you are increasingly doing it wrong. You would use bDD to enrich your user stories from bugs encountered in the system being tested.

And this exposes a high risk: testers covering the gaps from proper requirements analysis. But it also proves the importance of having testers in your Agile teams. When I’m asked how does Agile approach change the traditional role of testers, my answer is: it does not! While Agile emphasizes the importance of involving testers in the definition of the user stories and acceptance criteria, it has always been a good practice to have the requirements reviewed by testers (and the rest of the team) to make sure these were accurate, testable, measurable and anything that define them as SMART. Same happens in other parts of the testing process. Test automation? Reporting? Exploratory testing? I feel most of these topics became popular during the last few years but things are not done differently in general.

So what about using Bug Driven Development? Let’s think about this scenario: third Sprint, the Product Owner has not been deeply involved in the process and non-business users are appointed to attend the demos and sign-off the incremental part that has been built, user stories are too high level, the business analyst was only involved during the initial Sprint and the rest of the team does not have a profound domain knowledge. It sounds bad, right? But I told you: if you are using Bug Driven Development, this is the result of many things done wrongly in the first place.

Let’s use the example of the diagram below and put in a timeline:

bug driven development

  1. We have a business requirement which comes from the Project Charter or the Business Requirements Document, which defines the construction of a new interface to manually upload reconciliation files through sFTP. This is just a small part of the final solution and is targeted to be built as an increment on the current Sprint.
  2. As part of the initial analysis, the BR is broken down into 2 different User Stories: one of them relates to the user authentication and the other one to the upload process.
  3. While conducting the initial test design, the tester founds a lack of detail on the expected file extension which ends up in the addition of another user story defining the scenarios where it could contain zipped files of plain CSVs.
  4. After running one of the test cases for the first time, the tester founds a defect and while this is investigated the team founds that a user could switch from the base directory and browse sensitive data. This raises a concern and ends up with the addition of another user story to define the directories restrictions.
  5. The tester keeps exploring the system under test and founds something else as User Story N.

Some of these “discoveries” could have ended up as an enriched acceptance criteria, but the risk here is that an insufficiently defined requirement ends up with a significant amount of expectations in detriment of a very basic definition of its value or adherence to the business from a user point of view.

Obviously the sooner the user stories are enriched and completed, the less we will be using Bug Driven Development and the happier our lives will be 🙂

Its defect speaking

Pere Felices just sent me a very funny text about a (software) defect’s life, which I’m sharing here so you can also enjoy it:

I am defect. For some people I am a mild inconvenience and for some I am their worst nightmare, probably a life threatening nightmare. For many years, people like you have treated me as a hunting target and treated me as a non-living entity – without any emotion, say or dreams. Till now, I kept my silence but now I had it enough. TestingGeek has allowed me to tell my story to the world, to tell you truth about me and my feelings.

You call me so many names (And all of them are bad BTW), but do you know anything at all about me? Do you know where I lived before you forced me to live in your code – to be found, discussed, killed, ignored and humiliated?  People tell me so many things, but do you realize reasons for my existent? I know I am not desired, I know I am not welcomed and to be honest, I do not want to come anywhere near your (sometime dirty) code, requirements etc. But you force me to live in your requirements, code, network and so many unimaginable places because of your misunderstandings, lack of knowledge or plain sloppiness some time.

You do not realize, but I pay a great price for your sloppiness and your lack of understanding. I take blame for lost life, money and happiness for many users. Plane is crashed because there was a defect; transaction was not complete because there was a bug and so on. Why don’t you pause, think and say plane was crashed because someone did not do their job properly. I am there not because I love staying in your code, but because someone took short cut, invited me there to be found by someone else. I was invited, ignored and now I am blamed. Where is justice? Unfortunately defects cannot trial humans in their court, but I hope our fate will change.

My life is extremely comfortable till you guys put me in the code. After that, it’s all misery and my life becomes extremely miserable. From that moment onwards, I live my life in anticipation of to be found, broken in pieces, discussed and humiliation. I do not like being here and so always gives you hint of my presence. Sometime, I have power to give strong hints and it becomes impossible for you to ignore me. But sometime, you just do not recognize my hints, you over look what I say in log files, you don’t notice when I create slight flicker or make your system slow. You attribute things like these to something else and leave me there to rot, to get worsen. That doesn’t leave me any option but to gather strength and try harder. Most of the time I succeed and you notice me. Unfortunately I cannot understand your situation so some time by the time you notice me, I might have crashed a plane or ruined millions. So please, practice, observe and understand my hints. I will be very happy if you find me and kill me in such a way that I do not have to come again, but alas it doesn’t happen.

Most of the time, instead of killing me you just change my dress and location. Sometime, you even break me in to pieces and scatter me in your code base. Unfortunately, we do not follow the law of physics so some time when you break me in pieces, every piece could be bigger than the original itself. Even in pieces we communicate with each other, we affect each other and because of this you get confused. Rather than finding all the pieces, you take one piece and kill it or unfortunately break it in even more pieces…and cycle continues.

Buried in your millions of line of code, I wait patiently for my angles called testers who have skills and mandate to discover me. Given the right environment these angles could find most of us. But look, what have you done to my angles? You have converted them from angel to robot so rather than finding me, they are following some steps. If I am lucky, they will find me otherwise my angles will pass by me and ignore me, because someone has given them steps to follow rather than mandate to find me. Will I not feel angry about it? How would you feel if you struggle to survive in a sea and rescue boat follow the route given to them and ignores your plea? Well, that’s how I feel.

Sometime my angels create robot themselves and call it test automation. This can be extremely useful, but only if mandate for them is to find me rather than creating more robots. Unfortunately, for many people mandate is limited to the creation of these robots and they are worse for me. Well, it’s like missing rescue boat in periodic manner, after every check-in, after every few hours or on nightly basis.

I am not selfish and understand that sometime you just can’t kill me, but believe me I will be very happy if you can find me, discuss me meaningfully and take conscious decision to keep me in the code. Because, if you do that I’ll understand that I’ll never ever kill someone because of my presence, I’ll know that I will not ruin your millions. So as long as you have assessed risk associated with me staying in your code, I can live there happily. I just do not want to live there with feeling that I am not wanted here and I can possibly hurt someone.

Please, I do not want to stay in your code or system. I am extremely happy outside, don’t invite me inside. I know some of us are a bit naughty and will come without invitation. For those naughty defects, give our angels mandate to find them in best possible way rather than following steps or creating just robots. I am good at heart and do not want to hurt anyone, so please find me and get me out of your code base.

Remember, I am a defect buried in your code and waiting for you. Please be aware of my presence and keep your eyes open for me.

Waiting to be found – A defect.

Fuente: Testinggeek.com