Model Driven Testing: requirements, models & test

Hier soll der Titel reinDigital Transformation – Evolution, Innovation, Disruption
www.qs-tag.de
Organisator: imbus AG www.qs-tag.de
Model Driven Testing
Requirements, models & test
Gregory Solovey
Company
Logo

Our ultimate goal is to deliver products with
zero implementation defects (the shift left
testing).
This presentation emphasizes the
requirements’ testability aspects – properties
that allow to build a complete test.
Goal

40 years of Model Driven Testing
MDT is related to exploratory test
as computer science expert to business domain expert

Part 1. Test-Friendly Requirements – what are they?
From attributes of ideal tests to attributes of ideal requirements
Part 2. Support test completeness – how to proceed
if we have “good” requirements?
Use modeling tool, combine test management with the modeling tool,
hold reviews, monitor test quality
Part 3. Embed Test-Friendliness – what to do if we
don’t have “good” requirements?
Examples/exercises
Agenda

Part 1
Test-Friendly Requirements
GOAL

A Google search on “requirements testability” will
return the following criteria:
Atomic, Complete, Consistent, Controllable,
Formalized, Non-Conjugated, Observable,
Quantitative, Traceable, Unambiguous, Unitary
The common sense definitions of these criteria are
not always obvious guidelines for creating “testable”
requirements.
Ideal Requirements

A false sense of security
REQs TEXT
RPREQ_1500
As Application_3 SW, I want Platform SW to control state
LEDs during early HW start-up, warm and cold reset, so that
“state LEDs” indicate when module is in resetting phase and
initialized.
RPREQ_1747
As Application_3 SW, I want Platform SW to set color and
pattern on state and interface LEDs according to received
requests, so that I can see a state of a particular unit.

Counter-example – not so ideal requirements
Use case diagram (1 diagram): start-up, cold/ warm reset/ OFF for various boards
Activity diagram (7 diagrams): Algorithms/ conditions of start-up, cold/ warm reset/ OFF
Sequence diagram (4 diagrams): Message exchange for LED settings

Counter-example – not so ideal requirements
The model associated with these requirements includes
more data, such as:
 HW/OS/browser variants and respective state machines
 Different number of LEDs per HW variants
 Different sequence of colors (RED, GREEN, YELLOW) and
color pattern changes for various events (stable, blinking,
alternating)
When using formal test design methods, more than 240
test cases are required to find all implementation errors.
But testers can get away with writing just two test cases to
cover the two requirements.

First, we will define what an “ideal test” is - what are
its attributes and constraints.
Next, we will infer the attributes and constraints of
requirements which support ideal tests.
From test to requirements

1. Complete
1.1. contains clearly set pre-conditions, stimuli, and expected results
1.2. covers all requirements, models
1.3. covers all implementation errors
2. Effortless to create
2.1. uses known test design methods
2.2. uses manageable model sizes
3. Reviewable
3.1. mirrors the object structure and behavior
4. Executable
4.1. is controllable: can be initiated from external interfaces
4.2. is observable: the execution results are accessible
5. Maintainable
5.1. requires a single testware update for a single requirement change
5.2. is traceable to requirements to support debugging
Ideal Test

1.1. Contains clearly set pre-conditions, stimuli,
and expected results
Complete
given <preconditions>,
when <test actions>,
then <expected result>
Unambiguous
Each requirement should allow to clearly define
the expected results.

Vague descriptions
• “...Its responsibilities include, but are not limited to...”
• “...performs timely switch...”
• “…achieve a more accurate phase alignment…”
• “…most likely in 20-40 seconds ranges...”

Complete
1.2. Covers all requirements
Traceable
Implement tagging for each requirement. The tags can then be
included in the tests, to link them to the requirements. This allows
to calculate the end-to-end coverage (section traceability). This is
necessary but not sufficient.

Complete
1.3. Covers all implementation errors
A test is designed to uncover an error. If a system
component is described informally in business terms
(in spoken language), only a subject-matter expert can
define the associated tests. However, the
completeness of such a test cannot be proved.

Contra-example
The fault FAULT_GPS_RECEIVER_FAIL is raised by the TimingUnit if
GPS is in the sync source list and the TimingUnit receives this fault from
the GPS indicating that there is a communication failure to the GPS
receiver. This is of major severity and causes TimingUnit to transition to
“Enabled / Degraded” state. Additional info field should be filled with the
content of the additional info field from GPS fault notification. The fault
can also be generated by TimingUnit directly, when it detects that current
protocol is mismatching with provisioned priority list.
The fault description and the model (scenario/algorithm), where this
object is used have to be separated. Without the full context, it is
challenging to understand how the action has to be taken, what are the
values to set and how to verify them. The tester should not have to piece
together an algorithm from pieces found in different object descriptions.

Complete
Errors are well defined only for formal models (UML-like). The
completeness can be achieved only for a test built to cover all
conventional errors of a formal model.
There are a few types of commonly used formal models:
• Structural diagrams: class, object, component
• Behavioral diagrams: use case, activity diagram (algorithm),
state machine, sequence
All implementation errors fall in the “swap” category, where one of
the object’s elements is inadvertently swapped with another
element of the same type. Such errors cannot be detected by a
syntax analyzer.

Complete
• Arithmetic expressions: α + β
Error Model: α  β, α  constant; ‘+’  ‘-’
• Relational expressions: α == β
Error Model: α  β, α  constant; ‘==’  ‘<=’
• Logical expressions: α ∧ β
Error Model: α  β, α  constant; ‘∧’  ‘∨’
• Algorithm: a set of functional and conditional blocks and the
connections among them.
Error Model: expression and connection errors
• State Machine: a set of states and a set of events that transfer
control between states and generate outputs.
Error Model: transfer and output function errors

Effortless to create
2.1. Uses known test design methods
Hierarchy of UML diagrams
For known SW models (UML diagrams) there are known test
design methods that guarantee the minimum set of test cases that
can detect all known error classes.

Effortless to Create
2.2. Uses manageable model sizes
Limit model size
In the software testing world, in contrast with VLSI, the automation of test
generation is very rarely used. Therefore, independent software
components have to be reasonably sized for manual test creation. It
should be possible to evaluate the completeness and correctness of the
test in the limited time of a test review. The size of a requirement that a
tester can analyze independently should be limited to approximately ten
objects: states in a finite automaton, "if" statements in an algorithm,
objects and methods in an OO model, message exchanges in a
sequence diagram, elements of GUI, etc. The approach is to "divide and
conquer". If the subsystem description is much bigger than the “desired”
size, then some elements (nodes of state machine, algorithm blocks,
message sequence, etc.) have to be broken in separate units and
presented as child diagrams.

Unmanageable model size
This “Resource Object” state diagram has 15 states, 4 decision blocks, 75
transitions with conditions. Testing will require more than a thousand test
cases, and the review of their completeness is not feasible.

Reviewable
3.2. mirrors the object structure and behavior
Top-down hierarchy of SW models (UML diagrams).

Executable
Test harness - input to design document
Each test case must comply with the testability prerequisites, namely
controllability and observability. It should be possible to launch each test
case from an external interface (accessible by the tester) and the results
of its execution should be available for a verdict. However, the nature of
the object-to-test (especially for embedded systems) is that sometimes
there is no direct access to APIs, messages and internal attributes that
are required to execute the test.
A test harness is a set of "instruments" that provides the ability to access
APIs, test functions and database content, or to send messages. A test
harness can be implemented as a set of CLI commands, GUI objects, or
http requests.

Controllability issues
The attribute BIST_RESULT (Self Test Result) represents
the aggregated initialization results (PASS/ FAIL) from all of
the drivers managed by the TimingUnit.
The requirement is not controllable: What are the drivers?
Do all drivers count? How to simulate “fail” driver self test
verdict?

Executable

Executable
CLI access

Executable
HTTP access
Structure a url as a RESTfull API:
http://<object>.com:10080/<appl>/<api_name>/<parameter>?token=<value>
DB access
Define keywords which are translated into SQL queries, from
templates stored in libraries. Provide connection to the database
and return results to the user interface.

Maintainable
5.1. requires a single testware update for a single
requirement change
5.2. is traceable to requirements to support debugging
Avoid model duplication
The diagrams and their elements used by other diagrams should
be uniquely defined. This ensures that only one set of test cases
will be created. Any changes in the model will trigger the
respective testware changes in a single place.
End-2-End two-way traceability allows
• control coverage
• refer to the models during debugging
• select test cases to update, when the requirements are
changed

Summary - Ideal Requirements
• Present an object as a top-down hierarchy of SW models
as deep as necessary, where an element of the model can
be elaborated by another model.
• Each model is to be presented in a clear and unambiguous
manner, using UML diagrams, such as use case,
algorithm, state machine, sequence diagram, syntax,
condition, etc.
• Identify each diagram/ its elements with a unique tag.
• Use references to existing models instead of duplicating
them.
• Each model should consist of no more than 10 elements,
which is practical for manual test generation.

Part 2
Lines of defense for test
completeness
GOAL

First line of defense:
use a modeling tool
GOAL

Object – structural view
Modern software is architected as
layered (often embedded) systems.
Lower layer modules provide services
to the higher layers.
Object to be developed
Higher level entities
Low level entities
APIs Messages
System
settings
Faults
Application/
Business
layer
Application
1
Application
2
Application
6
Middleware/
Platform
layer
Service
1
Service
2
Service
3
HW
abstraction
layer
Component
1
Component
2
Component
3
Interface
layer
API
1
API
2
API
7

Object – behavioral view
Higher level entities
Low level entities
APIs Messages
System
settings
Faults
IQXC
(1) SCN E/NA/NA
(2) framer reset (link)
TU
(1) ACN (PhaseEnable)
CPRI Driver
if (SelfTest [GRro] eq "PASS" and SelfTest[SEro] eq "PASS
and SelfTest[PTMro] eq "PASS“)

Model hierarchy – Nokia
Let’s take a look at an approach using MagicDraw.
• 1st level: Use case diagram: describes the main
functionality based on customer requirements
• 2nd level: Activity diagram: describes the
functionality as algorithms and/or state machines
• 3rd level: Sequence diagram: describes the
interactions between components of the 3rd level
during the execution of an activity
• 4th level: Individual activity diagram: describes the
behavior of 3rd levels’ components .

Object – behavioral view
Use case
Diagram 1
Activity
Diagram 9
Sequence
diagram 5
Activity
diagram 3
Sequence
diagram 2
Sequence
diagram 7
Activity
diagram 3
Use case
diagram 2
Activity
Diagram 5
Activity
Diagram 3
Activity
diagram 9
State
machine 8
Activity
diagram 3

Diagram hierarchy
Application/
Business
layer
Application 1 Application 2 Application 6
Middleware/
Platform
layer
Service 1 Service 2 Service 3
HW
abstraction
layer
Component 1 Component 2 Component 3
Interface
layer API 1 API 2 API 7

Model hierarchy – graphical view

A tool is not a panacea
Modeling tools are better than general-purpose document
tools. However, they do not support the testability guidelines
out-of-the-box and still make it possible to:
• define models outside a top-down hierarchy
• present a model as plain English text
• not include interfaces into the models
• use multiple copies of unique models
• have models with unmanageable numbers of elements
Without additional customization (verification rules, for
example), none of the tools explicitly support Test-Friendly
Requirements guidelines.

Second line of defense:
Incorporate a test management
into the modeling tool
GOAL

Testware hierarchy
• A Test Plan is one of the traditional test types, such as
application, feature, sanity, regression, performance,
integration, etc.
• A Test Suite reflects the structural view of the object-to-test.
• A Use Case presents the behavioral view, such as end-to-
end scenarios or business functions.
• A Test Case is a set of actions, such as a message
exchange with the object-to-test, with one compare
statement.

Model – Test
Use case
Diagram 1
Activity
Diagram 9
Sequence
diagram 5
Activity
diagram 3
Sequence
diagram 2
Sequence
diagram 7
Activity
diagram 3
Use case
diagram 2
Activity
Diagram 5
Activity
Diagram 3
Activity
diagram 9
State
machine 8
Activity
diagram 3
Application/
Business
layer
Applicatio
n 1
Applicatio
n 2
Applicatio
n 6
Middleware/
Platform
layer
Servic
e 1
Servic
e 2
Servic
e 3
HW
abstraction
layer
Componen
t 1
Componen
t 2
Componen
t 3
Interface
layer
API
1
API
2
API
7
A behavioral model is associated with a
hierarchy of test objects. Four test hierarchy
layers must be put in relationship with
several diagram layers.

Model–Test relationship
• A test plan is defined for a sub-system, for example
regression, sanity, several feature and performance test
plans. A regression test plan has to check all sub-system
diagrams. A feature test plan has to check only the
diagrams that describe that feature’s functionality.
• A test suite is created for each diagram that needs to be
checked.
• A use case is associated with scenarios, tasks,
procedures, functions of each diagram.
• A test case initiates a set of actions that produce a
system response to be compared with the expected
result.
• All test cases should be built using known test design
methods for the specific UML diagram type

Third line of defense:
provide E2E reviews
GOAL

Review processes
Code & keywords
development
Test automation
Design
creation
Test Plan
creation
Requirements/
Design review:
Testability
Test Plan review:
Test completeness
& traceability
Code review:
Test harness
Architecture/
Feature
creation
Test Script review:
Test readability
Continuous
Integration

Requirements Review process
During the requirements review testers should verify that the
document complies with the test-friendly guidelines:
• the document is presented as a top-down hierarchy of UML
diagrams of acceptable sizes.
• all object attributes, messages, and APIs are accessible
from external interfaces. If not, request should be made to
developers to implement respective test harness

Design Review process
Developers should implement a test harness prior to
testing. This requires that additional time be allotted in
the project plan. Based on our experience, the
overhead is approximately 5%. Developers always
dedicate time to incorporate hooks, simulators, code
traces in order to execute their unit test. The same
debugging code can be reused as a base for the test
harness.
Note that the test harness has to be defined during the
requirements/ design review, before development
starts, and it has to be available at code submission
time.

Test Plan Review process
Reviewers should make sure that tests:
• exist for each element of the object
structural view. This guarantees the test
completeness.
• exist for each diagram of the object-to-
test behavioral view (hierarchy of
models). This guarantees the test
completeness.
• are built using known test design
methods. This proves that all
implementation errors are covered.

Fourth line of defense:
Monitoring test quality
GOAL

Quality Monitoring
A system is as good as its weakest link. It is important that
organizations monitor the test quality by employing
dashboards that present the following quality metrics (KPIs at
the release/project/feature/component level):
• Requirements’ format
• Test harness implementation by development groups
• Requirements/ diagrams coverage by tests
• Abstract tests coverage by automated regression and
feature test scripts
• Code coverage by automated unit tests

Quality Monitoring
Requirements-Models-Tests repository CI/ CD/ DevOps environment
Quality Dashboards:
• system components coverage by test
• new features coverage by test
During each step of product development, starting from customer requests,
through requirements, design, test, and finally to automated scripts, it
should be possible to measure the coverage of artifacts generated in each
process step by artifacts produced in the next step. The coverage can
ultimately be cumulated across all system artifacts.

Quality Dashboard
Reqs/
Model
review
traceability
formal-ability
Test Plan
review
traceability
testability
completeness
Code
review
keyword
Codecover
covera
ge
Model-test
Test-script
Appl 1
Appl 2
Appl 3
Appl 4
Appl 5
Appl 6
Select to
compare FIDsSelect to
compare
technologies
Select to
compare
applications
OSs
Browser
FID 252
FID 345
Config
Devices
FID 297
FID 985
FID 176
FID 418
FID 274
FID 518
FID 273
LS14.1
LR14.3
LR15.1
Select to
compare
releases

Part 3
Embed Test-Friendliness
GOAL

Not so friendly requirement
Theoretically, an architect, developer,and tester need to proverequirements completeness andconsistence, but, practically, eachhave different objectives during therequirements review process. Anarchitect’s main goal is to check thecompleteness of requirements, theirconsistency, and how they reflect thecustomer expectations. Thedeveloper tries to make sure thatthere is enough data to Verify that allattributes, messages, and commandsare acceptable from externalinterfaces. If that is not the case,make notes to request access to pre-conditions and triggers in the TestPlan as a test harness, which shouldthen be implemented by thedevelopers.1.Verify that the model section of therequirement description is presentedas one of the traditional softwaremodels: state machine, ladderdiagram, algorithm, syntax,instruction set, etc.
<Start Requirement ABC_456>
<Finish Requirement ABC_456>

Plain English
on the ES interrupt, the X_Monitor performs a “double
reading” of the TOD (Time Of the Day) to recover the GPS
TOD for the next ES. It means the X_Monitor reads the
framer register of HSIQ driver with framerid#0 on this ES
interrupt and repeats the reading on next ES interrupt to
confirm the accuracy of the HSIQ TOD. If confirmed,
GpsTime TOD on last ES is initialized and Linux timestamp
is memorized.
The description is in plain English. None of the architects/
developers/ testers were able to explain this description
without looking at the source code.

Attempt to implement
All truth passes through three stages.
First, it is ridiculed.
Second, it is violently opposed.
Third, it is accepted as being self-evident.
–Arthur Schopenhauer
Stage 1
“Testers’ prerogative is to learn the business and technology in order to verify their
implementation, and it’s not to dictate to us how to change the documentation
culture”.
Stage 2
“We (system engineers and architects) are the experts, and we know that too
much formalization and formatting will dramatically slow down the requirements’
delivery”.
Stage 3
“This is well known stuff and we already monitor traceability, conduct reviews and
use UML models where possible”.

1. Use authority to request support from
architects or specification specialists.
2. Do it yourself and confirm correctness
from architects or specification specialists.
Transformation

Instructions
For the purposes of this exercise we will use simplified instructions:
• Describe an object as a top-down hierarchy of UML diagrams, as deep
as necessary, where an element of the diagram can be elaborated by
another diagram.
• Each diagram should consist of no more than 10 elements
• The process of model elaboration should stop at the level where
programming language data structures are specified (arrays, hashes,
pointers, DB schemas, etc).

Triangle Example
A function that reads three numbers that are the lengths of triangle edges
and returns the triangle type

Triangle Example
A function that reads three numbers that are the lengths of triangle edges
and returns the triangle type.
Iteration 1: informal requirements
A script reads three numbers that are the lengths of a triangle’s edges and
returns the triangle type.
No initial data boundaries and possible outputs are specified
Iteration 2: informal requirements; specify output
A script reads three numbers whose value is less than 30, representing the
lengths of a triangle’s edges, and returns one of four messages: “These
numbers cannot form a triangle (not a triangle) - NT”; “equilateral triangle -
ET”; “isosceles triangle - IT”; “regular triangle -RT”.
No algorithm is specified

Triangle Example
a< b+c and
b< a+c and
c< a+b
a = b a = c
b = c b =c
Not a
triangle (NT)
Equilateral
(ET)
Isosceles
(IT)
Regular
(RT)
0
2
1
1
1
1
0
0
00
Enter a, b,
c
1
53
4
1
Iteration 3: formal requirements • Model is incomplete – there
are no blocks that verify the
number and types of input
values.
• Model is way too big -
includes more than 10
elements.

Triangle Example
Req # Model
Req_1 Model: algorithm of black boxes
If ((side’s boundary conditions incorrect::req_2) OR (sides cannot form a triangle”::req_3)) {
print NT;
} elsif (a triangle is equilateral ::req_4) { print ET;
} elsif (a triangle is isosceles ::req_5) { print IT;
} else { print RT; }
Req_2 Model: syntax of application attributes
• There are three mandatory attributes of the application
• Each attribute type is a digit
• Each attribute is a positive number
Req_3 Model: a condition on the values of three sides of the triangle
((a< b+c) and (b< a+c) and (c< a+b))
((a=b) and (b=c))
((a=b) or (b=c) or (a=c))
Req_6 Model: syntax of output messages
• There are four output messages
• Format of these messages is two symbols: (NT; ET; IT; RT)
Iteration 4: test-friendly requirements

Triangle Example
TC # description a b c result
1-14 Enter less than 3 parameters , enter symbols, enter
negative and 0 values for each parameter
NT
15-17 a<b+c: 3 cases for predicate “<“, and each variable
needs to be changed
6
6
11
2
3
3
3
3
9
NT
NT
RT
18-20 b<a+c 2
3
3
6
6
11
3
3
9
NT
NT
RT
21-23 c<a+b 2
3
3
3
3
9
6
6
11
NT
NT
RT
24-26 2: a=b: three cases for predicate “=“ 11
11
3
3
11
11
9
9
9
RT
IT
RT
27-29 3: b=c (a=b) 3
11
11
3
11
11
2
11
3
IT
ET
IT
30-32 4: a=c (a<>b) 3
11
11
1
9
9
2
11
3
RT
IT
RT
33-35 5: b=c (a<>b and a<>c) 1
9
9
3
11
11
2
11
3
RT
IT
RT

A simple calculator in Google search
Enter two numbers (a,b) separated by an operator (+,-,*,/) and then enter “=”

Iteration 1:
Enter input string: [+-]?d+([,.]?d*)[+-*/]?d+([,.]?d*)=
Observe result as d+(.?d*)

Iteration 1:
Enter input string: [+-]?d+([,.]?d*)[+-*/]?d+([,.]?d*)=
Observe result as d+(.?d*)
Iteration 2: State machine
2
sign
1
bef
1
after
1
dot
1
sign
start
res
2
bef
2
dot
2
after
Error
d
+,- d
d d d
dd
+,-,*,/
,. ,. d
+,-,*,/
d
=
=
a+b
a-b
a*b
a/b

Iteration 4:
Hierarchy of state machines
2
sign
1
sign
start
resError
d
+,- d d
+,-,*,/
d
=
a+b
a-b
a*b
a/b
Enter a digit Enter a digit

Ten most frequent words
A function for efficiently displaying the ten most frequent words in a file

Ten most frequent words
A function for efficiently displaying the ten most frequent words in a file
Iteration 1: Hierarchy of algorithms
1. select all words from the file to a set of words:
Words are “w+ (‘word’ and ‘_’ characters)”, separated by “s+ (spaces,
tabs, n, r)”
2. order all words (sort the set)
3. count instances of each word in the ordered set
(count the identical words in the sequence, save the number in the
respective hash)
4. find the ten biggest numbers (sort numbers in the hash)
5. select the first ten words in the ordered hash
Iteration 2:

LED
The panes contain a LED row for each T1/E1 port. When a dial feature
card is up and an alarm is received on the associated T1/E1 port the
respective LED should be lighten. T1/E1 Alarm can be associated with
the one of the following: “loss of alignment”, or “loss of multi-frame”
at the local or remote node. In addition, the same LED indicated
receiving of ‘Alarm Indication Signal” from a board XYZ, or “RED
Alarm” from a board ABC

LED
The panes contain a LED row for each T1/E1 port. When a dial feature
card is up and an alarm is received on the associated T1/E1 port the
respective LED should be lighten. T1/E1 Alarm can be associated with
the one of the following: “loss of alignment”, or “loss of multi-frame”
at the local or remote node. In addition, the same LED indicated
receiving of ‘Alarm Indication Signal” from a board XYZ, or “RED
Alarm” from a board ABC
Iteration 1: Logical Condition
DFC - a dial feature card is up
LOA – receiving of a “loss of alignment” alarm
LMF – receiving of a “loss of multi-frame” alarm
AIS – receiving of a “loss of alignment” alarm
REA - receiving of a RED Alarm
B-XYZ – the board is XYZ
B-ABC – the board is ABC
For each T1/E1 the respective LED goes up if:
(DFC and (LOA or LMF or (AIS and B-XYZ) or (REA and B-ABC)))

Branch delay
<Requirement 124-2. Branch Delay>
The OAM sends to RFM RO “GET_BRANCH_DELAY” action request,
and as a result, the RFM RO requests delays of all associated XY
units. The RFM RO requests delay from each XY RO via
“ACTION_DELAY” message. In the case where RFM unit is
connected to a XY unit, the RFM RO monitors the state and status
changes of its XY ROs and for the absence (i.e. supervisory
notification) of the XY RO. After RFM RO has indicated acceptance of
the “GET_BRANCH_DELAY” action request, a timer (4 sec) is started
to wait for the XY ROs replies. If the timer is expired, RFM RO sends
the action complete indication with the status byte set to ERROR. If
the GET_BRANCH_DELAY is received and the XY is already absent
or not operationally enabled, the RFM RO sends an ACTION_RSP
response with the NAK_CAUSE set to NAK_RSRC_UNAVAILABLE.
Otherwise, the RFM RO return to OAM the response with delay value
for XY RO with Frame2, and double value for XY RO with Frame3.
<End. Requirement 124-2. Branch Delay>

Branch Delay
Iteration 1: Use sequence diagram

Further reading
Requirements coverage - a false sense of security
Tower of Babel insights
A Continuous Integration Test Framework
Automating Inside the Lines
Embedding testability
From test techniques to test methods
QA of testing
A Test Mature Organization
Everything You Always Wanted to Know
About Test, But Were Afraid to Ask

Finita la commedia
Thank you for attending this session
Send your comments or questions to
gregory.solovey@nokia.com

Model Driven Testing: requirements, models & test

Recommended

More Related Content

What's hot (18)

Similar to Model Driven Testing: requirements, models & test (20)

Recently uploaded (20)

Model Driven Testing: requirements, models & test