Page 8 of 8

Decisions on conferences

This afternoon I read an interesting post from my colleague and fellow DEWT member Jean-Paul. In his post he askes the question: “What do you, or rather what does your manager, see as valid justification to attend a conference?”. The funny thing is, that I am manager at the same company Jean-Paul works at so I am one of those manangers who have to decide if testers can go to conferences or not.

While I was thinking about this, I realised that to express my opinion I need to answer 3 questions:

1) Why should testers attend conferences?
2) What are the criteria I use to justify if somebody can go to a conference?
3) What do I expect from testers who go to conferences?

To answer question 1: I fully agree with Jean-Paul: “Conferences typically are the place where you can learn the latest developments and opinions, submerge yourself into the testing mindset, confer with your peers, refresh your ideas and expand your network.”. So that is why I think every tester who is serious about learning and becoming a better tester, should attend conferences.

Before I can answer question 2, I must explain something first. There are a lot of conferences nowadays and I wonder why people always want to go to EuroStar. I admit that it is one of the best known conferences around (in Europe) and it has been one of the few international highly regarded conferences until a couple of years ago. But there are more conferences so why go to EuroStar? I am not saying you should never go to EuroStar, but maybe there are other interesting events or conferences around? In the Netherlands we have quite a few, so maybe a tester can attend those first before going to fly around Europe to visit EuroStar?

The criteria for attending conferences I use are almost the same I use for courses. Roughly these criteria are: do we have budget, does the testers need the course and is this the best way to gain the knowlegde? So if a tester can tell me why he wants to go and what he is going to learn at the conference he is halfway in getting a green light. The exact justification differs per person, so it is hard to describe them here. But it needs to fit in the testers development plan, the departments strategy and again in the budget. But the justification isn’t fully “hard”. There are soft criteria which can’t be measured easily. I mean things like: do I think the testers earns this? Do I grant this to the person? There are a lot of other ways to learn and to become a better tester. And if someone, for example, would read books, read or even write blogs or is busy learning by not only working or attending courses payed by his boss, he makes a good chance with me to get a green light.

The last question is even harder to answer. But yes, as a manager I expect something in return: a good learning experience! So you can expect that we’ll discuss what you have experienced and learned afterwards. I expect that you ask yourself some critical questions like: what did I take home from the conference? What can I use? Where can I improve? Which topic is interessing for further study? For yourself but also for your colleagues and for the organisation you work for. There is always some benefit and what is it? Sure it is hard to really use something from a conference in your daily work. By discussing it with the people who didn’t go, this will become much easier! And if you saw presentations you didn’t like or you maybe even thought they were complete nonsence, explain yourself why and discuss this with your peers. Maybe even find the presentor after the talk and tell him why you didn’t like his talk. The same counts for courses you attend. If you only go there and do nothing with it, the learning benefit is relatively low. So work with it!

Other benefits you can have from conferences are the ones Jean-Paul mentioned: a boosted testing mindset, good discussions with peers and networking. And I think testers should be aware of these “side effects” and be ready to explain them to your manager. This might help you convince him (or me) to let you go.

RST – Part 2

I updated the first part of my write-up about RST a little. You can find that post here.

Heuristic test strategy model

An important part of the RST course is the heuristic test strategy model. Teaching us the mnemonics. It is fun learning how these can be remembered easily: the dumber the mnemonic, the more memorable it is…

HICCUPPS (Oracles)
Nothing to explain here I think
SFDPOT (Product Elements)
Still not very funny, just meaning San Francisco Depot.
CIDTESTD (Project Environment)
Kid Tested and mother approved! From a cereals commercial we don’t know in the Netherlands
CRUSSPIC STMPL (Quality Criteria)
The Eastern European hockey player, rocket scientist, ballet dancer, poet and politician.
FDSFSCURA (Test Techniques)
The cry of roman soldiers storming into battle: “My sandals hurt!”

If you want to know what the letters mean, just watch this video I shot during class.

Test Strategy and test plans

After the impressive part on the heuristic test strategy model, test strategy and test plans were discussed some more. With a nice defintions of a (test) plan:
Plan (set of ideas that guide your test proces) = Strategy (set of ideas that guide your test design) + Logistics (set of ideas that guide your resources to fulfill the strategy)

“Usability is often a testability problem.”

Of course I have thought of testabilty before. I also can remember several occasions where I have asked developers to help me with scripts or tooling to do my work more efficient and more rapid. On the other hand are testers asking for testabilty enough? Testers can make their work far more efficient by collaborating with developers. Ask yourself the question: “how often do I discuss testing with developers?” In agile development this is becoming common practise more and more, but shouldn’t all testing be facilitated by good tooling? It will help testing become more Rapid. Let the computer do the counting (in logging)!

