June ALM User Group Meeting–Acceptance Testing Using SpecFlow!

by Angela 17. May 2012 06:12

Get ready, we have a packed summer full of great topics at the Chicago Visual Studio ALM user group! Be sure to join us in beautiful downtown Chicago at the Aon Center in June for this next session on how to improve your user acceptance testing practices using SpecFlow! Be sure to pre-register on our user group site so we can get you entered into the security tool, and please do keep us posted if you have to cancel! We don’t like throwing away food and it helps me to order the right amount.

Topic Description:

Imagine a project you’ve worked on in the past. Whether or not you or your organization makes use of Agile processes, you probably spent a good deal of time going back and forth with business stakeholders on the fine detail of how the software you’re building should behave. It’s possible you had to dedicate effort simply to producing a demo that the business will appreciate and understand. It’s even more likely that at some point, you and the business had disagreement(s) on whether something was “working”, “finished”, or “done”. Those types of discussions can leach away at your team’s time, expend effort, and impact morale as well as create tension between development teams and the business.

Now imagine if you could instead pour that blood, sweat, and tears into developing your application’s functionality. Imagine a scenario where new features are authored test-first, by non-tech staff in a plainly understandable, shareable, and versionable text format. Imagine a situation where the same set of specifications can be shared to drive a browser-based test suite at the same time that the specifications drive an integration test suite. These are the types of scenarios that tools like SpecFlow are particularly well-suited to address.

Unit tests are great for verifying atomic pieces of software functionality, but they are very poor at capturing and communicating specifications at any other resolution than fine-grained. They’re also completely useless to a non-technical user attempting to understand a system’s functionality.

This is where acceptance testing enters the picture. Although commonly classified as BDD (Behavior-driven design), tools and frameworks like SpecFlow serve to bridge the gap between proving the correctness of a piece of code from the inside, micro perspective and the correctness of an application as a whole from the outside perspective.

In this talk, we’ll go over what acceptance testing is, when it should be used, and how to add acceptance testing into an existing application using SpecFlow. We’ll also talk a bit about DSLs (domain-specific languages), the pyramid of returns vs. effort when it comes to different types of testing, techniques for authoring and designing tests and bindings, and finally, because this *is* a group about ALM, how to integrate SpecFlow into a CI environment and why you or your organization should do so.

If attendees wish to follow the demo on their laptops, they can save time by pre-installing the VS tooling for SpecFlow – http://specflow.org. The download there adds some tooling support within the VS IDE, and is not needed to run SpecFlow.


Speaker Bio:

Josh Elster is the founder and principal of his independent production and consulting company, Liquid Electron. With clients ranging from small media design shops to multi-billion dollar corporations, Josh’s experience spans a number of different sectors, projects, and roles. In February of 2012, Josh joined the community advisors board for Microsoft’s Patterns and Practices team for the CQRS journey project (http://cqrsjourney.github.com), as well as being a contributor. Like the common cold, but without the whole being ill aspect, it is Josh’s hope that he can infect others with his passion for software development. When not serving as Patient Zero, Josh can be found reading, playing video games or guitar, or coding. His website can be found at http://www.liquidelectron.com. His Twitter handle is @liquid_electron. His most recent demonstration project, the PostcardApp, can be found at http://www.postcardsfromskyrim.net.


An interesting Quest (pun intended)…into Agile testing!

by Angela 9. May 2012 08:57

So there is a fantastic little conference gaining steam in the Midwest called Quest, which is all about Quality Engineered Software.  If you’ve never heard of it, you should seriously check it out next year regardless of your role.  As I have always said, Quality is NOT the sole responsibility of the testers, and this conference has something for everyone.  I was fortunate enough to be introduced to the local QAI chair who runs the conference the first year it ran (2008), which lucky for me also happened to be in my back yard.  I was with Microsoft at the time, and we had opted in as the biggest conference sponsor, cause let’s be real - who on earth in QA ever thought “Yeah, Microsoft has some awesome testing tools”.  ::crickets::  Right.

At the time VSTS (remember THAT brand? Smile with tongue out) was still new-ish, and the testing tools were focused almost entirely on automated testing. Yeah, I know, TECHNICALLY there was that one manual test type but let’s not even go there.  I know a few, like literally 3, customers used the .MHT files to manage manual tests in TFS, but it wasn’t enough. The automated tools were pretty awesome, but what we found was that MOST customers were NOT doing a lot of automation yet. Most everyone was still primarily doing manual testing, and with Word and Excel, maybe SharePoint. We had a great time at Quest talking to testers and learning about what they REALLY need to be happy and productive, we got the word out on VSTS and TFS, and started planning for the next year.  I was able to be part of Quest as a Microsoftie in early 2009 as well, when the 2010 tools (and a REAL manual test tool) were just starting to take shape, and then the conference spent a couple of years in other cities.  Fast-forward to 2012 when Quest returned once again to Chicago.

I was no longer a Microsoftie, but if you’ve ever met me you know that working a booth and talking to as many people as possible about something I am passionate about is something I rock at, and enjoy! So I attended Quest 2012 again this year, this time as a guest of Microsoft.  I worked the Microsoft booth doing demos and answering questions about both the 2010 tools and the next generation of tools, and WOW did we get some great responses to them.  Particularly the exploratory testing tools.  I am pretty sure the reverse engineering of test cases from ad-hoc exploratory tests, and 1-click rich bug generation that sent ALL THE DATA EVER to developers gave a few spectators the chills. I certainly got a lot of jaws dropping and comments like “THIS is a Microsoft tool?!” and “I wish I had this right now!”. It was pretty great.

I was also fortunate enough to also get to attend a few pre-conference workshops, keynotes and a session or two.  I have to say, WOW, the conference is really expanding, and I was very impressed with the quality of the speakers and breadth of content.  As a born again agilista, I was so pleasantly surprised to see an entire TRACK on Agile with some great topics.  I was able to attend “Transition to Agile Testing” and “Test Assessments: Practical Steps to Assessing the Maturity of your Organization“ and learned quite a bit in both sessions.  One disappointment, there is even more FUD out there in the QA world than what I see in the developer world when it comes to Agile, what it actually means and how it SHOULD be practiced.  I’m not about being a hard core “to the letter” Scrummer or anything, but I also am not about doing it wrong, calling it Agile, and blaming the failure on some fundamental problem with Agile.  There are lots of Agile practices that can be adopted to improve how you build, test and deliver software, without going “all in”, and that was something I kept trying to convey whenever I spoke up.

I heard “Agile is all about documenting as little as possible”, “Agile lacks discipline”, “Agile is about building software faster”, and all of the usual suspects you would expect to hear.  No, it’s about "documenting only as much as is necessary; there is a difference!  Agile requires MORE discipline actually.  People on Agile teams don’t work faster, they just deliver value to the business SOONER than in traditional waterfall models, which sure, can be argued is “faster” in terms of time to market.  The only thing that will make me work faster would be a better laptop and typing lessons.  I still look at the keyboard, I know :: sigh::   I am highly considering doing a session next year on Mythbusting Agile and Scrum, to help people understand both the law and the spirit of Agile practices.  Overall it was great to see that the QA community is also embracing Agile and attempting to collaborate better with the development side of the house. We just need the development side to do the same Winking smile  I also met at least a dozen certified Scrum Masters in my workshops as well, which was great to see! 

One of my favorite parts of the conference was of course getting to catch up and talk tech with Brian Harry.  He was the first keynote presenter of the conference, and spoke on how Microsoft “does Agile”, the failures and successes along the way, and even spent some time talking about his personal experiences as a manager learning to work in an Agile environment. I.LOVED.THIS. Yeah, I’m a bit of a Brian Harry fan-girl, but it really was a fantastic talk, and I had many people approach me in the booth later to comment on how much they enjoyed it. My favorite part was Brian admitting that at first, even HE was uncomfortable with the changes. It FELT like he was losing control of the team, but he eventually saw that he had BETTER visibility and MORE control over the process, and consequently the software teams.  It was brilliant.  So many managers FEAR Agile and Scrum for just those reasons. It’s uncomfortable letting teams self organize, trusting them to deliver value more often without constant and overwhelming oversight by project managers, and living without a 2 year detailed project plan - that in all actuality is outdated and invalid as little as a week into the project.  Wait, WHY is that scary? Sorry, couldn’t let that get by.

And so off I go again, into the software world, inspired to keep trying to get through to the Agile doubters and nay-sayers, and to help teams to adopt Agile practices and tooling to deliver better software, sooner.


Agile | ALM | Application Lifecycle Management | TFS 2010 | SDLC | Team Foundation Server | Testing | Test Case Management | User Acceptance Testing | VS 11 Beta | VS 2010 | Visual Studio | development

Powered by BlogEngine.NET
Original Design by Laptop Geek, Adapted by onesoft