Functional Testing Simplified: The Process, Approach, Techniques and Examples

An overview of Functional Testing:

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

Since testing is such an ocean and the scope of it is so vast, we have dedicated testers perform different kinds of testing. Many of you are probably already familiar with most concepts, but it wouldn’t hurt to organize it all here.

So let’s get back to some basics.

an overview of functional testing


On the broadest level, there are two kinds or classes of testing.

Testing classes

#1) Black box testing:

This kind of testing is exactly what it sounds like! Picture a black colored box as shown below.

Black box testing

Let’s ask ourselves some basic questions so that we can derive a technical definition.

  1. Can you see the box’s external characteristics?
  2. Can you see what lies within the box?

If you now try to answer these fundamental questions, it’ll give you a perfect idea of what this entails. The answer to the above question is yes and no respectively. Therefore, black box testing can be defined as the type of testing where you view the system under test as a black box and observe how it reacts to various situations.

You don’t need to get into the system’s internals like its implementation, code or internal characteristics. The tester will derive the different inputs to this system based on the requirements, record the outputs for each of them and make sure they are consistent with the expectations.

Examples of black box testing are: Functional testing, System testing, Acceptance testing, Regression testing, Beta testing and sometimes Integration testing also comes under this category.

#2) White box testing:

White box testing, on the other hand, is almost the opposite of the black box testing. Let us assume that the same black box is a transparent box as below.

White box testing

Again let’s ask some questions to derive its meaning:

  1. Can you see the box’s internal characteristics?
  2. Should you be testing the code?

The answer to both these questions is an affirmative “yes”. Commonly known synonyms for white box testing are glass box testing, transparent box testing, or structural testing.

Therefore white box testing is a mechanism where a tester has access to the internal code of the system and executes tests to check the robustness of the code. He doesn’t have to get into the actual functionality of the application.

Examples of white box testing are Unit testing, API testing, Integration and Regression testing also extend into this category based on scope. Sometimes even functional tests require the usage of white box testing.

Now that we have formed a basis and background, the scope of this article will be to discuss the functionality testing aspect in detail.

Introduction to Functional testing

Definition: As the name goes, a functional test is a kind of black box testing that is performed to confirm that the functionality of an application or system is behaving as expected.

Therefore, 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 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.

Functional testing Types: It has many categories and these can be used based on the scenario. The most prominent types are discussed in brief below:

  • Unit Testing: Unit testing is usually performed by the developer who writes different code units that could be related or unrelated to achieve a particular functionality.

Therefore, this usually entails writing unit tests which would call the methods in each unit and validate that when the needed parameters are passed, its return value is as expected. Code coverage is an important part of unit testing where 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 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’s also called build verification testing.
  • Regression tests: Testing performed to ensure that the adding new code, enhancements, fixing of bugs is not breaking existing functionality or cause 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 feedback is taken. This is similar to User Acceptance testing.

I’m again going to represent this in easy flow-chart:

flow chart

Difference Between Unit, Functional and Integration Testing

Tests a program by separating it into code modules or units and individually testing those modules.Tests a user scenario which involves two or more individual modules to work correctlyFunctional tests determine if the application is behaving according to specifications
Not very complex in natureMore complex than unit tests.More complex than unit tests and sometimes even more complex than integration tests.
It is a white box testing techniqueIt is a white box and black box testing techniqueIt is a black box testing technique
Unit testing helps in screening/uncovering bugs that might occur frequentlyIntegration testing will help uncovering the error that occurs when individual modules are assembled to work together.Functional testing helps to uncover bugs that do not let the application serve its desired purpose.
Unit tests should be more in numberIntegration tests should be added if it’s not possible to add a unit test as they are complex and take more time to executeFunctional tests should be less in number when compared to unit tests as they might take more time to execute.

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. So a pictorial representation looks like something below:

Functional Testing Process


Different kind 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 has mostly four parts to it:

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

Obviously, attempting to author each and every kind of test is not only impossible but also time-consuming and expensive.

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

Let’s explain this with an example.

Functional Testing Example Use Case: 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 user, 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 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 cannot be left blank. User id must begin with a character or 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

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

  1. Positive testing and
  2. negative testing

Off course, each of these categories has their own subsection of tests that will be carried out.

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

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

