Black Box Testing Techniques Part 2

Decision tables, state based

In this post, we will discuss about other black box testing techniques which are widely used  based on their need. The techniques are Decision tables, State based testing, Compatibility, User documentation and Domain testing.

State Transition:

The State or behavior of a System changes on interaction with other objects, testing this transition between states of an object or objects is ‘State Transition’.

Example :

Consider ATM machine and you want withdraw cash using debit/credit card.

  • If user enters wrong password–Applicaton will ask to re enter password.
  • If user enters wrong password second time, application will ask the user to re enter.
  • Third time if user enters wrong password –Card will get blocked.

so there will be 3 different phases of application which is nothing but state transition.

State Transition Based Technique

Advantages:
  • Designing of test cases becomes easy.
  • Transition issues which influence the end result can be easily found.
Disadvantages:
  • Small impact on business rules and test conditions.
  • Requires UML to be included in design phase.
Deriving test cases:
  • First test case is happy path, where the correct PIN is entered the first time.
  • Second test case (for every state) is  to enter an incorrect PIN each time, so that the system shows error message.
  • Third test case, the PIN was incorrect the first time but OK, the second time.
  • Then, test when the PIN was correct on the third attempt.

Decision Tables:

Decision table technique is used when different combination of inputs result in different actions. A decision table is useful when input and output data can be expressed as Boolean conditions like True, False, Valid, Invalid.

Example :

Consider Login application

  • If both the inputs are ‘Invalid’ then error message will be displayed.
  • Similarly, If either of the inputs are invalid, error message will be displayed.
  • When both inputs are ‘Valid’ then user will be logged in.

Hence, the combination of inputs are – ‘Input 1’ and ‘Input 2’ and Result is ‘Output’ .Number of possible Combinations is given by 2 ^ n , where n is  number of  Inputs. In the example the possible combinations are 2^2 = 4.


Decision table example

Observe that, the output of first three columns is same, so instead of testing all three combinations we can select 1 out of 3 and col 4 . This might seem easy because of lesser combinations.

But, For n = 12 , combinations will be 4096. WoW! how many days will it take to complete the combinations. So, using decision table technique we can select the subset of possible combinations instead of all 4096 as described in the above example.

Compatibility Testing:

Until now, We learnt about different techniques to test product requirements and features. when expected result matches the actual result, we called it as ‘Test case passed’.

But, results of the product delivered depends equally on the infrastructure used, such as:

  • Processor :  like Dual core, Core i3, Core i5, AMD  etc.
  • Architecture : 32 bit (x86) or 64 bit (x64)
  • RAM and Disk space :4 Gb, 500 Gb
  • Operating system (OS) : like XP, Win 7, Win 8, Linux, Mac
  • Compatibility of the peripherals : DVD drive, Printers, Network card
  • Database : Oracle, SQL Server, MySQL
  • Browser Compatibility : Chrome, Firefox, Internet explorer etc.

“The compatibility tests are performed to ensure that, the product built functions as expected with different infrastructure components”.

User Documentation Testing:

The end user is provided with user manuals, installation document, software release notes etc in order to understand the system.

The main objective of user documentation testing is :

  • To verify that the document is up to date with the software provided i.e, all the information is available.
  • To ensure that what is available in the product is explained correctly.

Simply, User Documentation  Product available and vice versa.

The amount of time and money spent on user documentation testing provides good results as these are the first documents that the user will look at before using the product. Also, defects found should be monitored and fixed.

The important rule to follow is to update these documents whenever there are updates and changes in the product.

Domain Testing:

White box testing is all about looking into the code and  black box is about testing without knowledge of internals of the system. Whereas, Domain testing is based on the domain knowledge, without looking into specifications of the system.

This type of testing requires business domain knowledge of the application rather than how the software works or how the software is coded. so, what is term ‘domain knowledge’?

Domain Knowledge:  Good understanding of the business flow and how it operates. for e.g, consider flipkart.com , The domain knowledge is all about knowing the process like : how products are placed, how they are operated, shipped, when customer places an order for a product like ‘Mobile Phone’ . Thus, domain testing is considered as the extension of Black box testing.

Communicating between end-users and software developers is often difficult. They must find a common language to communicate in. Generally, ‘Business Analysts’ (BA) are the one’s with expertise in respective domains.

Examples are : Banking domain, Warehouse Management System domain (WMS)E commerce domain (flipkart, amazon, jabong) etc.

Consider the example of ATM machine:
  1. Insert  ATM card.
  2. Enter PIN.
  3. Choose Account type.
  4. Enter amount.
  5. Take the cash.
  6. Exit and retrieve the card.
In this example tester is not concerned  about testing everything in the design; but  testing the business flow of the application.While testing we should consider all the steps mentioned above and also the missing steps like if required denominations can be withdrawn if available (part of testing only).

 

So, here we come to the end of black box testing techniques basics. In future posts we will discuss about advanced topics and real time application examples related to these techniques in detail.
[su_divider size=”1″]Divider[/su_divider]
References:
IEEE 829-2008, Standard for Software and System Test Documentation.
Software testing principles – srinivasan and gopalaswamy.
RBT overview-  Bender RBT.
Wikipedia.org.