Top 25+ Azure Test Plan or TFS Interview Questions

Most Popular Interview Questions on Azure Test Plan:

Azure Test Plan is alternatively also known as Azure DevOps Test Plan or TFS (Team Foundation Server).

I have been using Azure Test Plan at work as a test management tool for more than 2 years now.

Here, in this article, I would be providing a comprehensive list of interview questions for the Azure Test Plan (quite a few tricky questions and their solutions that I have learned with experience on the tool).

=> Complete Azure Guide for ALL

Azure Test Plan Interview Questions

Before we move on to the set of interview questions, I would like to set a holistic context on what Azure Test Plan is and what purpose does it solve for a QA team.

• Azure Test Plan is alternatively also known as Azure DevOps Test Plan or TFS (Team Foundation Server).
• Azure Test Plan is one of the best web-based test management tools for manual and automated testing.
• The tool provides a very good option to have an end to end traceability by having requirements, specification documents and/or user stories linked to the test cases, test results and the reported defects.
• The tool helps keep track of the configuration details like test cases run against a specific environment or number of builds run, the author of the test cases and the QA who executed the test cases.
• It helps to assign or distribute the test cases across many testers within the team.
• It serves a large purpose i.e. starting right from creating new test cases, reusing existing test cases until easily tracking the progress of the testing effort.
• It also enables having a customized dashboard with simple and apparent charts.

Top TFS Interview Questions

Here is a comprehensive list of interview questions on TFS:

Q #1) Name different types of Test suites that TFS allows the user to create and how is each one different from the other?

Answer: Test Suite is the grouping of multiple test cases. The grouping of test cases could be against the requirement or any other work item like user stories, a feature, a change request or these could be grouped together as a ‘Regression test suite’ or ‘Smoke test suite’.

There are three types of test suites that the users can create in TFS:

• Static test suite
• Requirement test suite
• Query-based test suite

[Workflow:
Create Test suite: Open Project ->Test ->Test Plan -> Right click on Project -> Click on Test Suite.
Create Backlog item: Open Project ->Boards ->Backlogs -> New work item]

a) Static test suite: This creates a basic folder where you can manually add existing test cases or create new ones. You can also add multiple child suites under the main suite. For Example – A Functional Testing phase of Sprint 15 has 3 change requests.

Example: When CR-123, CR-456, CR-789  are 3 change requests, then you have a structure of static suites created as below:

You can then add the test cases under each of these child test suites.

b) Requirement-based suite: This type of suite is usually used in the Agile methodology of testing or essentially when the team decides on having each test suite mapped against each requirement. The requirement could be any work item representing user stories or any functional requirement.

1. In order to have a requirement-based suite, first, you need to add the work items (user stories, features) under the Backlog.
2. Create Requirement based test suite, then a query window will pop up as the below image.

Here, you select Field =Work Item Type, Value =Microsoft.RequirementCategory and Area Path= <Project Name> and click on Run Query.

The resultant window will display all the existing backlog items/requirements for the project. Select the one you wish to add and the test suite folder gets created with the title just the same as the user story that you selected. All the test cases that you create under the suite would now get mapped against the user story.

c) Query-based suite: Like the name itself suggests this type of suite allows you to add existing test cases by querying the project database in TFS. The reusability of existing test cases is the aspect that this type of suite focuses on.

When you add a query-based suite, a query window displays, where you can add the existing test cases from the current project or another project.

(Note: @Project refers to the current project and @me refers to my user id in TFS in the below image)

Q #2) You had a discussion with your business analyst with respect to the testing approach & the testing scope for a particular test case(s) and you need to notify your teammates on the same. How can you notify them through TFS?

Answer: When you double click a test case in the List view and open it, a window displays where you could see the Test case title, tags you have added, sections for Summary, Steps, Attachments, and Discussion. In order to notify anything to the teammate(s), one can make use of a feature called “@mention”.

In the Discussion section, you can use @ symbol and then the list of user ids for the project displays. You can then select a user id to whom you wish to notify, followed by a message. You can also enter multiple @user ids for notifying multiple teammates at a time.

