44 seconds, to check if you are an Agile team

Does having Daily stand up, Planning, and Retrospective meeting ceremonies, make a Team agile.

Just spent few seconds to respond 11 quick check points, to find out if you are an Agile team. If your response is NO for any question, then you may like to reconsider your claim of being Agile.


Quick Check Items

Your Response (Yes/No)

1 Do the team members have direct access to the Product owner?  
2 Do the Team members know the team’s velocity?  
3 Do the Team member estimate the User Stories without influence of the supervisors?  
4 Do the Team members help each other?  
5 Do the Team members respect viewpoint and skills of other team members?  
6 Do the Team members have courage to accept the mistakes without fear?  
7 Does the Iteration (sprint) size fall below 6 weeks?  
8 Does the Team improve and tracks the action items determined in the Retrospective meeting  
9 Does the Team use various Burn down charts?  
10 Is the Team empowered to push back the change in the scope during the iteration?  
11 Are Items in Product backlog prioritized by their business value?  

These 11 questions look at the existing process from different perspective to evaluate the agility. Leave your comments if you have experience in working with Agile teams.


15 point tests for Browser Compatiability

This blog may be useful for you if  you have encountered that your team: is getting Production bug reproducible on specific browser(s) has missed important Browser Compatibility test cases is new to Browser compatibility has to ensure testing coverage on … Continue reading

Want to save Testing Time: Go for Orthogonal Array

The Orthogonal Array testing technique is a statistical way of reducing the test cases by removing redundant test conditions. A software system works on large number of interactions and integrations. It is very difficult to find out the erring interaction/integrations which the It is observed that major source of the bugs are interactions and integrations.

The bugs in the software are usually caused by a specific Condition independent of other conditions in the system. A condition is a set of conditions or variables, configurations, and logical linking of variables.

Think about testing a simple system, which has four variables and each variable can have 3 inputs. We need 81 cases (3x3x3x3) to test each pair of this system. If we use the orthogonal array techniques, we will have only 9 cases to test the system where all the pair-wise combination will be validated. It will unearth the combination which is causing the failure in the system.

In the above case, Orthogonal Array techniques has reduced the test condition by 89%, i.e. now with 11% of existing test cases all the variable pairs are validated. Interestingly, it will will provide 100% coverage of pair combinations, 33% of three way combinations, 11% of four way combinations. Further to reduce the test condition, orthogonal technique can be used on three way and four way combinations.

Use of Orthogonal array techniques will ensure

  • All the pair-wise combinations of the selected variables are validated.
  • An effective test set containing with fewer test cases
  • Lowers the cost of testing as test cycles are shorter

For one of the client, which is Leader in the Video communications, orthogonal array techniques reduced the test cases from 8171 to 2614 i.e. reduced by 68%. Test cycle efforts were reduced from 164 to 55 person days.

How to Save Cost of Testing by Tests Reusability

Reduce Investment planned for Testing by Tests Reusability

In software test life cycle (STLC), among various phases, test case development is most critical and consumes considerable portion of the time, allocated for testing. While working on various projects, my target was to write optimized number of effective test cases.  During each product/project I tested, I used to feel that I have executed the similar tests in the earlier assignments. I am sure you might also have observed, that you are sometime writing the test cases, which you have already written for some other project/product.

Let me explain with an example of Login, whether you are in Finance, health care or CRM domain, test engineer has to write almost similar cases with few more addition or deletion. Also, as a Supervisor, you might have observed that on many occasions your team missed potential test cases; reason could be the time crunch, skill, experience ….. Usually Test case effectiveness is dependent on individual’s skills.  Supervisor faces bigger challenges on estimating the count of test cases to be written as it will provide the basis for test execution time. Also they face challenge to ensure their team is not missing potential test cases as well as spending effort to write quality test cases instead of redundant and exhaustive test cases. I experienced that my various teams used to find many potential test cases during the test execution and add them to the test suite later.

How is the idea if a Team

  • Can estimate testing efforts close to reality
  • Saves investments by shortening the Testing life cycle
  • Instead of investing efforts in writing test cases from scratch, choosing test cases from an organized test cases repository
  • Can verify the completeness of their Tests by checking them against predefined set of cases
  • Can shorten the Test cases Review cycle
  • Ensure the completeness of Test suite
  • deliver quality product by ensuring no missing test cases

Now, how to implement the Test reusability and ensure the completeness of test cases.  I am writing on these topic too. Will publish them soon.

Selenium-WebDriver Code to Write in an excel file

// Before executing this program, create an XLS file, testExcel.xls in D drive


import java.io.FileOutputStream;

import java.io.IOException;

import jxl.Workbook;

import jxl.read.biff.BiffException;

import jxl.write.WritableWorkbook;

import jxl.write.WritableSheet;

import jxl.write.Label;

import jxl.write.WriteException;

public class Sample{

public static void main(String[] args) throws IOException, WriteException, BiffException{

//Declare the name of the Excel file

FileOutputStream exlFileName= new FileOutputStream(“D:\\testExcel.xls”);

//making the instance of a Writable Excel workbook and giving it a Name

WritableWorkbook exlWorkBook = Workbook.createWorkbook(exlFileName);

//Creating Writable worksheets in the writable workbook

WritableSheet exlWorkSheet = exlWorkBook.createSheet(“sheet num 0”, 0);

//Creating content for a cell in the excel workbook

Label cellContent = new Label(0,0,”at 0,0 the Content is : good”);

//Adding a cell and inserting content in the cell.


//Confirm the writing in the excel i.e. Write in the excel workbook.


//Close the workbook


}//eof main

}//eof class

