Can Agile Designer be used outside of Functional Testing?

Document ID : KB000016554
Last Modified Date : 14/02/2018
Show Technical Document Details
Introduction:

CA Agile Requirements Designer (ARD) is a sophisticated testing tool that uses the concepts of model-based testing to provide end-to-end support for requirements gathering, test design, test creation, test automation, and more. You can read more how it works and how to get started with ARD here: https://docops.ca.com/ca-agile-requirements-designer/2-6/en/getting-started.  

Question:

Can ARD be used for non-functional testing? I’m not sure exactly how this would work or if it's possible. 

Environment:
CA Agile Requirements Designer (ARD)- Agile Designer
Answer:

To start, we can reword the question to be "Can combinatoric-based testing add value to this type of testing, and specifically, can ARD help?".

 

Performance Testing:

  • To decide if ARD is right for your performance testing, you will need to ask 'Are there many different User Paths or Configurations?'.
  • If ARD can producea set of test cases for user path and configuration combinations, then the current performance testing suite can test each one. 
  • By doing this, we can have ARD find some of the more obscure paths that should scale, but might not. 
  • This helps deal with events where combinations of paths might suddenly become way more prevalent, and we need to make sure our application scales. 
  • Without ARD, when we are writing performance tests, we typically do not spend much time writing hundreds of different variations of the same scenario to build our tests, so the load on any given test can be quite a homogenous-With ARD, that variety is much easier to achieve.
  • If ARD was integrated with Taurus or CA BlazeMeter, we could create a native Taurus script (or any other open source tool) and to scale we could leverage the BlazeMeter cloud. 

 

Resilience Testing:

  • This form of testing has the same points as performance testing. 

 

Security Testing:

  • You could create a model to test different types of permissions, which would allow you to identify and test each combination easily.


Accessibility Testing:

  • With ARD, you can check combinations of devices, modes, user types, etc. 

 

Unit Testing:

  • As long as what you are testing is complicated enough, you could build a dedicated model for it. 
  • You can also imagine that if we had a model which encompassed 'Emails', but also many other things and a developer was re-writing how we parse these Emails, we could filter just for tests pertaining to Emails. Then we could generate hundreds (or more) automated tests for the application that we would have missed through manual testing. Once created, these tests could be provided to development as acceptance tests, ad-hoc and on demand. 
  • You wouldn't have to limit ARD to producing literal unit tests. You can imagine you have a finite set of unit tests that development has already written, which can each take data combinations as input. ARD can feed those value combinations and link them to differing expected results. 
  • This would mainly be useful for functions that demand that level of testing, so it may not be worth it the majority of the time, but it is possible. 

 

In summary, if a testing requirement in complex enough and has enough possible combinations, applying ARD will save time and increase the efficiency of testing.