Complete Functional Testing Guide With Its Types And Example

An In-Depth Comprehensive Functional Testing Tutorial with Types, Techniques, and Examples:

What is Functional Testing?

Functional testing is a kind of black-box testing that is performed to confirm that the functionality of an application or system is behaving as expected.

 It is done to verify all the functionality of an application. 

LIST of the Tutorials covered in this series:

Tutorial #1: What is Functional Testing (this tutorial)
Tutorial #2: Functionality Testing Interview Questions
Tutorial #3: Top Functional Automation Testing Tools
Tutorial #4: What is Non-Functional Testing?
Tutorial #5: Difference Between Unit, Functional, and Integration Testing
Tutorial #6: Why Functional and Performance Testing Should be Done Simultaneously


Tutorial #7: Functional Test Automation with Ranorex Studio
Tutorial #8: UFT Functional Tool New Features
Tutorial #9: Cross Browser Functional Automation Using Parrot QA Tool
Tutorial #10: Jubula Open Source Tool tutorial for functionality testing

functional testing

Introduction To Functional Testing

There must be something that defines what is acceptable behavior and what is not.

This is specified in a functional or requirement specification. It is a document that describes what a user is permitted to do so, that he can determine the conformance of the application or system to it. Additionally, sometimes this could also entail the actual business side scenarios to be validated.

Therefore, functionality testing can be carried out via two popular techniques:

  • Testing based on Requirements: Contains all the functional specifications which form a basis for all the tests to be conducted.
  • Testing based on Business scenarios: Contains the information about how the system will be perceived from a business process perspective.

Testing and Quality Assurance are a huge part of the SDLC process. As a tester, we need to be aware of all the types of testing even if we’re not directly involved with them daily.

As testing is an ocean, the scope of it is so vast indeed, and we have dedicated testers who perform different kinds of testing. Most probably all of us must be familiar with most of the concepts, but it will not hurt to organize it all here.

Functional Testing Types

Functional testing has many categories and these can be used based on the scenario.

The most prominent types are briefly discussed below:

Unit Testing:

Unit testing is usually performed by a developer who writes different code units that could be related or unrelated to achieve a particular functionality. His, this usually entails writing unit tests which would call the methods in each unit and validate those when the required parameters are passed, and its return value is as expected.

Code coverage is an important part of unit testing where the test cases need to exist to cover the below three:

i) Line coverage
ii) Code path coverage
iii) Method coverage

Sanity Testing: Testing that is done to ensure that all the major and vital functionalities of the application/system are working correctly. This is generally done after a smoke test.

Smoke Testing: Testing that is done after each build is released to test to ensure build stability. It is also called as build verification testing.

Regression Tests: Testing performed to ensure that adding new code, enhancements, fixing of bugs is not breaking the existing functionality or causing any instability and still works according to the specifications.

Regression tests need not be as extensive as the actual functional tests but should ensure just the amount of coverage to certify that the functionality is stable.

Integration Tests: When the system relies on multiple functional modules that might individually work perfectly, but have to work coherently when clubbed together to achieve an end to end scenario, validation of such scenarios is called Integration testing.

Beta/Usability Testing: Product is exposed to the actual customer in a production like an environment and they test the product. The user’s comfort is derived from this and the feedback is taken. This is similar to that of User Acceptance testing.

Let’s represent this in an easy flow-chart:

Functional Testing Categories

Functional System Testing:

System testing is a testing that is performed on a complete system to verify if it works as expected once all the modules or components are integrated.

End to end testing is performed to verify the functionality of the product. This testing is performed only when system integration testing is complete including both the functional & non-functional requirements.

=> Difference Between Unit, Functional and Integration Testing


This testing process has three main steps:

Steps of Functional testing Process

Approach, Techniques, and Examples

Functional or behavioral testing generates an output based on the given inputs and determines if the System is functioning correctly as per the specifications.

Hence, the pictorial representation will look as shown below:

Functional Testing Process

Entry/Exit criteria

