Entries Tagged 'Testing best practices' ↓

Developers are not good testers. What you say?

This can be a big debate. Developers testing their own code – what will be the testing output? All happy endings! Yes, the person who develops the code generally sees only happy paths of the product and don’t want to go in much details.

The main concern of developer testing is – misunderstanding of requirements. If requirements are misunderstood by developer then no matter at what depth developer test the application, he will never find the error. The first place where the bug gets introduced will remain till end, as developer will see it as functionality.

Optimistic developers – Yes, I wrote the code and I am confident it’s working properly. No need to test this path, no need to test that path, as I know it’s working properly. And right here developers skip the bugs.

Developer vs Tester: Developer always wants to see his code working properly. So he will test it to check if it’s working correctly. But you know why tester will test the application? To make it fail in any way, and tester surely will test how application is not working correctly. This is the main difference in developer testing and tester testing.

Should developers test their own work?

Test in progressI personally don’t mind developers testing their own code. After all it’s there baby ;-) They know their code very well. They know what are the traps in their codes. Where it can fail, where to concentrate more, which is important path of the application. Developer can do unit testing very well and can effectively identify boundary cases. (Image credit)

This is all applicable to a developer who is a good tester! But most of the developers consider testing as painful job, even they know the system well, due to their negligence they tend to skip many testing  paths, as it’s a very painful experience for them. If developers find any errors in their code in unit testing then it’s comparatively easier to fix, as the code is fresh to them, rather than getting the bug from testers after two-three days. But this only possible if the developer is interested in doing that much testing.

It’s testers responsibility to make sure each and every path is tested or not. Testers should ideally give importance to all small possible details to verify application is not breaking anywhere.

Developers, please don’t review your own code. Generally you will overlook the issues in your code. So give it to others for review.

Everyone is having specialization in particular subject. Developers generally think how to develop the application on the other hand testers think how the end user is going to use the application.

Conclusion

So in short there is no problem if developers are doing the basic unit testing and basic verification testing. Developers can test few exceptional conditions they know are critical and should not be missed. But there are some great testers out there. Through the build to test team. Don’t waste your time as well. For success of any project there should be independent testing team validating your applications. After all it’s our (testers) responsibility to make the ‘baby’ smarter!!

What you say? 

Tips to design test data before executing your test cases

I have mentioned importance of proper test data in many of my previous articles. Tester should check and update the test data before execution of any test case. In this article I will provide tips on how to prepare test environment so that any important test case will not be missed by improper test data and incomplete test environment setup.

What do I mean by test data?

If you are writing test case then you need input data for any kind of test. Tester may provide this input data at the time of executing the test cases or application may pick the required input data from the predefined data locations. The test data may be any kind of input to application, any kind of file that is loaded by the application or entries read from the database tables. It may be in any format like xml test data, system test data, SQL test data or stress test data.

Continue reading →