Unit Testing versus Functional Testing

Unit Testing versus Functional Testing

Unit tests meant for a developer that the code is doing things right; functional tests meant for a developer that the code is doing the right things.

Unit Tests are written from a programmers perspective. They are made to ensure that a particular method (or a unit) of a class performs a set of specific tasks.

Functional Tests are written from the user’s perspective. They ensure that the system is functioning as users are expecting it to

Unit tests:

A unit is the smallest testable part of an application like functions, classes, procedures, interfaces. Unit testing is a method by which individual units of source code are tested to determine if they are fit for use.Unit tests are basically written and executed by software developers to make sure that code meets its design and requirements and behaves as expected.

The goal of unit testing is to segregate each part of the program and test that the individual parts are working correctly.This means that for any function or procedure when a set of inputs are given then it should return the proper values. It should handle the failures gracefully during the course of execution when any invalid input is given

Advantages of Unit testing:

1. Issues are found at early stage. Since unit testing are carried out by developers where they test their individual code before the integration. Hence the issues can be found very early and can be resolved then and there without impacting the other piece of codes.

2. Unit testing helps in maintaining and changing the code. This is possible by making the codes less interdependent so that unit testing can be executed. Hence chances of impact of changes to any other code gets reduced.

3. The cost of fixing a defect detected during unit testing is lesser in comparison to that of defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or when the software is live.Since the bugs are found early in unit testing hence it also helps in reducing the cost of bug fixes. Just imagine the cost of bug found during the later stages of development like during system testing or during acceptance testing.

4. Unit testing helps in simplifying the debugging process. If suppose a test fails then only latest changes made in code needs to be debugged.Debugging is easy. When a test fails, only the latest changes need to be debugged.

Functional tests:

Functional tests are conducted to ensure the system behaves according to the functional requirements.  Use cases are developed to validate that all functions outlined in the requirements are present in the system and work as intended.  This testing should not be performed by the people who built the system.

Functions (or features) are tested by feeding them input and examining the output. Functional testing ensures that the requirements are properly satisfied by the application. This type of testing is not concerned with how processing occurs, but rather, with the results of processing.

During functional testing, Black Box Testing technique is used in which the internal logic of the system being tested is not known to the tester.Functional testing is primarily is used to verify that a piece of software is providing the same output as required by the end-user or business. Typically, functional testing involves evaluating and comparing each software function with the business requirements. Software is tested by providing it with some related input so that the output can be evaluated to see how it conforms, relates or varies compared to its base requirements.


No matter how clever we are at building the projects we work on, no matter how flexible the systems are that we build, if what we produce isn’t usable, we’ve wasted our time. As a result, functional testing is the most important part of development.Because both types of tests are necessary, you’ll need guidelines for writing them.

What is GUI Testing and Most common GUI Test Cases for Web based Application

What is GUI Testing and Most common GUI Test Cases for Web-based Application:

There are two types of interfaces in a computer application.
1.Command Line Interface is where you type text and computer respond to that command.
2.GUI stands for Graphical User Interface where you interact with the computer using images rather than text.

The term “User Interface” refers to the methods and devices that are used to accommodate interaction between machines and the human beings, users, who use them. User interfaces can take on many forms, but always accomplish two fundamental tasks: communicating information from the product to the user, and communicating information from the user to the product.

The term “Graphical user interface”(GUI) is the layer where the digital product communicated with human and human communicated with the digital product. A well-designed product can fail with an unsuccessful interface. Conversely, a product has not good design values can become successful with its well-designed interface. To get the best interaction between digital product and user, the graphical interface design itself needs to have some design values and requires a systematic approach to the design process. But, to ensure optimum performance, it also requires a model of interaction to understand exactly what is going on in the interaction and identify the likely root of difficulties.

Following are the GUI elements which can be used for interaction between the user and application:

GUI testing involves checking the screens with the controls like menus, buttons, icons, and all types of bars – toolbar, menu bar, dialog boxes and windows, etc.

GUI Testing basically involves

