Category: Training (Page 2 of 2)

How to become a software testing expert?

January 4, 2012 / / 3 Comments

This blog post was originally written as an column for www.testnewsonline.com (English) and www.testnieuws.nl (Dutch).

This is the third and last part on the theme “how to become a software testing expert.” Part 1 “You can learn testing!” can be found here and Part 2 “What makes a good tester?” is here.

In part one I said that if you want to be an expert software tester, you must qualify yourself in many skills. That through feedback, actively seeking and making mistakes, helps you find out where you can improve. And that coaching is a great way to learn faster. In part two I stated that passion and attitude are most important. Then the skills, competencies and qualities such as proactivity, communication, social / emotional development, collaboration, fast learning, curiosity, but also the ability to apply test techniques. Knowledge to me is the least important. A good tester has test, technical and domain knowledge (in that order of importance).

Passion and attitude
“Without passion no change and no progress” said Ferry Bezem of Twynstra Gudde in this Dutch Article. “How passion for your job can lead to success” is one of the other many articles I found when I googled “passion in your work”. To become succesfull, you need to find out who you are and where you get energy. To become good, you need to have passion for your profession. This article explains how to “develop” passion. In addition attitude or mentality are important as well. With the right attitude, you will be successful for sure! And don’t forget: you can change your attitude!

Critical thinking
Testing for me is questioning a product in order to evaluate it. A tester does this by learning everything there is to learn about the product and analyze this information. Critical thinking is an essential competency of a tester. But how many testers train it? On a well known Dutch book site I searched for books on critical thinking. What struck me was that there are several books on critical thinking for medical personal to find. And that sounds actually quite logical: medics diagnose patients, testers do the same for their “patients”: the test object!

Waste

We write comprehensive test plans that are never read. We use extensive templates to make sure nothing is forgotten (and we do not have to think too much). We do product risk assessments but subsequently we don’t do anything with the risks identified. We often do not use any test techniques. Why?! I think because many people simply don’t know how. I often ask why test techniques are not used. The most common answer is: because there is not enough time!? But these techniques should make our testing more effective and efficient, don’t they? As a tester you should be dreaming these techniques. You should OWN them!

Adaptive?
Every novice tester in the Netherlands starts with TMap or ISTQB. With that fact in itself is nothing wrong. A three-day class where the basics of software testing are taught is a good start. But too often that’s it. We like to guide our testing with process models: ISTQB and TMAP are full of them. But the reality is often more complex and testers get in trouble when the situation is slightly different as they are used to. The choice of a particular tool, technique or method depends on the context. TMap Next claims to be an adaptive method, but do you remember how much time was spent on this topic in your class? And how adaptive are you yourself? Do you use the same template over and over? Do you simply copy the test plan for the next release using a search and replace?

Learn, practice and training
I learned very much by critical reading. There are many free software test magazines and there are many great books on software testing. The internet is an excellent source of (often free) information. There are many videos available of presentations at meetings and conferences. On my blog I keep a list of great resources for testers. Lynn McKee has a similar list. Or start reading blogs, twitter can inform you about new interesting blogs and other things worth reading.

Try weekend testing or a testing dojo to practice your skills. Join a local software test community or organize your own gathering with a group of testers who want to meet and learn. At several employers I introduced intervision meetings for testers. I also founded DEWT with a group of passionate colleagues: like-minded people who like to challenge and inspire each other. We spend many hours discussing our profession and we certainly do not always agree. We discuss and practice in a safe environment and learn from each other.

Try something different
Have you been a software tester for years and are you planning to spice up your resume with another certificate? Then maybe the BBST training is something for you. Let me warn you in advance: this training will give you no certificate and it requires you to study and do exercises almost daily for a month. If you really want to learn, you need to invest a lot of time. Malcolm Gladwell claims in his book Outliers that the key to success in any field is practicing 10,000 hours. Try a training that changes your view on testing: rapid software testing for example. This training has changed my view of my profession and inspired me tremendously. Visiting conferences can be very inspiring and instructive. Join TestNet or another (online) testing community like The Software Testing Club and get inspired. You have plenty of choice!

