Test Manager, The Story of a

I am a member of the The Software Testing Club which is a global and professional community of software testers. The community shares information through online question and answer sessions and access to test related bloggers, updates on testing events worldwide, The Testing Planet online articles, and much more. If you  are not a member I highly suggest you join. Follow the link above.

A member of the club, Rob Lambert wrote a story “The Story of a Test Manager” that I spent an hour while drinking my morning coffee reading. The story is fictional however, I bet you can relate to the main points through your own experiences as a software tester. As I read the story I wanted to tell the characters about TFS2010 but then I want to tell everyone even my hair dresser. My dogs love hearing the words TFS they think it’s a cookie!  Microsoft TFS nerd and proud of it.

Thanks to Rob Lambert for a great story.



Why Software Fails - your not using TFS2010 & Test Manager?

A colleague emailed asking if anyone had seen this article. It was written in 2005 and is very enlightening to read even today. I thought I’d post it for people to read. Click here Why Software Fails

As outlined in the article here are the most common factors:

  • Unrealistic or unarticulated project goals

  • Inaccurate estimates of needed resources

  • Badly defined system requirements

  • Poor reporting of the project's status

  • Unmanaged risks

  • Poor communication among customers, developers, and users

  • Use of immature technology

  • Inability to handle the project's complexity

  • Sloppy development practices

  • Poor project management

  • Stakeholder politics

  • Commercial pressures

Has this changed, in my opinion not enough yet. As a strong advocate of Agile and a user of Microsoft TFS2010 and Test Manger - the communications is available we just need to get better at it and share the responsibilities as a team.

Testa Smile

Microsoft Test Manager - Feature Pack 2 is available

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 

    Testa Smile

    Microsoft Test Manager– Test Plan shortcuts

    Quick access to Test Plans using the “Copy URL for plan” option in the Testing Center window.


    1. 1. Open Test Manager
    2. 2. Open the TFS Team Project that your Test Plan resides in
    3. 3. Highlight the Test Plan by selecting that you want to create a shortcut for
    4. 4. Click on the Copy URL for plan icon in the toolbar menu (see below)


    (Note: when you click the “Copy URL for plan” icon the URL address to the plan is stored on your clipboard)

    5. Next, go to your desktop and right click, select New then select Shortcut


    6. The Create Shortcut window opens, paste the URL from the clipboard, using either Ctrl-V or right-click Paste, now click the next button.


    7. Create Shortcut window opens where you enter a name for your shortcut. Make sure you are entering the actual Test Plan name or using a naming convention that allows you to easily identify the shortcut. Click Finish. (Notice a name by default is given: “New Internet Shortcut” if you miss entering your own)


    8. The short cut is created and looks like below, when you click on it the Test Plan opens.




    Test Manager & VS2010 automation playback in FireFox

    Microsoft has released a plug-in for Mozilla FireFox that allows you to record a action recording, a coded UI or web test in Internet Explorer 7 or 8 and play the same test back against FireFox. The current plug-in supports FireFox 3.5 and 3.6. The plug-in can be downloaded and installed on top of an existing 2010 install.

    Download here: Test Package for Mozilla FireFox Power Tool

    Note: after you download read the ReadMe file there is some configuration setup required before you can use this tool.



    Microsoft Test Manager – adding parameters to Shared Steps

    Shared steps can have parameters however, before adding iterations of data there are considerations you need to take into account.

    If you consider logically how this works, adding a bunch of parameters and data to a Shared Step will have that step repeat running through the data you added. Then once all iterations of the shared step complete your next test case step would run. Make sense.

    • What if I want the Shared Step parameters to run with other parameters in my Test Case?
    • What if I want to add data to my Test Case Shared Step parameters months later?

    The cleanest and most flexible way I believe and have found is to add data (iterations) to my Shared Step parameters from within the Test Case. Remember a Shared Step can be used in any Test Case and therefore needs to be flexible.


    A Shared Step with Parameters > no data (iteration) added.


    Shared Step with Parameters (userid & password) inside the Test Case


    Above there are three parameters of which two belong to the Shared Step, the other the test case. You can add many parameter iterations to this test case without affecting any other test case that contains the same shared step. (If the UserID and Pswd’s were in the shared step that step would keep opening and login for each iteration before doing the test case step two.)

    I have seen cases where testing always uses the same UserID and Pswd for login. In that case having these as parameters set within a Shared Step makes sense. If a new set of credentials is issued you can easily change them in one place, quick and simple.

    Note: now this is confusing. I set my parameters in a Shared Step added the Shared Step to a Test Case. In the Test Case the shared step parameters display however they do not show any data.

    [I will try a scenario where parameters are set in the Shared Step and in the Test Case to see what happens!  - will let you know the outcome]

    Comments on this subject are welcome. If you have found a different way to handle a combination of parameters in shared steps and test cases or situations you have come across  – lets learn together.

    Testa :-)

    Never Test Alone – TASSQ presentation in TO

    Andre King & I presented “Never Test Alone” at TASSQ in Toronto yesterday evening. After the presentation Joe Larizza (TASSQ President) addressed the group saying that with the economy businesses are looking for ways to reduce costs. Outsourcing testing will be one of them. People need to be proactive in finding ways to reduce cost and produce quicker. Joe encouraged people to talk to their management teams, present the concept outlines in “Never Test Alone” and volunteer to give it a try. See how it works, what it saves and in the end you may be saving more then you expect.

    In Never Test Alone testers are involved in the Requirements & Design reviews and validations. This allows the test team to prepare for testing early, creating test cases, test scenario's and other documentation at the start of the project. Plus testers add value to the process from their experience and perspective. This reduces the cost of the test group weeding through requirements later to get an understanding that may not even be a correct one of the system. Enhancements that testers log during testing will come out during the requirement review phase. If deemed required can save money by being incorporated before development starts versus later.

    Team up testers with developers during the creation of unit tests, the more tested at this stage the less cost in fixing, less bugs later, and we can reduce the duplication of testing being done between the two groups. Testers now know what has been tested therefore will not have to retest later. A testers perspective in what needs tested will differ from a developers so the combination of the two creates very rigorous unit tests.

    If you are doing continuous builds (http://en.wikipedia.org/wiki/Build_automation) the unit tests are run against each build becoming regression tests. So we now have during unit testing, the functional testing and automated regression testing happening very early in the project.

    Unit tests can be used in load testing. One example is login where UserID and Password are entered. The unit test can be build to retrieve from a listing of many UserID/Password combinations to execute login many times. What is the savings in knowing during development that the system is not going to have problems with 1,000 concurrent logins? Add this test to the build regression tests and you know throughout your project how well it is standing up to load. Why leave load testing to the end, do it early and save time, money and possibly the project.

    Andre demonstrated a tool for automated white box testing, Microsoft Research PEX (http://research.microsoft.com/en-us/projects/Pex/). Very impressive and it can be run against code by testers saving development time for development. Check out the link above for a white paper on PEX. Maybe Microsoft will make a version of PEX that testing can use which does not require us to have access to the actual source code.

    This is a list of some effects from following this presentation:

    • testing a lot earlier
    • saving money on bug management
    • saving money on system changes late in the project
    • reducing timelines
    • building a team relationship
    •  great feeling of accomplishment

    And you are not testing alone, it is a group effort and it is the route to success.

     Link to TASSQ

    Presentation Slides