1.Check the all required objects, elements, fields, buttons,labels and links are available
2.Check the URLs of the each page
3.check the page titles of the each page
4.Check all pages for broken links
5. All fields on pages (e.g. text box, radio options, drop-down lists) should be aligned properly with size, position, width, height of the elements.
6.Do buttons follow the project standards for size and position
7.Enough space should be provided between field labels, columns, rows, error messages etc.
8.All mandatory fields should be validated and indicated by asterisk (*) symbol
9.Validation error messages should be displayed properly at correct position
10.Input fields should be checked for maximum field value. Input values greater than specified max limit should not be accepted or stored in database
11.Confirmation messages should be displayed before performing any update or delete operation
12.Tooltip text should be meaningful.
13.1 Are the field backgrounds the correct color?
13.2 Are the field prompts the correct color?
13.3 Are the screen and field colors adjusted correctly for non-editable mode?
13.4 Are all the buttons are in standard format and size?
13.5 Is the general screen background the correct color?
13.6 Is the page background (color) distraction free?
13.7 Testing the colors of the error messages, warning messages and success messages displayed in different CSS styles for each.
14.1 Are all the screen prompts specified in the correct screen font?
14.2 Does content remain if you need to go back to a previous page, or if you move forward to another new page?
14.3 Is all text properly aligned?
14.4 Is the text in all fields specified in the correct screen font?
14.5 Is all the heading are left aligned
14.6 Font size, style and color for headline, description text and labels should be standard as specified in SRS and check the font whether it is readable or not.
14.7 Testing of the spelling, and ensure that you have test cases that look for grammar or spelling errors…
15.1 Are all graphics properly aligned?
15.2 Are graphics being used the most efficient use of file size?
15.3 Assure that buttons are all of similar size and shape, and same font & font size.
15.4 Banner style & size & display exact same as existing windows
15.5 Does text wrap properly around pictures/graphics?
15.6 Testing the alignment of the images and Check all pages for broken images.

16.1 Can all screens accessible via buttons on this screen be accessed correctly?
16.2 Does the Tab Order specified on the screen go in sequence from Top Left to bottom right? This is the default unless otherwise specified.
16.3 Is there a link to home on every single page?
16.4 When an error message occurs does the focus return to the field in error when the user cancels it?
16.5 Testing of the scrollbars according to the size of the page if any.
16.6 Pagination should be enabled when there are more results than the default result count per page
16.7 Check for Next, Previous, First and Last page pagination functionality

17.1 Are all the field prompts spelled correctly?
17.2 Are fonts too large or too small to read?
17.3 Can the typical user run the system without frustration?
17.4 Do pages print legibly without cutting off text?
17.5 Does the site convey a clear sense of its intended audience?
17.6 Does the site have a consistent, clearly recognizable “look-&-feel”?
17.7 Check the screen in different resolutions with the help of zooming in and zooming out like 640 x 480, 600×800, etc.
17.8 Testing whether the interface is attractive or not.
17.9 Does the system provide or facilitate customer service? i.e. responsive, helpful, accurate?
17.10 Is all terminology understandable for all of the site’s intended users?

Object Identification In Selenium

Object Identification In Selenium:

Object identification is a very crucial part of any automation effort be it in QTP, selenium or any other tool for that matter. So it makes it very important for each one of the automation folks around to be able to identify the objects used in the automation effort

Identifying Objects is Selenium (WebDriver) is pretty simple if you are working on an application built on Firefox, but it gets very tricky if you are working on IE application. So it would be best to master the object identification techniques.

If you have used the Selenium IDE for any recording you would have noticed that there are multiple ways of identifying an object. By default the Selenium IDE tries to recognize the object by the ID or name attribute. Selenium IDE identifies the objects by the attributes mentioned in the order below

Object identification is very important part of automation activity. So the automation people should be able to identify the objects for automation purpose.

For identifying these objects Selenium uses a concept of ‘Locators’. These locators are used to identify the objects which are mostly used while automating the test cases using Selenium.

Locators: There are number of locators present. These are among them.

  •  ID
  •  Name
  •  Link Text
  •  CSS Selector
    Tag and ID
    Tag and class
    Tag and attribute
    Tag, class, and attribute
    Inner text
  •   DOM (Document Object Model)
    dom: index
  •  XPath

For testing different applications i.e. Application Under Test (AUT), we need to identify the object it is made of. All applications either it is Web Application or Desktop Application; it is consisting of different objects like below:

  • Button
  • Text Box
  • Link
  • Drop Down
  • Radio Button
  • List Box
  • Slider