Learning from others
I enjoy working with others. As I observe, I ask questions or explain my view on the situation. We still can learn a lot from our colleagues in projects … and vice versa! And I’m not just talking about fellow testers. A programmer can build a tool or script in only a few hours that can save testers days of work. By doing unit tests together, we gain insight in what developers test and how they do it. Try working together: pair programming or pair testing can be a powerful tool. Unfortunately, it has a negative image, because it seems to double the effort. But I think it can be beneficial. The added value is mastering the details of a job easier, fewer mistakes, faster learning, team building, cooperation and fun.

Writing and presenting
Blogging, writing columns or giving presentations forces you to structure your thoughts. In addition, your stories or presentations will trigger reactions by others. By taking this feedback seriously, can you sharpen your thoughts and learn again.

Finally
Ask yourself what you can do better often. Evaluate! Ask for reviews on your products regulary. Also ask for feedback from your colleagues on the process, your skills and your performance proactively. Furthermore, my advice is simple: you need a lot of practice to become an expert. So what are you going to do tomorrow?

————

Huib Schoots sees himself as a context-driven tester. Currently he works as team manager testing at Rabobank International and he is board member of TestNet. He is a member of DEWT (Dutch Workshop on Exploratory Testing), student in the Miagi-Do School of Software Testing and maintains a blog on www.magnifiant.com

What makes a good tester?

December 7, 2011 / / 4 Comments

This blog post was originally written as an column for www.testnewsonline.com (English) and www.testnieuws.nl (Dutch).

What makes a good tester?
This is the second of a series of three columns. The central themes of the columns is “how do I become a software testing expert?” Part 1 can be found here.

The question “what makes a good tester?” keeps us busy. This was demonstrated by the attention this subject received at different conferences. At EuroSTAR Susan Windsor gave a well attended presentation about this topic called “How to Create Good Testers”. During the Agile Testing Days, a group of passionate and renowned agilist and testers got together to discuss various test subjects while enjoying beer and pizza. After an inventory and a “dot-vote” the topic “Great Testers” received the most votes. That gave great input for this column, thanks guys!

In this Dutch article on talent, personal qualities, skills and competencies, Patrick Schriel says: “A skill is the ability to be able to perform an act or solve a problem. Competencies are knowledge and skills, they are not innate, but are caused by intense and deliberate practice “. With skills I think of being able to apply a particular test technique, or being able to work with certain systems, etc. But for a tester key qualities and characteristics are important and these are much harder to train. Think of pro-activity and creativity. In addition, attitude (and / or mindset) is important. What is your feeling about change, what are your beliefs, how open minded are you?

Attitude
What makes a good tester? It depends on the context. Every project is different, every team has its own dynamics and each test has different requirements. Lisa Crispin said during the meeting in Potsdam: “Most important is attitude, we will teach them the skills”. And I totally agree. Passion for the job to me is vital. In the attitude of a tester, I find curiosity also very important. Or as Richard Feynman put it: “The Pleasure of Finding Things Out“. A tester is always looking for information, how does this work? He constantly is asking questions to understand. I remember the following quotes from the rapid software testing training: “A tester’s responsibility to remain unsure when everybody is sure” and “Testing is about questioning and learning under conditions of fundamental uncertainty”. A tester knows that things can be different (Jerry Weinberg). And in Potsdam Michael Bolton added “a good tester is able to see the complexity of things that seem simple and the simplicity of things that appear complex.”

Passion
Passion provides drive for commitment and enjoyment. I think passion and skills enhance each other: the more joy you find in something, the more time you’ll spend, the more exercise and practice you get, the better you become. The better you get, the easier things are, the more you discover, it becomes more fun. The snowball starts rolling!

Competencies
A good tester is proactive and able to work together and knows that software development is a team sport. Something you do with a team and you as a tester are actively looking for opportunities to work together with your team. A good tester knows that he is even more effective when he works with developers for example. A developer can help him test faster and smarter. Obviously communication is important. But what is communication anyway? In Potsdam Michael Bolton shared his list with 27 (!) items that have to do with communication: conversation, presentation, argumentation, rhetoric and visualization are some of them. In addition to all above social and emotional development is important to collaborate effectively.

