Testers Are from Mars, Developers Are from Venus; Can You Join Hands on Earth?

Developers and Testers: Two people from two different planets working together to deliver a quality product to an “Alien”! Funny isn’t it?! The story is more or less the same in every software firm. A developer works hard to develop a product, which he handles with so much care and gentleness; a tester works hard to break this code handling it in the worst possible cases and scenarios to test its defects, resistance power, and strength.
So, when a developer finally hands over his much-nurtured sprint to the merciless team of testers, ready to execute the ‘out of the box’ testing, this is what happens:
o User Interface element alignment?                                                      Off!
o Inputting special characters instead of string?                                Unknown result!
o Putting 01 for a range from 1-10?                                                           Crash!
o Entering a date in the past?                                                                    Crash!
o Working with special characters in names like, Neil ’O?                Nope!

And there they silently demolish the code….

Sandpapers scrape and scratch, but to create polished surfaces!
So, there is this formidable wall between developers and testers most of the time, which stops them from having a sustained smooth association. There are many reasons attributed to this silent difference in opinions. For instance, developers are often seen to possess parental attachment to the stuff they create. It’s more like; “I know my kid, he wouldn’t do that”, when the reality is, the kid actually did just that! It might sound silly, but a good programmer should learn to be more objective and accept the fact that they have to do terrible things to their code. Because, if they don’t, others will!

Another problem is, developers have little or no idea how their code is going to be handled at the other end of the boundary wall, and thus they aren’t ready for the million bugs that testers backfire at them. Being in the developing environment, which usually revolves around positive scenarios of how to make things work efficiently, they often lack the ability to switch to ‘what can go wrong’ mind state.
Programmers are pros at breaking down complex scenarios into small programmable chunks; ‘The Computers’! – What can be a better example to support that statement! Can you imagine, the computers do all their work with just 0 & 1, the binary numbers and some operations on these, like OR, AND, NOR, NAND, NOT, XOR and XNOR! On the other hand, testers are experts in finding complex scenarios, where they can probably uncover a glitch to break the system!
Thus, the million justifications, silent cursing, and muted murmurs before finally reaching “The end product”! Though these are the situations, the product keeps gaining value from the combined efforts of programmers and testers. And that is how self-resistant codes are born; after all, testers care for their end product, you see! And it’s for developers to realize how their application can flunk in million ways, any time!

Developers with Testers- the perfect wedding!
Though organizations often make efforts to improve the communication between developers and testers, this is often not enough. If only their thoughts cross these barriers and start thinking somewhat within the same boundaries, can we expect super conflict-free Apps! (Pun intended)
It’s always a good idea for programmers to sit through some training/seminars that test engineers attend. A Developer who has attended such seminars is found to avoid making silly (yet common) errors and is often more vigilant. Moreover, a programmer’s awareness of testing tools, methods and processes goes a long way in enabling smooth and fast testing practices. He learns to stand in tester’s shoes while writing codes, to understand what in his code can probably be a tester’s target, what changes he makes will give testers a tough time and what makes it easy, thus making the entire process productive. For instance, any coder might not find it an issue to change a button label from, say, “Clear” to Reset”, but a developer who has sat through the testers’ seminar/ training can probably understand why this silly button label change affects the testing and how it can be frustrating to his colleagues in Testing.
The developer can thus create applications keeping in mind the worst cases that his code can go through, or gets tested in. He will eventually learn to make discipline around testing (or breaking) his own creation- his own code, which indeed makes him a better programmer. So an out of the box thinking is always good! Also, testers need to understand that everything changes with time, and so are the cases with software development too. It doesn’t make sense to change/ rebuild the code every time there’s a change, but the efficient solution is to encourage programmers to make wise changes in their code than to frequently change it.

One team- One goal
In hybrid agile development environment like ours, we handpick Engineers from departments, to form a dedicated team working together throughout the lifecycle of a particular project, with the single goal- the final release! I say ‘Engineers’ and not testers, designers or Business Analysts (BAs), because everyone in this team is a developer, and contributes to the development. This ensures that there are no separate groups (like developing group, testing group, BA, etc.) coming into play at various stages of developing a product, but a single team dedicated to every phase of the product development- from day 1, Sprint 0 to the Release of the End Product! This practice guarantees that the resources and their time are fully and efficiently utilized at every phase.
For instance, with the beginning of a new project, from day one, that is, the initial product backlog creation stage, you have a team in place, consisting of testers, QA experts, developers, UI designers, DBAs and analysts gathering at every SCRUM meetings, to discuss and contribute to everything they may not be directly involved in. Even before the development of the product starts, that is, at the programming estimation phase, testers start writing test cases, estimations etc. for features that will be developed, BAs do the requirement analysis and stuff, Developers plan and decide on features, and so on. At each SCRUM meeting, the team determines how it shall accomplish the work that needs to be done. This way, not only everyone has tasks throughout the sprint, but also knows and understands the roles, responsibilities, hard work and effort taken by each member. Thus, they learn to respect, understand and get on well together to work as a REAL POWERFUL TEAM!
Ultimately, we know the entire team has one single goal- “A Quality product”! It’s just that the developers and testers take entirely different paths to get there, just as in the much-admired Love stories!