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.

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 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)

Staticas 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.

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 :-)).

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!

Test Environment is nothing but a replica of actual production environment (being used by end-users) with close-enough hardware and software configurations, where the testing would happen for the developed application.

Independence & Freedom – everybody likes it. Wants it. Fights for it. And finally celebrates it. It gives you the objectivity to express your views & opinions. It is essential for a thriving society where the mind is without fear & the head is held high. As India celebrates its ‘Independence Day’ on August 15th, let’s see what it means for a Test team.

Are you a Manual Tester? A Test Lead? Good in people’s management? Or Planning? Whatever! You still need to know the basics of programming and automation tool. You need not be a framework-developer, but every organization now wants a Software Tester who knows both functional test + automation scripting!

The Defect Severity (Technical) - In simple words, how severe is the defect for the application’s quality? Say you click on the ‘Help’ link and the application crashes. Whoaa! Bing-Bang Craaaashh..! Quite a severe defect, right?

The Defect Priority (Business) - In simple words, what is the precedence, importance or urgency to fix a defect? Say you click on the ‘Help’ link and the application crashes. Whoaa! Bing-Bang Craaaashh..! Quite a severe defect, right? But how many of us really click the ‘Help’ link? Business usage statistics show less than 2%. Now what do you think should be the urgency to fix a defect that impacts just the 2% of the end-users? Yeah! Not ‘High’ obviously. There would be other urgent defects to fix prior to this. Defect Priority defines the order in which defects should be fixed, i.e. its impact to the end-users, the business perspective.

About STS

Software Testing Studio is an attempt to share some incredible knowledge from industry leaders & experts, which should be helpful for anybody to start his/her career in ‘Software Testing’ or to progress it further. Apart from the technical nitty-gritties, one can also find some intellectual posts by industry experts sharing their Wisdom.