Knowledge
Of course knowledge is important. But curiosity and the ability to learn quickly, makes that a tester can quickly attain knowledge and therefore makes it less important. A good tester has knowledge of the following (in order of importance) testing, IT and domain. But attitude, skills and qualities for a tester are far more important! It was Lasse Koskela who talked about the “Least qualified implementer” in his keynote at the Agile Testing Days. This is the principle that in an agile team someone with the right skills but the least knowledge picks up the work item in order to get the whole team as much as possible at the same level of knowledge. Interesting! I want to read more about this.

When I recruit testers, the behavior and attitude of the individual is most important: his competencies, motivation and attitude. Knowledge is also important for me, but is more easy to learn quickly … that is, if that tester is eager enough to make his work a success.

Note: in a reaction on the Dutch version of this column Derk-Jan de Grood mentioned that in the examples I cited I was limiting the tester to a error seeker, a developer and a critical questioner. It is certainly not my intention to confine the tester an error finder, developer and critical questioner. So if that is the message which you took away from my story, then I need to be clearer. Testing to me is: “questioning a product in order to evaluate it”. A tester is someone who provides information about the product. He does this by learning everything there is to learn about the product . It is possible that a tester does not find any errors (although we all know that they are in there for sure). While I was writing my reply to Derk-Jan I realized that I forgot a very important skill / attitude in my story: the ability to THINK! A good tester thinks! Systems thinking and critical thinking are skills that every tester should have and train.

The last part of this series looks at where and how you can improve your knowledge and experience.

Huib Schoots sees himself as a context-driven tester. Currently he works as team manager testing at Rabobank International and is board member of TestNet. He is a member of DEWT (Dutch Workshop on Exploratory Testing), student in the Miagi-Do School of Software Testing and maintains a blog on www.magnifiant.com

Part 3: How to become a software testing expert?

You can learn testing!

November 11, 2011 / / 5 Comments

This blog post was originally written as an column for www.testnewsonline.com (English) and www.testnieuws.nl (Dutch).

This is the first in a series of three columns. The central theme of the columns is “how do I become a software testing expert?”.

To become great in your profession, you need to learn a lot. This seems obvious. Jos van Rooyen wrote an article in Dutch entitled “Hoe goed zijn we als tester?” (How good are we as testers?). In this article he writes: “Many people call themselves professional tester without having a solid foundation. Yes, we follow the ISTQB Foundation, etc. and think that we are professional.” I fully agree with this. Lesson 272 in the book Lessons Learned in Software Testing: “If you can get a black belt in only two weeks, avoid fights”. You have to learn and practice a lot to become good at your profession. But that goes for everything: just think of sports or music.

Jos draws the conclusion that testers on average are good. I do not agree with his conclusion (besides from the fact that mathematically any population is average). I think testers can do much better! On my weblog I once wrote: “A lot of them claim that they are great testers. But are they? I think a lot of testers maybe aren’t that great…”

Knowledge and skills
What makes a great tester? The skills that make a great tester, I will discuss in Part 2. Testing is a profession, that is something I don’t need to explain. And it’s obvious that you need a lot of different skills to be a true professional. And skills, the learned capacity to carry out pre-determined results often with the minimum outlay of time, energy, need to be trained. To become an expert in a particular skill you must practice a lot, and improve yourself continuously. To be an expert in a particular field, such as software testing, you need to become proficient in many skills.

To become an expert, knowledge is important. Knowledge you can gain in many ways and you must never stop learning! “Stagnation means decline,” they say and especially in IT this is true for me. But applying this knowledge is often difficult. Experience is of great importance. James Bach said in his presentation Becoming a Software Testing Expert “Do not confuse experience with expertise.” You can have years of experience, but how do you know that you have gained the right experience? How do you know if you do it “right”? Because let’s face it: there is a lot to be improved in our projects. We have to do much better, but how do we achieve that? And how do we know what we can improve?

