As a start to making this blog more than just pointers to other testing or BI sites, I’d like to set the stage by talking a bit about the context my team works in.

I’m a test lead on the SQL Server Analysis Services product team. The feature area my team works on is the tools. Up until the latest release of our product, SQL Server 2008 R2, this included primarily the developer and maintenance tools used to work with our OLAP server. Our development tool is called Business Intelligence Development Studio (BIDS). This tool is an extension to Visual Studio that co-exists with other development tools that plug into Visual Studio like the Microsoft language products such as Visual C# and Visual Basic .NET. Our management tools plug into SQL Server Management Studio (SSMS) which is also an extension to Visual Studio. Unlike BIDS, SSMS plugs into what is called the isolated Visual Studio shell which will not include other Microsoft Development tools. (The version of the Visual Studio shell that BIDS plugs into is called the integrated Visual Studio shell).

In the SQL Server 2008 R2 product cycle, Analysis Services built a new product, PowerPivot. My team specifically worked on the part of PowerPivot called PowerPivot for Excel. It is implemented as an add-in for Excel 2010. This was a shift for us. We moved from building development and maintenance tools to a real end-user information worker tool. Rather than plugging into Visual Studio, PowerPivot plugs into Microsoft Office (The other part of PowerPivot is Power Pivot for SharePoint which implements the server side of PowerPivot. My team doesn’t test that component). The 2008 R2 cycle was an interesting one for us since we built our test automation libraries and tests pretty much from scratch as PowerPivot was, in essence, a Version 1 project for us.

In the area of how we test, we test both manually and through automation. The automation approach we use is UI automation using a test framework that we developed on our team at the end of the SQL Server 2005 product cycle. It has gone through many changes since then, driven by the needs of the team. I will talk  more about this framework in future posts since it’s a big part of how we do our work. When I joined the team, there was pressure to do all our testing using automation but we decided that would be a big mistake, especially in our area, since it is user facing and includes the user interface to our tools.  We now spend a significant amount of time doing manual testing along with our test automation work and it’s been important to our ability to do our job.

That’s a quick look at the context we work in. I’ll say more about our automation framework in my next post.