In case you need to add a link in the message, add the symbol # followed by the URL and then press ENTER. The message is added as a discussion point and an email is auto-sent to the user mentioned in @mention.

For Example, @Shalini Singh you can refer to the test coverage matrix

In the above example, I added a notification which shall trigger an email for Shalini Singh with a message as above along with the hyperlink text www.softwaretestinghelp.com/test-coverage/

See the below image for better understanding:

Q #3) How do you sort the test cases that you add in the TFS?

Answer: When you add test cases in TFS, quite often they get added in an unsorted fashion. There are 2 ways in which you can sort the test cases.

a) In the List view of the test cases, there is a column named ‘Order’. Each test case gets a unique order id auto-assigned based on the order in which the test case is added. You can sort the test case by clicking on the column Order.

[image source]

b) Or, on the top right corner, there is an option named “Order tests”. Clicking on the Order tests sorts all the test cases in the list view.

Q #4) What are the different views available for test cases in TFS?

Answer: There are two views available for test cases in TFS:

1. List view
2. Grid view

a) List View: This is the default view of the test cases in TFS. In this view, as the name suggests all the test cases are listed down in a sorted way if the list is sorted using Order id.

There are multiple columns displayed for each test case in this view; like Outcome – which is the latest status of the test case, Order – representing the order id based on the test case insertion order, ID – an auto-generated unique test case id, Title, Configuration, Expected Result, etc.

In this view you can perform the following actions:

1. You can run the test cases.
2. Mark testing status for each test case.
3. Add new test cases or import existing test cases.
4. Delete existing test cases.
5. Filter the test cases based on different criteria like configurations, tags, etc.
6. You can also distribute the test cases among the testers.
7. Move the test cases by simple drag and drop.
8. Change the configuration of the test cases.
9. Double-click on the test case opens up another window where a grid view of test cases are displayed. You can add, update or delete test steps in this window.

The below image depicts the ListView:

b) Grid View: On the top right corner of the List view – you can see the option ‘List’, clicking on this option switches the view to ‘Grid’. Grid view is very similar to that of an Excel worksheet view. In this view, you will not be allowed to perform those actions that the list view allows you to do.

Grid view:

• It enables the user to add multiple test steps very much as Excel does.
• You can even reuse the existing test cases from Excel in an easier way in this view.
• You can insert a row, delete a row or update the test cases.

However, please remember that in a grid view, you cannot import an existing test case through a query and you cannot run or update the test case status.

Another prime difference between the two views is that despite that both the views allow the user to manually add, delete or update the test cases –

• List view allows you to add or update one test case at a time.
• Grid view allows you to add or update multiple test cases each with multiple test steps in one go.

The below image depicts the Grid View.

Q #5) Does TFS provide options like drag and drop and Spell check in the Grid View of test cases? If not, how can you overcome this issue?

Answer: TFS doesn’t provide options like drag and drop of test steps to copy over data from one cell to another or in order to auto-increment a numerical identifier in the other cells.

The best alternative is to prepare the test cases in Excel with a drag and drop feature wherever required and correct all typographical errors by running spell check and then move them into TFS.

Q #6) You can add multiple lines in a cell using ALT+Enter in Excel. How can you perform the same action in TFS – Grid view?

Answer: SHIFT+Enter is the shortcut that is used in TFS while adding test cases in Grid view.

Q #7) What are the different criteria that are used in the Query search?

Answer: Like the SQL queries, query search also enables the users to search the entire TFS database based on a field or column name, an operator and the expected value.

Query search can be done using different criteria as explained below:

a) Query search based on a check that certain field includes a text value:

In the below image, any work item (user stories, features or test cases or test suite, etc.) from the current project with title or description containing the words “web” and “performance or guidance” would be fetched when run.

b) Query search based on WorkItemType:

The image below shows the query search based on WorkItemType = bugs.