The faster we can test, the more chance we have to find bugs. Bad testibilty gives bugs a chance to hide and therefore it is a serious issue. RST gave me insight in the importance of testability and while studying the appendices of the course material, I found some nice heuristics (Heuristics of Software Testability by James Bach, Satisfice, Inc.) testers can use to gain insight in testabilty: Controlability, Observability, Avalability, Simplicity, Stability and Information. While reading I realized that this is an obvious list, but I can’t remember a single project I did or have seen where testers were aware of all these factors that influence their work.

Safety language

Another eye opener was safety language! Testers tend to be very precise. Results are compared in detail, using 5 decimals if possible. And after a couple of tests we say: it works! Since I attended Michael’s TestFraming tutorial at TestNet in July, I already knew the importance of telling the good stories:
1. The product story, about how the product works, what fails and what might fail.
2. The testing story, about how we have tested the product, what we want to test and what we won’t test at all.
3. The story about how good testing was, the testability of the product and the risks and costs.

This subject also came up during the intervision session we had last week at work, where 6 colleagues who went to EuroStar last year shared their experiences and take aways. One of the topics discussed were “elevator pitches”, the importance of presenting and effective communication.

Accuracy verus precision

“Sometimes we testers spent to much time to find precise answers as accurate answers would do.” The difference between accuracy and precision is nicely demonstrated on wikipedia. I like the target analogy very much. Another thing I took away as an open door, but very true and not applied too often: in testing we should let the risk define the level of accuracy and precision needed.

A quote to finalize this post: “Testing is about questioning and learning under conditions of fundamental uncertainty“.

The quality? Oh, we test it in! (part 2)

Who is actually responsible for the quality? To answer that question, I ask myself two questions: what is quality? And what is responsible?

Quality is a difficult concept. In training on software testing I often ask the question: “is the coffee any good?” I get the most diverse answers. Some answer: “for coffee from a machine, it is doable”. If someone says, “horrible!” my response would be: “Why do you drink the coffee anyway?”. A nice discussion about the concept of quality. Quality is value to someone (who matters), at a given time. So the coffee, even if it is not really good, can still have value: for example, to wake up/stay awake! So the coffee has some quality for someone who wants to stay awake.

The other topic is responsibility. Who is responsible for the software? Anyone who ever worked with a RACI matrix, knows that there are different “types” of responsibility. Responsible and Accountable, which in Dutch both can be transleted in “verantwoordelijk” (responsible). In this context, I look at the question: who is responsible for the quality? The project (or project board) for its production. But what about the rest of the team?

Andreas says: “A nurse in hospital is still partly responsible for welfare of patients? Not just the doctor. An inspection department at Unilever is responsible aren’t they? Not only the people behind the machines?”. The example of the doctor and nurse is a good example. Of course the nurse has responsibilities. To nurse the patient as directed by the doctor who suggests a diagnosis and treatment. Each profession has task and are jointly accountable. Not responsible for the health of the patient! They should do the best possible in their profession. But if a patient decides to leave the hospital during treatment, it is his choice! Similar to: if the customer decides to ship the software. In spite or because of the results of testing.

I totally agree with Jan Jaap saying: “many testers are limited ….” and “testers of all companies: broaden your horizons!”. Testing is definitely not just a plan, case writing, execution, reporting. It can and should be much more. Only the purpose of testing, I would like to formulate it differently. Not “contribute to the project objectives with a focus on quality“. I’d rather go for the definition of Cem Kaner, “Software testing is a technical investigation for the purpose of revealing the quality of a software product on behalf of stakeholders.” or the shorter definition of Jerry Weinberg: “Testing is gathering information with the intention of informing a decision”. The goal is to provide information! And thus helps the tester actually contribute to the project goal.

In early quality measures, I also recognise quality reviews, inspections, etc. But here is much more than just working on documentation. I think of: pair programming, help unit testing (improvement), improve testability by asking for logging, acceptance criteria drawn up by acceptance tests (even before fully written requirements and specifications). And there’s so much more testers can do.

The quality? Oh, we test it in!

Friday I saw a tweet by Andreas Prins. Since they are in Dutch, I will translate them here.

His tweet: Question: is this statement correct? # The quality? We will #test that in!

My reaction: Can I have a bucket? RT @ andreasprins: Question: is this statement correct? # The quality? We will #test that in!

After replying, I saw that Jan Jaap Cannegieter also replied with this tweet: @andreasprins statement: “quality, we will test it in” is true, it’s just awfully expensive and time consuming.

I couldn’t believe my eyes. So I replied: @jjcannegieter @AndreasPrins No, never true …. You can’t test quality in, you /build/ it in!

After a while Andreas replied: @huibschoots @jeroenro Thanks clear responses, I share your opinion, you’re really together responsible, but how do you do that?

I replied: By working together! Testers help developers to improve quality. Too long for a tweet. Want a blog?

Andreas asked his questions because he was preparing a column for TestNieuws, a Dutch website on testing. In his post he sums up the reactions and he concludes:

Having thought about this, we can conclude the following:
– The quality of testing afterwards is not possible because the product is there already
– Early involvement can prevent deterioration
– We need a new way of thinking where we not only feel responsible for providing insight into the quality but we also feel responsible for the quality itself. The moment we as testers also feel responsible for the quality, and we are a team, so testers are actually responsible for the quality, then we will also be asked to work to together to achieve this quality.

No, no and no again! Testers can test as much they want, the /tester/ will not improve the quality. The developer does, to the software, at least. Perhaps a semantic discussion as Jan Jaap calls it, but still very interesting! Because the statement is fundamentally wrong! And with these statements perceptions and fallacies are born. The perception of the organization is often that testers will test the quality in. Or even worse: the regression test will find the major bugs, so why test early?

Making testers responsible for quality is also fundamentally wrong. Even as part of a team, testers are still not responsible for quality. Testers are there to help others, with their service of testing. Which is a sapient activity, questioning the product. Helping the team (or our client) to make informed decisions about software by critical thinking (see: RST by James Bach and Michael Bolton).
To be continued!

First DEWT peer conference

Pre-conference drinks

After a long and instructive week of RST, I picked up Michael at his hotel on Friday evening and we drove to Driebergen for the first DEWT peer conference (#DEWT1). We checked in and went to our rooms for a small powernap waiting for the others to arrive. Since the conference would only start the next day, we had the inevidiable drinks and fun. You can imagine that putting 7 testgeeks in the same room will end up in enjoyable stories about our craft. The bar closed at 23:00, but we found the night porter happy to bring us more drinks. Somewhere around 2 a.m. we went to bed after a very entertaining evening/night.

Opening by morning chair Ruud Cox

On Saturday Michel and Jeanne joined us after breakfast and our DEWT conference could finally start. Ruud being the chairman in the morning kicked off thanking everybody for being there.

Artful Testing
Zeger did his “Artful Testing” talk. A very well done talk using a amazingly beautiful prezi. Although he had 15 minutes according to the program he managed to keep us facinated for triple the amount of time. He must have paid Ruud to get his extra time 🙂 Or was it because his talk kept us all from looking at the clock?

Zeger Artfully in action

Zeger’s talk was about (without giving away too much) the connection between testing and art. The ingredients were:

  • how testers can benefit from arts
  • some good comparisons between art and software, testers and art critics
  • some nice “artful testing” heuristics, too bad they are still without a nice mnemonic, but Zeger might change that over time.
  • a good testing challenge
  • nice photo’s and other pieces of art
  • Ambiguities, mystification and anagrams (nope no Da Vinci Code here)

I don’t know what Zeger loves more: art or testing, but he sure did a good job combining them. This talk is on the program of the Belgium Testing Days and I suggest you go and see this talk! I hope Zeger will also send in his talk for the TestNet fall event as well.

 

Michael Bolton on Transpection

Transpection
Michael Bolton was up next on the topic transpection. We asked Michael to help us explore the intruiging “tool” of transpection. After a short introduction, referring to several post by James Bach and himself we started an exercise. We did the exercise in pair, where we were to collect information on the subject. Michel and I searched some articles and then tried a little transpection of our own. In the round up we collected all information in a nice mindmap.

BTW: See Zeger’s blog for more information on how we studied transpection.

Lighting Talks

After lunch Jeanne took over as conference chair and lighting talks were on the program.

Jeroen Rosink

Jeroen Rosink: Testing Pyramid, about testers in the classic career path (test analyst – test coordinator – test manager) getting more senior in their job and there are only a few places at the top of the pyramid.

Me: The power of knowing nothing, about people without knowlegde asking lots of good questions, not being biased. And the usefulness of telling people why instead of how. Inspired by my first days in a new job and this video of Simon Sinek.

Zeger van Hesse: Bader Meinhoff-phenomenon, about the advantage of knowing a lot. Since the phenomenon says that when you have seen it once, you start recognizing it more often. A powerfull thing for testers.

 

Introducing RST in Dutch projects
Ray talked about his experience on how he tried to introduce his take aways form the RST training in his projects. An interesting discussion followed Ray’s short talk and we made a mindmap on how to make the case for Rapid Testing. At the end a discussion from the RST class in the week before the conference about giving release advices popped up again.

Credibility

The last talk was done by Ruud on Credibility. Ruud referred to a presentation on this subject by Randy Rice which inspired him. Credibility is build on trust and is one the most valuable assests a tester has. If you lose your credibility you will have a though time doing your job. Ruud showed a cool heuristic he uses to keep reminding himself on the key factors of credibility. He also made a nice design he can put on his monitor so he is reminded whole day.

 

STYLE by Ruud Cox

STYLE

  • Safety language
  • Two ears one mouth
  • Yes but
  • Lighten up a little
  • Empathy

After this topic the conference was officially over and we had some drinks (with nice testing games), dinner together (with some yes/no question mysteries and lifting my parrot jokes to perfection) and we left for home. This conference was excellent!! Why? It was great fun, I learned a lot, got to explore some really interesting topics with cool colleagues and went home with a lot of new ideas. Thanks guys!

Ray Oei, our technician, at work

This conference was attended by: Jeroen Rosink, Ray Oei, Jeanne Hofmans, Michel Kraaij, Huib Schoots, Jean-Paul Varwijk, Ruud Cox, Zeger Van Hese, Michael Bolton. Peter “Simon” Schrijver and Anna Danchenko could not attend.
Ray filmed the whole day, I’m curious about the movies he made….

RST – Rapid Software Testing

Via Twitter I read the post by Brian Osman blogging his experience with the RST by James Bach, which triggered me to finish the first post on RST today.

8, 9 and 10 June I attended the Rapid Sofwtare Testing training in Utrecht. Michael Bolton was invited by my employer to train almost 50 testers and test managers in one week. This great course got me thinking and my mind is overflowing with ideas! This post is to capture some interesting topics from the course from the notes I took.

Inspiration!

It was cool to see how Michael really knows how to inspire his audience. The first day gave me a nice view on testing vs. checking. This wasn’t new for me since I have seen Michael speak on several occasions. The part about “It works really means: it works, to some degree, on my machine, it appears to fulfill some requirement in some point of time.” made me think about the meaning of testing and how others look at it. Also the view that testability is important and the great use of heuristics inspired me to start using this in my daily work.

Asking questions

Michael is brilliant in asking questions and demonstrating “good” and “bad” behaviour by testers and stakeholders. The value of credibility and the use of safety language was discussed. It was interesting to see that the whole classs agreed with Michael without much discussion about this. I can imagine that lots of testers agree, but in our daily work we do not use it very often. We should train ourselves more in using safety language and carefully formulating our testing story. Testers also should be asking more questions! A great sentence I heard Michael use a couple of times could help us: “Hmmm, interesting, let’s talk about that!”.

Great testing questions

During the course we made a list of Great Testing Questions on a flip-over. This is the list from our class, but there are a million more questions testers can ask.

  • Who is my client?
  • Can I ask questions?
  • Are there more rules?
  • What is the budget?
  • Are there more like this?
  • Are there more of these?
  • What is the risk?

But more about safety language and questions later.

How RST can work

The best take away from the first day were my thoughts on how RST can work. During one of the exercises we were making mind maps while listing product elements. After this 15 minute exercise it became clear to me how powerful using a mindmap and heuristics can be creating test ideas rapidly. Me and my RST buddy Matthias worked together inspiring each other after every new idea. Imagine what our list could become when we would ask a designer or programmer to review it. Two-way inspiration in a split second! And how many more new ideas could we retrieve from the requirements or the client?

The best quotes from the first day could be (because we were served many): “Testers responsibility is to remain unsure when everybody is sure!” and “Testing is about questioning and learning under conditions of fundamental uncertainty”.

Context-driven tester?

Since I did the Rapid Software Testing course I know: I am (or at least want to become) a context-driven tester! Although I often praticed the Basic Principles of the context-driven school in the past and “Lessons learned in software testing” has been my favorite testing book for years now, the course made it perfectly clear to me that testing should be context-driven. RST: a must do for every tester who takes his/her job seriously.

More to follow later!

A blog about testing? Magnifiant!

This is my blog on software testing. I always say that out of the 1000 ideas I have (and believe me, I produce lots), only 5 have the potention to become any good. The rest are great or even brilliant but totally unrealistic, unfeasible or misunderstood. I want to use this medium to share my ideas and thoughts on software testing with the testing community out there. So feel free to comment. And if you do not agree (at all) with me, just let me know. In that case you might have encountered one of those brilliant ideas I thought I had. Your feedback is highly appreciated and will be used to sharpen my own ideas while exploring yours.

In Dutch, the name of my blog would be “Grandiaal” which is a mixture of the words “Grandioos” (Grandiose or magnificent) and “Geniaal” (genius of brilliant). In English this could be translated to: Magnifiant, a word linking magnificent and brilliant. This name is great because there is also the word Magnifier in it, a tool which is used to investigate and enlarge subjects. To explore and learn from the subject.

Newer posts »