BT

InfoQ Homepage News Deliver Faster by Killing the Test Column

Deliver Faster by Killing the Test Column

Bookmarks

Columns like "In test" often lead to teams having more work in progress and less work actually being finished. Removing such columns can increase collaboration between testers and developers and enable teams to deliver faster.

Jit Gosai, principal tester for the BBC iPlayer & Sounds team, spoke at Lean Agile Exchange 2020 about how teams can deliver faster by killing the test column.

Typically, task boards have an "In testing" column for work being done by the testers and an additional "Waiting for test" column to collect work that’s "Dev done". Gosai said that testers know what they need to work on next; developers can move onto other work while waiting for testers to finish and we can keep people on teams fully utilised.

If no issues are found, then the task can move into the next column, typically "Done" or "Waiting for release". But what happens if the testers do find a problem or need more information? There are a number of choices: does it go back into the "In Dev" column, pushed back into the backlog, or do you now create a "Waiting for Dev" column as a holding area? Gosai mentioned that any of these options result in more work in progress or context switching for the developer.

Meanwhile, what are the testers to do? Move onto the next item in their column, or wait for the developer? No matter which option the team decides, testing will always appear to be the teams biggest bottleneck for getting tasks completed more often than not as there will always be more developers than testers in a team, Gosai argued.

When we remove the "In test" column, developers remain with the work while testers are testing it, and they can work together to see it through to production, Gosai said. Developers would have to collaborate with testers to understand what needs to happen next and complete it together.

With a good process improvement practice in place, testers and developers can start to see how they can work together to mitigate any risks in the work done by the team. This encourages the insights found during testing to be built into the process instead of being handed over to developers in bug reports, Gosai concluded.

InfoQ interviewed Jit Gosai after his talk.

InfoQ: What are the drawbacks of having columns for testing on the board?

Jit Gosai: The "In testing" and "Waiting for test" columns look like good ideas, but as explained they often lead to more work in progress and other problems (for more details, see my post on issues the "In test" column causes).

The usual responses to resolving it include adding more testers (usually too expensive) or automation which is typically end-to-end UI testing - which starts to encourage other bad developer habits, such as writing more integrated testing with the full stack rather than isolated tests, testing becoming someone else’s responsibility, and pushing testing towards the end of the development life cycle, to name just a few. You can find more about these issues in my post The unintended consequences of automated UI tests.

InfoQ: How can we remove the test columns but still keep insight into the testing?

Gosai: The idea of removing the testing column doesn’t mean that testing is no longer important or isn’t happening anymore. It’s actually about focusing the team on a common goal which is to focus on finishing work rather than starting more work.

Having fewer stages for the work to go through means that developers stay with the work longer, or allowing other developers to contribute. This now gives the opportunity for testers and developers to start understanding what the other has already done and what testing still needs to happen.

InfoQ: How does removing test columns enable teams to deliver faster?

Gosai: In two core ways. One is that there is less work in progress and an increased focus on finishing work. This will naturally lead to more work being completed, especially if it requires any rework due to defects or other unforeseen circumstances. The other is that now developers and testers are working together to mitigate any risks associated with the code changes.

Working together at this stage is about sharing information, such as what you already know about the changes and what else you have learned while carrying them out. This enables individuals to incorporate and build on top of others’ knowledge and create new ideas that they may not have necessarily had if they were working alone. Now is a perfect opportunity to see if these mitigations can be built into the development process, either through automation or some other process. This is also a good time to see if the task is actually rework (e.g. issues found in the live environment) and can be learned from so as to prevent this issue from happening again.

While the benefits of these improvements wouldn’t be seen immediately, the long term implications can be considerable in improving the lead times of tasks, which would help teams get more done within the same time frame and therefore deliver faster.

There are a few assumptions to note within these speed improvements, the two main ones being that developers and testers actually begin to collaborate to understand what the other has done/would be doing, and don’t just move to a hidden mini dev/test handover process; and the other being an effective continuous improvement programme to learn from the other discipline and the types of failures that get through to the live environment.

InfoQ: How can we use what’s visible on the task board to improve testing?

Gosai: If working as collaboratively as I’ve mentioned above is quite new to the team and they have yet to implement a continuous improvement strategy, then there are a few techniques they can still use to kick start this process. If testing has indeed been identified as the team’s biggest bottleneck to releasing, then they can use the "In testing" column to their advantage.

Instead of testers simply picking work out of this column and working on it till it’s done, they should work with the team to help them understand how they approach testing, the types of things they are looking for and also finding during testing. Doing this with a handful of tasks is likely to help them identify some key themes within their work. For example, are there similar root causes such as usability or accessibility issues, or some hardware/software combination that always results in a bug? Is there something the devs could look out for while making the changes? These themes can be used to create a backlog of tasks that the team can begin to tackle to see if they can be addressed earlier on in the development life cycle.

By focusing on the process and not the people, it makes it easier to talk about what testers are doing, how developers and testers could mitigate this work earlier on in the life cycle, and begins to be the seeds of the continuous improvement programme.

Leadership in this process is very important. Leaders need to help testers feel comfortable that they are not being targeted as the "problem" within the team, but are actually the solution in educating the team in what risks they are looking for when testing. Developers will also need help to work closer with other disciplines through coaching in communication and developing empathy around the fact that they are not trying to replace the other disciplines, but working to improve the process together.

