(Feature image: Courtesy of British Council)

While this site is dedicated to helping anyone out there to become a great testing professional, I sometimes feel that I need to pass on some traditional wisdom as well. You cannot just shape your skills alone, you need to prepare yourself for the future as well.

Sometimes I wish I had someone to guide me in the earlier years of my career. Luckily for all of you, I am ready to share my experience and wisdom so that you can benefit from it.

Let’s start with the definition of a tester: A professional who ensures that the solution has been developed as per the business rules and when productionized, the system will not misbehave or crash.

Whether you are doing waterfall, agile, iterative or DevOps, you will always work with requirements in one form or another.

When a solution is developed: it can have defects, it may not align with business requirements (if the Dev team is really crap!) or in the worst case scenario, what the developers delivered is not what the business requested. Hence you need to test the application before it can be productionized. This is to ensure that solution delivers value to business.

Now traditionally, this is done by specific test teams whose job is to test and ascertain business and technical requirements. There is no specific requirements to become a tester. While now you have the ISTQB Foundation Software Testing Certification (a number of companies have started to include this in job posting), in reality anyone can become a tester. All you need is an eye for details, ability to carry out the same task over and over again, a desire to break a system to find its vulnerabilities, an innate desire for knowledge, and willingness to learn new tools and skills.

However let me make a declaration first.

The era of black box testing is coming to an end. Let’s face the inevitable truth.

Organizations now need testers who are technically savvy, know a lot of tools, can help developers identify design flaws and can work basically as an extension of the development team.

Previously developers would have chucked their code (sometimes poorly unit tested) to the Test team (in the below diagram depicted as the Ops team) in the hope that testers will find the defects. Because IT IS THEIR JOB! If the testers find the defect, good on them. If they miss the defect and it ends up in production, well WHY DID TESTING NOT FIND THE DEFECT? Screams the product owner. So either way, Testing will bear the brunt of all criticism from senior management. Even if the release was a success, the kudos to test team will dry out as soon as the next defect slips through the fingers.

(Image: Courtesy of Red Hat)

Well, there has been a gradual shift in the way software testers are being engaged in the Software/IT industry. More and more companies are moving towards outsourced contractors for testing services. Testers are now being requested to have more technical knowledge and have some coding capability too. Companies like Atlassian is no longer recruiting testers, rather all their QC engineers are developers.

While other companies are not going to that extreme, it is evident that testing professionals are no longer black box testers. Besides upskilling and tools modernisation, testers need to start thinking like a developer and look at ways to improve the SDLC process so that there are fewer defects in system test. So working closely with development team is important. In the era of outsourced model, testers now need to prove themselves to be relevant to the IT model.

Below design practices were previously the domain of developers, but now testers are being asked to raised concerns if these design standards are not followed. NOTE how these are not business requirements, rather design standards/best practices that the solution must follow.

• Store all strings and error messages in resource files so that the application can be localized
• Mask all session IDs
• All images are encrypted in the database
• Do not store credit card details in the database for PCI Compliance
• Consider using the test scope from testers to expand the scope of unit testing – the idea is to reduce the defects found during system test
• Run a data collection exercise for a project/application for a predefined period where root cause of all defects are identified. This will give an idea if majority of the defects are due to code issue or other issues not under development such as incorrect requirements, lack of details in the requirements, environment issue, user error, data issues etc. The more extensive the unit test coverage is, the fewer defects testers will find.

So in summary, if you are a software tester, I recommend you start upskilling and learn new tools. Remember, the line separating developer and tester are now slowly blurring and the onus is on you to make yourself relevant.

Smartphones will be the next battleground for the software and gaming industry as processing power increases and machine learning evolves.