C l e m e n s

Recent posts

Tags

Categories

Navigation

Pages

Archive

Blogroll

    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    VS2010 TMap Testing Template | Initial Work Items #1

    During the unfolding of the TMap for VS2010 process template, several pre-defined work items are created for the test organization. These work items helps the test organization to start structured test process with a Master Test Plan.

    When starting a testing effort first several things needs to be in place… we need to understand the assignment, determine what we are going to test what are the risks, etc… the first four steps in the image below.

    BDTM steps

    Beside these steps also decisions needs to be taken about what to test where, you don’t want to loose money by testing things twice. As described in the TMap Next book:

    The type of system and/or development approach and/or test policy determine which forms of which test levels are best used. For iterative system development, for instance, a thorough acceptance test is less obvious. This is because the quality from the user perspective has already been tested in previous test levels. However, for package implementations there is a far greater emphasis on a thorough acceptance test. The risks here are focused on the implementation of the package in the organization, a typical acceptance test aspect. 

    So, topics covered by the master test plan can be:

    mtp


    All these activities are described in detail in the TMap Next book, and you also get these steps when using the TMap for VS2010 process template, as initial work items.

    WA WI

    These Master Test Plan activities got descriptive guidance attached to it. Accessible by using Microsoft Test Manager 2010, Visual Studio 2010 or the TFS 2010 Web Access tool, helping every role, to understand the assignment, the activities and test goals.

    mtm ini
    [Microsoft Test Manager 2010 | Initial Master Test Plan Work Items with guidance]

    VS ini[Visual Studio 2010 | Initial Master Test Plan Work Items with guidance] 

    wa ini

    [ TFS 2010 Web Access | Initial Master Test Plan Work Items with guidance]  

    So, when the project starts the guy / girl with the Test Manager role has to assign the different tasks to the right team members to complete the Master Test Plan.

    In a following post [probably not the next one] some Word and Excel templates which support these tasks and can be found at the project portal. First a planned post about initial work items for planning the infrastructure.


    If you want to keep up to date about TMap testing and the VS2010 process template, send me an email with your name and organization. Beside this blog and our the TMap codeplex site we have a community of users, to exchange ideas, usages stories and additional updates of the template en testing practices.

    TMap for VS2010 Testing Process Template RC published on Codeplex.

    A bit later as planned, due to my broken leg.

    Just checked in the RC version of the TMap for VS2010 process template…
    Downloaded it from TMap.Codeplex.com.

    codeplex

    Still a lot of work to do, specially on the documentation and reporting part [lucky me, my colleagues from Sogeti US, Sweden and other Sogeti countries are helping me]. But still, the documentation section is a very good starting point when you want to discover the TMap processes for VS2010.

    Later this week I will post some more content.

    Speaking at Dutch DevDays and Danish ALM Day

    Will be speaking at the Dutch DevDays [about VS2010 general/practical usages] and Danish ALM Day [about TMap for VS2010] in March/April.

    The Hague, The Netherlands
    March 30-31, 2010
    DevDays 2010

    [update]
    Will give the interactive session "ALM Best Practices: Modeling the Showcase Application" with @Edwb (www.edwardbakker.nl) and the session "ALM Best Practices: Testing the Showcase Application" with www.RobKuijt.nl. Rob is a real tester, who will give an interesting look in the world of the tester. 

     

    Copenhagen, Denmark
    April 9, 2010
    ALM Day 2010

     

    Not as much as Brian Keller [4 weeks, 7 countries, 25+ sessions, 1 suitcase…]… looking forward to it, specially because I can travel again and almost can walk without crutches. So, I can do my talks standing with my hands on the keyboard without falling.

    Test Tool Checklists - TMAP NEXT DOWNLOADS

    Some interesting downloads from my test expert colleagues…
    Beside you can find these documents on our www.TMap.NET site all these templates and checklists also have a place in the TMap Process Template for VS2010 [which can be found at TMap.Codeplex.com].

    excel Overview "Tools per TMap activity"
    TMap has a lot of test specific activities in this Excel sheet you can see a link between these activities and the tool categories. Interesting to map Visual Studio with Test Professional 2010 to it,  it almost fulfills every category.
    word Checklist "Intake Test Tools"
    After your test tool selection this is a nice checklist when setting up your test environments.
    excel Checklist "Test Environment"
    Nice checklist when setting up your Lab environment with Lab Manager.
    word Overzicht "Test Tool selection criteria" [Test Tool Selection Criteria]. Combined with the “tools per TMap activity” will give you a nice capability overview of your test tools…

    More in the process template and on the TMap site.

    VS2010 Architecture Explorer Analyzers

    DGML, the new VS2010 visualization technology has capabilities to render graphs. Graphs like dependencies between classes, inheritance graphs, custom graph, you actually can visualize any relation you want. Cameron Skinner has posts about DGML and Chris Lovett has some great video’s.

    4 
    [class dependencies uml2doc.codeplex.com]

    Now the interesting thing is that you can analyze these graphs. In the image below you see the analyzers; Circular ReferencesHubUnreferenced.
    The purple classes are unreferenced which probably means dead code or entry point of the application. The kind of blue-green nodes are hub, classes which are important and heavy used, and no strongly connected classes in this solution.

    5

    Make your own analyzer.

    You also can make your own analyzer. For example code coverage or naming conventions or … whatever you can imaging. In the example below I created an analyzer which marks the nodes green with the string ‘Clemens’… (code you know is great:)

    1

     

    Ok, maybe not that interesting analyzer, more interesting is the creation… in the /PrivateAssemblies/Providers folder there are already several analyzers available, actually the ones mentioned above.

    6 

    A small analyze of this assembly tells us that all the analyzers are using the IProvider interface and the ProviderAttribute [see below]. After some more exploration you will find that the prgroesion.common assembly has a method ‘ProviderDiscovery’ which looks for classes in the provider directory.

    Capture 

    so, making a assembly with the code below is a good start:

    [Provider(Name = "ClemensAnalyzer")]
    public class TestAnalyzer : IProvider

    In the void Initialize(IServiceProvider serviceProvider); you have to initialize your provider, register the actions and action handler [action.ActionHandlers.Add(new ActionHandler(this.OnAnalyzeTests));]… which calls your analysis…

    foreach (Node node in this._graph.VisibleNodes)
        {
           if (node.Label.Contains("Clemens"))
               {
                      node[HasClemens] = true;
                      outputObjects.Add(node);
                      this.ThrowIfCancelled();
               }
        }

    the node[HasClemens] = true; is some additional meta data you add to your diagram: private static GraphProperty HasClemens = GraphProperty.Register("HasClemens", typeof(bool), new GraphMetadata("Clemens","This one contains Clemens",null,GraphMetadataFlags.Default), typeof(TestAnalyzer));

    All this and a bit more [didn’t finished the analysis completely, there is a lot more possible] result in your own analyzer…

    Picture1

    Now, let’s start making a useful one :-)

    Visual Studio 2010 Team Foundation Server Requirements Management Guidance

    Another delivery from the VS ALM Rangers is public available… the Requirements Management Guidance

    Very useful guidance, with a small contribution from me with the Enrich VSTA 2010 Use case diagram with SketchFlow Screens post. [see the Requirements Elicitation part].

    1

    Visual Studio 2010 Ranger News

    > Rangers - Visual Studio Team Foundation Server 2010 Upgrade Guidance ships to Codeplex

    2

    > Rangers – Visual Studio 2010 Quick Reference Guidance ships to Codeplex

    1


    more will follow..!
    http://blogs.msdn.com/willy-peter_schaub/archive/2009/11/16/rangers-visual-studio-2010-architect-edition-guidance-kickoff.aspx

    Traceability in VS2010

    Always an interesting question, how does traceability work in VS2010?
    To often asked without any context, or only asked from a requirements perspective. Still way too open to answer in a tweet. So, a post to canalize those questions a little bit more…

    [see the image below for the numbers]
    1_2 you can take two directions when talking about traceability. The first is focused on “work”, the work items repository part of TFS [on the left side of the green dotted line]. with work related traceability we can answer questions like “did we completed all tasks for that requirement?” [for more see the red list]. Information which is very important for every roll in the Application Lifecycle. A tester want to know if he can start testing, so he want to see if the developer is ready. A project manager wants to plan the work. Developers want to know if designers are ready to start with a stabile set of needs… and many more. All work related information, and information which can be tracked/ traced by using work item and its repository.

     trace

    2_2 VS2010 main capability for work related traceability are the TFS work item repository [see image below from MSDN] and linking of work items, setting up a hierarchy. 

    Dd286718WIT_TaskOverview(en-us,VS100)       Dd293542TreeListScenario(en-us,VS100)

    We can breakdown requirements, or user stories, in tasks. 4_2 tasks that needs to be executed to get the requirement done. These tasks can have a parent-child relation [and other see Working with Link Types on MSDN]. Giving us the information we need in any kind of way, for example reports.

    us

    So far the work related traceability. The other kind of traceability 1_2 is based on artifacts, things we make during the application lifecycle, I will call them ALM artifacts. ALM artifacts are used to create the solution/ application. For example the source, XAML and configuration files which make the solution. But, also the diagrams which we created to make a correct, consistent and good communicated application architecture, we use them to drill down from the needs to code. And also test cases belong to the things we make during the application lifecycle [I can imaging when you get confused now, test cases are within VS2010 work item types, but they definitely belong to the artifacts section].

    3_2 Use case – user story what is the difference… I often use both [see this piece of MSDN documentation for modeling requirements]. User stories are work item types and use cases are ALM artifacts. So, they are a great bridge between the ‘work-world’ and ‘artifact-world’. The good thing is the capability of VS2010 to link diagrams, and other model elements to work items. [How to: Link Work Items to Model Elements], this give us the capability to create a trace.

    domainFrom the description and diagrams of the requirements, the often called problem domain, we have to make a big jump into the solution domain.8 Diagrams are created like the component diagram and layer diagrams visualizing the high level pieces of the solution with the dependency and interfaces between these components and layers. [used this image in this post; the modeling world].

    It is also a big gap for traceability, to get this a little bit better a solution can be the replaying of scenarios written down in the user stories and drawn in activities as described in this post; VS2010 Modeling; Create Lifeline from Component.

    A trace back from component/layer to requirement can be a link from model element to the user story work items in where he is used. Never did this, it’s a manual process and probably people will forget the links, maybe with some kind of notification this would be valuable…

    6 An interesting VS2010 capability is the connection between the layer diagram and the sources. This makes a trace possible between the high level design and the sources. See image below.

    layer val

    7 Because test cases are work item types in VS2010 they can be connected to any other ALM artifact, giving us the possibility to connect for example test cases to use case diagrams. Easier to accomplish and to maintain is the connection with test tasks and corresponding user story. But this doesn’t answers questions like; “which code is touched by this test”. VS2010 answers this question with Test Impact, see “Determining Which Builds Have Bug Fixes, New Features, or Requirements”, “Recommending Tests to Run That are Affected by Code Changes” and “Developing Tests from a Model”.

    Another interesting traceability scenario can be build with test case generation, see this ‘old’ Model Based Testing beta 1 video. [some more info on MBT can be read on Rob’s blog]

    Next, 3_25786 all have a work related task. So, not only traceability within the two sections is possible also traceability between the two sections is possible. answering questions like; “which task created this line of code?”… creating this link / trace is a manual task but it can be controlled by a check-in policy.

    workitem

    So, when someone asks you the question; “what about traceability in VS2010?” you now can canalize this and guide him/ her to the real traceability question they want to have answered [and tell the solution]….

    < probably more to come on this interesting topic, also because the extensibility model of the diagrams is powerful enough to create your own required traceability between artifacts with notifications and work item linking… very very interesting >

    VS2010 Modeling; Create Lifeline from Component

    From the VS2010 MSDN sequence diagram documentation

    Relationship to other diagrams

    You can use UML sequence diagrams together with other diagrams in several ways.

    Lifelines and types

    The lifelines you draw in a sequence diagram can represent typical instances of the components or classes in your system. You can create lifelines from types, and types from lifelines, and show the types on UML class diagrams and UML component diagrams. For more information, see Classes and Lifelines.

    Beside we can create lifelines from/for classes we also can create lifelines for/from components… which is actually a very interesting feature.

    Context menu on a component shows the create lifeline option [not available when clicking on a part ]
    cl

    After the creation of several lifelines, you can draw the interactions between the components. There isn’t functionality like the bi-directional method creation in the class-sequence diagram interaction for the component-sequence diagram. Kind of logic, a component only has interfaces.

    sq

    Why would you want to do this, create sequence diagrams for components?
    While the component diagram 3_2 is a static view of your system the sequence diagram is dynamic, it visualizes the flow in your application, the sequence of actions that occur in the system. So, you could use sequence diagrams to validate your system, your component design. Take a scenario, a requirement scenario, and create a sequence of actions from in a  sequence diagram 4_2 . By doing this you create a kind of simulated behavior of the component structure, which you can check on correctness and consistency.

    The scenarios used for this can be found in the use case diagrams 1_2 , which describe the actions that take place on/in the system. Now describes a use case diagram not really a scenario, you better can use an activity diagram for that 2_2, which can be based on the use case diagram as a kind of use case realization. Now the interesting thing is, testers use activity diagrams to create test cases, they have specific technologies to extract the right amount and type of scenarios [see http://robkuijt.nl/index.php?entry=entry080423-135750 ], these scenarios we can use to validate our component design which actually closes the loop.

    all

    It would be even more interesting and powerful if we not only could link sequence and component diagrams but also use case and activity diagrams making notification when an activity changes and a scenario can’t be run anymore on the purposed component… hard to accomplish, but interesting, versioning would be hard…

    Microsoft Test and Lab Manager and security and permission settings

    Within TFS you can set permissions, what people are aloud to do within projects and with 2010 in place also within project collections and within Microsoft Test and Lab Manager.

    In some situations, project settings, you want to set these permissions. For example in the TMap process template there are different rolls responsible for different tasks. The Test Manager is responsible for the Master test plan, the Test infrastructure coordinator for the test infrastructure and tools, the test coordinator for the test plans, the runs and reports and the tester for creating and execution of the tests cases.

    These rolls/ groups you also can find in the TMap Process Template.

    rols

    All rolls have there specific restrictions. For example a Test Infrastructure Coordinator is aloud to setup lab environments but a Tester isn’t, and a test coordinator can create a test plan but a tester isn’t. A test manager and coordinator can edit test runs results. A tester can execute test cases but a developer can’t, a developer can change sources but a tester can’t… etc, etc… A frequent ask question by test organizations is: how can a set this restrictions…. the answer is it is easy but you need to have project edit permissions :-)

    On several places you can set security permissions.

    In the Team Foundation Admin Console, the same settings can be set within Visual Studio menu Team—>  Team Project Collections Setting

    Picture1

    You only can set project collection and TFS specific setting at this level, not that interesting for test management.

    Within Visual Studio, right mouse click on within Team Explorer or by using the Team menu.

    Picture2

    This is a more interesting place to set permissions for the test organization. For example in this setting a test coordinator is aloud to create test runs, but can’t change configurations and environments.

    Picture3

    This results in the fact that he must contact the test infrastructure coordinator to maintain the test infrastructure. And he got a message when he tries to change a setting in Lab Center.

    lab restrictions

    A hidden security setting [I call it hidden because its hard to find in my opinion and I had to search for the projectplan permissions] is a the Area and Iteration menu item, just below the ‘Group Membership’  item.

     Picture4

    When clicking the ‘Areas and Iteration’ menu item and click on the bottom right of the dialog what appears you can set permissions for the selected Area node or Iteration node. For the test organization important manage test plan permissions can be set.

    Picture5

    When you set this permission so a tester isn’t aloud to manage test plans he gets nice an clean messages when he tries to save one.

    testplan restrictions

    But, it gets even more interesting. When a tester isn’t aloud to manage test plans he also can’t add test cases to a test plan. So, the create new test case in the plan tab of MTLM also will result in a ‘Not Aloud Message’. While the tester is aloud to create test cases he isn’t aloud to add them to a test plan, within MTLM he has to create test cases in the ‘organize’ tab –> test case manager. So a test coordinator, or some one else who has the manage test plan permission can add it to the test plan.  

    Picture6

    I have spoken with test organizations who prefer this way of restrictions also have spoken with who don’t want this. Within the TMap Process Template, you will find a light weight implementation of these permissions settings. [not yet in the download ]

    To mention all the permission settings locations, right click on the source control treeview and select properties, you can set permissions for source control in that dialog [ you also have to maintain the reporting server and the SharePoint server separately]. ping me if I forgot a security settings location…