When Devs tell you how to test their code!

Developers pouring ideas on how to test! Sounds familiar? How does it get perceived? Does such input make you feel - Upset, responsible, frustrated, offended? 

As a Tester, you might think “Why should someone supervise or control on how you prepare for your task or how to do the testing?”

I find it alright if Devs or anyone from the team is suggesting how to experiment or what to Test. 

The reasons could be: 

• They know behind the scene happenings as they analysed and picked up a few details before leading to code that functionality. Thinking around technology combinations and workable solutions.
• They recognise specific libraries being manipulated/handled and which may have certain behaviour to watch for when we test.
• Or that 3rd party may have that unexplained rule/policy known to Devs alone as they examined and dealt with it to make that code work.

For e.g. 

Consider a third party library that has been updated, but which you can’t use right away until you resolve certain dependencies. Once the dependencies are updated, the devs decide to use the updated third-party library. During the update, they would identify changes, improvements, and new features. The Devs would therefore be best placed to advise on new scenarios or considerations that should be tested.

Another example: 

An application that permits the user to switch between the mobile and web-front ends via single sign-on or session continuation would use a variety of underlying technology features to make this happen. In such a case, the logic to test would be beyond regular “business” logic and is thus best discussed with developers and security teams. 

And another example: 

As users of the Android and iOS mobile OS, we usually get familiar with new features and changes. Such information is at a high level, and usually about how to use the feature. However, when developers have to ensure that the app works in the newer version of the mobile OS, they have access to lower-level developer documentation and sometimes need to change the app to get it to work on the new OS.

When this happens to me, I consider it as part of preventing the risk if any. 

I check if I have those ideas noted, 

• If not, I will include - this boosts my learning, and I can use this approach when I check similar products. 
• And if yes, it’s a fabulous thing that Devs and I concur! 

We claim Quality is the team’s responsibility, then why not to welcome another viewpoint. It’s always a pleasant addition at the end of the day. And keeping everyone in the loop does save a lot of time down the line.

I always welcome the suggestions coming my way on how there is one more way something can get attempted - from others' experience or just a sheer thought. 

When it comes to quality, let’s embrace all the minds!