Types of Testing

Unit Testing

 

Unit testing of software applications is done during the development (coding) of an application. 

The objective of unit testing is to isolate a section of code and verify its correctness. In procedural programming a unit may be an individual function or procedure 

The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Unit testing is usually performed by the developer. 

 

Why do Unit Testing? Why it is important?

Sometimes software developers attempt to save time by doing minimal unit testing. This is a myth because skimping on unit testing leads to higher defect fixing costs during system testing, integration testing and even beta testing after the application is completed. Proper unit testing done during the development stage saves both time and money in the end. 

 

Unit testing in Software Testing Life Cycle

 

Building unit Test Cases

Unit testing is commonly automated, but may still be performed manually. The IEEE does not favor one over the other. A manual approach to unit testing may employ a step-by-step instructional document. 

Under the automated approach- 

· A developer could write another section of code in the application just to test the function. They would later comment out and finally remove the test code when the application is done.

· They could also isolate the function to test it more rigorously. This is a more thorough unit testing practice that involves copy and pasting the function to its own testing environment to other than its natural environment. Isolating the code helps in revealing unnecessary dependencies between the code being tested and other units or data spaces in the product. These dependencies can then be eliminated.

A coder may use a Unit Test Framework to develop automated test cases. Using an automation framework, the developer codes criteria into the test to verify the correctness of the unit. During execution of the test cases, the framework logs those that fail any criterion. Many frameworks will also automatically flag and report in a summary these failed test cases. Depending upon the severity of a failure, the framework may halt subsequent testing. 

 

Mock Objects

Unit testing relies on mock objects being created to test sections of code that are not yet part of a complete application. Mock objects fill in for the missing parts of the program. For example, you might have a function that needs variables or objects that are not created yet. In unit testing, those will be accounted for in the form of mock objects created solely for the purpose of the unit testing done on that section of code. 

 

Unit Testing Tools

There are several automated tools available to assist with unit testing. We will provide a few examples below: 

· Rational Software - Rational Software by IBM has a unit test feature known as "Rational Test Realtime". The software contains a complete range of testing tools for much more than just unit testing. It is used for Ada, Java, C and C++. It creates unit tests by reverse engineering the software.  Operating systems it supports include Windows, Linux, Solaris, HP-UX and AIX. Go to http://www-01.ibm.com/software/rational/ to learn more.

· JavaScript Assertion Unit- Also known as jsAsserUnit, this Freeware JavaScript unit testing tool can be used on any platform that supports JavaScript. It is available at http://jsassertunit.sourceforge.net/docs/index.html

· CUT - CUT is a Freeware unit test tool for C, C++ and Objective C. It is great for embedded software testing frameworks and desktop applications on Linux and Windows operating systems. Learn more at sourceforge.net by going to http://sourceforge.net/projects/cut/.

· Dotunit - Dotunit is a .net framework Freeware unit testing tool. Part of Junit on the Microsoft .net framework, Dotunit is used for automating unit testing on windows systems. This is another tool from sourceforge.net, so look for it at: http://dotunit.sourceforge.net/

Those are just a few of the available unit testing tools. There are lots more, especially for C languages and Java, but you are sure to find a unit testing tool for your programming needs regardless of the language you use.

 

Extreme Programming & Unit Testing

Unit testing in Extreme Programming involves the extensive use of testing frameworks. A unit test framework is used in order to create automated unit tests. Unit testing frameworks are not unique to extreme programming, but they are essential to it. Below we look at some of what extreme programming brings to the world of unit testing: 

· Tests are written before the code

· Rely heavily on testing frameworks

· All classes in the applications are tested

· Quick and easy integration is made possible

 Unit Testing Myth

· It requires time and I am always over-scheduled

· My code is rock solid! 

· I do not need unit tests. 

Myths by their very nature are false assumptions.  These assumptions lead to a vicious cycle as follows - 

  

