Functional Testing

Appian Max Team — Tue, 23 Apr 2024 13:22:14 GMT

Current Revision posted to Guide by Appian Max Team on 4/23/2024 1:22:14 PM

Introduction

Functional testing is required to verify that a software application performs correctly according to design specifications. It provides you with the opportunity to identify any defects which would prevent the application from being unfit for users.

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole.
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint.
- During development, unit test and set status to "Ready to Test" for peer review and system testing.
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint.
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases.
- They should attend each sprint demonstration to know what to expect.
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing.
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0.
- Don't wait until the last minute!
UAT should occur after every sprint.
- Defects caused by test cases that fail can be rolled into future sprints.

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories.
Create individual test cases that are easy to test; they can even be automated.

Unit Testing

Unit tests are typically performed by each developer before integrating a component into the larger system. Their purpose is to confirm that the component is sufficiently complete and correct to integrate without causing undue impact on the rest of the development team. Unit tests should be performed on each component prior to its integration into any larger system. They are not supervised by the QA team, and results do not need to be documented and managed.

What is Unit Testing?

Unit Testing is the testing of “units” or “components” of a system during the development process by the developer. Unit Testing should occur at the smallest or most granular level of developed code such as an Appian object or even a piece of logic inside an Appian object. Unit Testing should then be expanded to test whether objects interact with each other appropriately.

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

If new connections such as an integration, a subprocess being inserted into a process model, or a database connection are part of the story being developed, System Integration Testing should also be performed as part of Unit Testing.

Why is Unit Testing important?

Unit Testing is important for many reasons. It improves quality of developed work, it increases efficiency by allowing developers to find and resolve issues that could arise in QA testing, UAT, or even in production, and thorough Unit Testing leaves a developer and team confident in developed work.

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

User Acceptance testing is the formal, contractual verification of an application by the end user team designated by the Product Owner. It is primarily performed by the end users, and the delivery team only has a supporting role. Even with this limited role, management of the process is critical to project success - UAT should happen with every delivered increment and end user involvement is critical to project success.

Tags: Delivery, testing

Functional Testing

Appian Max Team — Tue, 02 Apr 2024 15:07:17 GMT

Revision 16 posted to Guide by Appian Max Team on 4/2/2024 3:07:17 PM

Introduction

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole.
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint.
- During development, unit test and set status to "Ready to Test" for peer review and system testing.
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint.
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases.
- They should attend each sprint demonstration to know what to expect.
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing.
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0.
- Don't wait until the last minute!
UAT should occur after every sprint.
- Defects caused by test cases that fail can be rolled into future sprints.

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories.
Create individual test cases that are easy to test; they can even be automated.

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Tags: Delivery, testing

Functional Testing

Kim Day — Tue, 31 Oct 2023 16:37:21 GMT

Revision 15 posted to Guide by Kim Day on 10/31/2023 4:37:21 PM

Introduction

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole.
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint.
- During development, unit test and set status to "Ready to Test" for peer review and system testing.
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint.
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases.
- They should attend each sprint demonstration to know what to expect.
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing.
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0.
- Don't wait until the last minute!
UAT should occur after every sprint.
- Defects caused by test cases that fail can be rolled into future sprints.

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories.
Create individual test cases that are easy to test; they can even be automated.

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Tags: Delivery, testing

Functional Testing

Kim Day — Tue, 31 Oct 2023 15:09:40 GMT

Revision 14 posted to Guide by Kim Day on 10/31/2023 3:09:40 PM

Introduction

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole.
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint.
- During development, unit test and set status to "Ready to Test" for peer review and system testing.
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint.
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases.
- They should attend each sprint demonstration to know what to expect.
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing.
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0.
- Don't wait until the last minute!
UAT should occur after every sprint.
- Defects caused by test cases that fail can be rolled into future sprints.

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories.
Create individual test cases that are easy to test; they can even be automated.

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Tags: Delivery, testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:58:39 GMT

Revision 13 posted to Guide by joel.larin on 10/25/2023 2:58:39 PM

Introduction

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole.
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint.
- During development, unit test and set status to "Ready to Test" for peer review and system testing.
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint.
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases.
- They should attend each sprint demonstration to know what to expect.
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing.
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0.
- Don't wait until the last minute!
UAT should occur after every sprint.
- Defects caused by test cases that fail can be rolled into future sprints.

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories.
Create individual test cases that are easy to test; they can even be automated.

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:55:51 GMT

Revision 12 posted to Guide by joel.larin on 10/25/2023 2:55:51 PM

Introduction

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole.
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint.
- During development, unit test and set status to "Ready to Test" for peer review and system testing.
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint.
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases.
- They should attend each sprint demonstration to know what to expect.
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing.
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0.
- Don't wait until the last minute!
UAT should occur after every sprint.
- Defects caused by test cases that fail can be rolled into future sprints.

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories.
Create individual test cases that are easy to test; they can even be automated.

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:54:40 GMT

Revision 11 posted to Guide by joel.larin on 10/25/2023 2:54:40 PM