Learning
Looking at the different stages of competence in a learning process: you start unconsciously incompetent. So you need to find out where you can improve. Through feedback from others, but also by looking for new knowledge and experience, you find out what else you can learn. In Part 3, I will discuss where and how you can gain knowledge and experience. But we also learn by making mistakes. Preferably in a safe environment. We learn from feedback and evaluations. In the agile world, retrospectives are common and often used. In a retrospective the team identifies what went well and what can be improved.

Coaching
For juniors coaching is essential. But not only for newcomers, for anyone who wants to learn, who wants to develop, a coach has added value. Antony Marcano wrote a nice article in which he says: “One thing that I notice is that while the teams are being coached, they do amazing things. They are more happy, more productive, fast to improve as if there are no limits to what they can achieve”. In many organizations, I notice that coaching is not often used. Here Marcano says: “So, if you have a professional software team without a coach, consider, are you really helping your business save money by going it alone? Or, like the professional sports team, is having a professional development team without a coach another example of a false economy.”

I want to conclude with a tweet from Michael Bolton: “Great sports teams treat practice with the same seriousness as a game — and every game as practice and learning. Testers take note. “

Huib Schoots sees himself as a context-driven tester. Currently he works as team manager testing at Rabobank International and is board member of TestNet. He is a member of DEWT (Dutch Workshop on Exploratory Testing), student in the Miagi-Do School of Software Testing and maintains a blog on www.magnifiant.com

Second part: What makes a good tester?

A new cash CAT?

September 23, 2011 / / 7 Comments

Two weeks ago I had a discussion with an account manager of a testing consulting company about CAT: Certified Agile Tester. His company sells this training and he told me he sees a certification training as a driving license: once you obtain it, you still need to learn how to drive like an expert. I do not believe that ISTQB or TMap certification makes anybody a better tester. And this agile tester certification is even worse… How can you give somebody a certificate for a mindset?

I do not think you’re a good tester if you have an (advanced) certificate in ISTQB or whatever. It tells me nothing about your motivation. Especially not when the certificate could (or even worse, should) be obtained during working time paid by your employer… I think that certification is not necessarily bad, but it is certainly no blessing to our profession. James Bach wrote a great blog post about it in 2005 (!). IMHO certification gives a kind of false security about testing skills. And unfortunately this is maintained by the whole market. The big companies (let’s just for convenience call them “demand side”) have difficulty selecting the right external hires. So they look for certificates which makes selecting easier. The “supply side” is more than happy to participate in the certification hype. Because they earn a lot of money by providing training. But also from a commercial interest because the “demand side” keep asking for these certificates. And if they want to sell their people, they must have certificates. Sadly a mechanism that keeps the certification alive!

Certification says very little about a tester. I know plenty of testers with lots of certificates that I would never hire. Why not? Because they are no good in testing! And the certificates do not make them any better.

The CAT website explains: to become a Certified Agile Tester you have to succeed in three different ways:

  • A soft skills assessment on capacity for teamwork
  • An exam, which requires free answering – no multiple choice questions
  • A practical section where the examinee’s testing skills are put to the test.

This soft skill assessment makes me wonder. As a manager I find it difficult to assess my testers after some months or even a whole year, but the trainers of this course can in only 5 days?

The exam doesn’t prove the examinee is a good agile tester! How many exams have we taken during our lives? And do we still know everything we have learned? Like I said in my last blog post, you become a better tester by continous learning, not by taking exams!

The practical section sounds good. Although I cannot imagine that you can fail your certification on this part.  

The course itself looks okay: the subjects trained are interesting and on the reading list are books I have read and would recommend to others. But the whole idea of certification is bad! Agile is a mindset and how can a mindset be certified?

The testing/training industry has found another cashcowCAT!

Preparing a talk: so you think you can test?

August 27, 2011 / / 17 Comments

I am asked to do a talk at a test consultancy company. To prepare for this talk I want to share my thoughts with you. Hope you can challenge me to rethink or sharpen them.

As a test consultant I have worked for numerous companies and have met or worked with hundreds of testers. A lot of them claim that they are great testers. But are they? I think a lot of testers maybe aren’t that great…