• When field = Work Item Type, operator =” In Group” and Value =Microsoft.BugCategory, it searches for all TFS bugs reported for the project.
• When Value = Microsoft. Test CaseCategory, this search is made to fetch all the test cases matching the rest of the field criteria.
• Similarly, when Value = Microsoft. RequirementCategory – work items from the backlog – i.e. the user stories or the features are fetched.

c) Query search based on the available column options:

In the below image, all the bugs assigned are searched.

The query could be based on the search criteria of a column value match, the columns could be any available column like Tags, Priority, Assigned To, ID, Configuration, Description, and many other available columns.

You can also fetch certain columns that have null or blank values in it. In the below image, all the tasks with blank activity would be retrieved.

Q #8) Can you reuse the existing Test cases in TFS? If yes, explain all the different alternatives to do so.

Answer: Excel allows you to drag and drop certain test steps and they get copied over multiple cells quickly if there are numerical identifiers dragging the cell values that auto-populates the incremented identifiers.

Spell check is another benefit which is available in Excel and is very essential while test case creation in order to avoid any typographical errors. Unfortunately, this is a known drawback in TFS as of now that Microsoft is already addressing and is working on.

Yet the fortunate side is that you can still write the test cases in Excel in the format matching the Grid view, and can run the spell-check. They can easily copy-paste the excel data using CTRL C & CTRL V in the Grid view of the TFS and press CTRL +S to save the test case(s).

Q #9) After importing an existing test case with id – 123(for instance) through the query, does the id of newly cloned test case change or does it retain as 123?

Answer: When you click on Add existing test case on the List view of the test cases, a query window pop up –
Select WorkItemType=Microsoft.Test CaseCategory, AreaPath=<project name> and ID= <Test case ID>.

The existing test case with the id gets copied over to the current suite and the test id remains the same.

(Example: If the id imported was 123, after cloning the test case, the cloned test case retains the same id.)

Q #10) In subsequence with the Q9 above, if you make an update to the cloned test cases, and now the same test case id is imported again using the query, which data will it show – original or the updated?

Answer: If you update a few test steps and click Save, the test case id still won’t change. You then have to navigate to the third test suite and import the test case with the same id. Now, the updated test case with the latest test steps gets added. However, there will be no change to the original test case in the first test suite.

Q #11) How do you add tags column in the Test cases section? When and how is using Tags beneficial?

Answer: For adding tags column in the Test case section, there exists an option on ListView named Column options. This option opens a window through which you will be able to add the ‘Tags’ column in the Test cases section.

‘Add Tag’ enables you to add any text value as Tag. (See the highlighted option in the below image)

You can also add tags in the Grid view. In order to add multiple tags in the Grid view, enter multiple texts in the Tags column each separated by a comma.

