Development vs. Testing
Industry Wisdom Interview Q&A

Take it easy, Developer. It’s not personal!

Testers don’t break the software, it’s already broken”!

Agree or not, once in a while every one of us enjoy criticizing something – a person or a situation. A conflict between a developer & a tester is not new – it has been there since the inception of Software Testing. After all, nobody likes it when their mistakes are pinpointed & written on the wall. What they don’t understand is – it’s not about ‘You’, it’s about the ‘Software’!

Yeah! As a tester you must have encountered an ‘Fcuk Yuo’ situation at least once in your career when you thought ‘Take it easy, developer. It’s not personal!’…There are multiple situations where a tester needs development team’s support ‘to ensure better quality’ but…

Let’s look at some of these ‘quality’ situations:

Unit Testing is done by Developers

Unit TestingYeah! In theory! But practically, most of the times we find during our ‘Smoke Test’ that the main functional flow itself isn’t working. It’s like developing a Gmail login page where error is displayed as soon as the user clicks ‘Sign In’ after entering username and password 🙂 Yeah! WTF! Is this a kind of development we expect? Nah! But what’s the way out? First – curse the developer 🙂 drop a mail marked as Critical keeping seniors in loop. The issue gets fixed & comes back for retest.

Purpose: Developer loses his/her credibility, Tester is frustrated & cursing the Dev community!

Test ABC in one week

Ha-ha! Another common I guess. For most of the non-testing professionals, ‘Testing is just a formality & pretty easy’. Just click here & there few times, check some flows, done. Right? Absolutely wrong!

Software Testing is not just a technology, it’s a mindset. It requires analysis, design, execution, retests, reporting & closure. It’s a process. Not just clicking here & there to verify few of the flows. It takes time to ensure the quality of ANY product – NOBODY wants a failure in live environment.

Purpose: Developer thinks Testing is quite easy, Test team is again frustrated by the lack-of-understanding from Dev counterparts.

‘Software Design’ is as important for testing team

What is you are testing Flipkart and you don’t know what all components makes up the system? How different components are integrated? Be it user authentication, catalog, search, cart, payment gateway, etc. Yeah! Anybody will be lost, or in other words will lose some functional flows to include in the test coverage. The integration!

So the product/software architecture is as important for Test teams as it is for Development team. It is always a good practice to include test team representatives in architecture sessions. But as usual, the general perception is ‘Testing team has nothing to do with the architecture’ – just develop & deploy the build for testing.

Purpose: Developers don’t understand the importance of ‘Software Design’, for testing team to ensure test cases coverage & execution quality.

Follow the Defect life cycle please!

Defect Life cycleFixed, retest all the defects’ the developer said >> Tester looks into Defect Management tool (e.g. HP Quality Center) and see that none of the defect’s status is changed to either ‘Fixed’ or ‘Ready for Test’ >> But still he/she verifies all defects & reopens half of them.

Looks like a common scenario, right? Yeah! Developers seldom follow the defect life cycle in the management tool. It’s communicated either via mail or orally or chat. What’s the point of using a defect management tool then? Developers need to understand that the tool is to ‘Track defects to closure’, i.e. it is for ALL teams involved in defect identification & resolution – be it Business, Technical, Development or Test team. It’s NOT just the responsibility of the Test team!

Purpose: Developer’s lack of ownership & responsibility once development is completed. Understand that the job is not over yet – defects resolution is as important as initial development. For a Tester, it means a lot of rework & hatred towards the process of maintaining the defect life cycle all by self.

Follow the best coding practices at least

What it has to do with Testing? Test team uses multiple tools & techniques for ensuring the quality of the developed product. E.g. Automation testing. Now how does automation work? The tool/script identifies different objects/fields/elements available on the application’s UI using certain property values like ID, Name, etc.

From automation perspective, the first & most challenging part is identifying ALL the objects on the screen. Why? Because developers didn’t follow a consistent approach for different object’s properties, or across the environments. The result – increase in time taken to automate.

Purpose: Unknowingly, everybody in the development team doesn’t follow a consistent coding practices which indirectly impacts the Testing activities.

Defect is not reproducible

The famous one-liner among the tester-developer communication 🙂 “The defect is not reproducible” – on my machine, in this environment, on this browser, etc. Identifying the defects isn’t enough for a tester, he/she needs to keep a track of steps followed, screenshots of the errors, check the logs, etc. And that’s a good practice. What if it’s just the reverse? The client says I am getting an error in ABC flow but you as a Test Manager say it was working completely fine. Will the client believe you? No! You need to provide evidences – execution logs, test cases, screenshots, etc.

Defect not reproducible

But as a developer before saying ‘The defect is not reproducible’ – at least try different combinations around the steps, do some analysis. After all it will make the software better, & if the error has occurred once it might re-occur in live environment as well – and if it does, you cannot escape saying “The defect is not reproducible on my machine” 😉

Purpose: It’s not about the machine, browser or environment. Eventually everything is about the software that will be used in the live environment by the end-users. Don’t escape from doing some analysis, it only helps from future perspective.

We are Dev Team | You are Testing Team

The separation of debugging from testing was initially introduced by Glenford J. Myers in 1979. Although his attention was on breakage testing (“a successful test is one that finds a bug”) it illustrated the desire of the software engineering community to separate fundamental development activities, such as debugging, from that of verification. Since then, there have always been two streams – Software development and Software Testing. Slowly the bifurcation percolated among the teams and the hatred towards each-other grew. But what we don’t understand is – Development and Testing should go hand-in-hand to deliver a quality product. Though separate, but the goal is same – a Quality Software.

Everybody in technology is doing his/her job to ensure customer satisfaction. It is not two different or rather opposite teams – both are important for a successful delivery!

We are intellects. Testing? Cheap labor

Software Testing? Can’t you change your technology? Development is much better…Anybody can do Testing, do something good with your degree…It’s boring…Testing is no more a skill set…There is no career in Software Testing!

We agree to disagree. The sole criteria this assumption is based upon is the horde of Manual Software Testers in the market (it’s a job market after all). General perception is – Software Testing doesn’t require technical skills. Result – Every Tom, Dick & Harry is pursuing a career in Software Testing. After certain time, everything becomes stagnant for them! It’s not just about ‘Software Testing’, everyone needs to move out of their comfort zone once they hit the dead-end.

Testing is a skill. While this may come as a surprise to some people it is a simple fact. Yeah! Automation scripting knowledge is important to distinguish your candidature but it is not everything. The ability to analyze, communicate & reason are equally important. A great Software Tester has to have many competencies – Critical thinking, Business & Architecture understanding, Domain knowledge, Tools know-how (can be acquired through relevant training & practice), Test & People Management, Test to improve attitude, etc.

Chill! It’s not personal

Last but not the least – It’s not personal. Some developers tend to take it personally if their module yield high-defects. What they don’t understand is that – “Testers don’t break the software, it’s already broken”. And it’s NOT personal, it’s the job of testing team to identify defects, to make the software better. We are just doing our job. At the end, it’s all about delivering a quality product!

Missed some ‘Take it easy, developer. It’s not personal!’ situation? Or do you have an experience to share? Would love to read your thoughts in the comments section below!

Save

Save

Save

Save

Save

Save

Save

Save

Leave a Reply

Your email address will not be published. Required fields are marked *