Today was the first official day of CAST, the tutorials day.
Before I start talking about the tutorial itself (I chose to attend to Michael Bolton's testopsies) the day began with lean coffee - where a bunch of early birds (and me) gathered to talk a bit about all kinds of subjects. we started out with a fairly large group of people for a lean coffee (I think we were about 10 when we started, and ~15 near the end), but it still managed to hear almost everyone (though not as much as I was hoping - as it tends to happen in large conversations, three or four of us were more vocal than the rest). Some topics that were very interesting for me to hear about came up (and two of them were topics I raised, so yay me!). two subjects that I want to point out were "session based test management debriefing"and "office politics" - The first topic was raised by Brendan Connoly (who has a great blog that you should read), where he wanted to know whether others in the group has tried SBTM, and how did they deal with the debriefing part that seems to be very heavy. We spent some time on trying to understand what are the gains he was aiming to achieve in debriefing, and Dwayne said that it's a powerful tool for either training or for peer review of your testing. Matt did mention that out of the many cases where he encountered claims of using SBTM, none were actually doing that, and the first thing they didn't do was the debrief. Apparently, this is quite a common challenge. Personally, for the purposes stated (letting people know where you are) I find that saying "what I'm about to do", perhaps during the daily stand-up, is usually enough.
The other subject that was raised by Neil (whom I mentioned in the last post, and is by far faster than I am in getting posts written), and he wanted to hear people ideas about dealing with cases where you don't agree with decisions done at your work place. It resonated with a subject I'm very fond of - which is finding the best way to work with management to promote my ideas about how we should approach testing.
Then came the tutorial of the day.
Frankly, it was a good session, that I probably have very little to write about, since it was more of an experience for me and less of "now I know something specific". At first, we split up to small groups and created something to represent "what is testing". The form our group chose (and we weren't the only group to do so) was to create a mindmap (which you can see here). I had the opportunity to work with Perze Ababa and Steven Woody, and we had a really interesting discussion about "what testing is for, and how does it look like", which, despite being very abstract, was interesting, and, at least for me - enlightening. I got a glimpse of how other testers think about their testing, and try to defend (and change) my own take on the matter.
The next step was to try and define the activities that are in testing. We grabbed Neil to join our group, and engaged in a discussion. Suddenly, during the part where we collected the draft into some presentable form, Neil asked "What's a word for "deep diving" that starts with an "M"?
The result is posted here:
Most of the points are clear and self explanatory, but there are a couple of points where we used words that fit the acronym better than the idea we had:
By Modeling and refining we meant that while testing we perform activities that improve our understanding of the product - investigating a bug is one easy example, as we build a model of how the software really works, and when investigating the bug we refine that model and adjust it to reality.
The second part is the "setup\configuration\orientation" part. At the beginning of the discussion we specifically excluded things that happen before and after testing, which are usually named "setup" and "report". However, we came to conclusion that even after the setup part is done, a test will probably have a part where the tester verifies that the configuration is as it should be, or that a test will include a part requiring configuration changes (upgrade tests are the easiest example), and sometimes, in mid test a tester will briefly stop just to figure out "where am I now, and what is the state of the system?"
The best part of the testopsies was, naturally, when we actually sat down to testing. I paired with Neil, which was really impressive - The model in which we paired was "tester \ reviewer", and I first got to see Neil in action. Neil did a very impressive job of testing while speaking constantly to narrate the work he was doing, while taking notes on the side, so I could understand (some of) how he was thinking and what he was doing - with the exception that he was talking *very* fast while trying to beat the 12-minutes clock. You can watch Neil's session in his blog post.
After the session we talked a bit about some of his choices and techniques, I was impressed by the speed in which he oriented himself, and how orderly and details were his notes.
Then came my turn, after Michael focusing everyone to the list they comprised and see if it needed adjusting after the test session. We were quite happy with our list (which might not be complete, but is quite convenient). During my turn, I tried to add some tool-usage which we didn't do much, and after some very short 12 minutes, I think I managed to do a semi-decent work. Neil then surprised me again when he kept a scorecard of minute-by-minute timing and marked what part of Christmas was applied during that minute (picture in his post), from which he drew an interesting conclusion about the difference between "orientation time" and "hands-on testing" time.
That's about it - while I would have enjoyed some more iterations of actual testing & feedback, I found this workshop fruitful and fun.
At the evening I went to Excelon house, where we talked about, and I got to meet Joshua, and then we played what is probably the longest Munchkin game I've ever played (just a bit over 2 hours, I think). While it was a bit late when we were done, it was a nice way to close the evening.
No comments:
Post a Comment