Entry Criteria:

  • The Requirement Specification document is defined and approved.
  • Test Cases have been prepared.
  • Test data has been created.
  • The environment for testing is ready, all the tools that are required are available and ready.
  • Complete or partial Application is developed and unit tested and is ready for testing.

Exit Criteria:

  • Execution of all the functional test cases has been completed.
  • No critical or P1, P2 bugs are open.
  • Reported bugs have been acknowledged.

Steps Involved

The various steps involved in this testing are mentioned below:

  • The very first step involved is to determine the functionality of the product that needs to be tested and it includes testing the main functionalities, error condition, and messages, usability testing i.e. whether the product is user-friendly or not, etc.
  • The next step is to create the input data for the functionality to be tested as per the requirement specification.
  • Later, from the requirement specification, the output is determined for the functionality under test.
  • Prepared test cases are executed.
  • Actual output i.e. the output after executing the test case and expected output (determined from requirement specification) are compared to find whether the functionality is working as expected or not.


Different kinds of scenarios can be thought of and authored in the form of “test cases”. As QA folks, we all know how the skeleton of a test case looks.

It mostly has four parts to it:

  • Test summary
  • Pre-requisites
  • Test Steps and
  • Expected results.

Attempting to author every kind of test is not only impossible but also time-consuming and expensive.

Typically, we would want to uncover the maximum bugs without any escapes with existing tests. Therefore, the QA needs to use optimization techniques and strategize how they would approach the testing.

Let’s explain this with an example.

Functional Testing Use Case Examples:

Take an online HRMS portal where the employee logs in with his user account and password. On the login page, there are two text fields for the username & password, and two buttons: Login and Cancel. Successful login takes the user to the HRMS home page and cancel will cancel the login.

Specifications are as shown below:

#1 ) The user id field takes a minimum of 6 characters, a maximum of 10 characters, numbers(0-9), letters(a-z, A-z), special characters (only underscore, period, hyphen allowed) and it cannot be left blank. User id must begin with a character or a number and not special characters.

#2) Password field takes a minimum of 6 characters, a maximum of 8 characters, numbers (0-9), letters (a-z, A-Z), special characters (all), and cannot be blank.

Example Use Case - HRMS Online Portal

The basic approach to testing this scenario can be classified into two broad categories:

  1. Positive testing and
  2. Negative testing

Of course, each of these categories has its sub-section of tests that will be carried out.

Positive tests are happy path tests that are done to ensure that the product meets – at least the basic requirements that are vital to customer usage.

Negative scenarios ensure that the product behaves properly even when it is subjected to unexpected data.

Suggested Read => What is Negative Testing and How to Write Negative Test Cases

Now, let me try to structure the testing techniques using a flowchart below. We’ll get into the details of each of those tests.

Functional Testing Techniques

Functional Testing Techniques

#1) End-user based/System Tests

The system under test may have many components which when coupled together achieve the user scenario.

In the Example, a customer scenario would include tasks like HRMS application loading, entering the correct credentials, going to the home page, performing some actions and logging out of the system. This particular flow has to work without any errors for a basic business scenario.

Some samples are given below:

Sl NoSummaryPre-requisiteTest caseExpected results.
1.Fully privileged user can make account changes1)User account must exist
2) User needs to have the required privileges
1) User enters the userid and password
2) User sees edit permissions to modify account itself
3) User modifies account information and saves.
4) User logs out.
1) User is logged into the home page
2) Edit screen is presented to the user.

3) Account information is saved
4) User is taken back to login page
2.Another valid user without full privileges1)User account must exist
2) User needs to have the minimum privileges
1) User enters the userid and password
2) User sees edit permissions to modify only certain fields.
3) User modifies only those fields and saves.
4) User logs out.
1) User is logged into the home page
2) Edit screen is presented to the user only on certain fields. The account fields are grayed out.
3) Fields modified are saved
4) User is taken back to login page

This is a basic example of how test cases are authored for situations. The format above will apply to all the below tests as well. For the sake of strong conceptual grounding, I have put in only some simple tests above and below.

#2) Equivalence Tests

