StarWest 2016: Some Major Implementable Take Aways
Two weeks ago I attended the StarWest west conference in Anaheim, California. To give a quick synopsis of the conference, it basically is one of the most recognized QA conferences in North America. The conference is put on by a company called "TechWell", and it was focused on spreading new ideas and throughout the QA community. It was located at DisneyLand in Anaheim, California and I was there from Monday to Friday. The pre-conference workshops started on Monday, and the conference itself was Wednesday and Thursday. I also stuck around for the "Leadership Summit", which was an add on.
One of the reasons I love attending conferences, is to figure out what trends are permeating throughout the industry I operate in. While my traditional conference of choice is still Microsoft Build, I decided that as a quality champion, I needed to inspect the traditional testing industry to ensure I wasn't missing things my team could benefit from. See, at my place of work, we push our teams to adopt new things everyday, and had the ability to basically design our process from the ground up, injecting a crap ton of technical focus along the early group forming stages. We focused a lot on ensuring we are developing our technical skills for testing, and growing environments which would allow us to express those skills in the art that is automation. Given the last mentioned skills are currently focused around a .Net environment, going to MS Build was very natural for me. But, as our team matures, I wanted to see how we compared against other testing teams, and I wanted to ensure that from a strict quality perspective we were not missing out.
Total Team Testing
It was surprising to see how many conference attendees were struggling with adopting agile and understanding their role as testers in an agile process. There were at least three talks with respect to "Agile Testing" (there actually was an "Agile Testing Track"), and at least three talks with respect to "DevOps & Testing" (again in its' own track). In numerous talks I attended, folks were throwing up their hands to identify themselves as part of waterfall teams. In general, there was not a good consensus what it meant for testers to be agile, and numerous approaches were proposed as to what an agile tester should be and how to keep up with the increased velocity of development.
I noticed that we as an industry group, are trying to change the way we are thinking about testing.
Numerous sessions I attended attempted to identify what it meant for us as testers to be a part of the new way of doing things. The one that really resonated with me, was @BobGalen's talk about ideas during the second day of the workshops. Bob was really pushing the idea of testing being a team responsibility and the quality engineer adopt a "quality champion" role, as opposed to only testing. This approach implies that the test engineer becomes a sort of testing coach, and involves the team with respect to the testing process. He or she may be the architect of the test plan, but everyone on the team tests. I really liked this mindset, because for the most part at Title Source, we have adopted this mindset and have worked out a lot of the kinks that come with delivering value to the team, without testing everything ourselves.
Implementing Team Testing Take Aways
There were two main implementable take aways which I noted for transitioning from individual to team testing.
1. In Agile We Spiral Into Everything...Including Testing (Courtesy of @BobGalen)
The idea that things have to be 100% polished before delivery does not jive with the agile methodology. This lesson also applies to testing. As Bob explained to me, in agile testing, we need to focus less on concrete test artifacts, and more on understanding the domain knowledge of the team. The greater the domain knowledge of the team, the less formal documentation we as testers have to provide, and the more guiding we need to do. Having said that, if your team is brand new and does not understand the business process, you probably still need concrete testing artifacts to provide more guidance to the team (for example test cases). The more the team matures, and the more business knowledge you pick up the less structured your test artifacts can become, and the more you can trust your team's knowledge of what is "right". To me, this is the optimal scenario, because as a quality champion, you can then spend more of your energy on strategic test approaches, and learning new testing approaches you may not have thought of (or had time to execute) before...like performance or security tests.
Implement The Advice!
So to "Gump It Down" (sorry for the Quicken Loans Family of Companies jargon), the less business domain knowledge your team has, the more specific the test artifacts have to be. If your team is new, write test cases, if you have a good deal of business experience, allow for more exploration during the test process.
Shift Left And Use Automation To Do It!
As I was listening to @MaryHThorne preach about how to implement a behaviour driven development approach using a tool called SpecFlow, something dawned on me. As test engineers, we want to have more time to explore new test processes! I was listening to Mary and thinking of how the tool she was preaching about, could help me "shift left".
Shifting left essentially refers to testing early and often. As Mary was talking about SpecFlow, and basically wrapping automated methods in human readable verbs to be used during writing of acceptance criteria for user stories, I thought that this idea could help me and my team at the same time! The tool would allow me to be a bit more selfish, as giving others the ability to write automated tests directly for acceptance criteria would take some work off of my plate, and give me time to bring other testing processes into the fold.
I won't go into details as to how SpecFlow works, but the idea that a product owner could write acceptance criteria with the team and they would be translated into tests really excited me. The product owner would benefit from this model since he or she would be able to (would be forced to) gain intimate knowledge of the product he or she is driving (specifically the way it should behave). This would force him or her to interact closely with his or her team, and truly have a stake in the development process (since he or she wrote the criteria).
Additionally, the product owner would forced to become more technically savvy, since if he or she was writing acceptance criteria for automation, he or she would be forced to learn about the development environment (SpecFlow is an IDE package). Having said the above, we do have to understand that there is a bit of work to implement the SpecFlow verbs, and "CRUD" (Create, Read, Update, Delete) libraries. But after the initial investment, everyone would win. The product owner becomes more involved, the team gets awesome acceptance criteria, and the test engineer gets to focus on bringing in different types of test approaches, raising overall quality and as shifting left goes, everything happens earlier in the development process, since all of the above tasks can happen in parallel! Thanks @MaryHThorne, you inspired me!
Implement The Advice!
To implement the above, you need two things. An open minded product owner, some time to explore SpecFlow and write some initial libraries. Go to the SpecFlow link below, load it into Visual Studio, and create a simple Create Read Update library. Then talk to your product owner. Have him or her write some acceptance criteria for a story. Create a simple test using SpecFlow, show the product owner the test, repeat!
Overall Conference Rating
So as you saw above, I learned a lot brought back some implementable thoughts and had a great time (evidence below). I take conferences as an opportunity to take vacation around the area, and this was no exception. Just for the record, it's on my own $ and through my own organization efforts.
The conference provided a lot of inspiration and the opportunity to meet some great knowledgeable, fun people in the testing family. Our team is working on the ideas above (and more), and so I deem this conference a 4/5. The only reason I did not give the conference a last star, is because I did experience some speakers that were not 100% prepared for their talks. To those, I gave individual feedback. I hope they treat it like all feedback should be treated, a gracious gift in the process of continous improvement.
Shift Left Testing
SpecFlow: A DotNet Behaviour Driven Design Testing Tool
Twitter Handles Mentioned (aka worth following!)@BobGalen