Bridging Relationship: Testers vs Programmers

Today my co-tester and I had spent few minutes talking about the problems he faced during his test iteration over a cup of hot espresso cappuccino at office cafeteria. He was explaining about the problems he faces with a programmer (in his cubicle) to whom he closely interacts and works. After hearing him for a while I diagnosed that my co-tester is actually diseased. Yes, he is badly infected with 'programmer syndrome' disease. The cause of this disease is to show high symptom of 'always complaining/talking about developer's incapability/problem'. The effect of this disease is it will create adverse effect on his own thinking capability of not to acquire more testing skills and in other words it affects the right way of building tester mindset.

"Leaving the problems apart, ah...wait...NO - I can't leave my problems just like that, I still have more problems to complain my developers - Yes I'm a tester, how can I be without problems? 


Gurr...I too have many problems to complain a tester in my module who is really bad. - Yes I'm a programmer, I face unnecessary problems with 'that' tester!"

I have also heard from many testers complaining about programmers that they write buggy code, creates buggy product, doesn't know how to code well, doesn't accept my valid bugs and specifically pointing to a specific programmer complaining like...'look THAT programmer is not good', etc. Concurrently I have heard programmers say like, I hate THAT tester every time when I read his bug reports -writes silly bugs, 'THAT tester always annoys me -I don't know why', 'look THAT tester does real bad job'. My question to both the programmer & testers is -Is being bad a birth trait? Please start thinking about it. I think, being bad is an acquired skill as being good. At the same time we cannot dwell well with the bad programmer/tester if we are highly skilled enough (at least to our presumptions), yeah? That's where the underlying problem is. So how are we going to bridge the good and bad of a tester or a programmer to smash this bias thereby one can bridge the relationship better. It's a highly debatable topic, isn't?

After working in this software testing craft for 5 years, I realize that this gap between a tester (who tests the functional/non functional code of a program) and programmer (who writes software program codes) should be bridged well for smooth commutation of software product releases without any bias. Thus I tried to implement a practice to myself i.e. the practice of understanding a good tester/programmer and spotting a bad tester/programmer with 10 noticeable points. I consulted the same to my co-testers & programmers and they found it useful. Glad to know it was also useful for them to understand who is a good tester/programmer and thereby they cleared their mind traps and let the decision with management for bad tester/programmer actionable points. Later good testers have continued to start bridging excellent reputation with good programmers and good programmers have got everything they wanted from a good tester (effective bug reports, test reports, feature modification requests, heuristics, etc.). My co-testers & programmers have got benefited to build and bridge excellent relationships together for successful product releases. Thus I would like to share the same tips in this post, presuming it may embrace another tester/programmer as well.

Ten good tips to spot a good tester:
1. Use sapience well.
2. Have high technical aptitude skills.
3. Have strong analytical, lateral, logical and critical thinking skills
4. Does bug advocacy & brainstorms well.
5. Writes effective/reliable bug reports and loves to gain/build credibility from programmers & team.
6. Involves programmer in test design reviews and have excellent go-getter attitude.
7. Enjoy playing around with business logic against the application under test to uncover more defects.
8. Looks intellectual, updates his testing skills periodically through weekend testing.
9. Always acquire high reputation from the development house of managers, programmers, testers, clients and also creates high demand to assist other testers. Possess training & mentoring skills.
10. Will be a good team player with excellent team building skills.

Ten good tips to spot a bad tester:
1. Write bug reports which seem to be very unique & useful for programmers. However realizes lately that it was a one-line bug report, no records of identified-problem attached to the artifacts, no screen grab/video capture, no clear bug summary, etc... More realization happens when programmer comes to tester desk and ask for "I don't understand 'what the problem is?' in the reported bug, can you please explain more in detail?"

2. Waits until information comes to his desk, doesn't hold high energy or go-getter attitude. Love not to come-out of comfort zone.

3. Compare & complain about the work culture, test teams, programmers with current employer to his/her previous employer. Knowingly or unknowingly kills own time along with the person who sits next to him or an online chat friend. Rather than spending time in other useful test activities.

4. Misunderstands business logic.
5. Doesn't show interest to increase his/her knowledge space by doing collaborative or paired testing. 

6. Never question the functional instructions, follows blindly.

7. Restricts sharing.

8. Hesitate to seek for help or never asks

9. Restricts learning.

10. Sleeps in office.

Ten good tips to spot a good programmer:
1. Write neat codes with clear comments.

2. Understands tester perspective & customer demands well.

3. Knows the importance of extensive unit testing.

4. Put right questions to tester to seek defect co-occurrence.

5. Fix bugs considering integration & regression issues.

6. Informs tester to test diligently on specific modules as there would be higher chances of code breaks, well in advance prior customer release/review.

7. Follow up with tester periodically to assess "how recent build works?" Sets expectations of what needs to be tested, based on current situation.

8. Invites tester to periodic developmental team meetings that he/she participates to urge the interest of knowing "how tester tests differently unlike programmers".

9. Motivate testers to raise more defects on the built code, sits next to tester and observe carefully of the tests he performs. And appreciate for the bug he/she finds in programmer code.

10. The wire frames, business logic, software requirement specification, functional workarounds will be in his finger tips.

Ten good tips to spot a bad programmer:
1. Writes lengthy & duplicate codes with improper naming conventions.

2. The desired functionality will be made to work, without integrating the dependency features of the same functionality taking into account. This leads to adverse integration issues.

3. Often forgets to commit the updated codes to repository.
4. Writes buggy codes with unclear 'comments'. Comments will help another/new programmer or tester to understand the logical work flow of the written code.

5. Often forgets the syntax.

6. Poor understanding of the business logic, leads to write complex code for simple workaround.

7. Never do Impact analysis, fails to plan & analyze the overall cause-and-effect of the functions before writing codes. 

8. No development patterns.
9. Considers testers are of no use. Who has false presumptions of anyone can test & tester do not necessarily require any skills. Doesn't appreciate a good tester who adds value to the product of the programmers build.

10. Who is not afraid to re-factor whenever and wherever applicable.

Tester Vs Programmer

All we need to do is to understand the good and bad of both to realize current contexts. I believe and follow that he, who understands the realism, can wisely react well. I truly believe that there are no best practices. However, there are lots of good practices available. If the good practice seems best practices in your contexts, then it may work for you go-ahead!

Best Regards,
Shiva Mathivanan

Disclaimer: Like how doctors hide patients database to anonymous I'm purposely hiding the diseased co-tester name as he is under my treatment now. I might reveal his details once he gets completely recovered from 'programmer syndrome' disease. :)