5 Developers’ Doubts Making Them Stuck Before They Even Start Testing

Everybody knows that they can’t do without testing. However good code the developer writes, there will almost for sure be bugs in that code. That’s why some basic testing to proof check the freshly written code is essential, not to say about some cases when developers working at startups are expected to be also testers and write all the tests.

What makes developers and beginner testers stuck even before they start writing tests is lack of experience and unsurety, of course. However, if you intend to take it seriously and actually complete that testing task, you’ll need to face all your doubts and overcome them to start testing.

Here are the 5 doubts developers face most often when they are to test a product:

1. Am I using the right testing tool?

When you start your first project, you never know which testing tools you need for testing it. There are so many of them other may have recommended you – Cucumber, Minitest, RSpec, Capybara… But the thing is the more time you spend picking up the right tool (even if you are feeling productive during this), the less productive you are as all you do at this point is hesitating, not acting. What you should be doing instead is just to pick a test stack you already know or, if you don’t have any tried tools, take the default one. For example, you can start with the tools Rails gives you. Later you’ll be able to add more. Trying out new test tools is OK, but if this keeps you from doing your job, the best idea is to come back to those tools over time when you are ready for them, that is, you know your project better and figured out your workflow.

2. What tests should I run first?

If you are hesitating whether you should start with unit, functional or integration tests, you can start from the features or screens which are built first. First, pick a thing off the features list and write one failing integration test for that feature. Second, once you know what kind of routes and controllers you are missing, write a few failing functional tests. Third, as controllers require logic and data to do the job, write unit tests and models next. Finally, once you get the unit tests passing, get your functional and then the integration tests pass, and move on to your next feature. Of course, once you see that your testing process has clearly defined steps to follow, it’s much easier for you to stay motivated. And as you aren’t faced with the necessity to make frequent decisions, you have less temptation to procrastinate.

3. That thing is too hard to test.

Whenever you need to test the command line utility, network code, rake task or anything that looks almost impossible to test, the best thing you can do is move just as much code as possible out of that hard-to-test file or class and add it into a new object which will be easy to test. In this way that “untestable” thing will create and pass its parameters to the new object. Surely, the original thing is still hard to test for you, but at least there’s only a few code lines and it’s easy to stub it now.

4. I’ll write the tests when the project’s done.

Developer craves shipping code, not testing it. When the tests are seen as finishing strokes before shipping, developers tend to write the minimum tests number just enough to feel the code works. This perspective lacks focus on product quality and only makes testing feel annoying rather than useful. In this case motivating yourself to test is surely hard. What strategy motivates developers to test and avoid underrating the quality is test-driven development. TDD mixes testing with design and coding and makes testing feel like part of coding. This way testing becomes more fun that burden and the benefit of testing much earlier, and thus better, is achieved.

5. I feel like I’m doing it all wrong.

This doubt is purely of psychological nature. Beginners always feel unsure. The stress on the quality importance is especially powerful if you’re building on Ruby, with its community pushing code quality really hard (even though it’s a good thing) and seemingly expecting you to ship perfect 100% tested code despite it’s your first try. Such expectations make it real scary to start a project, not to say about an open source one which is available for everybody to use.

Still, it’ll be easier to deal with the pressure if you remember a few true ideas. First, every developer in their life has felt embarrassed by their code later. Second, good code that’s shipped is better than perfect code that isn’t. And finally, some people criticising your code are just like doing it, so you better listen to people who not just criticise but also help you improve it.

Of course, you feel unsure when you aren’t experienced enough, but how will you learn to do it without trying? Whenever you have similar doubts, follow the advice we gave you and never let bad thoughts make you lose your motivation while testing.

TestFort Blog

About TestFort Blog

TestFort blog is an official blog of TestFort QA Lab company and is dedicated to various QA and software testing issues.

no comments yet

Be the first to comment this post!

Would you like to share your thoughts?

Software testing & QA blog by TestFort © 2017