you know that the files and data that are part of a completed build can delete?
you know that the data deleted cannot be recovered?
you know by default Test Results from any automated tests run against the build
are deleted by default?
If you have the right permissions you can right-click in Build Explorer
on a completed build and select delete. When you do that by default all the
items associated with that completed build are deleted.
Details: Information about the completed build that
is displayed in Build Explorer. This information includes build steps,
requestor, and date and time queued.
Drop: File and folders output by the build and
copied to the drop location.
Test Results: Results of any automated tests
executed during the build process or results of any test published against this
Label: The version control marker associated with
the specific file versions used by the build process.
Symbols: The debugging symbols published to a
symbol server during the build.
You can also configure the retention policy and set auto deletion rules
. Nothing wrong with that however is the person responsible for the “Build”
setup and maintenance deleting could be deleting Test Results?
There is an option that can be set to stop the deletion of your Test
Make sure your teams understands what happens when deleting completed
builds. Set that option to keep your test results, unless you don’t want them!
If you are interested in following
any of the MSDN Forum’s there is a gadget you can download that makes access to
your favourite threads quick and simple.
It is Methodology May at the TALMUG
Methodology. In the world of software development there are not many words that raise contention quite as quickly as this. But why is that? What are the differences between Agile, Iterative, and Rigorous software development methodologies? There has been buzz about Scrum, XP, Lean, Waterfall, Kanban, and RUP for years; how do they fit into this discussion? But most importantly, why should you care? What does the test team think of all this?
In Methodology May the TALMUG brings you a panel of ALM professionals to discuss and debate these very questions and maybe help you see what methodology could work best at your company.
Pizza and Pop will be available at 5:30pm - Come out and join in on the discussions.
Being held at 40 University, Suite 1301, Toronto meeting starts at 6pm.
Follow on twitter @TOALMUG
Click here to Sign Up
Karthik K.K has posted on LinkedIn (click to see) a chart that compares the features of Visual Studio & Test Manager to Quick Test Professional (QTP).
I like the last item:
|Visual Studio 2010 Test ||QTP ||Who’s Best |
|VSTS is cheaper and can be used for both development & testing. ||QTP is costlier and can be used ONLY for testing. ||VSTS |
VSTS can also be used by Business Analyst, Project Managers, and Stakeholders. It can assist teams being Agile or Scrum or Waterfall thru a process template. The process template can be customized to meet your company need. VSTS reports on all aspects of a project and can tell you at any time where in the project you are at, the quality of the project to date, the status of your requirements/user stories. You can have a “Requirement to Test Matrix” in seconds at anytime.
If this alone has got your attention and you want to know more contact me directly.
The first Toronto VS ALM User Group kick off meeting is being held on April 12th @6:30pm sign up at TALMUG to get the details and register.
The User Group is for all roles within the Application Life Management team. Topics presented will vary from generic ALM practices to ALM with Visual Studio. If your involved in product management, a stakeholder, a business analysis or product owner, a developer or a tester this User Group is for you.
The goal of the first meeting will be to:
Define the group’s mission
Select an appropriate name
Document the roles of the executive
Discuss how to reach out for sponsors
Discuss meeting locations
Discuss ideas for the first few meeting topics
Come out on April 12th and help us to kick-off this new user group code named TALMUG.
Team Foundation Server (TFS) and Visual Studio(VS) excels when it comes to requirements traceability. Depending on what process you are using in TFS your stakeholders needs are documented in a work item called one of the following: requirements, user stories, use cases or backlog items. For this blog I am using the term requirement.
What is requirements traceability?
Continuous knowledge of the life of a requirement from conception to creation to design to development to verification to implementation and change. The ability to trace a requirements state and/or status at any time during a project.
First step in making requirements traceable.
In Visual Studio other work items are used to identify work that needs to be done to a requirement before it can be deemed done. There are different work item types depending on the process template you are using, however all contain the following: Task, Test Case, Shared Step, Bug. Additional work items can be added if not in your process template like Review, Issue, Change Request to name just a few. All these work items can be linked to the requirement they are helping to fulfill. Visual Studio 2010 introduced the concept of hierarchy by which a work item is linked to another work item using a linked type. The work item task is a child of a requirement, two requirements can be related, a test case tests a requirement. Work items like tasks may be linked to show predecessor or successor of another task. To learn more about choosing link types to effectively track your project click here MSDN Library.
Linked type listing:
Example of a requirement with linked work items:
What can be traced?
In Visual Studio during diagram modeling requirements and other work item types can be attached to objects in the model. During modeling you can either create or link requirements. This allows you to trace work items like requirements from a model diagram.
Example of a Use Case model with requirements linked:
Within the requirement work item I can see all other linked work items and information about them like state, assigned to. Knowing the state of work items linked to a requirement tells me the state and status of the actual requirement itself.
Development when checking in code to VS source control can be forced to associate what requirement or other work item their code relates too. Code check-ins create a Change Set that contains information about the check in and gets linked to the work item(s) associated during a check-in. When fixing bugs this is a nice feature.
In Visual Studio I can create queries to show any type of traceability report. Examples: Requirements to Tests Matrix, Requirements to Tasks, Requirements to Issues, Test Cases with Bugs to name just a few. Queries can also be exported or opened in excel, sent to someone thru email or opened in Microsoft Project. Queries exported to excel allows for adding additional excel reporting features like a Pivot Charts.
Requirements to Test Matrix – is there test cases for each requirement
Visual Studio comes with many reports that trace Requirements showing linked tasks and remaining work left, test case results state and many more scenario’s. Remember depending on what process template you are working with will determine the reports you see.
Checkout MSDN library for lots more information on Requirements Traceability in TFS & VS.
An update is available that includes the following:
Support for multi-line test steps in Microsoft Test Manager
Changes to the 2010 client to allow it to work with a TFS 11 Server
KB2522890 – Team Explorer Crashes when opening build from TFS 2008
KB2552300 - Gated Check-ins fail with the “Preserve local Changes” option
KB2561827 – DiffMerge closes with unhandled exception when comparing two files.
Here is the update: http://go.microsoft.com/fwlink/?LinkID=212065&clcid=0x409
If your looking for a way to create
test configurations that can be used in all your team projects check out Dave Lloyds blog. Dave explains how to edit the process
template to add or change test configurations.
Some controls are not recognized without added help. You need to make sure that the controls being added to the solution by development are first compatible and second have be referenced so that they are recognizable by MTM.
Silverlight Control recognition:
How to setup up your Silverlight Application for Testing instructions.
Set a Unique Automation Property for Silverlight Controls for Testing
Testing WPF application check this out.
Supported configurations and platforms for Action Recordings and Coded UI Tests check this out.
Feature Pack 2 is now available and includes the following: Click to Download
Codes UI Test [CUIT] Editor
new CUIT Editor, opens by selecting the UIMap.uitest in Solution Explorer
click here to see Editor
LightSwitch applications [Microsoft]
tested and works well with LightSwitch applications
- Microsoft VS 2010 Test Package for Silverlight 4
test Silverlight apps and other desktop applications
enables testing with Coded UI tests and record, playback in Microsoft Test Runner
data and diagnostics can be collected during runtime however, Intellitrace logs are not as of yet
tested to work with Silverlight 4.0 apps hosted in IE (adding Silverlight apps in future)
Note: read the “about” for restrictions
Microsoft VS2010 Test Package for Mozilla FireFox
- enables playback and UI actions for Firefox 3.5 and above
- enables testing with Coded UI tests (CUIT), automated Web Performance and Manual fast-forward tools
- you can create a set of tests once and execute on both IE and Firefox from Microsoft Test Runner
You need to download KB2403277 which can be done before installing or during the installation process of Service Pack 2.
Click to Download