9 ways to Reduce Software Development Cost

We know that project cost can be reduced if there is low number of Bugs/Changes as well as if these bugs/changes can be detected early in S/W Development Life Cycle. This topic talks about how we can reduce the number of bugs passed to testing team from development team.
During the development, one should not surprise seeing the bugs. They are byproduct of entire development cycle. Bugs cause rework which consequently increases the cost of the project as well as schedule.  This topic is about save rework and reduces cost of the software.

Though bug free system cannot be developed in a multimember team but the number of bugs found during the testing and production can be reduced by detecting the bugs early, before releasing the Build to testing team.

Adding the below mentioned activities in your development and testing cycle will definitely help in reducing the project cost as well as help in quality delivery. You may get an impression that most of the activities are suggested for developers. Let me clarify that as they are the people

  1. Right Process and Right Tools: Implement the right lightweight processes since beginning of the software development. Anything which has to be done repetitively, automate it.
  2. Clarify Assumptions: For all functionality, if there are any assumptions are made, clarify them with client, test engineers, Business analyst and other stake holders.Actor (Development and Testing Team)
    Why: Impact of declination of an assumption later will cause rework in either design, coding, testing or in all phases.
  3. During the implementation, if you are considering any behavior as implicit, obvious, or understood, then better to document/communicate it and verify with stakeholders.
    Actor (Development Team/Test Engineers)
    Why: It will help in developing what is required by customer rather than investing time in development of features which is luxury to have but not required.
  4. Test Engineers should develop test cases component wise and release them to Development team asap for Review (Design phase is recommended).
    Actor (Testing Team/Development Team)
    Why: Developer understands what test engineer is going to test beforehand including special cases. Also another advantage is that most of the test cases are User’s action on system; hence the usability and interface problems can be detected during design and coding.
  5. Each developer should Review the test cases related to his component. Test engineers should add missing test cases as detected by development team.
    Actor (Development Team/Testing Team)
    Why: To learn more about the functionality. Also it will expose the understanding gaps between Development and Testing team. This activity needs more time to be allocated to development team. Remember cost of bug is low in early phases of development.
  6. Unit Testing: It will help in identifying the issues, which may be missed by Blackbox test engineers.
    Actor (Development Team/Testing Team (white box testing experts))
  7. Testing team should develop a set of test cases called ‘Development Smoke Test cases’. Development team should execute the ‘Development Smoke Test cases’ before releasing build to Testing Team.
    Actor (Development Team/Testing Team)
    Why: There are cases where build gets rejected by QA in their smoke testing because of broken major features. Development/Testing team has to do rework.
  8. Find the Test cases effectiveness. How?, check how many bugs can be mapped to test cases. If the effectiveness is <80%, review the test cases development approach of testing team.
    Actor (Testing Team)
    WHY: All stakeholders are relying on testing team’s test cases to detect the bugs. Find technique to improve the testing effectiveness. (See my blogs on this topic).
  9. Configuration Testing and Load Testing should be done asap as later detection of performance issues does not leave enough time to do something substantive.
Advertisements

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.

exlWorkSheet.addCell(cellContent);

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

exlWorkBook.write();

//Close the workbook

exlWorkBook.close();

}//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

1)

Data Integrity

1

Is the complete data in the database is stored in tables

2

Is the data well logically organized

3

Is the data stored in tables is correct

4

Is there any unnecessary data present

5

Is the data present in the correct table

6

Is the data present in correct field within the table

7

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

8

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

 

 

2)

Field Validations

1

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

2

Is ‘Null’ as value not allowed in database

3

Is Field not mandatory while allowing NULL values on that field

4

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

5

Is the length of each field of sufficient size

6

Is the Data type of each field is as per specifications

7

Does all similar fields have same names across tables

8

Is there any computed field in the Database

 

 

3)

Constraints

1

Is required Primary key constraints are created on the Tables

2

Is required Foreign key constraints are created on the Tables

3

Are valid references are done for foreign key

4

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

5

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

6

Does Foreign key contains only not NULL values

 

 

4)

Stored Procedures/ Functions

1

Is proper coding conventions followed

2

Is proper handling done for exceptions

3

Are all conditions/loops covered by input data

4

Does TRIM is applied when data is fetched from Database

5

Does executing the Stored Procedure manually gives the correct result

6

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

7

Does execution of the Stored Procedure fires the required triggers

8

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

9

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

10

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

 

 

5)

Triggers

1

Is proper coding conventions followed in Triggers

2

Are the triggers executed for the respective DML transactions

3

Does the trigger updates the data correctly once executed

 

 

6)

Indexes

1

Are required Clustered indexes created on the tables

2

Are required Non Clustered indexes created on the tables

 

 

7)

Transactions

1

Are the transactions done correct

2

Is the data committed if the transaction is successfully executed

3

Is the data rollbacked if the transaction is not executed successfully

4

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

5

Are all the transactions executed by using TRANSACTION keyword

 

 

8)

Security

1

Is the data secured from unauthorized access

2

Are different user roles created with different permissions

3

Do all the users have access on Database

 

 

9)

Performance

1

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

2

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

3

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

4

Is Performance Profiling done

5

Is Performance Benchmarking done

6

Is Query Execution Plan created

7

Is Database testing done when server is behind Load Balancer

8

Is Database normalized

 

 

10)

Miscellaneous

1

Are the log events added in database for all login events

2

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

3

Does scheduled jobs execute timely

4

Is Test Data Dev Tool available

 

 

11)

SQL Injection

1

Is the Query parameterized

2

Does URL contain any query details

 

 

12)

Backup and Recovery

1

Is timely backup of Database taken

 

 

Database Testing; need for quality product

Database Testing for Quality Products

Until few years back, database testing was done by developers, who also develop the database objects. However, as the complexity of the database increasing, there is a demand of the dedicated test engineer for database who can do the testing as a Black box as well as white box tester. Database testing is important, considering the fact that a business application is about capturing users’ inputs, process them, and save the transactional data back in the database.

There is a need for the test engineers who can test the database’s objects to ensure the early detection of the issues. Considering the importance of the database testing, Database Test plan is now created separately.  A database test plan covers two aspects of the database, black box and white box.

Black box:

Verify the database schema as per the ER diagram.

White box testing:

Unit testing of database object such as Stored procedure, functions etc.

Performance Tuning

Optimization of queries, Query Execution plans, stored procedures, functions.

Orthogonal Array: High Test Coverage at low cost and efforts

The Orthogonal Array (OA) 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 OA technique, 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, OA technique 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 provide 100% coverage of pair combinations, 33% of three way combinations, 11% of four way combinations. Further to reduce the test condition, OA technique can be used on three way and four way combinations.

Use of OA 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 Long Term Health Care, OA techniques reduced the potential test cases from approx. 3592 to 1151 i.e. reduced by 68%. Test cycle efforts were reduced from 89 to 29 person days.

Testing team implemented the OA technique on the target system module wise. Testing team listed down the all the test conditions and then broke all the test conditions (if possible) in to the smaller condition where each condition can be tested with a pair of variables. This activity resulted in one OA of for each module. Depending on the count of variables and input values, the size of each OA was different.