Software Testing
Testing Fundamentals

Different means to Test | What’s your Testing approach or method?

Now that we have already discussed,

The next obvious step is to understand the different Test approaches or methods, i.e. ways or means on how we can test the application-under-test (AUT) effectively. Will you start testing in parallel with development or only after the development is completed? What about testing at the code-level? i.e. code reviews to ensure best practices are followed. Will it only be reviews or will you actually run the application to identify defects? How about utilizing some automation tool to ease the process? Or will it be hybrid? As you might have guessed there are various approaches or methods to test a application. Broadly these are divided as explained in this article.

Preventative approach

Prevention is better than cure’, Yeah! Same applies to Software Testing. Tests are designed at an early stage, i.e. finding infinite ways to test and break your software before it goes to production. Identify or forecast the risks early & plan accordingly. Being pro-active always pays – you can avoid certain kind of defects early, before actual test execution begin.

Preventive vs Reactive Testing approach

Reactive approach

Responsive – as in tests are designed after software development is completed. You react as & when the problem (defect) occurs. In other words, you work more nights & weekends 🙁 it might result into re-evaluation of the test plan or test activities. It’s costly and built around a failure mentality. It’s like waiting until you’ve lost the game to study how your opponent beat you during the game (reactive) as opposed to scouting out your opponent long before the game, learning their strength and weaknesses and being prepared to win the game before it is played (preventive).

Black-box Testing (functional)

Can you see what’s inside a closed black-box? No, right? Similarly Black-box method treats the AUT as a black-box (no knowledge about its internal structure). Result – We are not bothered about how the internal structure of the application is maintained/changed until the outside functionality is working as expected (as per requirements). Knowing what the application does is more important than knowledge of how it does it. This is the most widely used test method for System & Acceptance tests as it doesn’t require professionals with coding knowledge and also it provides an external perspective of the AUT (as an end-user who have no knowledge of the actual code).

E.g. we are only concerned if user can watch television, change channels & volume, etc.

White-box Black-box Testing

White-box Testing (structural)

It’s obvious, just reverse the approach. Since it’s a White-box >> we can see what’s in it, i.e. the internal structure, and use that knowledge to expand the coverage to test every possible flow at code-level. For example – Statement coverage, Branch coverage or Path coverage. It requires programming skills and is usually preferred only for Unit & Integration test levels. You can call it by different names – Clear-box, Glass-box or Transparent-box as far as you can see the internal contents of the box :-).

E.g. we are concerned if the internal circuit for the television is designed correctly.

Gray Box testing

As you might have guessed – a hybrid approach, i.e. leveraging the strength of both, it’s the combination of White-box and Black-box Testing. Not complete but still the tester has little knowledge about the internal structure of the AUT.

Static Testing (Verification)

Static as in immobile – the code is not executed. Rather the code, requirements, design and other documents are manually reviewed to find errors (such as code flaws or potentially malicious code) before the test cases are actually executed to verify the functionality. The benefit – saves effort by identifying errors earlier! There are different industry-accepted techniques to review such as Informal reviews, Technical reviews, Walk-through, Inspection and Code reviews.

static-and-dynamic-testing

Dynamic Testing (Validation)

Dynamic as in active – the code is executed. How? By exercising the different functional or non-functional flows of the AUT in run-time environment from the User interface (e.g. webpage). The objective – to confirm that the AUT is working in accordance with the client requirements. Dynamic testing is performed at all levels of testing and it can be either Black-box or White-box testing.

Note: Both static and dynamic testing set-out to uncover vulnerabilities and coding errors within AUT using different methods.

Manual Testing

I hope this is self-explanatory. No automation tools like Selenium or HPE UFT are utilized to test the AUT. Instead the designed test cases are run manually by the testers, i.e. manually checking different functional / non-functional flows. It requires business, domain & application knowledge to successfully test an application. The advantage – as it’s not scripted, a tester can follow ad-hoc tests as well while doing test execution (that results in more defects :-)).

Manual-Automation-Testing

Automated Testing

Wouldn’t it be great if computer can run the tests on an application all by itself? Yeah! Software-testing-Software 🙂 Automation testing refers to a test method wherein tools like Selenium, UFT, JMeter, LoadRunner, etc. are utilized to script (or record-&-play) the test cases which can then be run by the computer at any time. The advantage – why waste manual efforts on tests which are frequently repeated (i.e. regression tests). Additionally automated tests can be executed on different machines with different OS platform combinations, concurrently. The catch – requires programming skills 😛

Note: Most projects will have a hybrid approach utilizing Manual tests for functional testing & automation for regression testing. In fact, both testing techniques are 100% necessary and complement each other in multiple ways. Though automation testing cannot ever replace manual testing, but the focus is now shifting towards professionals with both manual + automation experience.

As you might have guessed, there are multiple factors involved before deciding on the Test method – application type, resource expertise, budget & time constraints, client expectations, Project risks, etc.

Hope you got a fair idea about different testing approach / methods. Don’t worry we will have separate discussions on these aspects in our future articles. Till then, subscribe to STS to get all the latest articles directly in your Inbox!

Happy Testing!!

Save

Save

Save

Save

Save

Save

Save

Save

One thought on “Different means to Test | What’s your Testing approach or method?”

Leave a Reply

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