TesterHQ - The Evil Tester Blog Aggregator

Sep 13, 2016 - 3 minute read - Linkedin

Stop finding simple bugs. Use Automated Validation tools early.

Original Pulse Article on [Linkedin]

I recently realised that I wasn’t taking advantage of as many automated validation tools as I could do. Hopefully after reading this post you will question whether your process uses enough automated validation.

The process of “Testing” provides one way of reducing risk on our projects.

  • “There is a risk that we have bugs in the software”

Therefore, we test the software to identify problems, which we then fix, to reduce the risk that the user will find the bugs in the software.

When testing, “there is a risk that our testing misses issues”, and there are reasons for that:

  • lack of time
  • prioritising areas of the software means some parts don’t receive as much attention
  • lack of technical knowledge
  • etc.

Given this, we want our test process to increase its effectiveness and find issues that only the test process would find. We really don’t want testing to find issues that a tool implementing a series of automated validation rules could find.

We don’t want testing to find issues that a tool implementing a series of automated validation rules could find.

We easily check our compiled code for syntax errors. The compiler does that for us.

Parts of our application do not go through this process.

As an example, I recently wrote a simple ‘joke’ application to generate the type of slogans in my book “Dear Evil Tester”.

Despite having only 15 lines of HTML, I managed to write it in such a way that it was buggy on iOS devices.

  • none of the browsers I used for testing rendered it poorly
  • none of the browsers I used for testing reported an issue
  • when I reviewed the code it looked fine, given my understanding of HTML

But it failed to render one of the buttons on iOS.

I could have found this problem early by running the HTML through a standards validation tool e.g. :

Either of these free tools could have found the error and fixing it to make the HTML standards compliant was a 2 minute job.

Had I used these tools, any browser that claims to adhere to the HTML standards should have no problem rendering the application.

I could have done this for free, prior to my testing it, and certainly prior to release.

Many parts of our applications have tools that can apply validation and review rules automatically:

  • Interpreted languages like Ruby and JavaScript have linters and static analysis tools
  • CSS has validation tools
  • HTML has other validation tools
  • Compiled languages have tools that go beyond the compiler e.g. findbugs, checkstyle

If we do not use these tools then we increase the risk that:

  • our testing finds defects that could have been found earlier and automatically
  • we have to repeat testing after ‘minor’ defects have been discovered and fixed
  • we miss very small ‘compliance’ issues which only manifest on certain devices
  • we don’t use the devices that the errors manifest on, and therefore release defect to production

I suggest that for each of the technologies that you use on your project you spend sometime looking for static analysis tools that you can apply. And mitigate the risk that your development process allows simple issues to slip through that can decrease the effectiveness and cost efficiency of your testing.

Related Blog Posts: