Exclusive Visual Studio 2010 Courses in July

TesthouseVisual Studio 2010 training courses on Coded UI – Test Automation and Web & load Test – Performance Testing for July at the Microsoft Campus, Reading .  Be the first to gain the relevant skills and expertise of using Microsoft Visual Studio 2010 – a highly sought after tool that is truly making a significant buzz within the testing community since its release last year.  Details of the courses we have on offer are:

1.  Coded UI (Test Automation) – 4^th-5^th July 2011 (2 Days)

A two-day workshop, the purpose of which is to provide a practical introduction to the Coded UI – test automation tool in Visual Studio for developers and testers.  Price: £750

Course Outline

2.  Web & Load Test (Performance Testing) – 6^th-7^th July 2011 (2 Days)

An introduction to the web and load testing capabilities of Visual Studio 2010 test suite. Aimed at QA and Performance Engineers who needs to create scripts to load test their web applications.  Price: £750 Course Outline

We are giving priority to MSDN subscribers by offering a further discount, so reserve your place now.

To book these, or if you require more information, please contact Testhouse on 020 8555 5577 or email Melanie Ancheta at melanie.ancheta@testhouse.net.

Best Regards,

Melanie

Seasons Greetings for 2011!!!

A Very Happy and Prosperous New Year to all!

We wish you the very best this coming 2011!!

Best regards,

From everyone here at Testhouse!!!

Live Webcast on Mobile Testing

Today’s market of mobile and PDA users presents businesses with a new way to reach and service their customers. Servicing this market and staying ahead of your competition is about delivering a quality application which is quick and easy to use. This makes Mobile Phone and PDA testing critical to your business.

We are partnering with HP and DeviceAnywhere to deliver comprehensive testing across the web, WAP and mobile devices, helping you successfully bring your product or services to the mobile platform.

The webinar  includes a demo of DeviceAnywhere platform integrated with HP Technology.

To listen to the whole recording, please click Mobile Testing with Testhouse .

To view a demo of the application, please click Mobile Testing Demo

Let us know what you think, happy viewing!!!

Mel

Best practices for Microsoft Test Manager part 2: Testing in a Sprint

Hi there, and welcome to part two of Best Practices for Microsoft Test Manager: Testing in a Sprint. Last post we explored the theory behind Scrum and its advantages. This post we will take a more detailed look at the typical tasks that devs and tester participate within a scrum to deliver a particular piece of functionality/user story/Product Backlog Item (PBI). But first a little background for the new readers on what Microsoft Team System and how testing plays a part in this:

You can now be more productive throughout your testing lifecycle of planning, testing and tracking your progress by using Visual Studio Ultimate or Visual Studio Test Professional. These testing tools are integrated with Team Foundation Server, which lets you define your testing based on the same team projects that other areas of your organization are using.

Both Microsoft Visual Studio 2010 Ultimate and Visual Studio Test Professional 2010 now include a new application called Microsoft Test Manager to help you define and manage your testing effort by using test plans. You create a test plan and add any test suites, test cases, or configurations that you need, as shown in the following illustration.

By using the suite of tools in Visual Studio Test Professional and Visual Studio Ultimate, and combining those tools with Visual Studio Team Foundation Server, you can apply proven practices to manage your application's lifecycle, from understanding customer needs through code design and implementation to deployment. You can use the instrumentation in these tools to trace requirements to checked-in code, builds and test results. These practices can help your team create software that is valued by your customers and that is faster and more reliable

1. Plan and Track: Capture what is important to your customers, and track your project's progress. Enact processes and monitor their quality to help your team turn customer requirements into working software.
2. Design: Design functionality either on top of existing assets or from scratch, using architectural diagrams to communicate critical information about your team's software.
3. Develop: Write, unit test, debug, analyze, and profile your application using tools that are integrated with the rest of the application lifecycle so that your team can understand how your progress contributes to the project.
4. Build: Build your application using the integrated build system so that your team can ensure quality gates are met and see what requirements have been fulfilled in each build.
5. Test: Run manual or automated tests, including performance and stress tests. Manage testing systematically so that your team knows the software quality on any given day.
6. Deploy: Deploy into virtual environments to enable more sophisticated development and testing.

So back to today's topic, Testing in a Sprint. Let us begin by going through a typical iteration that would occur during a product cycle and highlight the collaborative challenges faced by testers and developers at key points.  Developer tasks will pass from left to right in the upper green arrow.  Tester tasks are shown on the lower red arrow. The grey arrows in the middle represent the nightly builds of the application under development throughout the sprint.

