Foreword – When an IT company receives a project from a client, it is assigned to an unit, then the unit assigns it to a team. The team consists of a manager, few technology leads, few technology analysts and a set of developers and testers. The developers do the coding according to the business requirements and the testers run a set of test cases (perform real life scenarios) on the developed application. This cycle of coding and testing continues until the testers declare the application to be defect free.
Thirteen months into an IT company, I have had little shares of both good and bad. Though this post is not about me or my journey, it is regarding some general observations about developers and testers. The camaraderie between a developer and a tester goes long way back in the past since the onset of information technology. Over the years, they have been inseparable.
A coder generally takes a week at most to develop a functionality in an application. Whereas a tester hardly takes an hour or two to find and report a defect. Majority of which are neither genuine nor replicable. There is always a big communication gap between a tester and a coder, that leads to wrong reporting of defects. The tester continues to test a code with his/her own understanding and without any clarifications from the developer. The only thing a tester looks forward to is dropping a mail reporting a defect. A tester is a quick mailer and spends no time in dropping mails stating defects with keeping everyone senior in CC, thus notifying everyone about the issue. These mails are like triggers which makes the managers go insane. The time bomb (read deadlines) starts ticking and the developers get to hear it the loudest.
Testers are ever smiling and happy creatures as they never have to worry about fixing anything. All they have to do is identify a bug and report it . Sometimes it does not even turn out to be a defect, mostly they are unaware of the new functionalities the client is demanding. On the other hand, the developers consider the testers to be their worst enemies. Once the testers spots a defect, their job is done. As the defect is identified and reported, the developer comes in the picture again. That particular developer first tries to identify whether that defect is due to the part coded by him/her. If not, his/her job is done. He or she assigns it to the coder who is actually responsible for the problem. Then starts the local-server mismatch paradox. The developer in charge of the defect goes on telling that the code works fine in his system and it is the server which is having the problem. This blame game continues for some days. Often the environment (version mismatch) is made the scapegoat and after a series of mails the issue finally gets resolved. After all these, a bug free application is still a myth.
Testing is done in many phases like unit testing, integration testing, system testing, quality assurance (QA) testing and user acceptance testing (UAT). This means a developer’s work needs to pass through all these phases before it is delivered to the client. This is a common practice in most of the companies. On the day of client delivery, if you walk into the office, you will have no trouble distinguishing the developers and the testers. The people rushing here and there clarifying doubts will be the developers and the only people smiling or laughing will be testers. There are times when testers go to the extent of entering decimal values in date fields to find defects in your code, which explains the smiling.
A developer and a tester both work for the same cause, that is to make the application better. Lucky are ones who get to be involved in both developing and testing. A tester turned developer will code more sensibly because he/she will already have some idea about how the testers are going to test. For a developer turned tester, it is usually payback time. 😀