Replacing QA Column in the Work Board

It was quite a journey. I started as a completely manual tester who could occasionally do exploratory testing. Then, I made a drastic change of transforming my work ethics, learning automation, using monitoring tools and moving my role towards the more generic QA role where testing in production is a part of the quality assessment. And now, with yet again a bigger change in my quality professional’s journey… I promote replacing QA column after development with something like “Desk Check”. 

I recently joined a new project engagement where we can build the product from scratch. This means that we also are creating our work culture from the bottom up. It looks like our favorite phrase nowadays is “adaptable to change”. With all this, we are trying to identify the first version of our work board.

When one of our team members automatically added a column called “QA” after development, I suggested to rename it to “Desk Check”. You may wonder why would I do that when I am still a part of the team with a role of QA?

Quality should be in-built, not tested in

Thinking of quality should start as early as the user story or feature is being created. How will we gain confidence that development was successful? What metrics will we use to measure implementation? Can we recover from the worst case scenarios easily? Questioning is a huge part of quality promoting. This should be done throughout the development process before even the desk check.

Desk check is not assigned to any role specifically

If development was successful can be evaluated not only by testers but also product owners or even other developers. Desk check is more of a concept where developers show their work (and their implemented checks), get asked questions, and sometimes pair test. It can be very useful to get a product owner to give feedback on the feature before it is marked as done.

Quality of the product is a shared responsibility

When I suggested using “Desk Check” instead of “QA”, one of the developers smiled and said “Oh, so you’re not a control freak gatekeeper. We all have to be responsible.”. This is exactly what I aim to promote. However, what matters here a lot is also the fact that your team is engaged in this.

Having the attitude that all the team is responsible for quality is quite a task and I won’t say you can do it on your own and change people overnight. You can’t. They have to be willing to work in these ways and it can be very challenging. Being responsible for quality as a developer has certain benefits: you gain confidence about your work’s reliability, learn to question your own work, get to collaborate and understand better other team members like product team, and, actually help with your developer skills to improve the automated checks. The drawback of this is: you need to put effort. Way more effort than if QA is responsible for quality.

In summary, it is a challenging change to actually shift left and not only talk about it. You may find yourself wondering what QA role does if the quality is inbuilt and developers write their own checks… And that’s normal. I did, too. What is important to understand is that teams still need Quality Evangelists to question, promote quality, investigate CI/CD clutter, analyze requirements, tackle misunderstandings and share their testing knowledge with others. 


4 thoughts on “Replacing QA Column in the Work Board

  1. A favorite comment of mine, that I read years ago, was that, “the wings on an airplane can’t be tested on, they have to be designed in.”

  2. Hi,

    Thanks for sharing your experience. I’m glad that it had the effect you were going for.

    I’m interested to know – how did you come up with / settle on the term “desk check”. I ask because it’s not something I would have thought of, and it also doesn’t necessarily make me think about testing, by anyone.

    Thanks in advance,


    • Hey Cassandra,

      Thanks a lot for your comment!

      The term “desk check” does not make me think about testing as well, and, that is intentional. Desk check as a concept I’ve heard before in teams and it is a used term, so I did not invent it. It just seems to match the goals I have about the agile processes.

      When there is no column for testing, then testing should be promoted from the very start – from requirements analysis to development. This should take place in pairing and the whole team should share responsibility for testing.

      As a QA, I promote quality mindset. I ask questions, I remind of testing, and I may test as well, but this should come in naturally even before the desk check. If desk check is the first time QA sees the feature, likely it will be more of a pair testing session with a developer. Yet again, it should be a pair.

      What’s more, I see desk check as more of a conversations rather than “here is the list of bugs in Jira, I assigned the card back to you”. Look at the code if you want, question why certain decisions were made – you can find a lot more collaborating and understanding the feature.

      I find pairing in general more effective and productive than creating silos in a workflow. When a dev is thinking of adding some checks – it is for them to gain confidence in what they built and maybe even find some room for improvement. If they do not have an idea how to test it, of course, there is a QA to help, but that is way before the desk check.

      Desk check shows the feature, metrics related to it and success measures not necessarily to QA – and maybe sometimes QA is not the best to judge if the feature is done or not. It may be a product owner or a tech lead (if it’s an infrastructure task). It’s quite a challenge of letting go and changing the mindset here, but it can be very worth it.

      Hope this answered your question and if you ever want to talk more – feel free to contact me anytime.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s