Truth is Unit testing increase the speed of development. 

Programmers think that integration testing will catch all errors and do not unit test. Once units are integrated, very simple errors which could have very easily found and fixed in unit tested take very long time to be traced and fixed. 

 

Unit Testing benefits

· Developers looking to learn what functionality is provided by a unit and how to use it can look at the unit tests to gain a basic understanding of the unit API.

· Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly (i.e. Regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified and fixed.

· Due to the modular nature of the unit testing, we can tests parts of project without waiting for others to be completed.

Unit Testing Limitations

· Unit testing can't be expected to catch every error in a program. It is not possible to evaluate all execution paths even in the most trivial programs

· Unit testing by its very nature focuses on a unit of code. Hence it can't catch integration errors or broad system level errors.

It's recommended unit testing be used in conjunction with other testing activities. 

 

Unit testing best practices

· Unit Test cases should be independent. In case of any enhancements or change in requirements, unit test cases should not be affected.

· Test only one code at a time.

· Follow clear and consistent naming conventions for your unit tests

· In case of change in code in any module, ensure there is a corresponding unit test case for the module and the module passes the tests before changing the implementation

· Bugs identified during unit testing must be fixed before proceeding to the next phase in SDLC

· Adopt a "test as your code" approach. The more code you write without testing the more paths you have to check for errors.

Summary 

As you can see, there can be a lot involved in unit testing. It can be complex or rather simple depending on the application being tested and the testing strategies, tools and philosophies used. Unit testing is always necessary on some level. That is a certainty. 

Integration Testing: Must Know Stuff! 

Definition and Terminologies:

In Integration Testing, individual software modules are integrated logically and tested as a group.

A typical software project consists of multiple software modules, coded by different programmers.  Integration testing focuses on checking data communication amongst these modules.

Hence it is also termed as 'I & T' (Integration and Testing), 'String Testing' and sometimes 'Thread Testing'.

Need of Integration Testing:

Although each software module is unit tested, defects still exist for various reasons like

· A Module in general is designed by an individual software developer whose understanding and programming logic may differ from other programmers. Integration testing becomes necessary to verify the software modules work in unity

· At the time of module development, there are wide chances of change in requirements by the clients. These new requirements may not be unit tested and hence integration testing becomes necessary.

· Interfaces of the software modules with the database could be erroneous

· External Hardware interfaces, if any, could be erroneous

· Inadequate exception handling could cause issues.

Integration Test Case:

Integration Test case differs from other test cases in the sense it focuses mainly on the interfaces & flow of data/information between the modules. Here priority is to be given for the integrating links rather than the unit functions which are already tested.

Sample Integration Test Cases for the following scenario:Application has 3 modules say 'Login Page', 'Mail box' and 'Delete mails' and each of them are integrated logically.

Here do not concentrate much on the Login Page testing as it's already been done in Unit Testing. But check how it's linked to the Mail Box Page.

Similarly Mail Box: Check its integration to the Delete Mails Module.

Test Case ID	Test Case Objective	Test Case Description	Expected Result
1	Check the interface link  between the Login and  Mailbox module	Enter login credentials  and click on the Login  button	To be directed  to the Mail Box
2	Check the interface link  between the Mailbox and  Delete Mails Module	From Mail box select the  an email and click delete  button	Selected email  should appear in  the Deleted/Trash  folder

 

 

Approaches/Methodologies/Strategies of Integration Testing:

The Software Industry uses variety of strategies to execute Integration testing , viz.

·  Big Bang Approach :

·  Incremental Approach: which is further divided into following 

o  Top Down Approach

o  Bottom Up Approach

o  Sandwich Approach - Combination of Top Down and Bottom Up

Below are the different strategies, the way they are executed and their limitations as well advantages.

 

Big Bang Approach:

Here all component are integrated together at once, and then tested.

Advantages:

· Convenient for small systems.

Disadvantages:

· Fault Localization is difficult.

· Given the sheer number of interfaces that need to be tested in this approach, some interfaces links to be tested could be missed easily.

· Since the integration testing can commence only after "all" the modules are designed, testing team will have less time for execution in the testing phase.

· Since all modules are tested at once, high risk critical modules are not isolated and tested on priority. Peripheral modules which deal with user interfaces are also not isolated and tested on priority.

 

Incremental Approach:

In this approach, testing is done by joining two or more modules that are logically related. Then the other related modules are added and tested for the proper functioning. Process continues until all of the modules are joined and tested successfully.

This process is carried out by using dummy programs called Stubs and Drivers. Stubs and Drivers do not implement the entire programming logic of the software module but just simulate data communication with the calling module.

Stub: Is called by the Module under Test.

Driver: Calls the Module to be tested.

Incremental Approach in turn is carried out by two different Methods:

· Bottom Up 

· Top Down

 

Bottom up Integration

In the bottom up strategy, each module at lower levels is tested with higher modules until all modules are tested. It takes help of Drivers for testing

Diagrammatic Representation:

Advantages:

· Fault localization is easier.

· No time  is wasted waiting for all modules to be developed unlike Big-bang approach

Disadvantages:

· Critical modules (at the top level of software architecture) which control the flow of application are tested last and may be prone to defects.

· Early prototype is not possible

 

Top down Integration:

In Top to down approach, testing takes place from top to down following the control flow of the software system.

Takes help of stubs for testing.

Diagrammatic Representation:

Advantages:

· Fault Localization is easier.

· Possibility to obtain an early prototype.

· Critical Modules are tested on priority; major design flaws could be found and fixed first.

Disadvantages:

· Needs many Stubs.

· Modules at lower level are tested inadequately.

 

Integration Testing Procedure

The integration test procedure irrespective of the test strategies (discussed above):

1. Prepare the Integration Test Plan

2. Design the Test Scenarios, Cases, and Scripts.

3. Executing the test Cases followed by reporting the defects.

4. Tracking & re-testing the defects.

5. Steps 3 and 4 are repeated until the completion of Integration is successfully.

 

Brief Description of Integration Test Plans:

It includes following attributes:

· Methods/Approaches to test (as discussed above).

· Scopes and Out of Scopes Items of Integration Testing.

· Roles and Responsibilities.

· Pre-requisites for Integration testing.

· Testing environment.

· Risk and Mitigation Plans.

 

Entry and Exit Criteria.

Entry and Exit Criteria to Integration testing phase in any software development model

Entry Criteria:

· Unit Tested Components/Modules

· All High prioritized bugs fixed and closed

· All Modules to be code completed and integrated successfully.

· Integration test Plan, test case, scenarios to be signed off and documented.

· Required Test Environment to be set up for Integration testing

Exit Criteria:

· Successful Testing of Integrated Application.

· Executed Test Cases are documented

· All High prioritized bugs fixed and closed

· Technical documents to be submitted followed by release Notes.

 

Best Practices/ Guidelines for Integration Testing

· First determine the Integration Test Strategy that could be adopted and later prepare the test cases and test data accordingly.

· Study the Architecture design of the Application and identify the Critical Modules. These need to be tested on priority.

· Obtain the interface designs from the Architectural team and create test cases to verify all of the interfaces in detail. Interface to database/external hardware/software application must be tested in detail.

· After the test cases, it's the test data which plays the critical role.

· Always have the mock data prepared, prior to executing. Do not select test data while executing the test cases.

What is System Testing? 

In the world of software testing, system testing is the testing of a complete and fully integrated software product.

Usually software is only one element of a larger computer based system. Ultimately, software is interfaced with other software/hardware systems. System testing is actually a series of different tests whose sole purpose is to exercise the full computer based system.

System testing falls under the black box testing category of software testing. White box testing is the testing of the internal workings or code of a software application. In contrast, black box or system testing is the opposite.System testing involves the external workings of the software from the user's perspective.

What do you verify in System Testing ?

 System testing involves testing the software code for following

· Testing the fully integrated applications  including external peripherals in order to check how components interact with one another and with the system as a whole. This is also called End to End scenario testing..

· Verify thorough testing of every input in the application to check for desired outputs.

Testing of the user's experience with the application. . 

That is a very basic description of what is involved in system testing. You need to build  detailed test cases and test suites that test each aspect of the application as seen from the outside without looking at the actual source code. 

 

The Software Testing Hierarchy

As with almost any technical process, software testing has a prescribed order in which things should be done. The following is a list of software testing categories arranged in chronological order. These are the steps taken to fully test new software in preparation for marketing it:

· Unit testing -testing performed on each module or block of code during development. Unit testing is normally done by the programmer who writes the code.

· Integration testing -testing done before, during and after integration of a new module into the main software package. This involves testing of each individual code module. One piece of software can contain several modules which are often created by several different programmers. It is crucial to test each module's effect on the entire program model.

· System testing -testing done by a professional testing agent on the completed software product before it is introduced to the market.

· Acceptance testing -beta testing of the product done by the actual end users.

 

Types of System Testing

There are more than 50 types of System Testing. For an exhaustive list of software testing types click here. Below we have listed types of system testing a large software development company would typically use

1. Usability Testing - Usability testing mainly focuses on the user's ease to use the application, flexibility in handling controls and ability of the system to meet its objectives

2. Load Testing - Load testing is necessary to know that a software solution will perform under real life loads.

3. Regression Testing - Regression testing involves testing done to make sure none of the changes made over the course of the development process have caused new bugs. It also makes sure no old bugs appear from the addition of new software modules over time.

4. Recovery Testing - Recovery testing is done to demonstrate a software solution is reliable, trustworthy and can successfully recoup from possible crashes.

5. Migration Testing - Migration testing is done to ensure that the software can be moved from older system infrastructures to current system infrastructures without any issues.

6. Functional Testing - Also known as functional completeness testing, functional testing involves trying to think of any possible missing functions. Testers might make a list of additional functionalities that a product could have to improve it during functional testing.

7. Hardware/Software Testing - IBM refers to Hardware/Software testing as "HW/SW Testing". This is when the tester focuses his/her attention on the interactions between the hardware and software during system testing.

 

What Types of System Testing Should Testers Use?

There are over 50 different types of system testing. The specific types used by a tester depend on several variables. Those variables include:

· Who the tester works for - This is a major factor in determining the types of system testing a tester will use. Methods used by large companies are different than that used by medium and small companies.

· Time available for testing - Ultimately, all 50  testing types could be used. Time is often what limits us to using only the types that are most relevant for the software project.

· Resources available to the tester - Of course some testers will not have necessary resources to conduct a testing type. For example if you are a tester working for a large software development firm, you are likely to have expensive automated testing software not available to others.

· Software Tester's Education - There is a certain learning curve for each type of software testing available. To use some of the software involved, a tester has to learn how to use it.

Testing Budget - Money becomes a factor not just for smaller companies and individual software developers but large companies as well. 

Smoke Vs Sanity Testing - Introduction and 

Differences 

Smoke and Sanity testing are the most misunderstood topics in Software Testing. There is enormous amount of literature on the subject, but most of them are confusing. The following article makes an attempt to address the confusion.

The key differences between Smoke and Sanity Testing can be learned with the help of following diagram -

To appreciate the above diagram, lets first understand -

what is a Software Build?

If you are developing a simple computer program which consists of only one source code file, you merely need to compile and link this one file, to produce an executable file. This process is very simple.
Usually this is not the case. A typical Software Project consists of hundreds or even thousands of source code files. Creating an executable program from these source files is a complicated and time-consuming task.
You need to use "build" software to create an executable program and the process is called "Software Build"

what is Smoke Testing?

 
Smoke Testing is performed after software build to ascertain that the critical functionalities of the program is working fine.It is executed "before" any detailed functional or regression tests are executed on the software build.The purpose is to reject a badly broken application, so that the QA team does not waste time installing and testing the software application.

In Smoke Testing, the test cases chosen cover the most important functionality or component of the system. The objective is not to perform exhaustive testing, but to verify that the critical functionalities of the system is working fine.
For Example a typical smoke test would be - Verify that the application launches successfully, Check that the GUI is responsive ... etc.

 

what is Sanity Testing?

After receiving a software build, with minor changes in code, or functionality, Sanity testing is performed to ascertain that the bugs have been fixed and no further issues are introduced due to these changes.The goal is to determine that the proposed functionality works roughly as expected. If sanity test fails, the build is rejected to save the time and costs involved in a more rigorous testing.

The objective is "not" to verify thoroughly the new functionality, but to determine that the developer has applied some rationality (sanity) while producing the software. For instance, if your scientific calculator gives the result of 2 + 2 =5! Then, there is no point testing the advanced functionalities like sin 30 + cos 50.

 

Smoke Testing Vs Sanity Testing - Key Differences

Smoke Testing	Sanity Testing
Smoke Testing is performed to  ascertain that the critical  functionalities of the program  is working fine	Sanity Testing is done to check the  new functionality / bugs have  been fixed
The objective of this testing is to  verify the "stability" of the system  in order to proceed with more  rigorous testing	The objective of the testing is to  verify the "rationality" of the  system in order to proceed with  more rigorous testing
This testing is performed by the  developers or testers	Sanity testing is usually performed  by testers
Smoke testing is usually  documented or scripted	Sanity testing is usually not  documented and is unscripted
Smoke testing is a subset of  Regression testing	Sanity testing is a subset of  Acceptance testing
Smoke testing exercises the entire  system from end to end	Sanity testing exercises only the  particular component of the entire  system
Smoke testing is like General  Health  Check Up	Sanity Testing is like specialized  health check up

 

Points to Note:-

· Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. 

· Sanity Testing is also called tester acceptance testing.

· Smoke testing performed on a particular build is also known as a build verification test.

· One of the best industry practice is to conduct a Daily build and smoke test in software projects.

· Both smoke and sanity tests can be executed manually or using an automation tool.  When automated tools are used, the tests are often initiated by the same process that generates the build itself.

· As per the needs of testing, you may have to execute both Sanity and Smoke Tests on the software build. In such cases you will first execute Smoke tests and then go ahead with Sanity Testing. In industry, test cases for Sanity Testing are commonly combined with that for smoke tests, to speed up test execution. Hence it's a common that the terms are often confused and used interchangeably

What is Regression Testing? 

The purpose of regression testing is to confirm that a  recent program or code change has not adversely affected existing features.

Regression testing is nothing but full or partial selection of already executed test cases which are re-executed to ensure existing functionalities work fine.

This testing is done to make sure that new code changes should not have side effects on the existing functionalities. It  ensures that old code still works once  the new code changes are done.

 

Need of Regression Testing

  

Regression Testing is required when there is a

· Change in requirements and code is modified according to the requirement

· New feature is added to the software

· Defect fixing

· Performance issue fix 

Regression Testing Techniques

Software maintenance is an activity which includes enhancements, error corrections, optimization and deletion of existing features. These modifications may cause the system to work incorrectly . Therefore , Regression Testing becomes necessary. Regression Testing can be carried out using following techniques:

                              

Retest All

· This is one of the methods for regression testing in which all the tests in the existing test bucket or suite should be re-executed. This is very expensive as it requires huge time and resources.

 

Regression Test Selection

· Instead of re-executing the entire test suite, it is better to select part of test suite to be run

· Test cases selected can be categorized as 1) Reusable Test Cases 2) Obsolete Test Cases.