In Equivalence partitioning, the test data are segregated into various partitions called equivalence data classes. Data in each partition must behave in the same way, therefore only one condition needs to be tested. Similarly, if one condition in a partition doesn’t work, then none of the others will work.

For Example, in the above scenario the user id field can have a maximum of 10 characters, so entering data > 10 should behave the same way.

#3) Boundary Value Tests

Boundary tests imply data limits to the application and validate how it behaves.

Therefore, if the inputs are supplied beyond the boundary values, then it is considered to be negative testing. So a minimum of 6 characters for the user sets the boundary limit. Tests written to have user id < 6 characters are boundary analysis tests.

#4) Decision-based Tests

Decision-based tests are centered around the ideology of the possible outcomes of the system when a particular condition is met.

In the above scenario given, the following decision-based tests can be immediately derived:

  1. If the wrong credentials are entered, it should indicate that to the user and reload the login page.
  2. If the user enters the correct credentials, it should take the user to the next UI.
  3. If the user enters the correct credentials but wishes to cancel the login, then it should not take the user to the next UI and reload the login page.

#5) Alternate Flow Tests

Alternate path tests are run to validate all the possible ways that exist, other than the main flow to accomplish a function.

#6) Ad-hoc Tests

When most of the bugs are uncovered through the above techniques, ad-hoc tests are a great way to uncover any discrepancies that are not observed earlier. These are performed with the mindset of breaking the system and see if it responds gracefully.

For Example, a sample test case would be:

  • A user is logged in, but the admin deletes the user account while he is performing some operations. It would be interesting to see how the application handles this gracefully.

Functional vs Non-Functional Testing:

Non-functional tests focus on the quality of the application/system as a whole. Hence, it tries to deduce how well the system performs as per the customer requirements as in contrast to the function it performs.

=> Read the exact difference here

Functional Test Automation

Can we automate functional Tests?

With Automation manual effort can be reduced, time can be saved, bug slippage can be avoided, and efficiency can be increased.

However, it is not possible to automate each and everything. This testing can be automated, but the user needs to work out for test cases for the automation to be done. It’s important to find the right test cases to be automated along with an appropriate tool.

Automating functional cases can have drawbacks like if the number of test cases are much more and are regressed again and again ( which has to be done ) then the developer might face an issue in committing changes to the code.

Many times while performing defect escape analysis, the prominent and perennial cause of escapes seems to have a lack of test coverage in a particular function.

Again, there are several causes for this to happen like lack of environments, lack of testers, too many functions being delivered, less time to cover all the testing aspects, and sometimes simply overlooking it.

While dedicated test teams might do detailed testing on each sprint or each test cycle, defects will always exist and there will always be defects that might get missed. This is one of the fundamental needs to have test automation in place, thereby having a marked improvement in the efficiency of the overall test process and test case coverage.

Although automated testing can never replace manual tests, having an ideal mix of the two will prove to be vital to have the desired quality in Software projects.

Automation Considerations:

#1) Select the correct Automation Tool: There are several tools available in the market, to choose an automation tool is a real daunting task! However, you could make a list of requirements, based on which you can select which automation tool to use.

Some primary aspects to think of include:

  • Select a tool that will be easy to use by all the QA members of the team, if they don’t already have the required skills.
  • The tool can be used across different environments. For Example: Can the scripts be created on one OS platform and run on another? Do you require CLI automation, UI automation, mobile application automation, or all?
  • The tool must have all the features you require. For Example: If some testers are not well-versed with a scripting language, the tool should have a record and playback feature and then support conversion of the recorded script to the desired scripting language. Likewise, if you also need the tool to support automated build tests, specific reporting, and logging, then it must be able to do that as well.
  • The tool must be able to support the reusability of test cases in case of UI changes.

Automation Tools: There are quite a few tools that are available for functional automation. Selenium is probably a hot favorite, but there are some other open-source tools as well like Sahi, Watir, Robotium, AutoIt, etc.

Several test automation tools are available in the market. But choosing the appropriate tool is very important for the organization. It might depend on the requirement, ease of use, and cost plays a major role here.

