Testing Applications

Share

On This Page
 Overview
 Unit testing
 User interface (UI) testing
 Performance testing
 Feedback
Overview
Copy link to clipboard

This page is about the ways you can test and validate your Appian applications. Testing
is an important part of the application life cycle—it’s how you can ensure that your
application is ready for deployment and use.

Testing is an on-going activity and instills confidence that your application will work as
you expect it to. Before you start writing tests, you should decide what kind of testing
your application needs and how much time you need to invest in it.

Testing should be done anytime you introduce new functionality or update an

application. You might decide to automate tests to ensure that developers can
implement application improvements more efficiently and safely. Automated regression
tests can also simplify maintenance of your application after it’s released. Testing that
your existing application still works with the new and updated changes is called
regression testing.

There are three types of testing you can do with Appian: Unit Testing, User Interface
(UI) Testing, and Performance Testing.

Unit testing
Copy link to clipboard

Unit testing focuses on the smallest testable parts of your application. The goal is to
validate that your logic or rules behave as expected under various conditions. For
example, you should test display and validation logic as you’re developing an interface,
rather than waiting until the end of your development cycle to test it.

Objects with rule inputs, such as integrations and expression rules, support either
default test values or test cases. You can continuously test these objects with different
data values as you develop them.
This type of testing also applies to process models. As you add more logic and nodes to
your model, you should test your changes by starting a process for debugging.

For expression rules, you can save your test conditions as test cases. This allows you
to reuse them for regression tests and documents important edge cases for other
Appian developers who might modify the rule in the future. You can execute these test
cases in bulk using the Manage Test Cases dialog. You can also automate running
these test cases with Jenkins.

When you inspect a package during direct deployments, you will be reminded to
address any missing test coverage and run the test cases for packaged rules. Running
test cases before you deploy is the best way to ensure modifications have not
negatively impacted any existing rules.

User interface (UI) testing

Copy link to clipboard

Testing from a user’s perspective validates the end-to-end experience and your design
choices. You should do it early and often as you’re developing to make sure your
application meets the user’s needs. For example, if you have a related action that
updates record data, UI testing ensures that the correct users can access the form and
that the information is updated successfully.

Appian supports three functional UI testing tools: FitNesse for Appian, Cucumber for
Appian, and Appian Selenium API. These tools support behavior-driven development
(BDD) by allowing you to easily write test cases in user-friendly text and run them with
the click of a button. Since we update these tools to be backwards compatible with
every Appian release, they are more robust than regular webdriver testing.

To achieve all the benefits of continuous integration through automated testing, refer to
the DevOps Quickstart on how to implement the full pipeline.

Performance testing
Copy link to clipboard

Performance testing ensures that your application will scale and behave as expected
during production-like or peak usage. When making changes you should take into
consideration the size of your data and the frequency of each action. For example, how
well will your application perform if you have a record grid with many rows of data and
you have “x” number of users who need to interact with the data on that grid.

It’s important to plan for performance testing early on and test performance before
major releases. Appian can be used with tools, like JMeter and Locust, that allow you to
efficiently automate load testing. For more information about application performance
testing, see Monitor Appian Applications
Test Automation Best Practices
In this article
Decide What Test Cases to Automate

Select the Right Automated Testing Tool

Divide Your Automated Testing Efforts

Create Good, Quality Test Data

Create Automated Tests That Are Resistant to Changes in the UI

Conclusion

There are a lot of reasons test automation is beneficial, and by adhering to automated
testing best practices you can ensure that your testing strateagy delivers the maximum
return on investment (ROI). Automated testing will shorten your development cycles,
avoid cumbersome repetitive tasks and help improve software quality but how do you
get started? These best practices a successful foundation to start improving your
software quality.

Thorough testing is crucial to the success of a software product. If your software doesn’t
work properly, chances are strong that most people won’t buy or use it…at least not for
long. But testing to find defects – or bugs – is time-consuming, expensive, often
repetitive, and subject to human error. Automated testing, in which Quality Assurance
teams use software tools to run detailed, repetitive, and data-intensive tests
automatically, helps teams improve software quality and make the most of their always-
limited testing resources. Test automation tools like TestComplete help teams test
faster, allows them to test substantially more code, improves test accuracy, and frees
up QA engineers so they can focus on tests that require manual attention and their
unique human skills.

