Tactics for Better Software Testing

Tactics for Better Software Testing

Tactics for Better Software Testing

Tactics for Better Software Testing 800 507 infrastructure

1) Start the software development cycle together. Or in other words, ‘start planning with software testing involved on day one.’ “In reality, any ramp up period is never sufficient,” according to one of our software testers. The risks associated with pushing software testing as far back in the software development life cycle SDLC (in order to save on resource costs) might not be cost-effective in the long run. In addition, if you fail to create a process, or perhaps a testing strategy as part of the development, then chances are you’ll incur more costs and further delay shipping your product. “QA engineers need to get as much visibility into requirements,” said our head of Quality Assurance.

Good planning is essential for success, as a general practice. For software testing, this includes identifying test objectives, methods of testing, resources and roles, tools, risks, reporting, timetable, environment, priorities, and regression test approach. It’s been recommended that for “every stage of development design, a corresponding test strategy should be created to test the new feature sets.”

Test automation necessitates that both software developer and software tester identify and assign conventions for Selenium locators, for example, at the onset. These locators allow software testers to find elements on a page that can be used in automated tests. If the developer changes that locator (in the next iteration), then the tester then has to make edits, which is typically more time-consuming versus starting from scratch. In addition, it is not a trivial task to uniquely identify locators, but tools such as Firebug come in really handy.

2) Document well. Or in other words, ‘you never know what you will forget in the future.’ In some cases, this also means, ‘make it easier for other people to understand your work‘ aka ‘have some respect‘. Just do a simple comment, such as what that script does. It doesn’t have to be an essay.

Again, any ramp up period is never sufficient. Say, a transition happens and somebody new has to jump in and read the code — what if he fails to understand what a script does for lack of documentation? He can write out a new one, instead, but he doesn’t know he’s re-writing something that’s already been written!

It’s best to have very detailed test cases, however just enough documentation should suffice for our agile development,” said another software tester. “Getting everybody — including the product owner / customer — on board test-case preparation helps ensure completeness of the test cases.”

3) Divide and Conquer. Manual software testing typically can start earlier, perhaps 2-3 iterations earlier, followed by automated testing. During development, it’s challenging to do test automation as there are moving parts. As a general practice though, once the application becomes stable, that’s the time automated testing can take place.

It’s also good practice to separate the testing environments because, “there’s a possibility that when scripts start running, the one doing manual testing might accidentally manipulate a certain data.” Worse thing that can happen is that the test automation crashes, and that means the manual testing will have to stop.

Automated testing would run faster within its own environment.

4) Test early, test often. “The value for us is that if we roll out incremental deployments, we can test early and apply fixes immediately. If we can apply fixes early, then we have more time to focus other bugs. In any case, having a sufficient test coverage is always recommended,” said a project manager.

The agile software development approach means testing as early as possible, and that involves unit testing for developers, integration testing, and then system testing. In addition, “each feature is being fully tested as it’s developed.”

Run at least three passes of testing. “Your first past at testing simply identifies if the function is working. We call this happy scenarios,” said another software tester. “The second pass is to test the happy scenario and the unhappy scenarios.”

For example, first pass is to make sure that an email is sent when the provided email is in the correct format, [email protected]. In the second pass, run another test with [email protected] and an email in the incorrect format, some.com.

The reason behind this approach is to guarantee that the basic functionalities are working in case an urgent deployment is required. In other cases, the first past at testing identifies where the defects are. The second pass of testing verifies that the defects have been resolved.

In effect, this ‘test early, test often’ approach calls for testing throughout the project, instead of testing being just a phase. The more passes of testing, the more chances of shipping that product on time and on budget. “Software should not fail in the last stages of your delivery cycle – if it does, then you have done something wrong along the way,” according to a related article.

 

What recommendations would you have for best practice software testing?