Finding an element and confirming the expected result requires locators. Through locator, In Document Object Mode (DOM) i.e. webpage, we uniquely identify the object. The ‘By‘ class is used in WebDriver to locate the elements.

o identify the objects such as Links, Buttons, Edit boxes, Drop downs, etc on the application Selenium uses a concept called “Locators”. There are around 8 different types of locators. Out of them, I will be explaining only four as they are widely used while automating the test cases using Selenium.

1. id = id – By default Selenium IDE takes “id” as Locator Every Web Page will be having some HTML Source code. This can be viewed using “View –> Page Source / View source” on the browser. In the following picture we can see “id” attribute of a HTML tag is used as a locator to identify an object.

2. name = name (Second locator) We will do the following steps to understand how exactly Selenium identifies the objects

3. xpath = xpathExpression. Xpath is used as a Locator to identify an object. This is an expression which is formed by combining various HTML tags. For example: //a[contains(text(),’VRL travels’)], //div[@id=’shortcuts’]/span/span[2]/a/span

4. link=link text (in HTML source we can located this using “href” tag)

Here XPath and CSS are the most widely used locators.

It is very easy to identify the object of the application which is built on Firefox but same on the other way if that application is made on IE browser then it is pretty difficult to identify the object.

There are different tools available to identify the objects on different browsers like Firefox/Chrome/IE etc.

If we are using Selenium IDE there are different ways to identifying the objects. By default Selenium identify the object using ‘ID’ or ‘Name’.

Here I have taken the example of ‘Flipkart’ home page. Here for search text box on Flipkart home page the recording is done through Selenium IDE. We can see here the order of identification of text box via different locators as above.

We can see the code of above recording. For each locator the code will look like as below:

