I found this old draft blog entry while going through some older blog entries. Since this has been laying around for many years now, I figured, it should be time to publish it now. Enjoy.
A couple of years ago Michael Bolton started a blog series on testing and management mistakes, to which I contributed four follow-up blog entries with an introduction, replacing blaming with placating, congruent responses, and causes. All of this was based on a single psychological model, or better, my understanding of it after having read through most of Jerry Weinberg’s work.
Recently I started to dive into some topics in psychology. While working through work from Schulz von Thun, I remembered this series when I crossed the idea of the inner team. I decided to revisit the original conversation and discuss it in the light of the inner team.
Schulz von Thun describes the inner team as a collective of personalities that each of us develops and carries with us. In any conversation, we face the struggle of forces for or against an argument. We also have a team leader, which could be stronger developed with some of us, or weaker, thereby yielding to different responses – sometimes even incongruent ones depending on the inner team member that cries the loudest at any given time.
Let’s revisit the conversation of the project manager asking a tester to work over the weekend, and take a closer look at the inner team within this tester.
Continue reading Testing and Management Mistakes: The Inner Team
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.
Continue reading So, I went for the board
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.
Continue reading Why you should go to CAST
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.
Continue reading On auditing, standards, and ISO 29119
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.
Continue reading Creating good 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.
Continue reading More learning as a professional
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.
Continue reading The “I don’t want to” attitude
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?
Continue reading How do you know you’re improving?
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.
Continue reading The No-Fake-Tester Rule
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.
Continue reading Shallow Disagreements