[MUSIC PLAYING]
VIKRAM PAROLKAR: Hey, guys, Vikram Parolkar
from the test automation team.
And in today's session, we're going
to be talking about model-based testing.
So what exactly is model-based testing?
Well, it's a software testing technique
where the behavior of a system under test
is checked against predictions made by a model.
Where does this model come from?
Well, that's where most of the test-case development occurs.
A business user who has innate subject matter experience
about an application is responsible for designing
that model and mapping the behavior of an application
as different data is passed through it.
Once the model is created, AI can
be leveraged to actually generate the test cases.
So time isn't spent creating test cases.
Rather, the creation of the model.
And it's very easy to change any test cases
because you're changing a model.
So if test cases are automatically
generated for you, why is this not a more common testing
technique?
Well, there's actually inherently several challenges.
However, UiPath Test Suite has specifically
been designed to solve them.
The challenges are that there's a very steep learning
curve with traditional model-based testing.
A formal specification and experience
is required to generate these models.
And because of the long generation time,
it takes a while to actually get that first test case out there.
In addition, because of the true linking
between the model-based tests and the model
itself, any time a model is changed,
it might result in completely different test scenarios.
Thus, not really aligning for historical testing.
However, UiPath Test Suite has several features
and functionalities such as object repository,
data-driven testing, and a free academy
to easily be able to train a large number of resources
to use UiPath and replicate any value that you might experience
from traditional model-based testing tools,
while taking a unique approach to testing itself.
So let's take a look at where UiPath
falls on the model-based testing spectrum.
For manual testing, you of course,
have to manually create the test-case documentation,
define the test case, predict the outcome.
There isn't any scripting involved,
but you have to manually execute and check
the outcome of the test.
With scripting, you still have to manually create
the test-case documentation, define the test outcomes,
script the test.
But the execution of the test and checking out the outcome
is automated.
With Test Suite, we take more of a hybrid approach.
You have the option of either creating
test-case documentation or a model
with things like state machines.
However, defining the test case is a bit more automated
because AI is involved to help identify objects
and scripting of the test is a bit more automated
because you can take advantage of features data-driven testing
and execution templates to help with the generation
of your test automations.
So the first feature of note for UiPath Test Suite
is the ability to easily create these model requirements
and specifications with UiPath Test Capture.
Test Capture will allow an application SME
to create an application business
model using various BPMN icons as well as swim lanes.
You'll be able to take screenshots for each action
and actually automatically capture required metadata
to pass from the business SME to the developer team
to ultimately accelerate any timelines for development.
In addition to a model, the beauty
is that you do get robust test-case documentation
automatically.
The next aspect of model-based testing
is the actual technical interface model.
And for this, UiPath has an object repository.
In UiPath Studio on the right-hand side,
we'll see object repository.
To create one, all you have to do
is enter this recording mode.
You'll be able to add a specific application, such as UiBank,
and then be able to capture all the elements on the screen
simply by clicking a button.
Our AI computer vision will automatically
detect all the elements on the screen,
and you'll be able to either select all or pick and choose
which ones you want to capture.
The cool thing is UiPath automatically will also
help you identify anchors to ensure
that even if these objects move around on the screen,
you'll still be able to reliably interact with them.
Now that our object repository is created,
we'll see how this combines with generation of test cases a bit
later.
Moving on to the business information model,
UiPath has a unique ability to allow a developer
to create state machines.
State machines, also known as state charts,
allow a tester to define the resulting
state of an application based on different data inputs
and system conditions of an application.
There are typically a finite number of states,
and the behavior of the system is
analyzed in between each states, and only
based on specific logic conditions
will it move on to a different state.
It keeps going through this model
until it results in a final state.
Again, let's take a look at this within UiPath Studio.
In UiPath Studio, to create a state machine, all
you have to do is go to the new file location
and select state machine.
Ultimately, a state machine is a flowchart
where you can define specific application
states or a final state.
In order to create the automation for each state,
you can define entry criteria, exit criteria,
and draw arrows or define transition criteria
between states.
Since I've already defined a technical object model,
it's very easy to use these objects inside of my business
model.
You simply need to drag and drop them into the center location
and combine them with a UI action, such as a type
into or a click activity.
Now, this state machine actually has four different scenarios.
I have two phases, either an initialization phase
or a tear-down phase, and depending on that,
I can either be logged in to the application or not logged in.
So let's go through a state where I'm logged in
and an initialization phase.
In order to proceed, I can simply go to the transition.
Let's say I'm already logged in.
I'm going to then check if that user is logged in
and then move on to the check user phase.
I'll be able to check a user with this entry criteria.
And then if I already have the correct user,
I'll be able to proceed and continue with the test case.
Test case is a final state, and so I'll only
have the entry criteria for this one.
Similarly, I could have taken a number of different pathways,
but that's how state machines work.
Now that I have my business model and my technical model,
the final phase is how does UiPath
do the AI generation of test cases.
Well, UiPath opts not to use AI because we want a tester rather
than randomly defining test cases to have control
on the scope of a test case.
And so we provide AI-based features
to help with creating these test cases in a faster manner.
Two of these features are execution templates
and data-driven testing.
Returning back to studio, for something like execution
templates, this allows me to put a wrapper
of repeated steps, such as initialization and teardown,
around all of my test cases.
This is an example of a test-case template where
I've simply invoked my state machine
as a reusable component.
As you recall, there were two phases,
the initialization phase is what I put at the beginning,
and the teardown phase is what I put at the end.
I can establish and assign this execution template
to my test case here.
Now, once I've defined a test case,
I can also pass as much data as I want to it.
In order to add test data and make a test case
a data-driven test, all I need to do
is navigate to my project pane, simply right click my test
case, and add test data to it.
I can select test data sources from either an Excel file
or UiPath's own data service.
In this case, I'll go ahead and select a file.
The test data is imported and here, you'll
notice I have two test scenarios.
So again, I've simply just created one test case,
but now, it'll operate regardless
of the initial or final state of an application
and execute multiple data scenarios
as I have defined in my test-case template.
To execute this during design time, all I need to do
is navigate to my test explorer and run my workflow.
You'll see my robot spin up, and UiBank is actually
on a random page.
It's already open.
However, that won't impact my test case because of our state
machine.
The state machine is going to recognize that UiBank
is already logged in.
It's going to check the user that it's logged in as,
and then determine whether any action is needed
or if it can proceed with the test case.
In our second data-driven test, we're actually already logged
out, and so the test case will be
able to identify the state of the application,
log in, and then proceed with applying for a loan.
At the end, we'll tear down by logging out,
and that's a quick demo of UiPath's unique approach
to model-based testing.
Until next time, bye.
[MUSIC PLAYING]