Software Quality Assurance has evolved to the point where, in order to be successful, a software tester needs to undergo technical training and acquire the critical engineering skills for thorough software testing. For too long QA was an afterthought for even the largest software providers, either ignored or performed perfunctorily by developers or anyone in the office who had free time before a release. In the Internet age, speed to market is more important than ever – as is having a solid product, and independent test resources have become both prevalent and crucial to ensure software quality assurance. No doubt a person with general technical skills and product knowledge can provide some testing value, but if a professional software tester understands coding, they can be even better at finding bugs than someone without coding knowledge.

Between having a better understanding of the application to the ability to optimize repetitive and time consuming tests, software testers that can understand code end up being better QA professionals.  Let’s discuss some details… 

Now you see me

Testers can better visualize and understand the code behind the application, helping a tester identify additional useful test cases. For example, a software tester knows that a particular page element was using an if/then logic, they can make absolutely sure that both paths of that algorithm are tested. Likewise for loops – it’s known that the end-points of the loop are often where bugs occur, so by knowing the logic for the loop construct, the software tester can look at the boundary conditions more precisely.

The practice of white-box testing is less relevant these days as more and more development teams perform unit testing; yet testers can still use an understanding of the code to inform themselves of more subtle aspects of the application, and create tests to improve the functional test coverage.

Tester insight: “Because of my Java and OOP experience, I often know when a certain item on the page is wrapped in an object at the backend. When I see that same object re-used elsewhere and notice a problem, I immediately go to the previous place (or several places) and attempt to replicate the issue. I cannot tell you how many times developers have voiced their appreciation of the thoroughness of my bug reports when I’ve captured and reported all this information, and it’s directly due to my understanding of how coding is done.”

Brian Borg, Chief QA Engineer, OnPath Testing-

Automated testing

A tester who knows how to write code will find it easy to create automated test scripts, which is a necessity for Continuous Integration (CI). Even UI, API and performance testing can be automated. This helps speed up the test cycle and frees the tester to focus on exploratory testing to identify new issues. The ability to write automated scripts isn’t the whole picture; if the SDET (Software Development Engineer in Test) understands the methods and functions built by the developers, they can use the same functions to set up and breakdown their test harness and test cases. Since they don’t need to recreate these functions themselves, this frees QA professionals up to focus on other crucial aspects of testing.

It is easy to execute automated testing by using software testing tools like Selenium IDE, which offers user-friendly GUIs and record-playback options. Software testers don’t need to know how to code these, but depending on the stability and complexity of the application, there is only so much benefit these record/playback tools can offer.  They cannot automate all the steps of certain tests, and they break easily when the app is updated. For instance, Selenium does not provide test reporting and an error recovery mechanism by default; these have to be emulated. Selenium also does not interact with Flash, PDF or JAVA applets. Testers with coding experience can overcome both anticipated and unforeseen challenges. 

Better communication with developers

QA and developers understand each other better if testers learn to code

Quality Assurance engineers that understanding coding can communicate better with developers when they share a common language. They understand better the constraints faced by developers while coding, and can even point out possible issues in the code.

Employability

It can be argued that if software is being developed, regardless of the industry, then automated testing software can be helpful on that development team. If a test engineer wants to stay highly relevant and employable in the market, there is no doubt that being able to read and understand code increases their chances of employability. But, this does not take away from the fact that manual testing forms the basis of automated testing. Without manual testing, there would not be any tests to automate.

But…the closer you are, the less you see.

This raises the pertinent question that with testers learning to code, who will test the code they create? Can they test their own code with the same objectivity as they test the code written by developers? We see two distinct skill sets in a development team – that of building an app and that of going all “CSI” on software, breaking it down and investigating where bugs may be hiding.  

One challenge we see is that coders have in their mind how the application works, so they test using the “happy-path”, the way they designed the software to work in a best-case scenario. In the real world people ignore what makes sense as far as the “right” way to use an application and uncover issues by using it in unexpected ways.  Better a software tester finds these errors than your customers, and dedicated testers have honed that software-breaking mentality. 

Dedicated QA testers often prepare for test automation by using existing test cases and plans. The test approach has therefore been performed many times, establishing a base of reliability, and once automated the code can be cross-checked by other testers as with any other development effort. Furthermore, there can be a regular cross-checking of the automated results with a manual execution pass, using the same test scenario and data inputs to ensure the automation scripts are providing accurate results.

If testers know how to read and write code, it is a tremendous advantage but the onus still lies on the tester to keep their focus on QA testing and finding those bugs!

It was Sir Francis Bacon who said “Knowledge is power.” There is no doubt that testers can test better if they understand the code. They should encourage the effort to diversify their knowledge as the complexity of application technology is inherent in the nature of software testing.

Recommended Posts

Leave a Comment