1. driver.findElement(By.id(“fk-top-search-box”)).click();
2 driver.findElement(By.name(“q”)).click();
3. driver.findElement(By.cssSelector(“#fk-top-search-box”)).click();
4. driver.findElement(By.xpath(“//input[@id=’fk-top-search-box’]”)).click();
5. driver.findElement(By.xpath(“//form[@id=’fk-header-search-form’]/div/div/div/input”)).click();
6. driver.findElement(By.xpath(“//form/div/div/div/input”)).click();

6 Tools to Help You with Object Recognition

Using one the six tools

  1. Firefox – Selenium IDE
  2. Firefox – Firebug
  3. Firefox – Firepath
  4. Google Chrome Developer Tools
  5. IE Developer tool bar
  6. fire-ie-selenium
  7. XPath Checker
  8. Fire Finder

Importance of Bug Life Cycle in Software Testing

Importance of Bug Life Cycle in Software Testing


Mistakes lead to the introduction of defects (also called bugs).  like all human beings I can make mistakes at any point in time, no matter what I might be working on. So it is on projects, where the business analyst can put a defect into a requirements specification, a tester can put a defect into a test case, a programmer can put a defect into the code, a technical writer can put a defect into the user guide, and so forth. Any work product can and often will have defects because any worker can and will make mistakes! Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software.

Bug Life Cycle:

In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. It starts when defect is found and ends when a defect is closed, after ensuring it’s not reproduced.Below find the various states that a defects goes through in its life-cycle. The number of states that a defect goes through varies from project to project. Below life-cycle, covers all possible states.



  1. New: When a defect is logged and posted for the first time. It is assigned a status NEW.
  2. Assigned: After the tester has posted the bug, the lead of the tester approves that the bug is genuine and he assigns the bug to corresponding developer and the developer team. It’s state given as Assigned.
  3. Open:  At  this state the developer has started analyzing and working on the defect fix.
  4. Fixed:  When developer makes necessary code changes and verifies the changes then he can make bug status as ‘Fixed’ and the bug is passed to testing team. 
  5. Retest:  At this stage the tester does the retesting of the code at this stage to check whether the defect is fixed by the developer or not and change the status to “Re-test.”
  6. Verified/Resolved:  The tester tests the bug again after it got fixed by the developer. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “verified/Resolved”.
  7. Reopen:  If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “reopened”. Once again the bug goes through the life cycle.
  8. Closed:  Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “closed”. This state means that the bug is fixed, tested and approved.
  9. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “duplicate”
  10. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “rejected”.If the developer feels the defect is not a genuine defect 
  11. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.If the present bug is not of a prime priority and if it is expected to get fixed in the next release, then status “Deferred” is assigned to such bugs
  12. Not a bug:  The state given as “Not a bug” if there is no change in the functionality of the application. For an example: If customer asks for some change in the look and field of the application like change of colour of some text then it is not a bug but just some change in the looks of the  application.If it does not affect the functionality of the application then the status assigned to a bug is “Not a bug”.
  13. Known bug:These are problems known to exist at the time of this (Current)release.It is same as Deferred status.

While defect prevention is much more effective and efficient in reducing the number of defects, most organization conducts defect discovery and removal.The challenges of following a bug life cycle are far outweighed by the benefits derived. A well planned and closely managed defect database not only tracks current defects against any number of builds and/or products, it also provides a virtual paper trail for the overall progress of a product as it is coded, tested, and released. If sufficient time is provided for building a defect tracker that works for your company, it is more likely you will release a less buggy product, or at least a product where most of the big ones have not gotten away

Verification and Validation in Software testing

 Verification and Validation in Software testing

Before getting into the various strategies of testing we must understand the process of verifying and validating the software code. Verification and validation is the generic name given to checking processes which ensure that the software conforms to its specification and meets the needs of the customer.

The system should be verified and validated at each stage of the software development process using documents produced in earlier stages. Verification and validation thus starts with requirements gathering phase and continues through design and code(development) reviews to product testing.

Verification will help to determine whether the software is of high quality, but it will not ensure that the system is useful.For example, You are testing an application. The system requirements say there is a field with max Length of 64 characters and Save button. The Use case says that the User will fill the name and save.When checking the presence of the field and the Save button, it is verification. When you follow the use case to use 64 characters, it is validation.

Suppose we have the specifications related to the project than by checking that specifications without executing to see whether the specifications are up to the mark or not is what we have done in verification.Similarly, Validation of the software is done to make sure that the software always meets the requirements of the customer by executing the specifications of the project and product.

Validation: The process of evaluating software during or at the end of the development process to determine whether it satisfies specified requirements.

validation:this is dynamic testing where we have to check the whole software whether its is meeting all required need of customer.

What is Verification?
Verification is a process of evaluating the intermediary work products of a software development life-cycle to check if we are in the right track of creating the final product.

We sometimes tend to neglect the importance of reviewing the documents but we should understand that reviewing itself can find out many hidden anomalies when if found or fixed in the later phase of development cycle, can be very costly.
In other words we can also state that verification is a process to evaluate the mediator products of software to check whether the products satisfy the conditions imposed during the beginning of the phase.

What is Validation?
Validation is the process of evaluating the final product to check whether the software meets the business needs. In simple words the test execution which we do in our day to day life are actually the validation activity which includes smoke testing, functional testing, regression testing, systems testing etc…




Evaluates the intermediary products to check whether it meets the specific requirements of the particular phase

Evaluates the final product to check whether it meets the business needs.

Checks whether the product is built as per the specified requirement and design specification.

It determines whether the software is fit for use and satisfy the business need.

Checks “Are we building the product right”?

Checks “Are we building the right product”?

This is done without executing the software

Is done with executing the software

Involves all the static testing techniques

Includes all the dynamic testing techniques.

Examples includes:

  • Reviews
  • Walk through
  • Inspections

Example includes all types of testing like smoke, regression, functional, systems and UAT

Verification is the process of evaluating products of a development phase to find out whether they meet the specified requirements. Validation is the process of evaluating software at the end of the development process to determine whether software meets the customer expectations and requirements.
The objective of Verification is to make sure that the product being develop is as per the requirements and design specifications. The objective of Validation is to make sure that the product actually meet up the user’s requirements, and check whether the specifications were correct in the first place.
Following activities are involved inVerification: Reviews, Meetings and Inspections. Following activities are involved in Validation: Testing like black box testing, white box testing, gray box testing etc.
Verification is carried out by QA team to check whether implementation software is as per specification document or not. Validation is carried out by testing team.
Execution of code is not comes underVerification. Execution of code is comes under Validation.
Verification process explains whether the outputs are according to inputs or not. Validation process describes whether the software is accepted by the user or not.
Verification is carried out before the Validation. Validation activitis carried out just after the Verification.
Following items are evaluated duringVerification: Plans, Requirement Specifications, Design Specifications, Code, Test Cases etc, Following item is evaluated during Validation: Actual product or Software under test.
Cost of errors caught in Verification is less than errors found in Validation. Cost of errors caught in Validation is more than errors found in Verification.
It is basically manually checking the of documents and files like requirement specifications etc. It is basically checking of developed program based on the requirement specifications documents & files.

Conclusion Verification and Validation:

  • Facilitates early detection and correction of errors.
  • Encourages and enhances the management intervention and inside into process and product risks.
  • Provide supportive measures towards the software life-cycle process, to enhance compliance with schedule and budget requirements.
  •  Verification means the review activities or the static testing techniques and validation means the actual test execution activities or the dynamic testing techniques.
  • Both are used to finds a defect in different way, Verification is used to identify the errors in requirement specifications & validation is used to find the defects in the implemented Software application.


STLC (Software Test Life Cycle)

STLC (Software Test Life Cycle)

Life-cycle in simple term refers to the sequence of changes from one form to other form. These changes can happen to any tangible or intangible things. Every entity has a life-cycle from its inception to retire / demise.In a similar fashion, Software is also an entity. Just like developing software involves a sequences of steps, testing also has steps which should be executed in a definite sequence.This phenomenon of executing the testing activities in a systematic and planned way is called testing life cycle.

The process of testing a software in a well planned and systematic way is known as software testing life cycle(STLC).Different organizations have different phases in STLC however generic Software Test Life Cycle (STLC) for waterfall development model consists of the following phases.

1. Requirements Analysis
2. Test Planning
3. Test Scenarios and Test Cases Development
4. Test Environment Setup
5. Test Execution and Bug Reporting
6.Test Cycle Closure

STLC Phases

1.Requirements Analysis

In this phase testers analyze the customer requirements and work with developers during the design phase to see which requirements are testable and how they are going to test those requirements.It is very important to start testing activities from the requirements phase itself because the cost of fixing defect is very less if it is found in requirements phase rather than in future phases.

2.Test Planning

In this phase all the planning about testing is done like what needs to be tested, how the testing will be done, test strategy to be followed, what will be the test environment, what test methodologies will be followed, hardware and software availability, resources, risks etc. A high level test plan document is created which includes all the planning inputs mentioned above and circulated to the stakeholders.

3. Test Scenarios and Test Cases Development

The test scenarios and test cases development activity is started once the test planning activity is finished.This is the phase of STLC where testing team write down the detailed test scenarios and test cases. Along with these, testing team also prepare the test data if any required for testing. Once the test cases are ready then these test cases are reviewed by peer members or QA lead. Also the Requirement Trace-ability Matrix (RTM) is prepared. The Requirement Trace-ability Matrix is an industry-accepted format for tracking requirements where each test case is mapped with the requirement. Using this RTM we can track backward & forward trace-ability.

4. Test Environment Setup

Setting up the test environment is vital part of the STLC. Basically test environment decides on which conditions software is tested. This is independent activity and can be started parallel with Test Case Development. In process of setting up testing environment test team is not involved in it. Based on company to company may be developer or customer creates the testing environment. Mean while testing team should prepare the smoke test cases to check the readiness of the test environment setup.

5. Test Execution and Bug Reporting

Once the unit testing is done by the developers and test team gets the test build, The test cases are executed and defects are reported in bug tracking tool, after the test execution is complete and all the defects are reported. Test execution reports are created and circulated to project stakeholders.
After developers fix the bugs raised by testers they give another build with fixes to testers, testers do re-testing and regression testing to ensure that the defect has been fixed and not affected any other areas of software.Testing is an iterative process i.e. If defect is found and fixed, testing needs to be done after every defect fix.After tester assures that defects have been fixed and no more critical defects remain in software the build is given for final testing.

6.Test Cycle Closure

Call out the testing team member meeting & evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software. Discuss what all went good, which area needs to be improve & taking the lessons from current STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC process. Test case & bug report will analyze to find out the defect distribution by type and severity. Once complete the test cycle then test closure report & Test metrics will be prepared. Test result analysis to find out the defect distribution by type and severity.