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
What You Will Learn:
- Introduction to Functional Testing
- Recommended Functional Testing Service Provider
- Functional Testing Types
- Entry/Exit criteria
- Steps Involved
- Functional Testing Techniques
- Functional Test Automation
- Recommended Reading
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 on a daily basis.
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.
Recommended Functional Testing Service Provider
Core Services: Automation Testing, Manual Testing, API Testing, Mobile QA, Security Testing, Performance Testing, QA Analysis, and Salesforce Testing.
Verdict: QA Source emphasizes on providing time-bound delivery. It offers customized services. It can provide all types of QA services to organizations of all sizes. These services are immediately scalable, effective, and efficient.
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 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 in order 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 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.
This testing process has three main steps:
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:
- 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.
- Execution of all the functional test cases has been completed.
- No critical or P1, P2 bugs are open.
- Reported bugs have been acknowledged.
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.
- 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
- 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 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.
The basic approach to testing this scenario can be classified into two broad categories:
- Positive testing and
- Negative testing
Of course, each of these categories has its own sub-section of tests that will be carried out.
Positive tests are happy path tests that are done to ensure that the product means – at least the basic requirements that are vital to the 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
#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 No||Summary||Pre-requisite||Test case||Expected results.|
|1.||Fully privileged user can make account changes||1)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 privileges||1)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:
- If the wrong credentials are entered, it should indicate that to the user and reload the login page.
- If the user enters the correct credentials, it should take the user to the next UI.
- If the user enters the correct credentials but wishes to cancel 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 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 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.
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 seem 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 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.
#1) Select the correct Automation Tool: There are a number of tools available in the market, make the choice of an automation tool 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.
There are several test automation tools that are available in the market. But choosing the appropriate tool is very important for the organization. It might depend on the requirement, ease of using and moreover, cost plays a major role here.
Given below are some of the top functional test tools:
- QASource for functional test services
#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 which 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 have 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 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 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 obviously 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 which 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.