Use these top tips to ensure that your software testing is successful and you get the
maximum return on investment (ROI):
1. Decide what Test Cases to Automate

2. Select the Right Automated Testing Tool

3. Divide your Automated Testing Efforts

4. Create Good, Quality Test Data

5. Create Automated Tests that are Resistant to Changes in the UI

Decide What Test Cases to Automate

It is impractical to automate all testing, so it is important to determine what test cases
should be automated first.

The benefit of automated testing is linked to how many times a given test can be
repeated. Tests that are only performed a few times are better left for manual testing.
Good test cases for automation are ones that are run frequently and require large
amounts of data to perform the same action.

You can get the most benefit out of your automated testing efforts by automating:

 Repetitive tests that run for multiple builds.

 Tests that tend to cause human error.

 Tests that require multiple data sets.

 Frequently used functionality that introduces high risk conditions.

 Tests that are impossible to perform manually.

 Tests that run on several different hardware or software platforms and configurations.

 Tests that take a lot of effort and time when manual testing.

Success in test automation requires careful planning and design work. Start out by
creating an automation plan. This allows you to identify the initial set of tests to
automate, and serve as a guide for future tests. First, you should define your goal for
automated testing and determine which types of tests to automate. There are a few
different types of testing, and each has its place in the testing process. For instance,
unit testing is used to test a small part of the intended application. To test a certain
piece of the application’s UI, you would use functional or GUI testing.

After determining your goal and which types of tests to automate, you should decide
what actions your automated tests will perform. Don’t just create test steps that test
various aspects of the application’s behavior at one time. Large, complex automated
tests are difficult to edit and debug. It is best to divide your tests into several logical,
smaller tests. It makes your test environment more coherent and manageable and
allows you to share test code, test data and processes. You will get more opportunities
to update your automated tests just by adding small tests that address new functionality.
Test the functionality of your application as you add it, rather than waiting until the whole
feature is implemented.

When creating tests, try to keep them small and focused on one objective. For example,
separate tests for read-only versus read/write tests. This allows you to use these
individual tests repeatedly without including them in every automated test.

Once you create several simple automated tests, you can group your tests into one,
larger automated test. You can organize automated tests by the application’s functional
area, major/minor division in the application, common functions or a base set of test
data. If an automated test refers to other tests, you may need to create a test tree,
where you can run tests in a specific order.

Select the Right Automated Testing Tool

Selecting an automated testing tool is essential for test automation. There are a lot of
automated testing tools on the market, and it is important to choose the automated
testing tool that best suits your overall requirements.
Consider these key points when selecting an automated testing tool:

 Support for your platforms and technology. Are you testing .Net, C# or WPF applications and

on what operating systems? Are you going to test web applications? Do you need support for

mobile application testing? Do you work with Android or iOS, or do you work with both

operating systems?

 Flexibility for testers of all skill levels. Can your QA department write automated test

scripts or is there a need for keyword testing?

 Feature rich but also easy to create automated tests. Does the automated testing

tool support record-and-playback test creation as well as manual creation of automated

tests; does it include features for implementing checkpoints to verify values, databases, or

key functionality of your application?

 Create automated tests that are reusable, maintainable and resistant to changes in the

applications UI. Will my automated tests break if my UI changes?

 Integrate with your existing ecosystem. Does your tool integrate with your CI/CD pipeline

such as Jenkins or Azure DevOps? Or your test management framework such as Zephyr?

What about a defect-management system like Jira, or a source control such as Git?

 Ability to test enterprise applications. Does your tool offer out-of-the box support to test

packaged applications such as SAP, Oracle, Salesforce, and Workday?

Divide Your Automated Testing Efforts