(Example: If you enter ‘Positive’, ‘Exploratory’ for a test case under the Grid view, then clicking Save will show multiple tags in List view as filters on the top right corner.

Refer to the image below:

Using tags serves many advantages:

1. Tag each test case against a specific category. Example: Positive, Negative in order to categorize the test cases into positive and negative scenarios.
2. Filtering the test cases based on the keyword (tags).
3. For each test case, you can also have a Requirement id mapped in the Tags column which will not only help to maintain the end to end traceability but will also allow you filter out the test cases based on each Requirement id and make sure that enough test coverage is in place.

Q #12) How can you quickly get test cases under the Regression suite ready if the functional test cases for the project is ready and multiple sprints of the project have already been delivered to the client?

Answer: Follow the below steps to quickly get the existing test cases under the Regression suite:

1. Once the functional test suites for a project are in place, identify all the test cases suitable for regression.
2. Add Tag as “Regression Candidate” for all regression test cases that you identify.
3. Create a new suite as “Regression Testing” under the project. The suite could be of the type static or query-based.
4. Click on Add existing test case, in the query window select criteria as Tags=’Regression Candidate’ and click Run.
5. The resultant will get all the test cases from the project identified for regression testing.
6. You can select all test cases from the resultant window and click Import. As a result, all the required test cases are added into the suite and the regression suite is ready.

Q #13) Can the test case author be different from the testers assigned to them in TFS. For instance, if person A is the one who has written the test case. How can you assign it to person B for its execution?

Answer: Yes, the test case author can be different from the testers assigned to them in TFS. When you add test cases for a test suite, your name shows up under Tester column by default.

In the list view of the test case, select a test case, right-click and select the option “Assign tester” which will then bring up the list of the existing users. You can select a tester and this is how you assign a test case to the QA within your team.

You can similarly select multiple test cases and follow the same workflow in order to assign multiple test cases to one tester in one go.

Q #14) For the test cases with, Example: 50 steps and you have partially executed them; how can you resume test execution and continue updating the test status from the steps where you left last time?

Answer: You can run the test case clicking on the Run button on the List view and this shall then open the test runner window.

See the below image:

If you are executing all 50 steps in one go, then you may update the test step status as Pass/Fail/Blocked/Not Applicable and hence the test case status gets updated accordingly.

However, if the same approach is followed while your partial execution, then the workflow would be as below:

Workflow 2:

• You have updated 5 steps to Fail and 20 steps to Pass, leave the rest of the 25 steps unexecuted. –+Save and close. – Consequently, this updates the test case status as Fail (as 5 steps were failed back).
• You then continue testing, by clicking on the Run button – The status for the previous 25 test steps are not retained. You will then need to update the test status and their comments starting from Step 1.

Workflow 3: This is the best approach to follow when you need to perform test execution for a test case partially and you need a way to resume testing later when required.

On the test runner, update the status of the test steps executed and leave the rest of the test steps unexecuted. DO NOT Save and Close the test case, instead of on the test case level, select the test case status as Pause. When the test case is in Pause status, the Resume option next to Run is enabled.

Image of the Resume button is shown below:

[image source]

Q #15) Among 10 test steps, 1 test step is failed after execution. The associated defect is retested after the fix is made. How can do you handle the updating of the testing status of the test case?

Answer: Pause the test case status whenever any step fails, so that you can resume from there and mark only the failed steps as passed.

If the Test case status was completed, then re-running it will require you to update the testing status from step 1 as the earlier status of the steps is refreshed and test cases will return to the Active status.

Q #16) Explain the workflow of test case execution in Test Runner and in the ListView.

Answer:

• On the Test Runner window
  • If you need to mark the test step as ‘Pass’, then click the Tick mark for that step.
  • If you want to mark the test step as ‘Fail’, then click the Cross sign for that step.
  • In case you need to add comments for a test step, the Pass test step doesn’t display the comment text area. As of now, the comments section is available on a ‘Failed’ steps only.
  • If you need to add a comment for a Passed step, mark it as Fail (click on Cross icon) and then Pass the step (click the tick icon) and you will see the comment section. This is the known issue in the TFS.
  • You can also pause on the test step level and on the test case level.
  • For the test case with parameterized data, multiple iterations of test cases are run.
  • You can mark the test case status as Blocked, too.
• On the List view of Tests
  
  
  • You can select multiple test cases on the Test cases list and mark them as Pass in one go and a few other sets of test cases as Fail. However, with this approach, the status of the test cases are not updated at the test step level.
  • There are other options as well such as Blocked, Not Applicable, Set as Active, Resume (for paused test case)

Q #17) How can you create a bug in TFS during test case execution? Does it automatically get linked with the test case?

Answer: Creating a bug in TFS while test execution:

On the Test Runner window, click on Create bug option in order to create a new bug (See the below image)

A window opens up as shown below in which you fill in the bug details and thereby clicking on Save auto-generates a bug id.

The link between the test case and bug id:

The bug gets automatically mapped to the TFS if it is a TFS bug id. In case, the bug has been reported in an external defect management tool, then you need to manually map the bug id in the comments section or the Tag column of the test step.

View TFS bug id mapped for a test case:

The Failed step gets automatically mapped to the bug. The test case also auto-maps to the TFS bug id. Here is how you can view the list of bug ids mapped to a test case.

1. Save and close the test runner window.
2. Navigate to the Related Work section Child links for the test case.
3. The child link will have all the associated bugs for that test case.

Q #18) How can you track testing progress?

Answer: Right next to the ‘Tests’ tab there is a ‘Charts’ tab. You can track the testing progress at the test case level or test result level and get a customized chart of your choice.

Enlisted below are the two examples of how to prepare a chart.

a) Test result metrics: the number of pass/failed/blocked/in-progress status:

