Developer demo to QA or Pair testing

-
We were having a two-week sprint. We calculate the capacity of the team and reduce a factor based on previous sprint data. Then we come up with a capacity number based on which we plan. This should work fine. But we always had an end of sprint rush. Everyone will be working hard to complete the commitment. Last two days of the sprint is hectic with fixing bugs. Last minute fixes too require testing the full story. There is a high chance something slipping through the eyes.

Even otherwise it should not be like this. We had the capacity and still some struggle to meet the sprint commitments. What is going wrong here?

It is the bugs eating your capacity.




When a developer completes a task it is handed over to the QA. Developer moves on to another item. This is normal scenario. Qa may not get onto testing the item immediately. It might be picked after a day. If the task is complete and works perfectly no issues. But if there is a bug then it is different dynamics.
Turnaround of the task is now delayed. This will have impact on overall schedule of the sprint. This will have a cascading effect on all the tasks and can cause havoc to the schedule. This is the root cause of the rush during end of sprint. How to avoid this situation? It will be great if the developer can deliver the bug free code to the Qa. From the old days we have come a long way and number of bugs trapped early is reduced a lot. There is still lot of scope for improvement here.

We started doing a developer demo to the Qa to improve our turnaround time. Our idea was to run through all the acceptance criteria in the dev demo. Initial idea was to have a quick validation with another pair of eyes what is developed. Running through all acceptance criteria needs some preparation. This preparation actually helps in solidifying the understanding and some bugs are found at this stage. These are fixed before the demo. Some more bugs are found when doing the demo. These escaped the developer but were visible to the fresh set of eyes. These issues are fixed and then the task is handed over to the Qa for certification.

This has a huge benefit in turnaround time. Since the developer gets the bug early it takes less time to fix. There is no context switching. Also code is fresh in the mind and tweaking it is pretty easy.

There is another benefit as Qa can focus on system and not silly bugs. Acceptance criteria is covered in the demo. Now Qa focus on other aspect of the quality. This un covers bugs of issues which usually gets missed when there are task level bugs. With these eliminated issues found are of better calibre. This brings in more confidence in the team. Client will trust this team lot better as quality is improved.

Caution when you start this


Make sure demo is short and precise:

Since this is a handover demo make sure it is short. Not any fancy stuff. Just what is needed to hand over the task.

Short notice: Demo should be planned in the SCRUM meeting. It should involve only few members, ideally dev who developed and Qa who will test it. Involving the whole team can be decided as a team if it will help the sprint goal.



Comments

  1. ssSeptember 30, 2016 at 5:47 AM

    It's a very interesting approach to show the practical functionality to QAs as soon as that particular feature got developed.
    It minimises the time taken by QA to understand the functionality and will get to know about more information on that particular task which are difficult to cover in Acceptance Criteria.

    I completely agree with the fact mentioned in above post that we may identify defects/bugs in very early stage(before QAs starts testing)

    I can't think of any disadvantages at this point and I would like each team should try in their projects and give a valid feedback.

    Thanks,
    Sagar

    ReplyDelete

Post a Comment

Popular posts from this blog

Greedy computing with API

-
Image
 We all know computing resources have a cost. Memory, long term storage, transportation and computing all have their own costs. There are lot of scenarios where your API end point won't be able to respond in time. These are scenarios where you need to use more resources to provide a response. Let us be greedy with our resources and explore different patterns which can solve this. Polling  This is a commonly used pattern where the caller initiates a process. Then keeps on checking if the process is complete. If the process is complete then the caller reads the data needed.  This is a good pattern when both systems are part of the same organization. At least developers of caller and callee should be able to discuss this implementation.  Call back This is an improvement over polling pattern. Here the caller supplies a call back URL to the long running process. Once the process is complete it calls the callback URL and informs the caller that process results are availabl...
Read more

ChatGPT for cavemen

-
Image
I heard a lot about ChatGPT and thought to come out of my cave to find out what the hype is about. Is it going to eat all my lunch or eat me for lunch?  Like any product I gave it all my details and signed up. I asked it about quantum computing an it gave some answer. So far so good. Next day I wanted to check its blogging skills. So I opened chatGPT and I got this . I checked throughout the day and it is still down. So it won’t eat me till it is fed few more servers.  Continuing after it was up.  I asked it to write a blog about itself. Here is what was generated by chatGPT.
Read more

Event driven architecture for micro services

-
This is a work in progress. I am designing an event driven architecture to be used in systems using micro services. Micro service architecture is popular because it solves few problems in development process. While it solves some problems it also brings in new problems to the table. Bad designs impact micro services harder than monoliths. But this is thought is for another time.  How micro services talk to each other. In a monolith you have one gigantic database, or you can easily call another component to process the information. In a microservice you can use a Que (or event bus) to pass the information. This is the problem I want to discuss. Main issue with que is it is not designed for this scenario. There are few products which give a good solution by providing a subscription-based approach. But these are large implementations. Using these is similar to bringing an excavator to plant a sapling in your garden. Yes, many people go with using these large implementations to resolve...
Read more