Recently came across a post in LinkedIn which explained about having good relations and trust with developers but at the same time not to believe in all they say about no need to test something. This chimed with my experiences I had as a tester and wanted to share it with the Software Testing community.
It is extremely important to have good relationships with developers. There should be respect and trust with developers as they are trying to do the best they can as everyone else. But there is a line where what they say should be tested, and the proof is in the product pudding.
One of the instances where it was proven correct to me that we got to test to make sure that things work as the developers claim was when we got a product to test that inherited code from an old implementation which was considered bullet-proof and nobody had touched the code for a long time because they believed that the underlying implementation was perfect, so the developers in question spun-off a few implementations based on that implementation. When they inherited the source code, they didn’t question if that code is doing the right thing. Probably because they believed that it did, or probably because they felt that if they touched it, it would result in base code itself becoming unstable, which would lead to problems that they were not ready to face.
Anyways, when I started testing the code, I found very basic issues in the native code which needed fixes. A week into the testing, and around some twenty defects, one fine morning I got a call from the development lead. He had never spoken to me to get introduced or even had communicated over email before. But there he was, and he went “Venkat, you know, you don’t need to test all that. It’s all great, and that code is all working fine, and there have been no complaints from the customers. That code has been running okay for years now.”
I told him, “Look, I cannot keep my eyes closed or look in another direction when I see problems. My job is to let the team know about the problems. It’s up to the management to decide if they want to fix it, which I think they will make the call on”.
“No, no, I don’t want you to look in another direction, but….”, he dragged.
I said, “What else do you want me to do? I am not going to stop filing these defects. If you want to close them or defer them, please talk to the management and convince them.”
After two to three days, they brought in three developers to fix those problems. Apparently, even the development lead’s manager was convinced that these problems are basic and got to be fixed, and even though the issues were not that team’s responsibility, they went ahead and formed a team to consult with the native team (whose team members by the way had moved on to other projects), and got those issues fixed.
If I believed in that development lead’s words that there were no problems in that area and that I need not test, those problems would have remained, and it was a matter of time one customer or other was going to find them, and the fixes would have happened (at an added cost of customers finding the defects).
Maintain good relationship with the developers, but don’t believe all they say.
Test.
Feel free to consult me for testing strategies.