Introduction

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:53:47 GMT

Revision 10 posted to Guide by joel.larin on 10/25/2023 2:53:47 PM

Introduction

How to Perform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:52:23 GMT

Revision 9 posted to Guide by joel.larin on 10/25/2023 2:52:23 PM

Introduction

How to Peform Functional Testing

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:50:25 GMT

Revision 8 posted to Guide by joel.larin on 10/25/2023 2:50:25 PM

Introduction

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:49:38 GMT

Revision 7 posted to Guide by joel.larin on 10/25/2023 2:49:38 PM

Introduction

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:49:04 GMT

Revision 6 posted to Guide by joel.larin on 10/25/2023 2:49:04 PM

Introduction

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing vs User Acceptance Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:47:21 GMT

Revision 5 posted to Guide by joel.larin on 10/25/2023 2:47:21 PM

Introduction

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing vs User Acceptance Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:46:36 GMT

Revision 4 posted to Guide by joel.larin on 10/25/2023 2:46:36 PM

Why Perform Functional Testing?

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing vs User Acceptance Testing

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:45:45 GMT

Revision 3 posted to Guide by joel.larin on 10/25/2023 2:45:45 PM

Introduction

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing vs User Acceptance Testing

What is Unit Testing?

When to Unit Test?

Unit Testing occurs throughout the development cycle, but specifically at the following points:

During story development as objects are created/updated.
After story development is complete and before the functionality is incorporated into the larger application.
During a peer review.
After implementing changes from a peer review.

Why is Unit Testing important?

How to Unit Test:

The strategy for Unit Testing will be different for different object types. Below are instructions for how different types of objects should be Unit Tested:

Expression Rules: Expression rules can be Unit Tested by using expression rule test cases. For more information on using expression rule test cases, see the Creating Expression Rule Test Cases Playbook play and the Expression Rule Testing with Appian Documentation page. Make sure all Unit Tests performed on expression rules are saved as test cases so that they can be automated in the future. Be sure to set up test cases to test the functionality of the rule by asserting outputs when possible and not resorting to only using “no error” assertions.
Interfaces: Interfaces can be Unit Tested manually or Unit Tested with automated testing tools like Fitnesse for Appian or the Appian Selenium API. The developer should consider what possible inputs a user can input on the interface and test these scenarios with varied and representative rule inputs, if applicable. Individual interfaces should be Unit Tested in designer with appropriate rule inputs and interactions before integrating into parent interfaces. Once the interface is integrated into its parent interfaces, general functional, AC, and exploratory testing should capture all front end flows with a test-user account.
Process Models: Process models need to be Unit Tested manually. All flows of a process model should be Unit Tested. Make sure that all subprocesses are thoroughly Unit Tested before incorporating them into a parent process. Process models that employ interfaces should also be Unit Tested to ensure that the interface’s values are correctly saved.
Decision Rules: Decision rules should be initially tested in the decision rule editor to ensure that correct values are returned when valid and invalid inputs are passed. Once decision rules have been tested in the editor, they should be wrapped in an expression rule wrapper. Wrapping them in an expression rule allows the usage of expression rule test cases and allows their testing to be automated. Finally, the expression rule that wraps the decision should also be tested in the context of wherever it is called whether it be another expression rule, an interface, a process model, etc.

Note that the above is not an exhaustive list of object types that need to be Unit Tested and it is also not an exhaustive list of strategies for Unit Testing the listed object types.

Functional Testing

joel.larin — Wed, 25 Oct 2023 14:43:41 GMT

Revision 2 posted to Guide by joel.larin on 10/25/2023 2:43:41 PM

Why Perform Functional Testing?

What Should You Test?

Developers should unit test before promoting to the Test environment to reduce the number of defects in functional testing.
End-to-end integration testing in the Test environment - make sure pieces that were developed independently can properly operate as a whole
Regression testing - retest previously tested functionality if the following has occurred:
- Shared Object updates
- Post integration updates
- Updates to previously released code

When Should You Test?

Unit testing should occur on a regular cycle throughout the sprint
- During development, unit test and set status to "Ready to Test" for peer review and system testing
- At the end of sprint development, move the application to the Test environment and run regression and system tests before releasing to the Test team for functional testing.
Testers should be involved in the sprint
- They should attend the sprint planning to give them the visibility to prepare the appropriate test cases
- They should attend each sprint demonstration to know what to expect
- Allow the testers to ask questions at the end of the demo to limit clarifications and bottlenecks during testing
- Definitions for "Ready for Test" and “Done” should be defined in Sprint 0
- Don't wait until the last minute!
UAT should occur after every sprint
- Defects caused by test cases that fail can be rolled into future sprints

How Should You Test?

Make a test plan based on the acceptance criteria in the user stories
Create individual test cases that are easy to test; they can even be automated

Unit Testing vs User Acceptance Testing

Functional Testing

joel.larin — Wed, 13 Sep 2023 13:40:06 GMT

Revision 1 posted to Guide by joel.larin on 9/13/2023 1:40:06 PM

DFAS