Testing early vs late. When to start?

Reading Time: 3 minutes

The purpose of this blog post is to answer the question “When is it appropriate to start testing? Is testing early as possible a good idea, or it’s better to wait for full functional requirements?”

Both approaches have their pros and cons and I, as always, of course, have my own distinct opinion, but I would like to provide my thoughts on this subject in order to help some poor soul from suffering by finding out on their own. So here’s small overview on what are the benefits and pit falls of each of these approaches.

Testing early as soon as possible – design phase testing ย and test modelling.

I intentionally call this not just early testing, but test modelling and test design. Let’s say you are assigned to a brand new project – mobile app or desktop or anything, or a completely new feature. All you have is designs, tech requirements which are very often barely answering all the questions related to development, but anyway. So, practically you have nothing to do for the next one or two weeks until you have something to put your hands on and you are given the noble task of “creating a test plan”. I won’t discuss my opinion about writing test cases, because I want to stay on topic, so here are some pros and cons for this specific approach:

What’s good about it?

  • You have more time, obviously.
  • You have the ability to exercise your imagination on how the work flows in the application are constructed, which might be very beneficial, actually.
  • You have the option to influence design and architecture, if you catch something suspicious – sort of getting in the shoes of UX designer.
See also  Hindsight lessons about automation: Start automating

What’s bad about it?

  • You can miserably fail and spend one or two weeks doing nothing relevant to the real task itself.
  • Might get lost or misguided by lack of information, if you don’t ask for it by yourself.

What can you do to improve?

  • Ask as many questions as possible – this might be annoying for some devs, but it’s part of the game, so give them candy or something and ask for anything relevant to the project.
  • Make abstract models of the work flows and functionalities – you can use mind maps and anything abstract that could help you wrap your head around your tasks. Stay away from predefined test cases, since they might occur irrelevant at the slightest change.

Testing late – full technical requirements stage.

This is a phenomenon that I observed many times in companies and in testing blogs and courses – you know how everyone pretends their organisation is agile, but it turns there’s some V model applied when it comes to testing and many people believe you should only engage in testing when you have complete documentation – functional requirements, otherwise it’s a waste of time. So here are the pros and cons:

What’s good about it?

  • You can sort of trust that everything you write will be relevant, since you are supposed to be in the “mature” stage of development and all design and architecture stuff should be hopefully done.
  • You can use more “classic” approach in planning your testing, not that I support it, but at least you won’t be having battles to explain why you use such revolutionary testing methodologies and etc.
See also  Some kick ass blog posts from last week #12

What’s bad about it?

  • Practically, there’s no such thing as full functional requirements – agile development appeared, because people wanted the opportunity to change constantly any time they want. This documentation is often hard to maintain or completely obsolete.
  • Having the above said, “test cases” might be irrelevant, due to the irrelevance of the documentation, and the chain goes on and on.

What can you do to improve?

  • Basically, try to focus your testing on your guts and your understanding of the product, previous knowledge and basic knowledge for the platform. Predefined test cases are not a good way to go.

What’s my opinion on these two?

I tried both and I sort of found all theirs cons the hard way, so my best advice is. Start testing early as soon as possible, but as smart as possible. My best guess to start testing is when you have something to put your hands on. Of course, there is time for modelling and test plan diagrams. After all, the testing process isn’t just poking around the product, it’s a scientific research and as such you have phases of what you want to test. So until you fund out what exactly are you having there, it’s a good idea to invest your time in researching what are the criteria that you want to apply to your testing, define your scope of research in other words. And then, when you have the ready product to start applying these assertions in order to provide accurate information about the product.

See also  Hindsight lessons about automation: Models of automation

Thank you very much for reading, hope it was helpful for you. If you liked it, please don’t forget to share and comment. ๐Ÿ™‚

Mr.Slavchev

Senior software testing engineer at https://siteground.com. Experience in mobile, automation, usability and exploratory testing. Rebel-driven tester, interested in the scientific part of testing and the thinking involved. Testing troll for life. Retired gamer and a beer lover. Martial arts practitioner.

More Posts - Website

Follow Me:
TwitterFacebookLinkedInGoogle Plus

2 thoughts on “Testing early vs late. When to start?”

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.