>> Hi, I'm Donovan Brown.
Principal DevOps manager from Microsoft.
Manual testing can be
a key testing technique to
deliver a great user experience.
Both Visual Studio Team Services and Team Foundation
Server offer the features you
need to manage your testing effort.
From manual and exploratory test,
to load and stress test.
Let's jump right in, let me show you how you get started.
To begin with manual testing,
I'm going to start right here on
the landing page of Visual Studio Team Services.
I know which count I want to start testing on,
and from here I can simply click on the "Test link".
This is going to take me to my 'Test
plans' tab of Visual Studio Team Services.
I happen already have a test plan created.
I'll show you how I created that
and also what configurations are,
which are incredibly important
when you're trying to build out a test matrix.
Actually, let's start with configurations.
If I click on "configuration," you're going to be able to
quickly see that I have two of them set up.
One of them that says Windows 10 and Chrome,
which is the browser I want to use,
and Windows 10 in Edge.
If I also wanted to test on
a different browser or a different Operating System,
I would simply come and add a new configuration.
I'll be able to give the configuration title,
let's say "Windows 10 and Firefox",
and when I do that, I can come down here
and add what we call configuration variables,
one of them for the Operating System,
as you can see I have windows 10,
seven, eight, and 8.1.
I'll show you how you can add additional values
there even values that aren't Windows,
and then I can obviously come down here and choose
a browser and I wanted to choose Firefox.
Now when I say that,
you'll see that I have a new configuration
over here on the left hand side.
Below it, I get to control
what values I want for browsers,
and what values I want to be
selectable for Operating System.
So, if I wanted to add Mac OS or Linux,
I can actually add those here,
and even add Safari as a Mac-specific,
which actually happens to be their browser
for this particular configuration,
and then build out my configuration.
Now, that I have the configurations that I want,
I can apply those to my test plan or
specific test suites or test cases,
so that I build out the matrix on where
I want all those tests to be executed.
To create a test plan, you simply
come here and create a new plan.
A plan simply has a date,
and a date range that allows us to
know over this iteration,
we plan to perform this series of testing.
People create test plans
over work items if they're big enough,
over releases generally, and even
over individual sprints that might make up a release.
So, they have this focus
testing that they want to be able to do,
and you can do that with plans and you can create them
at any granularity or level that you want.
I happen to have a plan
generated for the iteration
that my team is currently working on.
Now, a plan can be broken up
into different types of test suites.
A suite is a collection of test cases,
and we offer three different types
of test suites that you can use.
One of them is a static suite,
that is literally just a logical container,
where you can add whatever test cases to it you want.
The other is a requirement based suite.
That is where you're taking a product backlog item
more requirement off of your backlog,
in your associating test to that,
that define these acceptance criteria
for that particular work item,
and they're linked together even
outside of this particular test plan.
Then finally, we have a Query-based suite,
where you can actually write a work item query that
looks for specific types of test,
and will automatically populate
itself with those particular types of tests.
I happen to have all three types here.
Here I have an End to
End test suite, that is a static one.
Where I get to manually
choose which test I want to
apply in this particular item.
I can create new ones,
or I can go into another query,
and find an existing test case
that I might want to add in here,
and simply add it to the test as well,
and now I have two test cases in here.
If I open one of these up,
what you're going to be able see is
the anatomy of a particular test case.
Here I have the steps that I want to perform,
I want you to open up the admin portion of our site,
I want you to click on "security" and then I want you to
click on "members" and what I'm expecting is,
Abel should be shown as a member of the security group.
Here you can have as many steps as you want,
and they may or may not have expected results,
but only those with the expected results
really can pass or fail,
when you're running through your application
unless you had some type of exception.
We'll run a test case here,
so you can see how we can capture that information,
and even log a bug if something bad were to happen.
That is a Static-based suite.
A Query-based suite is
one where we actually have a query that
defines what is actually going to be
shown in this particular list.
And this right here,
basically says only priority
one test cases are
ever going to show up in that particular list.
So right now, we only
have Jessica's test showing up in here,
because it's the only one set to priority one.
If I were to go back and find the Abel test, for example,
and change the priority of this test from
Priority two to priority one and save it,
the next time I revisit this Query-based suite,
it's going to refresh and now you see that
there's two test cases in there,
because they both meet the criteria
of being a priority one test case.
This actually is a work item brought into my test plan,
and all the associated test cases
are also brought in with it.
This is what we call a requirements-based suite.
You might notice that the
verified Jessica's actually listed twice.
The reason why is because if I'd come here
and I look at the assigned configurations,
I've actually assigned two different
configurations to this test,
but only one to the Abel test.
If I wanted to go ahead and add the Firefox test,
you'll now see that you're going to see
the Jessica's test and here three times,
and the reason why, is because the configurations have to
all be satisfied for our test matrix to be complete.
Now, what I want to do very quickly
is just show you how you can run one of these test,
and collect information on bugs that might show up,
and how you can go ahead and verify
that a test actually works or not.
So, what we're going to do, is we're simply going to
collect this one here,
and we're going to simply click on "Run".
When we run this test, we're going to
get a new pop up window,
and it's going to have all of
the directions in it for us
to follow through on our test.
I don't actually have to run the test on this machine,
I could fire this up on any machine,
and be running a test on my mobile phone,
or another device external to my computer.
But what I'm going to do is I'm going to follow
these same directions right here on this screen.
So, it says "Open the Admin" which is
basically clicking on this gear here.
It says, "Open up security"
which happens to already be opened up.
So, I can go and say, "This is successful,
and this was successful" and then it says,
click on "members" which is here,
and Abel should be shown which here is.
So, this test is successful.
Had Abel's name not shown up there,
I could simply click on the "X," and I'd be able to leave
a comment explaining why
this particular item was an error.
I would tell what my expected response was,
where my actual response was.
If I really needed to, I could go ahead and create a bug.
Notice that the bug actually has in it,
the steps that I took, which ones failed,
and any comments that I'd had.
Had I made a screenshot,
I could simply copy and paste screenshot right
here into the steps that we reproduced,
to help the engineer who gets this bug assigned to
them to report the problem, and be able to fix it.
So, I'm going to go ahead and
cancel out of this because I don't need to save it.
I'm going to go ahead and say that
this actually passed instead,
and now I can simply save and close this particular item.
Now, all that information is going to be
stored for us underneath the test hub,
and we can go back in and we can review our test runs.
So, now for her to come back here,
I'd be able to see all the runs
that I've done in the past,
which ones are completed,
which ones are in progress,
if there is any bugs filed,
and also be able to see the outcome
of those individual tasks.
So, getting started with manual testing inside
a Visual Studio Team Services is extremely easy,
but it is also very powerful.
They give you the ability to build out
an entire test matrix with all your configurations,
test plans, and test suites.
Before I go, I want to encourage
you to visit docs.microsoft.com,
to learn more about Manual testing.