· Re-usable Test cases can be used in succeeding regression cycles.

· Obsolete Test Cases can't be used in succeeding cycles.

 

Prioritization of Test Cases

· Prioritize the test cases depending on business impact, critical &  frequently used functionalities . Selection of test cases based on priority will greatly reduce the regression test suite.

Selecting test cases for regression testing

It was found from industry data that good number of the defects reported by customers were due to last minute bug fixes creating side effects and hence selecting the test case for regression testing is an art and not that easy.  Effective Regression Tests can be done by selecting following test cases -

· Test cases which have frequent defects

· Functionalities which are more visible to the users

· Test cases which verify core features of the product

· Test cases of Functionalities which has undergone more and recent changes

· All Integration Test Cases

· All Complex Test Cases

· Boundary value test cases

· Sample of Successful test cases

· Sample of Failure test cases

 

Regression Testing Tools

 If your software undergoes frequent changes , regression testing costs will escalate.

In such cases , Manual execution of test cases increases test execution time as well as  costs.

Automation of regression test cases is the smart choice in such cases.  

Extent of automation depends on the number of test cases that remain re-usable for successive regression cycles. 

Following are most important tools used for both functional and regression testing:

Quick Test Professional (QTP):HP Quick Test Professional is automated software designed to automate functional and regression test cases. It uses VbScript language for automation. It is a Data driven , Keyword based tool. 