Given below are some of the top functional test tools:

  • Selenium
  • QTP
  • Junit
  • Loadrunner
  • SoapUI
  • TestComplete

=> Check this Complete list of top functional automation tools

#2) Pick the right test cases to automate: If you want to get the best out of automation, then it is vital to be smart about the kind of tests that you pick to automate. If there are tests that require some setup and configurations on and off during test execution, then those are best left non-automated.

Therefore, you can automate tests that:

  • Need to be run repeatedly.
  • Run with different kinds of data.
  • Some P1, P2 test cases take a lot of effort and time.
  • Tests that are error-prone.
  • Set of tests that need to be run in different environments, browsers, etc.

#3) Dedicated Automation Team: This is probably overlooked in most organizations and automation is imposed upon all the members of the QA team.

Each team member has varied experience levels, skill sets, interest levels, bandwidth to support automation, etc. Some individuals are possibly better skilled at executing manual tests, while some others may know scripting and automation tools.

In situations like this, it’s a good practice to take an analysis of all the members of the team and have some members dedicated to doing only automation.

Automation activity requires time, effort, knowledge, and a dedicated team which will help to achieve the required results instead of overloading all the members of the team with both manual and automation testing.

#4) Data-Driven Tests: Automated test cases that require multiple sets of data should be well written so that they can be reusable. The data could be written in sources such as text or properties file, XML files, or read from a database.

Whatever the data source is, creating a well-structured automation data makes the framework easier to maintain and makes the existing test scripts used to their full potential.

#5) UI changes must not break tests: The test cases you create using the selected tool must be able to deal with the potential UI changes. For instance, earlier versions of selenium used a location to identify the page elements.

Hence, if the UI changed, those elements were no longer found at those locations and will, in turn, lead to the mass failure of tests.

Therefore, it’s important to understand the shortcomings of the tool beforehand and author the test cases such that there are only minimal changes required in case of UI changes.

#6) Frequent Testing: Once you have a basic automation test bucket ready, plan to have more frequent execution of this bucket. This has a two-way advantage: One is that you can enhance the automation framework and make it more robust and the second is that you will catch more bugs in the process.


Enlisted below are the various advantages of Functional Testing:

  • This testing reproduces or is a replica of what the actual system is i.e. it is a replica of what the product is in the live environment. Testing is focused on the specifications as per the customer usage i.e. System specifications, Operating system, browsers, etc.
  • It does not work on any if and buts or any assumptions about the structure of the system.
  • This testing ensures to deliver a high-quality product that meets the customer requirement and makes sure that the customer is satisfied with the end results.
  • It ensures to deliver a bug-free product which has all the functionalities working as per the customer requirement.
  • Risk-based testing is done to decrease the chances of any kind of risk in the product.


This testing is done to make sure that the product works as expected and the entire requirement is implemented and the product is exactly as per the customer requirement.

However, it does not consider the other factors such as the performance of the product i.e. responsiveness, throughput time, etc., which are important and very much required to be a part of testing before releasing the product.


  • There are many chances of performing redundant testing.
  • Logical errors can be missed out in the product.
  • This testing is based on the requirement, if in case the requirement is not complete or is complicated or is not clear, performing this testing in such a scenario becomes difficult and can be time-consuming too.

Hence basically, both these types of testing are needed for a quality product.


This tutorial has comprehensively discussed everything that you need to know about functional testing, right from the basics.

Functional testing is one of the important testing processes as it verifies the functionality of a product which is the most required and indeed the important aspect of any product or application.

About the Author: Sanjay Zalavadia – as the VP of Client Service for Zephyr, brings over 15 years of leadership experience in IT and Technical Support Services. 

I hope that some of the techniques that we’ve suggested will come in handy for all the readers. Let us know your thoughts in the comments below.

Suggested Read => Feature Testing Tutorial

Recommended Reading