Being a great tester takes a lot of practice. I like this “Becoming a Software Testing Expert” talk by James Bach a lot. The video by the way can be found here. And I see a lot of testers do not study their craft or read books about it. They do not learn or experiment at all. As a matter of fact they claim that they improved by doing their job: after years of doing my job I have a lot of experience! But as James says in his slides: “Don’t confuse experience with expertise”

In this post I like to address three topics what I have experienced that could be helpful become a better tester:
1) Adapt to the context
2) Collaborate
3) Learn & practice!

Everthing is context, context is everything!
Testers in the Netherlands are often trained with the V-Model and methodologies like TMap, TestFrame or ISTQB. Although I do not agree with everything they claim, there is “nothing” wrong with these test methodologies. Not if you don’t take them literally and see them as a practice. We need to become more “agile” in using these methodologies. Since the value of any practice depends on its context. Testers should to be able to adapt to changing situations. Doing so they are able to provide the most value to their stakeholders. Testers should focus on their skills instead of focus on procedures and processes.

Collaborate
Being passionate is contagious! By being passionate you will get your team test infected. Showing your testing skills can help the others in your team. My experience is that even developers will participate in testing if you can show them your skills. They love to build handy test tools and automated scripts which can help the team being more effective in testing! Start using your testing skills and teach others to do better testing. Testers should teach their team members how to test better! I like the way Gojko Adzic descibes it in his presentation “Sleeping with the enemy“: our role in teams will change: from testing everything ourselves, we will also be advisers in our projects. Ensuring that the team does the testing right. Our value is getting the testing right. Of course we’ll still be testing ourselves, the critical, complex testing will always be our job. In exploratory testing or paired testing we can demonstrate our testing skills. Good software testing is a challenging intellectual process.

Times are changing and so is the way we do projects. Collaboration is the key in becoming more effective and efficient in testing. Software development is a team sport: people, working together, are the most important part of any project’s context. So why do we introduce lots of test levels and quality gates? Separate the different disciplines in our projects? Create bulky test plans individually which no one will read?

Learn & Practice
Have you ever seen TV series like Benelux’ next top model or X-factor? People battle to become the best model or singer and win the show. Of course testing is not about beating your colleagues in a match. But this might be the only difference… In the TV shows the models and singers need to show their quality in different areas, every week they are trained in boot camps or by very experienced gurus. These coaches come from different disciplines. To be the best you need to learn all aspects of your job. How do we testers learn?

We need to practice continuous learning. Become skilled in various ways of testing. Practical tips to become a top tester:

  • Take testing classes: Rapid Software Testing or BBST are good examples.
  • Learn and gather ideas from reading books, online magazines and blogs
  • Learn by visiting conferences, participate in online conferences or watch the video’s that have been put online
  • Practice in Testing Dojo’s, weekend testing, software testing clubs, or organize it yourself in your organisation or team.
  • Meet with enthusiastic colleagues and discuss your experiences: peer mentoring, intervison, peer conferences, SIG’s, workgroups, etc.
  • Collaborate, learn from other disciplines: writing/reviewing requirements, coding scripts, using tools, etc.
  • Try different (open source) tools
  • Start writing and presenting about your work and thoughts, get feedback and discuss your thought to improve and discover new ideas.
  • Coach and get coached! Even professional tennis players or soccer players have coaches and trainer to get better and stay on the top.
  • Evaluate often! Make sure you get feedback from your colleagues but also keep evaluating your own work: your processes and your products. Always keep asking yourself the question: how can I do better next time??

Markus Gärtner has written a great article about this stuff called Alternative Paths for Self Education in Software Testing in the July issue of Testing Planet.

Update: slides of the talk can be found in the download section or here.

Decisions on conferences

August 1, 2011 / / 1 Comment

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

July 7, 2011 / / 0 Comments

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“.

RST – Rapid Software Testing

June 23, 2011 / / 5 Comments

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!

Newer posts »

My website

http://www.huibschoots.nl

© 2024 Magnifiant: exploring software testing

Theme by Anders Noren — Up ↑