Quality Test cases results in quality Deliveries

Test Cases development is one of the most important activities in the Testing life cycle. Test cases development strategy changes depending upon the type of project, schedule, and input domain. Another challenge for the test engineers to write the effective test cases. First step during the test cases development is to find type of users. Choose those who are going to test the Target Test Item (TTI) using test data

While developing test cases, if we keep in mind the following items, the rework on test cases will be lesser and quality of test cases will be much better.

  • Understand the requirement well. How please refer my blog on Requirement understanding.
  • Find out the type of application and its module:
  • Input Centric application/module: where user has to enter lots of data
  • Querying centric application/module: User has to raise query, such as Reporting modules.
  • Domain Understanding: Learn about domain, it will help in finding gaps.
  • Make control flow on paper:

¨       These graphs need not to follow any conventions. They are only three components in the diagram. One directional line (arrow) to show the direction of control movement, Boxes to show Outputs, line between two boxes used for describing step or input data. We are drawing our understanding on paper. They are just showing the movement of Control from one step to another, information being generated at each step, data inputted at each step.

  • Scenarios development:

¨       Now with the help of control flow, draw scenarios. One scenario is a set/group of test cases, which are verifyin an aspect of System under test. Such as for a scenario “Invalid Login not allowed”, following are test cases,

  • Invalid User name and Valid Password will not be allowed to login.
  • Invalid User name and InValid Password will not be allowed to login.
  • Valid User name and InValid Password will not be allowed to login.

¨       Once the scenarios are ready, develop test cases. You may add/delete/modify the Scenarios, as your test cases development progresses as understanding of system, may require the re-organization.

Test cases development sequence: Develop the test cases in following sequence:

1. One Path Test cases.

Set of Test cases which will cover the functionalities of complete flow, such, from Login -> Searching an Item -> viewing its details -> Add to Shopping Cart -> Make Payment-> Log Out.

2. Alternate Path Test Cases

If you have written test cases for a flow of functionality, then find out the alternate way of performing same task.

3. Integration Test Cases:

Test cases for functionalities, where outcome of one functionality, is used by other. Such as After placing an order, the Order information is saved in database. Another functionality is try to fetch this information for print, query, modification.

4. Boundry test cases:

5. Write test cases for each input box.

6. Test cases to check the database length and length of data in input controls are same.

7. Use Orthogonal Array to reduce the Test cases and test data count.

Database Testing Checklist for test engineers

Some time back I thought to create a checklist for database testing to ensure we are covering every aspect in Testing. With the help of my colleagues, Neha and Ankit,we prepared this list. Add one more column to this list for the result of each check.


Database Testing Checklist


Check Point


Data Integrity


Is the complete data in the database is stored in tables


Is the data well logically organized


Is the data stored in tables is correct


Is there any unnecessary data present


Is the data present in the correct table


Is the data present in correct field within the table


Is the data stored correct with respect to Front End updated data


Is LTRIM and RTRIM performed on data before inserting data into database




Field Validations


Is ‘Allow Null’ condition removed at database level for mandatory fields on UI


Is ‘Null’ as value not allowed in database


Is Field not mandatory while allowing NULL values on that field


Is the Field length specified on UI same as field length specified in table to store same element from UI into database.


Is the length of each field of sufficient size


Is the Data type of each field is as per specifications


Does all similar fields have same names across tables


Is there any computed field in the Database






Is required Primary key constraints are created on the Tables


Is required Foreign key constraints are created on the Tables


Are valid references are done for foreign key


Is Data type of Primary key and the corresponding foreign key same in two tables


Does Primary key’s ‘Allow Null’ condition not allowed


Does Foreign key contains only not NULL values




Stored Procedures/ Functions


Is proper coding conventions followed


Is proper handling done for exceptions


Are all conditions/loops covered by input data


Does TRIM is applied when data is fetched from Database


Does executing the Stored Procedure manually gives the correct result


Does executing the Stored Procedure manually updates the table fields as expected


Does execution of the Stored Procedure fires the required triggers


Are all the Stored Procedures/Functions used by the application (i.e. no unused stored procedures present)


Does Stored procedures have ‘Allow Null’ condition checked at data base level


Are all the Stored Procedures and Functions successfully executed when Database is blank






Is proper coding conventions followed in Triggers


Are the triggers executed for the respective DML transactions


Does the trigger updates the data correctly once executed






Are required Clustered indexes created on the tables


Are required Non Clustered indexes created on the tables






Are the transactions done correct


Is the data committed if the transaction is successfully executed


Is the data rollbacked if the transaction is not executed successfully


Is the data rollbacked if the transaction is not executed successfully and multiple Databases are invlolved in the transaction


Are all the transactions executed by using TRANSACTION keyword






Is the data secured from unauthorized access


Are different user roles created with different permissions


Do all the users have access on Database






Does Database perform as expected (within expected time) when query is executed for less number of records


Does Database perform as expected (within expected time) when query is executed for large number of records


Does Database perform as expected (within expected time) when multiple users access same data


Is Performance Profiling done


Is Performance Benchmarking done


Is Query Execution Plan created


Is Database testing done when server is behind Load Balancer


Is Database normalized






Are the log events added in database for all login events


Is it verified in SQL Profiler that queries are executed only in Stored Procedures (i.e. no direct visible query in Profiler)


Does scheduled jobs execute timely


Is Test Data Dev Tool available




SQL Injection


Is the Query parameterized


Does URL contain any query details




Backup and Recovery


Is timely backup of Database taken