End of August two years ago, I announced that I was going for the AST board. I kept my expectations pretty low, and I am glad that I did. Two years have passed, so I figured let’s revisit that decision from back then. Long story short: I won’t go for another two years. Read on to find out why.
Last year, when the Association for Software Testing announced the location for their next annual conference CAST 2015, Grand Rapids, MI, there was an up-roar happening on social media and back channels like Skype and private conversations. To my own surprise, I saw members of the context-driven testing community falling short of their very own principles. Rather than observing and interacting with people, it seemed that some persons preferred to derive their knowledge about Grand Rapids based upon a prior CAST conference there. Experience may be a good resource to start looking at, but I found that I should trust the folks from the local area that I knew to put together an awesome conference – more so since they could explain to me why the past experience was not so well received. When it came to the October 2014 AST board member meeting, Pete Walen, the conference chair, the guy who managed to send in a proposal prior to CAST 2014 so that the AST board could decide upon it, invited us to the conference location, so that it was easy to see for us where we were going with the proposal. Here is what I learned during my two nights in the conference venue – and why I think you should attend.
Since I am publishing this on my personal blog, this is my personal view, the view of Markus Gärtner as an individual.
I think the first time I came across ISO 29119 discussion was during the Agile Testing Days 2010, and probably also during Stuart Reid’s keynote at EuroSTAR 2010. Remembering back that particular keynote, I think he was visibly nervous during his whole talk, eventually delivering nothing worth of a keynote. Yeah, I am still disappointed by that keynote four years later.
Recently ISO 29119 started to be heavily debated in one of the communities I am involved in. Since I think that others have expressed their thoughts on the matter more eloquently and deeper than I going to do, make sure to look further than my blog for a complete picture of the whole discussion. I am going to share my current state of thoughts here.
Time and again I run into an ambitious tester that presents me his (or her) latest idea for a testing challenges. “What do you think about this situation where you set out the tester to learn X?” “You could provide product foo to the tester, and have him learn X. What do you think?” Time and again, I think there is something seriously flawed with this approach to create and design testing challenges.
This morning, when I took a look at twitter, I noticed a direct message from Michael Bolton on my latest blog entry on learning:
In your blog post on learning, you’ve left out community, and bafflingly to me, practice.
Wholeheartedly I thanked him for the idea for today’s blog entry.
We live in a cruel world. Our profession of software development is very young compared to other fields such as banking, hotels, or carpenters. I truly believe we have taken a couple of wrong turns in our short history. In this blog entry I try to shed some light on it by some seemingly unrelated stories.
I remember a lively discussion at DEWT 4 around self-education, and how you would know whether or not you are improving. There are lots of ways to engage with self-directed learning – in software testing, software development, leadership, and other areas surrounding this field. But with all these methods around, a single question remains: How do you know whether you’re improving with whatever technique you follow?
Have you every worked with a fake tester? How would you notice? How would you notice how much they are faking? Triggered by a discussion back at DEWT 4, I had an insight triggered by a book that I read earlier in my life: The No-Asshole Rule from Bob Sutton. Let’s see how fake testers and the no asshole rule connect in our workplaces.
Stick long enough in context-driven testing, and you will hear the term “shallow agreement” one time or another. A shallow agreement happens when we forget to confirm our understanding regarding a user story before starting to work on it, and find out during the Sprint Review – or worse: later – that the functionality did not meet the expectations of our ProductOwner or end-user. Shallow agreement happens when we find out too late that we seemed to agree on something, but really weren’t. We didn’t check our assumptions, and usually both parties end up being disappointed by each other.
Last year, I realized there is also something like shallow disagreements – and I am not sure whether these are worse than shallow agreements.
There are a couple of professional organizations out there. I joined a few of them. How did I pick the ones that to join, you ask? This blog entry serves as an overview, and a decision aid for tester folks also looking forward to become more professional in their work life.