CA Agile Requirements Designer 101 - an introduction to the general premise of Model-Based Testing.

World®
’16
Pre-Con Lab: ARD 101 or “So How
Does Any of This Work Then?”
Ben Riley – Principal Consultant Presales – CA Technologies
DO5X29L
DEVOPS

2 © 2016 CA. ALL RIGHTS RESERVED.@CAWORLD #CAWORLD
For Informational Purposes Only
© 2016 CA. All rights reserved. All trademarks referenced herein belong to their respective companies.
The content provided in this CA World 2016 presentation is intended for informational purposes only and does not form any type of
warranty. The information provided by a CA partner and/or CA customer has not been reviewed for accuracy by CA.
Terms of this Presentation

Abstract
This lab will provide an in-depth overview of CA Agile
Requirements Designer and the fundamental concepts that
underpin its approach to software design and testing.
CA Agile Requirements Designer is a flowchart-modelling tool
used by Business Analysts, Programmers, Testers and
Automation Specialists to define and automatically test
complex systems.
Ben Riley
CA Technologies
Principal Consultant,
Presales

Agenda
2 HOURS
SOME LOVELY INFORMATION
HANDS ON WITH THE TOOL
LETS SEE WHAT YOU GOT….
1
2
3
4

What Do We Want to Achieve From This?
1. Deep understanding of the tool and what it can do
2. A fuller understanding of why it is important to its users!
3. Larger awareness of typical Design-Dev-Test Challenges
4. Let’s Play…

A Few Value Proposition Slides…
Not too many, don’t panic.

Quickly and simply introduce agile processes
into your existing Waterfall Lifecycles
Agile
Requirements
Designer

Common Challenges Part 1
§ 56% of software defects can be traced back to ambiguities in
requirements1
§ Detecting and resolving production defects is over 40x more
expensive than in requirements2
§ Industry standard for manual test case design coverage is
between 10-20%
Stats: 1 and 2 - Bender RBT, 2009. Others: based on CA Technologies’ audits

Common Challenges Part 2
§ Over-testing of some functions by factors of 40 is
not uncommon
§ Change requests to existing software requirements can
take up to as much as 60% of the SDLC
§ If I make a change I have no idea the effect this will have
on up stream or downstream systems

Continuous Development
§ Continuous Integration
§ Iterative Development
§ Dev Ops
§ Is mostly Ops
§ It starts when development and
testing are complete
§ It should start when the user has an idea!

CA Agile Requirements Designer
§ There are plenty of tools to manage requirements
§ There are plenty of tools to manage test cases
§ These can be considered logistical support
CA Agile Requirements Designer is an accelerator to improve
the input to these tools
§ Is a Test Case Design and Test Case Optimization tool
§ Is a Requirements Definition tool
§ Can calculate complexity very accurately
§ Can identify change across the entire SDLC
CA Agile Requirements Designer gives you multiple outputs
for one input

What is Coverage?
The Business thinks it’s:
– Code Covered
– Number of Test Covered – Tests Run
– Percentage of use cases
– All Paired Combinations
It is actually:
– Designing Sufficient Tests To VERIFY That The Design and Code
Correctly Implement The Requirements
– Did you get the right answer for the right reason? Two or more defects
may sometimes cancel each other out – Observability

A Simple Form Easy to Test?

The User Knows what they want
The Analyst specifies what that is
The Programmer writes the code
The Tester tests the program
The further the visions diverge The greater the problems
Clarity and Vision During Development
Business Analyst Programmer TesterUser

There are less bugs and the product is delivered faster
The closer the vision means the user gets a quality product

Verify & Clarify Clear Logic Test Cases
The scope for ambiguity is much less
The product is of higher quality and
is delivered faster
CA Agile Requirements Designer:
§ Design Tests
- Minimum
- Optimal
§ Design Data
- Find it
- Make it

The Results are Often Poor

“Everything should be made as simple
as possible, but not simpler.”
–Albert Einstein
We do know that when our eyes are open, our vision accounts for two-
thirds of the electrical activity of the brain—a full 2 billion of the 3 billion
firings per second—which was the finding of neuroanatomist R. S. Fixot in
a paper published in 1957.

Tester
Project Manager /
Development Manager
Business Analyst /
Requirements Manager Test Manager
The Requirements are
conceived and created
in CA Agile
Requirements Designer.
Relevant project managers fill
out detail. This can be passed
back up the chain to Bas, etc.
Test Managers ensure
implementation issues
are tackled. Also can be
passed up the chain for
verification.
Testers receive
comprehensive,
logical test plans
and test cases.
Requirements-Based Testing Model of Test Plan
Delivery – Full Traceability

Who Would Use CA Agile Requirements Designer?
§ I can see any process flow and predict how long the development and
testing process will take
§ My Users can clearly define a process as they think of it
§ My Business Analyst can define the process, which will be verified by
the user, create logic flows for programmers and test cases for testers
§ My Programmers can verify the process with the Business Analyst before
coding and Testers with test cases
§ My Testers can quickly define functional logic flows and verify them with
the Programmer, as well define the smallest set of test cases to verify
the program
§ My Outsourcing Partners can get stable requirements and clearly defined
work packages, which result in lower ongoing costs

§ Generate test scripts that provide maximum functionality
directly from requirements
§ Quickly and easily respond to change, and avoid delays and
budget over-runs
§ Fully test software in the smallest number of runs required,
delivering quality software on time and under budget
Agile
Requirements
Designer

Just a Quick Tour of the GUI…
A few things have changed…

Back to Basics
Setting up Simple Flows

Process Blocks
§ Process blocks represent ‘doing something’
i.e. not a decision, but something happening
– for example ‘Make Tea’ or ‘Reject Loan’ –
they don’t have to be results though, another
example process could be ‘Lookup Candidate’
§ Process blocks may only have one output, as
they are not making a decision
§ Process blocks can have unlimited inputs from
other blocks (two depicted here)
§ Test Data, Automation, and many other useful
pieces of supporting data can be attached to
a process block, as we’ll see later.

Decision Blocks
§ Decision blocks represent a choice or
decision made in the flowchart, for example
‘Have water?’ or ‘Amount of loan?’
§ Based upon these decisions, decision output
may end up in different parts of the diagram,
but they doesn’t have to
§ A decision can have as many outputs as required,
and can have as many inputs as required
§ All decision block options in the toolbar can be edited after the fact to resemble the
others, they are just defaults
§ Test Data, Automation, and many other useful pieces of supporting data can be
attached to a decision block, unlike process blocks much of this is done per output
as we’ll see later.

Adding Blocks
§ To create new blocks, simply drag them on to
the canvas (right hand side) from the toolbox.
§ You can also add new blocks by clicking
on a symbol on the left, and clicking
somewhere on the diagram for it to appear.
§ For most setups, the three blocks you will
be using the most are listed here on the
right: (Start/End, Process, True/False).
§ Any decision block can be edited to have
as many outputs as necessary (think Yellow,
Red, Blue rather than True/False) so don’t
worry about that for now.

Editing Blocks
§ To edit an existing block,
double-click it (or right-
click à Edit)
§ The number of tabs can
be intimidating. Most of
them are for advance use
and you’ll never have to
know what they do.
§ Different block types have
different sets of tabs (process, decision, subflow, etc.)

Exercise 1. Go to the Shop?
§ An easy one to start, open Make Tea from the examples folder
§ Refamiliarize yourself with manipulating the UI, double click on
blocks to open them up, drag to move blocks and arrows, drag new
items from the pallet to create new blocks
§ When ready, make the following change:
“When I want milk, but do not have it, I may go to the shop, the shop may
or may not have milk – for whatever reason, if I don’t come back with
milk, I will still not make tea, if I do get milk I will make tea.”
to the diagram, adjusting the diagram to take your changes
into account

Exercise 1. Go to the Shop? – Tick Tock the clock’s
running…10 minutes…
10 5 0

Exercise 1. Go to the Shop?
Get something like this?

Exercise 2. SuperCoffee and SuperHealth
We’re going to create a new flow, based upon a free drinks scheme for
customers of SuperCoffee if they’ve done enough running at SuperHealth
Here’s how the scheme works:
1. If I have run over 10 miles in the week, I earn a free drink
2. If I have run >0 miles in the week, and I am a Gold member of SuperCoffee, I earn
a free drink
3. If I have run 5-10 miles in the week, and I am a HealthPlus member of
SuperHealth I earn a free drink, unless it is a weekend. Of course by running 5-10
miles I also qualify for No. 2 potentially.
4. I have run 0 miles, I get nothing.
5. You can only qualify for one free drink, if you earn one for any reason, you can
never invalidate it.
How many possible paths do you get?

Exercise 2. SuperCoffee and SuperHealth – Tick Tock
…20 minutes…
20 15 10
10 5 0

Exercise 2. SuperCoffee and SuperHealth
Get anything like this?
If not, why not?
Compare with your neighbours!

Generation, Storing, Options, Coverage
§ Paths are generated to specific coverage targets
§ The optimiser will always choose the minimum number of
paths to cover what it has been asked to cover
§ With the exception, of ‘All possible paths’
§ There are many options for the path optimiser, from filters, to
constraints. Typically the defaults are fine.
§ Lets have a look through…

Coverage
§ One of the main features of CA Agile Requirements Designer
is the ability to measure coverage at all times, for any
particular set of paths for any particular coverage option.
§ Typically coverage achieved by humans is poor.
§ We’re going to let the computer play chess for us.
§ Lets have a look at the coverage windows…

Storing Paths, etc.
§ Go back to make tea, or one of the flows you have created.
§ Generate targeting the ‘all nodes’ coverage option, store the
paths, and open the coverage window, what is the %? Open
the ‘more’ section to see what’s actually being covered and
what is not.
Now, finish your coverage for All in/out, using the ‘add to
existing paths’ option.
§ Now, we’ll have a look at managing stored path types…

Change Impact, the Heart of the Tool
§ The principle of CA Agile Requirements Designer is, “Lets maintain
a 40-block diagram, rather than maintain 1000s of tests/data
points/scripts”
§ When you make a change to the diagram in CA Agile Requirements
Designer, the Impact analyser will allow you to maintain the test
cases, and thus the data and scripts- it will calculate what paths no
longer make sense, and give you options as to what you’d like to do
with them, including, repair them.
For anyone who has experienced manually maintaining tests,
you might recognise having the tool do this is a much better idea!

Exercise 4. Let’s Make a Change
1. Open up the flow ‘Song Streaming’
2. Clear down the test cases in the stored path type ‘test cases’
3. Store the optimal ‘all pairs’ paths for this flow. Make sure the “Try to find paths in
previous version” is Unchecked
4. Now, implement the change “When I am not connected to 3g, or the 3g is not
fast enough, I should check (before failing as before) if I am connected to 2g,
If I am, I should wait for the buffer – else, error as before”
5. Go back to view your stored paths, examine what the path impact analyser says,
delete the effected paths
6. Now go and look at the coverage, you’ll notice it’s dropped!
7. Generate both A) the new optimal set of paths and B) just the additional paths
required to finish the coverage.

A Real World Scenario?
§ The real world isn’t so easy.
§ Goal is to have a feasible model, not a perfect one.
§ Presentation matters.
§ Logically implement what it could mean, some defensible
interpretation.

Test Data in CA Agile Requirements Designer
§ How does it work?
§ In general, the idea is to set data based on where we go in the
diagram, rather than working it all out afterwards.
§ The reasoning is this: It’s easier to make 40 data assignments on 20
blocks, rather than maintain millions of data points manually!
§ The other advantage, as alluded to before, is of course that now,
when we change our diagram, our data can automatically react too!
§ Let me show you…!

Exercise 5. Let’s Set Up Some Data
1. Open up ‘Make tea’, at each decision point, add the necessary data
assignments for each output!
2. Now, generate and store some paths.
3. Go to the test data table and examine all of the data that results.
4. Now this is all boring, hard coded (to an extent) data, but we’ll fix
that later.
5. Play around, add more variables to some of the decision outputs,
change their values, and have a look at the effect in the table.
6. Now, change the diagram in someway, and react as we did before,
now consider your new data, neat, right?

Exercise 6. Let’s Set Up a Loan
1. So lets make something (mildly) more realistic.
2. Set up a flow where we are going to be generating many different
types of loan.
3. We need a decision to decide the product code: CT50, CT33, CT48, CT49,
we must also decide the amount (for now, we will have the options
<1,000, 1,000-10,000, 10,000-100,000, >100,000)
4. We will also need a decision to set the term of the loan, (1yr, 3yr, 5yr)
5. We will need a decision to set the interest rate (<1%,1-5%,>5%)
6. All of the decisions up to now just flow into the next, but from here, we
need a true false decision ‘backdate’ , if it is true, we must have a
decision to choose a backdateTime (1days, 2-359 days, 360 days) else do
not.
Now both paths go into a ‘calculate result’ block.

Exercise 6. Let’s Set Up a Loan
§ Again, generate some paths, and have a look at your
lovely data!
§ But there are issues… how do we deal with ranges?
How do we make data referentially intact? How do we
make it more dynamic and realistic?
§ …Data expressions!

The Data Painter window
§ The Data Painter window

Exercise 7. Let’s Generate:
1. A random number between 1 and 2000
2. A Random number of digits between 3 and 7 in length,
padded to the left with 0s to a length of 7
3. Multiply two random numbers together
4. Add a random number of days to the ~CDATE~ 01/01/2009 if
cdate misbehaves
5. Randomly choose a first name from a seedlist
6. A @percval@ of any two strings, or, if you want to be fancy,
two functions!
7. An email address based on first.lastname@gmail.com (use seedlists)

Let’s Generate
§ But what about this column?

Exercise 8. Referential and Random?
1. Using the knowledge of the functions we’ve just been using, go and fix out loan
flow, so that everything is parameterised (i.e. the ranges all have a random
expression for them between that range etc.)
2. Store paths, resolve the test data
3. Now, go back to our block ‘calculate result’
4. Using the formula Payment =(Interest rate * amount )/(12 * 100) + (amount /(
term * 12)) set up the variable and expression for ‘MonthlyPayment’ remember
to reference the columns for amount, term, interest rate etc.
5. Make sure this resolves properly!
6. Examine your data in the table
7. We won’t, but if we made a change to this kind of flow, the changes would reflect
up to our data too.