For more information on these forms of testing, you can check this article -> What is Negative Testing and How to Write Negative Test Cases

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

Testing Techniques:

Testing Techniques

#1) End user based/System tests: The system under test may have many components that when coupled together achieve the user scenario. In the example, a customer scenario would include 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 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, it is considered to be negative testing. So a minimum of 6 characters for 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 scenario given above, the following decision-based tests can be immediately derived:

  1. If 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 login, it should not take the user to the next UI and reload the login page.

#5) Alternate flow tests: Alternate path tests are basically 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 not observed earlier. These are performed with the mindset of breaking the system and see if it responds gracefully.

For more information read this article -> Ad-hoc Testing: How to Find Defects Without a Formal Testing Process

For the 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 v/s Non-Functional Testing

Now, we have a detailed discussion about functionality test. Let’s also briefly discuss the non-functional testing concept.

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

Non-functional test types: Some more popular kinds of non-functional tests are:

  • Performance: Stress, Load Testing: This testing is done to see if the application can withstand heavy stress and load if there are too many simultaneous users accessing the system at the same time.
  • Security testing: Testing which is done to determine how robust the application is to malicious attacks or unwarranted users.
  • Compatibility Testing: Testing is carried out to determine how well the application works in any particular environment.
  • Install Testing: Testing carried out to determine that the application can be downloaded, installed from something called a “package” and setup without any issues.
  • Recovery Testing: Testing done to figure out if an application is able to gracefully recover from disasters and catastrophic events such as hardware failures, system crashes, etc,
  • Volume/Tenacity Testing: Tests which is done to determine the application’s ability to handle certain amounts of data.

Functional Test Automation

Many times while performing defect escape analysis, the prominent and perennial cause of escapes seems to be 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 testing aspects and sometimes simply overlooking it.

While dedicated test teams might do detailed testing each sprint or each test cycle, there will always be defects 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 efficiency of the overall test process and test cases coverage.

Although automated functional 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: The amount of tools available in the market, make the choice of the automation tool a real daunting task! However you could make a list of requirements, based on which you can select what automation tool to use. Some primary aspects to think of are:

  • Select a tool that will be easy to use by all QA members of the team, if they don’t already have the needed 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 record and playback feature and then support conversion of the recorded script to the desired scripting language. Likewise, if you need the tool to also support automated build tests, specific reporting, and logging, it must be able to do that.
  • The tool must be able to support reusability of test cases in case of UI changes.

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

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

Therefore, you can automate tests which:

  • Need to be run repeatedly
  • Run with different kinds of data
  • Some P1, P2 test cases which take a lot of effort and time
  • Tests which 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 varying experience levels, skill sets, interest levels, bandwidth to support automation. Some individuals possibly better skilled at executing manual tests, while some others may have the knowledge of 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 doing only automation. Automation activity requires time, effort, knowledge and a dedicated team will help 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 files, XML files or read from a database.

Whatever the data source is, creating 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 potential UI changes. For instance, earlier versions of selenium used a location to identify page elements. So if the UI changed, those elements were no longer found at those locations leading to mass failure of tests.

Therefore, it’s important to understand the shortcomings of the tool beforehand and author 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; second is that you will obviously catch more bugs in the process.


This article comprehensively discusses everything you need to know about functional testing, right from the basics.

About Author: Sanjay Zalavadia – as the VP of Client Service for Zephyr, Sanjay brings over 15 years of leadership experience in IT and Technical Support Services. Throughout his career, he has successfully established and grown premier IT and Support Services teams across multiple geographies for both large and small companies.

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


#1 Dev Gandhi

Hi very well explained.

#2 Naga Sekhar

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 kumar

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 yamini

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.

#5 autominator

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 Gaurav Khurana

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

#7 Sabeer

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

#8 Sindhura grandhi

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

#9 Vijay

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

#10 Vijay

@ 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:

#11 Sumera

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!!

#12 Subhash


#13 Dr S Kotrappa

Very nice Software Testing article

#14 Venkat

Excellent explanation with ease

#15 Nimisha

Very detailed and useful.

#16 taonga

Helpful, well explained!!

#17 strat

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

#18 INDU

nice explanation

#19 O Bloody Hell

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.

#20 unique

very well explained, thank you

#21 Kimani

Good stuff. Very useful

#22 alishahenderson

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.


Leave a Comment