Rational Functional Tester (RFT):IBM's rational functional tester is a java tool used to automate the test cases of software applications. This is primarily used for automating regression test cases and it also integrates with Rational Test Manager. 

Selenium:This is an open source tool used for automating web applications. Selenium can be used for browser based regression testing.

 

Regression Testing and Configuration Management

Configuration Management during Regression Testing becomes imperative in Agile Environments where code is being continuously modified. To ensure effective regression tests , observe the following :

· Code being regression tested should be under a configuration management tool

· No changes must be allowed to code , during the regression test phase.  Regression test code must be kept immune to developer changes.

· The database used for regression testing must be isolated . No database changes must be allowed

 

Difference between Re-testing and regression testing:

Retesting means testing the functionality or bug again to ensure the code is fixed. If it is not fixed, defect needs to be re-opened. If fixed, defect is closed.

Regression testing means testing your software application when it undergoes a code change to ensure that the new code has not affected other parts of the software.

 

Challenges in Regression Testing:

 Following are the major testing problems for doing regression testing:

· With successive regression runs, test suites become fairly large.  Due to time and budget constraints, the entire regression test suite cannot be executed

· Minimizing test suite while achieving maximum test coverage remains a challenge

· Determination of frequency of Regression Tests , i.e., after every modification  or every build update or after a bunch of bug fixes, is a challenge.

Conclusion:

An effective regression strategy, save organizations both time and money. As per one of the case study in banking domain,  regression saves upto 60% time in bug fixes(which would have been caught by regression tests) and 40%  in money              

What is Non-functional Testing? 

Like functional testing, there are non-functional requirements like performance, usability, load factor that are also important. 

Many times you have come across to long load time messages while accessing an application. 

To address this issue, performance testing is carried out to check & fine tune system response times. The goal of performance testing is to reduce response time to an acceptable level. Likewise, you might have seen the message like "Server Busy". Hence, load testing is carried out to check systems performance at different loads i.e. number of users accessing the system. 

Depending on the results and expected usage, more system resources may be added. In general there are three testing types 

· Functional 

· Non - Functional 

· Maintenance 

Under these types of testing, you have multiple TESTING Level's but usually people call them as Testing Types. You may find some difference in this classification in different resources as per the requirement, but the general theme remains the same. This is not the complete list as there are more than 150 types of testing types and still adding. No need to bother or worry, you will pick them up as you age in the testing industry. Also, note that not all testing types are applicable to all projects but depend on nature & scope of the project. More on this in a later tutorial.