29 thoughts on “Complete Functional Testing Guide With Its Types And Example”

  1. Hi very well explained.

  2. This article includes from scratch level of testing and useful for all people including all levels,because it simply RECAP the subject as it seems fantastically explained.

  3. Hi Sanjay,

    Thanks for sharing the information. Frankly speaking bundles of data available online, but everybody wonder about the right information. But what ever the information you shared with us just the right one, right on target, things need to be taken care mostly while performing basic functional testing.

    wish all the best,

  4. Hi
    very useful article thanks for sharing..Please help me how to test a yahoo home page.As it contains many links adds and every thing how to test it manually.please answer this query.

    • @ yamini – you can use broken link checker tool to check if all links are functional or not. If you want to check if these links are correct or not then you can do it manually by comparing the links on the page else you can automate it one time and use the script multiple times. Other functional testing you can carry out as per the test cases and process mentioned on below page:

  5. thanks for sharing the well structure concepts. I always find myself have more confidence after read every post in STH. hopeful will post sth dealing testing in agile scrum team.

  6. Whole testing is summarised in one post. Keep up the good work

  7. Well explained in detail….not a kind of Bla Bla Stuff..
    It was really helpful. Thanks a lot.

  8. Very well explained. We learned alot, thanks for sharing with us

    • @all thanks for your comments. Glad to see you all like it.

  9. Very helpful and detailed information. I like how you broke down the information and gave examples of different testings and approaches. thank you so much!!

  10. Awesome,Superb

  11. Very nice Software Testing article

  12. Excellent explanation with ease

  13. Very detailed and useful.

  14. Helpful, well explained!!

  15. Please anybody know the number on which i can contact softwaretestinghelp( STH)? sent several emails but to no avail. thanks

  16. nice explanation

  17. Hey, excellent job. However, I would call attention to one thing, which you might want to note/clarify/comment upon:

    1) “Examples of black box testing are: Functional testing,…”

    followed by:

    2) “Functional testing Types: …. Unit Testing: …”

    and then in the table below…

    3) “It [unit testing] is a white box testing technique”

    You should perhaps expend a little commentary on this visible but (I’m pretty sure) logical apparent discrepancy. From my own experience I’m pretty sure what is going on, but others may not Get It and be confused.

  18. very well explained, thank you

  19. Good stuff. Very useful

  20. Hello buddy,

    You have done an amazing job I must say I am very impressed by your work after a long time a found a worth reading blog thank you so much for sharing it 🙂 and yeah functional tests are described and performed when the units of the application are considered complete. If parts of the application are changed after the trial began, the test is usually considered valid and must be repeated.

    White box testing relaxes this demand, in that the tests are known to be affected by the change of code can be considered as still valid.


  21. Alternate Flow(Path) Tests = Negative testing.

    • I may be incorrect but I don’t agree that Alternate Flow(Paths) Tests = Negative testing. In my experience, alternate flow tests are when you have a backup site or a backup comm path while negative testing is trying a positive test in the negative (ex. I can login with my username and password [pos] vs I login with a invalid username and password [neg]).

  22. Excuse me, but you say say functional testing is black box testing. After you go on saying that unit testing is a type of functional testing but it is actually white box testing?

    Also, you say unit and integration testing are types of functional testing and yet you compare these 3 as if they were 3 types of different testings?

    I had to stop reading the article, it’s so, so confusing.

  23. There are benefits of automated software testing, at the same time, it has its demands and drawbacks in it. Just like other methods in software development, there is no perfect one. Automated software testing requires a higher skill level of team members, increase tooling needs and requires more initial developer time and I think these are some of the disadvantages of automated software testing.

  24. Typically, system integration testing is taken up to validate the performance of the entire software system as a whole. The main purpose of this testing method is to expand the process and validate the integration of the modules with other groups. It is performed to verify if all the units operate in accordance with their specifications defined.

  25. “Thank you so much for sharing all this wonderful info. It is so appreciated!!!” “You have good humor in your posts/blogs. So much fun and easy to read! Keep it up software testing help. Your blog is really helpful for my website (software testing based as I’ll definitely implement it.

  26. Is It Safe For Me?


Leave a Comment