Select Group by=Outcome, Values=count of Tests.

Based on the type of chart selected on the Snapshot section (pie, bar, column, etc.) – The chart displayed will give you the metrics on the number of test cases – Not Run, Not Applicable, Passed, Failed, Blocked, Paused.

b) Test case status per assigned tester:

Select Pivot table under Snapshot, Rows=Tester, Columns=Outcome, Values Count of Tests – you can then see the pivot table that displays the metrics in the below format:

<Tester Name> <Number of test cases Not Run><Number of test cases Passed><Number of test cases Failed><Number of test cases Not Applicable><Total>

Q #19) How can you analyze which module/area has the most defects after the execution is completed for a specific sprint or iteration?

Answer: Create a chart using either a Stacked bar or Pivot table. Select Name=’Bugs by Team’, Y-axis =’Node name’, Group by=’Priority’, Aggregation =Count of work items.

This will display which module/area has the most defects after the execution is completed for a specific sprint or iteration. (see image below)

Q #20) How is parameterization supported in TFS? Explain how did you implement testing with data variations with an example from your project.

Answer: Parameterization is one of the noteworthy features that TFS provides. There are situations when you need to test the same step but with data variations / multiple test data and this is where parameterization helps.

Create or add Parameters:

There is an option known as “Parameters” just next to the “Test Plan”.

Parameter screen:

[image source ]

Clicking on this option opens up the Parameter screen where you can see your test data. In the below Example – there are data variations set to the 3 columns in the grid – Number1, Number2, Result.

Note: you can name the columns as you wish.

[image source]

Access the parameter in our test case:

Now that the parameter is ready to use. You can access these values in the test cases. In order to access the parameterized data, use @columnname in the test step wherever you wish to access it.

See the implementation below:

Here, @Number1 is used in step1, @Number2 column is used in step 2 and @Result is accessed in the expected result of step 3. If the parameterization was not in place, you might have needed 9 steps each with separate test data mentioned. This extra test case preparation effort is saved through this feature.

Execute test case with parameterized data:

From the List view of test cases, when you run them, the Test runner opens up.

The parameterized data will now run in iterations:

For our above Example:

The first run will show:
‘Test 1 of 3: Iteration 1’,
Step 1: Enter @Number1
Number1=5
Step 2: Enter @Number2
Number2=5
Step 3: Add both number Result=10 in the expected result column

You can mark pass/fail at the test step level or directly on the iteration level. Remember, even if you mark Iteration1 as Pass (for instance), the entire test case status is not set – test case is not yet fully run. Then click next and similarly, follow the approach for Iteration 2 and Iteration 3.

Once the status is updated for all the iterations, the test case status as Pass/Fail/Pause is auto-set. The number of iterations= the number of rows in the Parameter. Here, there was 3 iteration runs as there were 3 rows of test data available in the Parameters.

Take a look at the image below for reference (Note: the image is not a subsequence of the above example)

Q #21) What are the different ways to extract the test cases along with the updated status after execution?

Answer: There are 4 alternatives to extract the test cases along with the updated status after execution.

They are:

a) Export via Email – Select the Test Suite, select Export -> Export via Email. With this feature, you can export the test cases to the email id.

Refer the image below:

[image source]

b) Print the report: You can also print the report.

c) Export to excel utility: There is a utility using which you can export your test cases along with the results to an excel file.

For more details on utility, See the image below:

d) Copy-paste from the Grid view into Excel: You can copy-paste using Ctrl+C and Ctrl+V, respectively from the Grid view into Excel and then update the status manually for the actual result and testing status.

