SharePoint Conference 2009: ALM in SharePoint 2010

This was a session that actually had little to do with SharePoint, or maybe it´s just what it was completely about…depends how you look at it.

A quick recap of the most important features of the new VS 2010 (TFS 2010) capabilities in the area of ALM (Application LifeCycle Management)-

As it says on top of the slide shown above, VS 2010 is supposed to support the whole lifecycle of an application from the development phase, then into testing and finally production.
This has in previous version of both SharePoint and TFS/VS been a bit of a challenge. You had to do a lot of stuff on your won, from using WSP builder (or something else) to build your SharePoint artifacts into deployable WSP packages. In 2010 the build process on TFS now supports building WSPs out of the box (wonder what will happen to WSP builder now?) That, together with a much better building experience, will make the packaging of SharePoint applications much easier.

Here are a couple of other areas where Microsoft have made investments:

  • Dependency Diagrams – understand dependencies in your code visually
  • Gated Check-Ins – avoid breaking the build if the check-in code will do that
  • Test and Lab manager – plan, manage and execute test
  • Virtual Test Environments
  • IntelliTrace
  • Coded UI tests

There was one thing that apparently didn´t work in SharePoint and that was the ability to drill down into the code and see the values of the actual variables in historical debugging (Intellitrace). You can still see all the data collected but apparently they hadn´t had time to implement the SharePoint integration this time though. But the presenter, Jay Schmelzer, promised that will get around to do that soon.

The area that really impressed me was in the area of testing. The new Lab and Test center stuff are great. You can now (as a tester) go into an environment (not in Visual Studio) and first plan your test (setting up the steps) and then execute that test.

The cool thing here is that the screen splits in a 20/80 split with your test on the right and the desktop on the left. Then you go through the steps one by one and verify them. If you for example have a step that says “open browser” you open the browser and then sign off on that step or report a bug if it fails, If a bug is reported the UI for reporting a bug is automatically opened and all the data from the actual step is included. What is also so super cool is that along with the bug a video recording is supplied showing the actual things going taking place on the screen so that the developer can then look at the steps that the tester made. So this means that we no longer get bugs like “clicked the button and got an error” but now we can see what button actually was clicked and all other stuff that the user/tester did.

More cool stuff in testing. If you are really serious about your ALM process you normally use something called a BVT (Build Verification Test) that is supposed to verify that your application still works as excepted after a change has been made. In the old days (ha ha) I have used a web test that recorded some sort of scenario and then kicked of those BVTs to test my app for regression. Well, these web tests were sometimes a bit hard to get working properly and frankly they were a bit hard to work with. Also, they where usually conducted on the integration environment which mean you had to check in your code, build a package and deploy and install that on the server(s).

Well, now we get something called the coded UI test.

A coded UI test is basically a recording of a scenario that you make on your own dev machine, with the ability to pause, and generate many small test cases much like a unit test. You can pick elements the screen that you want to input data into (say a textbox) and also compare values on the screen (if textbox1 has a value of 3 then the texbox2 should show 6 or something like that). The good thing is that this is all generated as code in the background (hence the coded UI test) so you can hook into the tests and apply your own complex checking.

Then you can run these (BVTs) test when checking in or something to verify that your app still works. How great is this! Bravo Microsoft!

Advertisements
  1. Leave a comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: