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? ) 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 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.