Do Testers need to be Developers to support Continuous Delivery and Agility.. ?

In this blog post, I explained the need to prepare the traditional QA’s towards Agile and Continuous delivery teams. However, this one question will keep bubbling up for some more time until everyone accepts the transition.  So, what is the role of testers in Agile teams. Do testers need to become developers? Unless you are a startup, you likely have QAs around in the organization who have been providing Test Automation as a service, what do to with them now? and so on..

There are many books (Agile Testing, More Agile Testing) carry insightful discussion and experiences from experts on this subject. Whenever this topic comes up for discussion, I’d fall back to one of my favorite articles by Rob Lambert.

While that sounds more like a people and talent management concept, sounds like it makes whole lot of sense when you want to mature towards self organizing Agile teams who can deliver high quality working product in sustainable pace.

Why is that critical to have ‘T’ skilled testers part of the team?

First off all it fosters collaboration across the disciplines. Deep expertise in one area ensures that the team has an expert in that area. However, for the expert to communicate his/her point across, it requires basic understanding and broad knowledge in the areas other than their specialty.

A team member who has come from QA background has deep expertise to approach quality, test automation design patterns and practices. However, it’ll add value if that person can understand the development world to some degree. Basic understanding of web development (if relevant), ability to scan thru unit tests and understand what’s covered at that layer and how, basic database concepts, DevOps understanding etc.

Similarly team member who is passionate about development got deep development expertise, however, it’ll add value if that person can understand testing techniques, test automation practices to some extent.

Lets take this example, recently I came across this situation where we were automating some test cases for a single page application(SPA). Unlike a website, SPA takes longer time to load initially as it loads all the JavaScript code once and any further action in the UI will just get updated data from the backend to rerender parts of the screen. URL is less likely to change. There could be several actions in the same page, depending on the user actions there could be network activity to fetch new data and update the screen. Given the nature of the application, it promotes composition at the GUI level. Meaning, a page might contain several components and each of them might have its own lifecycle. Lets say the page we were automating composed of 2 different components and your test case needs both the components to be completely available before going forward with next step.

We started to automate with default webdriver timeout of 60 seconds. For example, its expected that Angular finished rendering and has no outstanding http requests within 60 seconds, otherwise, test will fail. This worked well for a few days. Suddenly, tests started failing and resolving this issue highlighted the need for ‘T’ skilled QA team members.

Approach 1

One way to solve the problem is to increase the timeout from 60 to 90 or add some dynamic thread sleep. Tests started passing but would occasionally fail. This justifies why developers don’t subscribe to GUI tests because of non-deterministic nature of this testing technique. Why did it pass with 60 sec timeout, why does it pass with 90 sec and why does it fail for no reason?

Approach 2

Took a pragmatic approach. Went ahead to see what changed in that component and why it started failing. Found out that component two introduced long-polling. Long-polling? yeah, they prefered using persistent or long lasting http connection between the client side component and their chat server. So, the root cause of the problem was if the test is waiting for all http connections to be resolved within 60 seconds and its not resolved due to long-polling. Regardless, if we simply extend the timeout or put some sleep(), issue will persist.

Perhaps, Approach 2 surfaced the real problem and lead further discussions on both sides. It needed a tester who can go below the GUI surface, understand how application code works and work with developers to find a long term fix. Classic ‘T’ skilled tester. Developers started thinking whether they should adopt timeout technique in the production code instead of long-polling or is there a better technique. Testing side of the house started thinking whether its realistic to expect all http calls to be finished or narrow down to the scope of a specific component that the automation needs. Ultimately healthier discussions between the team members rather than blaming each other.

On one hand it might feel like these practices attract generalizing specialists, running into the risk of diluting the strengths, instead of mastering one thing we tend to touch everything. But the idea should be use specialists’ strength to succeed in accelerated delivery cycle.

  • If a tester can evangelize quality practices in a manner that other fellow team members can support and follow, that’s a win-win for everyone.
  • Fosters better collaboration amongst the team members.
  • Promotes empathy for each other and mutual respect. Cooperation not competition.
  • Invites developers and other team members to step up and help when there is a need instead of saying ‘automation is not my thing’.
  • Enables everyone to think about improving quality and preventing bugs.

Consider building ‘T’ shaped skills for your teams..


One thought on “Do Testers need to be Developers to support Continuous Delivery and Agility.. ?

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