Exercise 8. Referential and Random?
1. Here’s one I made earlier…
2. Testers sometimes spend up to half their time searching or
creating appropriate data for their tests! Now we can again
maintain a few blocks, rather than 10000s of data points,
and refresh our data on demand! Neat eh?
3. This will be a part of our killer demo (of course, not in
as much detail).

Filters
§ For the most part, filters are used to easily select or see parts
of the diagram
§ In the very latest version, we can also apply filters prior to and
post optimisation
§ Lets construct some filters!

Exercise 9. Filters
1. Construct a filter to only see the blocks
which have test data defined for them
2. Change the importance of the ‘don’t
make tea’ block to critical, then
combine the filter above (set to no)
with a filter which selects only
critically important blocks
3. Store a filter for later use.

Exercise 9. Filters
1. Construct a filter to only see the blocks
which have test data defined for them
2. Change the importance of the ‘don’t
make tea’ block to critical, then
combine the filter above (set to no)
with a filter which selects only
critically important blocks
3. Store a filter for later use.
4. Why would we bother with these?

Import and Deduplication
CA Agile Requirements Designer can import test cases from
many different sources! Including…
§ HPE ALM
§ JIRA
§ CA Agile Central
§ VERSIONONE
§ EXCEL

Import and Deduplication
§ So we can import test cases? What’s the point?
§ We bring in each test case on a step by step basis, typically this will mean
there duplicate steps shared across many tests.
§ In CA Agile Requirements Designer, you can have the tool suggest
duplicate blocks to you, suggestions you can then either accept or reject
on a case by case basis.
§ Once you’ve marked the duplicates, the tool can deduplicate the blocks
for you, but keeping every path intact – this leaves you with a flow that it
has inferred from the test cases you give it!
§ This is an important accelerator, but not perfect!

Exercise 10. Bring in Some Tests and Dedupe!
§ In a new flow, go to the import tab, click ‘excel/general test cases’ – select
the .docx ‘Doc_procedure_testcases’
§ Map the relevant fields to fields in CA Agile Requirements Designer
§ Hit Import!
§ Open the dedupe window underneath test factory
§ Have a play with the sensitivity settings
§ Mark all the duplicates, then hit de-dupe in the main AgD window.
§ Re-layout the resulting diagram, make any fixes/additions – measure the
coverage of the stored paths, can we do it with less test cases?

Constraints
§ Constraints allow you to layer ‘rules’ on top of the diagram in order to
achieve specific functionality without an unreasonably large flow
§ Imagine a decision near the top of a large diagram, which can be true or
false, but much later in the diagram we make the same decision – if they
have to line up how would we do this without constraints? Would we
double the size of the diagram?
§ Can anyone think of why these may be necessary
§ Lets have a look at them for real…
§ In general, you should only use constraints when the same logic cannot
(easily) be achieved by flow logic alone, and there is usually a way
to do that.

Exercise 11. Build a Useful Constraint
§ Open our ‘loan’ flow, create a constraint such that whenever
the product is CT50, the backdate must be 360
§ If you generate paths now, you will notice there will be less
§ You can optionally have the path explorer ignore constraints
§ Feel free to build up more complicated constraints in the
‘path hints’ dialogue.

Extras
§ Version comparison
§ Rich text importer
§ Word doc builder
§ Clones copies and duplicates
§ Custom excel export
§ Properties window
§ Flow validation
§ Diagram exports
§ Accelerators
§ Shapes
§ Loops

Questions?

Recommended Sessions
SESSION # TITLE DATE/TIME
DO5X23E
Pre-Con Education: Requirements are King – Better
Requirements = Better Software
11/15/2016 at 11:00 am
DO5X27S What's New in CA Agile Requirements Designer? 11/17/2016 at 12:45 pm
DO5X40S Case Study: Why Rabobank Was Inspired 11/17/2016 at 3:45 pm

Must See Demos
Data
Compliance and
Testing
CA TDM
Theater 5
Deliver Test
Data Faster
CA TDM
Theater 5
Use Model
Based Testing
CA ARD
Theater 5
Achieve
Maximum Test
Coverage
CA ARD
Theater 5

Stay connected at communities.ca.com
Thank you.

CA Agile Requirements Designer 101 - an introduction to the general premise of Model-Based Testing.

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a CA Agile Requirements Designer 101 - an introduction to the general premise of Model-Based Testing.

Similar a CA Agile Requirements Designer 101 - an introduction to the general premise of Model-Based Testing. (20)

Más de CA Technologies

Más de CA Technologies (20)

Último

Último (20)

CA Agile Requirements Designer 101 - an introduction to the general premise of Model-Based Testing.