Just getting back into this course after focusing on the 70-480 test. Steve and Anthony cover creating test steps for a test case, creating action recordings, and using parameters. The parameters are pretty cool since they make it simple to execute multiple test runs using different data. The shared steps were also interesting, seems they would make tests much more maintainable.
My notes:
*******************************************************************************************
MODULE 3a
*******************************************************************************************
// half hour video, should be short notes
Create Test Cases
- designing Test Cases that have clear and measurable steps
- assigning Test Case properties (title, areas and iterations, state, priority, assign to,
and automation status)
- adding attachments and links
- adding the Test Case description and history
- adding Tested requirements
- managing Test Case workflow (state)
Demo
// everything above, no point in reproducing them
// we already have some test suites (we created them in the last module
// In MTM testing center, we can add requirements to our test plan, which creates a
// requirements based test suite
// Add a new test case to the suite
// We can add steps to the test case, can be very rough. Like a narrative pseudo-code
// test case may be specified before the functionality is even implemented (which is why
// we might keep it rough first)
// test cases have three states: Design, Ready, Closed.
// test cases can be automated with some "shucking and jiving"
// we can add attachments to test steps (like adding a link to the step "browse to app")
// can add general attachments to the test case. Step attachments are just annotated
// test case attachments
// "design" and "ready" states do the same thing
Create Test Steps
- adding and removing parameters to and from actions or expected results
- adding and removing data
- creating repeatable Test actions for using Fast Forward for Manual Testing
- creating expected results
- adding Test Step attachments
Demo
// everything above
// don't put "expected result" for every single step - huge waste of time
// save the "expected result" for the main point you are trying to test
// when performing the test, we can save an action recording, which will let us fast
// forward through repetitive steps. Automates things like data entry which might introduce
// errors into test.
EXAM BEST BETS
- Create several test cases, each with several test steps
- Be sure to attach a document or screenshot to a test step
- Practice using Fast Forward for Manual Testing with several different test cases
*******************************************************************************************
MODULE 3b
*******************************************************************************************
Define parameters
managing Test Case iterations
creating a parameter variable
renaming parameters
deleting parameters
The need for data driven tests
Testers will often run tests multiple times using different data for each test run
// trying different addresses in a form, different surnames, different zip codes
// different countries.
Parameterising tests
- When recording manual tests you simply prepend an “@” symbol in your test step in front
of the place where the parameter should appear.
For example.
- “Enter the @username in the sign-in textbox”
- The step above would create a parameter called “username” and this will appear in a
table as the bottom of the MTM as a column heading in a table.
- Add values under the column heading for each iteration of the test case
Playback of parameterised test cases
- When you use the Microsoft Test Runner to execute a test case that contains parameters,
the parameters are shown in the specific test step where you created them
- To reduce typo’s and increase speed, you can select a control where you want to place
the parameter value and simply choose Paste (CTRL+V) to have the appropriate value pasted into the control.
- This process also maps the parameter to the control for subsequent test iterations
Demo
//everything above
// Added parameters to TailspinToys UI test. As parameters are added to test steps, they
// appear in a table on the bottom of the test case editor
// Not possible to import data into this table, you have to use copy paste. It is possible
// to databind an automated test back to this parameter value table. The use case here
// is that a manual tester with good domain knowledge may add parameter values to test for
// boundary conditions, and by binding to this test data our automated test will pick this
// up with no editing or other intervention.
// When we run the test the first time, we "teach" the test where the parameter data goes.
// the test "binds" the parameter to a control.
// With the Action recording, it will automatically fill in the row of data when fast
// forward through the test steps.
// Putting in more care at the beginning with the action recording pays dividends. Test
// steps with no expected result do not technically need to be passed to pass the test,
// however it is important to pass individual test steps for the action recording to work
// right.
// In test case editor, it is possible to delete or rename parameters, and also possible
// to delete iterations (rows)
// Word "iteration" can be confusing - used to describe a project iteration (like a sprint)
// and also used to describe a row of parameter data
// Parameters are added to table in the order they are created and cannot be rearranged,
// which can give you a headache if you make a mistake and a parameter ends up in the
// wrong place...
Manage Shared Steps
creating Shared Steps
designing Shared Steps that can be reused effectively across different Test Cases
moving Shared Steps
creating Action Recording for Shared Steps
The need for shared steps
- As any testers who have had development experience will know, developers often refactor
code to identify sections that can be easily reused and duplication of code in an
application is frowned upon
- In the same way, a tester can identify steps that are used in multiple test cases (eg.
A user signs into the application) and these can be “refactors” out into what is called
a shared step.
Shared Steps
Characteristics of shared steps;
- Are like mini test cases (testlet)
- Can be imported into any part of a test case, not just at the start or end
- Can be created by selecting a number of steps and choosing “Convert into Shared Steps”
from the context menu
- Can be easily changed and the change automatically applies to everywhere the shared step
is referenced
// change flows through to everywhere the shared step is used.
Demo
//everything above
// highlight the rows and right click, select "Create Shared Steps"
// the name is how it will be identified, so can become a difficulty when there is a large
// library of shared steps.
// icon for a shared step is a stack of staircases, multiple steps are condensed into one.
// Old action recording will have to be recreated.
// Action recording for shared steps carries over to other test cases.
// The "testlet" of the shared step is self contained. It has it's own "play" button
// If fast forward fails, you can stop it and continue manually, or just deal with the
// error and fast forward the steps afterward.
// If you have an action recording that isn't working, you'll have to overwirte the whole
// action recording. Because it's a manual test it isn't really editable.
// Possible to create a single step shared step - great for maintainability, because any
// change would flow to all tests. Navigation (test URL might change) and Login
// (Username/Password could change).
// Now we have to give Steve crap about answering his phone... lol
// We can create an action recording for just the shared step.
Manage requirements
reviewing requirements
verifying requirements
verifying all requirements are accounted for
validating Test Coverage
// END THE SESSION HERE
Demo
//everything above
EXAM BEST BETS
Practice adding test iterations
Be sure you can work with parameters
Understand the benefit of Shared Steps
Use Shared Steps in Test Cases
No comments:
Post a Comment