Usually, the creation of different tests is based on the QA engineers’ skill levels. It is
important to identify the level of experience and skills for each of your team members
and divide your automated testing efforts accordingly. For instance, writing automated
test scripts requires expert knowledge of scripting languages. Thus, in order to perform
these tasks, you should have QA engineers that know the script language provided by
the automated testing tool.
Some team members may not be versed in writing automated test scripts. These QA
engineers may be better at writing test cases. It is better when an automated testing tool
has a way to create automated tests that do not require an in-depth knowledge of
scripting languages, like TestComplete’s keyword tests feature. A keyword test (also
known as keyword-driven testing) is a simple series of keywords with a specified action.
With keyword tests, you can simulate keystrokes, click buttons, select menu items, call
object methods and properties, and do a lot more. Keyword tests are often seen as an
alternative to automated test scripts. Unlike scripts, they can be easily used by technical
and non-technical users and allow users of all levels to create robust and powerful
automated tests.

You should also collaborate on your automated testing project with other QA engineers
in your department. Testing performed by a team is more effective for finding defects
and the right automated testing tool allows you to share your projects with several
testers.

Create Good, Quality Test Data

Good test data is extremely useful for data-driven testing. The data that should be
entered into input fields during an automated test is usually stored in an external file.
This data might be read from a database or any other data source like text or XML files,
Excel sheets, and database tables. A good automated testing tool actually understands
the contents of the data files and iterates over the contents in the automated test. Using
external data makes your automated tests reusable and easier to maintain. To add
different testing scenarios, the data files can be easily extended with new data without
needing to edit the actual automated test.

Typically, you create test data manually and then save it to the desired data storage.
However, TestComplete provides you with the Data Generator that assists you in
creating Table variables and Excel files that store test data. This approach lets you
generate data of the desired type (integer numbers, strings, boolean values and so on)
and automatically save this data to the specified variable or file. Using this feature, you
decrease the time spent on preparing test data for data-driven tests. For more
information on generating test data with TestComplete, see the Using Data Generators
section in TestComplete’s help.

Creating test data for your automated tests is boring, but you should invest time and
effort into creating data that is well structured. With good test data available, writing
automated tests becomes a lot easier. The earlier you create good-quality data, the
easier it is to extend existing automated tests along with the application's development.

Create Automated Tests That Are Resistant to

Changes in the UI
Automated tests created with scripts or keyword tests are dependent on the application
under test. The user interface of the application may change between builds, especially
in the early stages. These changes may affect the test results, or your automated tests
may no longer work with future versions of the application. The problem is automated
testing tools use a series of properties to identify and locate an object. Sometimes a
testing tool relies on location coordinates to find the object. For instance, if the control
caption or its location has changed, the automated test will no longer be able to find the
object when it runs and will fail. To run the automated test successfully, you may need
to replace old names with new ones in the entire project, before running the test against
the new version of the application. However, if you provide unique names for your
controls, it makes your automated tests resistant to these UI changes and ensures that
your automated tests work without having to make changes to the test itself. This also
eliminates the automated testing tool from relying on location coordinates to find the
control, which is less stable and breaks easily.

Create an Automated Test Now with TestComplete

 Start Free Trial

Conclusion
The best practices described in this article are the path to successful test automation
implementation. TestComplete includes a number of features that help you follow these
best practices:

 With TestComplete you can perform different types of software testing

 TestComplete allows you to divide your test into individual test parts, called test items test

items, and organize them in a tree-like structure. It lets you repeatedly use individual tests

and run them in a certain order.

 TestComplete supports keyword-driven testing. These automated tests can be easily created

by inexperienced TestComplete users or when a simple test needs to be created quickly.

 TestComplete supports five scripting languages that can be used for creating automated test

scripts: VBScript, JScript, DelphiScript C++Script and C#Script.

 With TestComplete, QA engineers can share a test project with their team.

 TestComplete offers a Name Mapping feature that allows you to create unique names for

processes, windows, controls and other objects. It makes your object names and tests

clearer and easier to understand, as well as, independent of all object properties and less

prone to errors if the UI changes. This feature allows you to test your application successfully

even in the early stages of the applications life cycle when the GUI changes often.

 There are a lot of other features that TestComplete provides to help you get started quickly

with your automated testing.

Adapting these recommended best practices and using TestComplete’s features can
help you avoid common mistakes and improve your automated testing process. This
helps you test faster, save money and get your products released on time. If you
haven’t tried TestComplete, download and try it today for 30 days.

You Might Also Like

Article