In keeping with our Scrum methodology from the previous post, our team will begin with a Sprint Goal and Backlog Meeting, and the decision is made by the team to move two users stories (US#1 and US#2) from the product backlog to the sprint backlog.

After the Backlog Meeting, the developers begin implementing the user stories in order of priority, while the test team gets itself prepared to test each user story as soon as possible, ideally when it becomes available with a nightly build.

As the sprint advances, the developers complete implementing US#1, and immediately continue with the US#2.  The devs cannot completely focus on US#2, however, as the testers have begun testing US#1 and are raising bugs against it.  The developers must divide their attention between implementing new functionality and fixing bugs filed against other US.  Ultimately, this will lengthen the time it takes to implement #US2.

The devs check in the code for US#2 along with (hopefully) fixes for US#1.  The testers now have to begin testing US#2 as well as verifying the supposed fixes for US#1.  Some of the bugs will have been sent back with a resolution of “not reproducible”, and others will be resolved with fixes that fail to adequately fix the bug, or which result in new bugs. Thus, the remainder of the iteration will follow this routine with developers fixing bugs, and testers engaged in verifying, reopening, and raising new bugs.

Toward the end of the sprint the bug count trends lower as the team focuses on Q/A; but there is a risk:  The testers might well wonder if any of the test cases that had passed earlier in the sprint have been impacted by more recent code churn.  For example, what if a particular test for US#1 had passed when originally run against Build #3; but would now fail if run against a more recent build?  The testers will need to address this risk by investing some effort in checking for regressions.  This can be accounted for by adding a “regress impacted tests” block near the end of the iteration.

So understanding a typical ideal sprint (and there have been many untypical sprints as well) we can begin to understand the risks involved with testing in a sprint: it can unravel very quickly with failing to act quickly to an action, low quality bug filing and fixing, and code changes late in the sprint breaking a previously working US. With that in mind, we can see how crucial it is that testers and developers need to work closer together within a product development iteration in order to deliver a quality product on time.

Microsoft test Manager adds value at each stage of the iteration:

• Plan your testing ahead of development: MTM provides rich tools for planning test coverage of user stories that help the testers stay ahead of the devs and avoid unnecessary delays.
• Tune in to the build cycle: MTM helps testers track what’s new in each build (user stories, tasks, bugs) and take appropriate action.
• File high quality bugs: MTM tightens the bug loop by empowering testers to file rich, easy-to-repro bugs, which leads to faster dev turnaround.  No more bug ping-pong.
• Fast-forward verification: MTM helps testers manage their bugs and close them efficiently using single-click to “verify” and playback of recorded actions.
• Regress impacted tests: MTM helps testers identify and regress test cases impacted by code churn.

Wow that really is quite a bit we have covered for today. I don't want to give an information overload in one post, so I will let that one sink in for a bit. In part three of this increasingly epic series I will look at the five bullet points above in greater detail and we will explore the features available in Microsoft Test Manager that enable how we can do these things. There's going to be even greater detail in that post than there has been in either two posts, and once you have read it I am sure that you will be grateful that I have split them up!

See you all next time,

Richard

Testhouse Senior Visual Studio Consultant

Best Practices for Microsoft Test Manager part 1: Introduction to Scrum Methodology

Best Practices for Microsoft Test Manager part 1: Introduction to Scrum Methodology

So it has been a long while since I blogged and for that I can only apologise: there's little point in evangelising the product if I don't use every opportunity to do so, and as the blog is available 24/7, there's little excuse not to.

In my defence I have been out on project and busy creating some training material: I also took a webinar recently which gave an introduction to Microsoft Test Manager for our Middle east partners, and I am pleased to say that it went down very well.
I also had an opportunity to spend a few days with a company in Cardiff who are beginning a project using Microsoft VSTS 2010, and I must say that I have completely forgotten how overwhelming it can be to someone who has little exposure to the Microsoft ALM just how much there is to learn.

So, with this in mind, and also in relation to something I alluded to in my previous post, I want us to explore how Microsoft Test Manager can help testers and developers work more closely together within a product development iteration – such as an agile sprint – to build quality upstream and keep their project on track. As it is a rather large subject, and I want us to start right at the beginning and explain a little bit about Scrum, this blog will be a two parter.

Scrum
Agile Testing Methodology is an approach to software development projects in which functionality is released in smaller cycles, or iterations. This functionality is based on features that have been broken down into sections small enough to be developed and tested within an iteration.

The advantage of Agile development is that changes to the product can be made dynamically. Incremental releases verify that features are released and signed off for production and fit within the overall scope of the product.

Scrum is a framework for agile software development and enables the creation of teams that are able to organise themselves and commit to deliver in a timely manner.
A role unique to the Scrum approach is that of a Scrum Master: overseer of project management tasks including team communication, requirements, schedules and progress. However the role differs from project manager as it is the Scrum Master's role to facilitate team communications, like leading daily scrums (see below) and also to provide guidance and remove impediments that are preventing the team from delivering its goals. Also as an agile team, it is committed to its team members and not a hierarchical management authority. Therefore the Scrum Master doesn’t lead the team.

A key benefit of Agile is that can it can be organised to shape into any organisation in terms of size of team, length of sprint, experience, etc.

• Kick Off- The goal of this meeting is to get everybody on the team together to review the product backlog.
• Elaboration - (list of prioritised work to be done for that particular sprint). While the team is collectively creating the sprint backlog, stories need to be broken into either sub-stories or smaller tasks. During this collective team exercise you can really see the differences in project management (at least if you have a more rigid and formal waterfall like type of background), because there is no management authority that assigns tasks to team members.
• Spring Backlog - Backlog is prioritised and work is committed for this particular sprint, which becomes the sprint backlog. Team will break down the backlog/ user stories into smaller tasks/sub stories. Team will allocate themselves to work required for the sprint and estimate the effort required to deliver stories. If required more work can be broken down and allocated. Note it is in these meetings that resource is also estimated: some people may have holidays or appointments coming up that will take them out of the sprint for a period of time. The team take ownership of the Sprint Backlog Estimations are set by the Team. Often an accompanying Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
• Scrum Meetings - Once sprint backlog has been committed to, scrum meetings will take place at  the same time everyday in the same location. These meetings are ideally very quick, focusing on the salient facts that are pertinent to this sprint only. The objective of the scrum is for each team member to answer 3 questions: what have I accomplished since the previous scrum, what I will be working on next, and what impediments are preventing me from accomplishing my goals. These meetings are key to ensure that the team can achieve their goal, or change quickly if any work is re-prioritised.
• Final Acceptance Meeting - Towards the end of a sprint typically a final acceptance meeting will take place. In this meeting the team will present what they have delivered in this sprint, usually to the business.
• Retrospective - At the end of an iteration there is a retrospective meeting. The team will get together to discuss 3 things from the previous sprint:
  • What we should start doing for the next sprint
  • We the team should stop doing for the next sprint
  • What from the previous sprint was successful and should be carried over.
  • Team members would be required to mention one of each of the above.

Advantages of Using Scrum

When a project is being developed using Scrum, testing cannot be considered as a phase at the end; it must be considered and integrated throughout the iteration cycle. It fuses with programming tasks, working in parallel. The role of a tester is therefore changed in Agile, although the tester must be prepared to put in the effort to change:

• Better communication and more collaboration among devs and testers

As Testing is integrated throughout the iteration cycle then testers are now also integrated from the start – the same also applies to developers. This participation not only from project commencement, but also taking into consideration that devs and testers are one agile team, that they get together on a daily basis and take part in the scrums, and that they are involved and exposed to the tasks that each other is performing towards the overall success of the sprint, means communication among themselves is improved. Scrum meetings also give other team members to comment and contribute to a sprint task that they may not be directly involved in but may be able to improve or offer a solution to an impediment.

• Testers are now more integral to the project

Testers should be prepared to contribute to the project. One of the fundamental concepts of Agile/Scrum methodologies is that teams must be self organising, and the contribution and offerings of a tester must be seen as equal to that of a developer.

• Testing efforts must be maximised

As delivery of functionality is greatly reduced to releases every month - 6 weeks, and, presuming that Continuous Integration is used, builds are frequently being released all the time. Therefore testing efforts ideally must be optimised, as there is no separate time for testing the functionality. The ideal approach to Agile testing is a combination of Automated Testing and Exploratory Testing.

• Exploratory testing is useful when looking for bugs, opportunities to improve, and missing features. So testers should plan on “exploring” the product at the beginning of each new sprint, or any time that there is a change done to a product feature within the sprint.
• Automated functional and regression testing will require planning within the sprint. Automated Testing from a UI point can be expensive in terms of time and maintenance, and so ideally automated testing throughout the product, from Unit Testing to Services testing to End to End testing should be implemented. Unit Testing provides the least amount of maintenance and the quickest feedback to verify if a software build is broken or not. Below the Test Automation Triangle emphasizes this point.

So to sum up, Scrum methodology is an entirely different form of software development from more formal methods, as the onus is placed on the team to deliver the project in a manner that they have control over. The next article will look at a typical sprint in far greater detail and will explore how Microsoft Test Manager can add value at key points to ensure that the project is on time and on track.

Cheers,

Richard.