Q #22) How can test steps be shared and where else can you use the shared steps?

Answer:

Sharing a test step: In the List view, when you double click on any Test case, the Test case detail window opens up. Next to the Summary, there is a Steps tab. When you maximize the steps tab, a screen displays as in the below image.

You can add a shared step as shown below: Click on the Create Shared Steps icon, and create a new test step. This is now shared and can be reused in another test suite or another project too. (See the image below)

Reusing shared step: Go the steps screen where you want to add an existing shared step. The icon just before “Create Shared steps” is for “Insert existing shared step”, click on the Icon, a query window opens up with Field=” Work Item Type”, Operator=” In Group”, Value=” Microsoft.SharedStepCaregory”.

When you run the query, all the existing shared steps are displayed. You can then select the steps and click on Insert shared steps. (See the image below)

Q #23) If the test data is available in a client-provided excel file, how can it be used in TFS?

Answer: You can simply copy-paste data from the client provided excel file into a new Parameter in TFS. (See Q #20 above as it clarifies how to create a new parameter and access the parameter in a test case).

Q #24) How can you make a locally accessible chart available on the dashboard for the team and the concerned stakeholders can also view?

Answer: The tab next to ‘Tests’ is ‘Chart’, where you can add charts. Once the chart is displayed, right-click on the chart, and the ‘Add to dashboard’ option is available – provided the dashboard widgets were already configured. Secondly, remember that charts addition to dashboard also requires admin rights else this option is disabled for you.

Q #25) How can you distribute all the test cases in the suite among the QA members for execution and notify them via TFS?

Answer: Right-click on the test suite and select “Assign testers to run all tests” and a dialog box opens up where you can add multiple testers user id, check on the Send email checkbox, enter Subject and Note. Click OK.

An email is sent to the testers in the list with the message. This is how allocation and notification of allocation are done simultaneously.

See the images below for better clarity:

Q #26) How can we have Tagged “Regression Candidate” removed on all Priority 2 test cases in one go?

Answer:

a) Retrieve the test cases for the project that are of Priority 2 through the query.

b) The query criteria is as follows:

• Team project =@Project
• WorkItemType in Group Microsoft.TestCaseCategory
• Priority = 2

c) Select all the test cases retrieved in the resultant window once the query is Run.

d) ‘Edit selected work item’ option gets displayed. Select this option. (See the image below)

e) Edit work items window gets displayed.

f) Select Field=Tags (Remove) = Value=Regression Candidate and click Save.

This workflow will remove the Tag=Regression Candidate for all the test cases with Priority 2 for the project.

Q #27) How do you fetch test cases with the specific configuration from multiple projects through the query?

Answer: Create a new test suite and name it appropriately. In the List view of the test case, select on ‘Add existing test case’, and a query window opens up.

Suggested reading =>> Frequently Asked Azure Interview Questions

• Do not select ‘Team Project’=@Project. This will fetch work items from the current Project, only.
• If you need to select test cases with configuration Example: “Pre-Production”, select query criteria with column Configuration =Pre-Production, Work Item Type=Microsoft.TestcaseCategory and check the checkbox on the top right corner of the query window “Query across projects”.
• Running this query will fetch test cases with configuration =Pre-Production from multiple projects.

Conclusion

While TFS test management tool is catching up the market in a gradual way, we tried to take a deep dive into the subject, consolidating its nitty-gritty and have tried our best to acquaint our QA folks on the vast and great features that TFS supports along with certain known issues or drawbacks and alternative ways to tackle them.

Hope, you reap the maximum benefit by understanding the workflow of the tool and equally get the know-how of the most likely and relevant questionnaires for TFS.

A popular quote reads “Leaders never stop learning”. I would like to conclude here – but never let the learning stop. “Be the Leader and wish you a very Happy Learning”.

Author: This post has been written by Shobha D. She works as a Project Lead and has 9+ years of experience in manual, automation, and API testing.

All the Best for your interview!!

PREV Tutorial | NEXT Tutorial