One of the key tasks for leadership within teams is creating a psychologically safe environment. This enables team members to be open about the problems they face and even share thoughts, ideas and solutions that are not yet fully formed, without risk of embarrassment or being judged incomptentent. It’s all very well having a backlog of continuous improvement tasks, but if people are unwilling to work on them together, you’re only going to get mediocre results. This inevitably means they never get the attention they deserve and the innovative will fail before it’s even started. You may have heard this in teams as "We’ve tried that before" or, "That’s never going to work because of... ".

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • In testing column

    by Ruslana Trunova /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree that less is more...
    but let's get to the real life...
    Let's assume that we've deleted that ”In testing” column.
    Now we have left with ”backlog”, ”in dev” and ”done”;
    basically all work (dev and qa) is done while we are on the ”in dev” stage/column.
    So dev after finishing the task will (for ex.) Leave a comment in that Jira ticket notifying Qa that this task is ready for verification.
    So.. Some tickets are ready for Qa in that column and some are not.
    Qa will have to click on each task to see if this is something to be tested or not yet.
    If there are no special column for Qa I think it's going to be a probability to not see something by mistake...Even if the dev notifies you personally that may be missed to.
    But a special separate column for QA means that Qa knows it is time to work on their ticket and if something is wrong it can easily be transferred back to ”in dev” stage.
    I don't think the”Qa in progress” column - is a wall in communication
    ---
    Qa in progress is not a problem. A lot of tasks in one sprint Is though.
    Make sure to put only as many tasks as the team can comfortably handle and efficiently concentrate on

  • Re: In testing column

    by Jitesh Gosai /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your comment Ruslana.

    “So dev after finishing the task will (for ex.) Leave a comment in that Jira ticket notifying Qa that this task is ready for verification."

    What you’ve described here is one of the main problems when teams just remove the test columns and expect to get the benefit I described above. Essentially they are still working the same way but have just hidden the work that the Testing column was showing. So all the problems you describe are going to occur.

    The part that hasn’t been developed is the developer and tester collaboratively working on the tickets. As I’ve described in the second question:

    “...Working together at this stage is about sharing information, such as what you already know about the changes and what else you have learned while carrying them out. This enables individuals to incorporate and build on top of others’ knowledge and create new ideas that they may not have necessarily had if they were working alone. Now is a perfect opportunity to see if these mitigations can be built into the development process, either through automation or some other process. This is also a good time to see if the task is actually rework (e.g. issues found in the live environment) and can be learned from so as to prevent this issue from happening again….”

    This may seem inefficient and slow, and yes it will be at first, but as the team starts to learn about each other and how they can improve the process things will begin to improve.

    Therefore to mitigate the issues you raise two things need to happen: 1) dev and test need to collaborate on tickets, not just hand them off to each other but work on them together and 2) a part of that work is to identify ways to do this work better, to mitigate the risks that testing is trying to highlight.

  • Re: In testing column

    by Aszen Xx /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What you seem to be suggesting is kind of pair programming between testers and developers, while the work is still in development stage. I think that could indeed work if testers are able to write automated tests for pushed code and developers are aware of the testing strategy early on. That would enable features to be tested and developed in parallel, you are right in noting that identifying ways for such collaboration still needs to be explored both in terms of tooling and process.

  • Re: In testing column

    by Radek Antoniuk /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with Ruslana that the amount of work is the problem, not the "QA column" itself.
    The Board shall be the source of truth and it is there for *visibility* and *transparency*. By removing "QA" column, the team looses the track of why the ticket is hanging in "DEV" state for so long - and possible opportunity for others to collaborate on helping in solving it.

    Collaboration is important, working between dev and qa is a goal to achieve, but not by decreasing transparency. As other mentioned, if there is a dedicated dev and qa person, this is always kind of "handing of work" because it is not the dev's role to do e2e testing.

    You are suggesting that each task must not be passed from "in progress" until it is finished and tested - that's great, but not in real life with complicated (long) tests.

    Obviously we can say "then the task should be smaller" - well, let's just say that every team needs to find its own way to work and what works better for them.
    It will be different for small startup or r&d team and different for big projects that are running in regulated environments - so let's not generalise.

  • Re: In testing column

    by Jitesh Gosai /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    You make a great point Ruslana, simply generalising and removing the test column and expecting to get all the benefits that working in one space isn't going to happen.

    You need to adapt the process to your unique set of circumstances which I addressed further in my talk at Lean Agile Exchange.

  • Re: In testing column

    by Jitesh Gosai /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for your comment Aszen Xx, if pair programming is an option then I'd highly recommend it but this isn't always going to be feasible for all testers or other disciplines that may work with developers.

    If they collaborate to really understand what they do and why they do it they may come across other methods that could shift that work either earlier on in the development life cycle or perhaps mitigate the risks their work is trying limit in an entirely different approach. But until they take the time to understand each other this is unlikely to happen and things stay as they always have.

    So how do we do this? You'll have to see my talk for that as I go into some detail on how devs and testers could work better together.

  • Re: In testing column

    by Pop Olimpiu /

    Your message is awaiting moderation. Thank you for participating in the discussion.

    In the end, the most important aspect is the way the team works. Tools are just tools if they are not picked up and if they are not used as expected. A team that has a common goal will achieve great things. The segregation on roles only is a very problematic one, that I seen in multiple companies where we just hide behind responsibilities. The topic is quite broad, the column must not be a swim lane it can be another step in the dev column. Or one can work by splitting a bigger topic in smaller pieces and make the things more dynamic. But, all in all the plain removal of a column will not bring any benefit. I worked without it and now there is a debate to add it...so the response is - like always - it depends :). Best of luck in these challenging times!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
Country/Zone:
State/Province/Region:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.