Functional testing is a form of software testing where you check that your application does what it’s supposed to. In effect, it’s a form of black box testing because you are only concerned with what it does, not how it does it. This is different from unit and integration testing, where you also care about how the software works. Functional testing should test your application from a user’s perspective, however, it’s not the same as user acceptance testing. It can happen at any stage in the development cycle once you have working code to test.
1is about the functionality of your application, not how it achieves it.
2is testing against the business/design requirements of your application.
3is about what the user sees and experiences, but is not the same as user acceptance testing.
4is not interested in the performance and reliability of your application.
5is generally black box.
6can happen at any stage in the development cycle, but generally is done during system and acceptance testing.
7should test all the moving parts of your code. This requires careful thought and test planning.
8should use carefully designed test data with known expected outcomes. This should come from the requirements/design.
9 is an essential part of any test plan.
10can be automated relatively easily.
What’s required for functional testing?
Functional testing can be done manually. However, it’s best if you can automate it. Functional testing automation tools will help make your life easier, especially if you are testing a complex application. Nowadays, many applications are browser-based rather than native. Such web applications are often easier to test. However, there are many issues relating to test automation. Especially when you are using functional testing tools based on Selenium.
Problems with traditional functional testing tools
- Modern web applications are often complex, producing dynamic UIs with embedded widgets and content.
- During development, they will go through many design changes, and even once deployed in production, minor UI/UX changes are common.
- These applications are also usually optimized for mobile through the use of responsive design.
- This means the application will display differently depending on the size of the screen it is displayed on.
- All these aspects cause real problems for Selenium-based tools.
Slow to write test scripts
Selenium-based test scripts are hard to write, requiring skilled Test Automation Engineers or Developers in Test to get them right. Even a simple test script takes hours to write and debug.
Test recorders are intended to simplify this process, but the scripts they produce are more brittle (see test maintenance below). They also usually require manual debugging and improvement.
Selenium scripts are extremely brittle. Every time you update your UI you can expect most of your Selenium-based tests to break. This is because every change makes it harder for the script to select the right element. Even a simple CSS change can cause the selectors to change.
Sometimes, the script simply fails to find the element at all and will fail instantly. Other times, it will actually select the wrong element. This causes real problems since it can lead to failures that don’t show up until many steps later. In the worst cases, it could invalidate the test altogether. In both cases, you have to manually fix the test script.
Hard to adapt for cross-browser
Adapting Selenium scripts to work cross-browser and cross-platform is a painstaking and slow task. Essentially the script has to be modified for every different combination of platform and browser.
Taken together with the slowness of producing the initial script, it can easily take a team of competent test engineers days to produce just a few working cross-browser test scripts.
Domain Object Models (DOMs) are the logical containers within your web application’s UI. In dynamic sites, you often embed content from another location or 3rd party provider. Things such as a PayPal Buy Now button, or a newsletter sign up. These objects exist inside their own DOM embedded inside your application. Sometimes, these DOMs can be nested many layers deep.
The problem is, Selenium-based scripts can only reliably access and interact with objects within their own DOM. The only way to access embedded objects is to use complex XPath queries. And if the embedded object changes at all that breaks the test.
The solution is to use an intelligent test agent for all your functional testing. By leveraging artificial intelligence, functional testing automation tools can become far more robust, efficient, and effective. Functionize’s Adaptive Language Processing™ allows you to create tests directly from test plans written in English. Our Adaptive Event Analysis™ then models your site, learning how the UI is meant to work. Tests are able to automatically run cross-browser and cross-platform. All tests are run in the Functionize Test Cloud, allowing thousands of tests to be completed in parallel.
All this means that with Functionize, you can easily automate all your functional testing. You don’t need to employ an army of Developers in Test to create new tests for you. Because we leverage the power of cloud computing, your functional testing completes far faster. And because our system understands how your site is meant to work, Functionize tests can self-heal when you make changes. For more complex changes, Root Cause Analysis is able to track down the trigger for any failure. It then tests the most likely causes of the failure and presents the best solutions for you to choose from.Automated Test Creation
Sign Up Today
Functionize is designed with all levels of testers in mind. We simplify test creation while providing rich features to tune tests for your most complex scenarios. Running in our test cloud gives you elastic scale to handle continuous testing in your CI/CD pipeline or large regression suites. Meanwhile the deep machine learning engine is modeling your applications and dynamically updating your tests as your UI changes; saving you the aggravation of constant maintenance.