Category: General (Page 2 of 2)

15 test bloggers you haven’t heard about, but you should…

July 9, 2012 / / 5 Comments

Everybody knows about James Bach, Michael Bolton, Lisa Crispin, Elisabeth Hendrickson, Gojko Adzic and other famous test bloggers. If not, this is a serious wake up call: WAKE UP! Open your eyes and start reading some of these excellent blogs about testing. But these are many other blogs on testing worthwhile reading. I have a large list of blogs by colleagues which I read regularly. I went through this list and selected these fairly unknown bloggers for you. I invite you to read their blogs, comment on them and come back often. As you can see it is an international community!

1. Australia: David Greenlees – Martial Tester

David is from down under and I “know” him form the Miagi-Do School of software testing. He has a goal in his testing life to get mentioned on the commendations list by James Bach. A great goal and while typing this and reading through the list, I want to get mentioned in that list too!

2. Belgium: Zeger van Hese – Testsidestory

Fellow DEWT, test friend and honorary Dutch. Did I mention that Zeger is program chair for EuroStar 2012? How can a EuroStar program chair be so unknown while is a) as great and fun guy to hang out with and b) a great tester who has done awesome presentations and writes great blog posts? “On being context-driven” and “Finding Porcini” are some of the great posts I like.

3. Canada: Iain McCowatt – Exploring Uncertainty

Iain was one of the trainers when I took BBST foundations last April and I started to read his blog. He did a great series on regression testing and writes well thought blog posts. Can anyone tell me how to pronounce his name?

4. Finland: Pekka Marjamäki – How do I Test

Pekka is an interesting guy. I “met” him via twitter and a while later I found his blog. Interesting stuff! Even Rex Black has commented recently on one of his posts. I still have to talk to him about Testing with the stars. Read about it on his blog. Very interesting concept.

5. Japan: Ben Kelly – Testjutsu

I met Ben in Sweden at Let’s Test in 2012 where he did a great presentation called The Testing Death. Ben is a thoughtful person of no so many words but still fun the hang around with. Give his blog a read. He isn’t very active recently but you still can find some jewels there.

6. Netherlands: Jean-Paul Varwijk – The wondrous world of software testing

He cannot be absent in this list. My fellow DEWT and testing buddy at work. Jean-Paul has an impressive track record the last year: he managed to get a black belt at the Miagi-Do School of software testing while doing his introduction challenge (which is very rare), he impressed James Bach with his answer to a challenge given to him over dinner and he does a couple of national and international talks on big testing conference all over Europe this year. A guy to keep an eye on…

7. Netherlands: Joep Schuurkens – The testing curve

I met Joep at Let’s Test conference in Sweden and found out he is actually Belgium 😉 Joep is context-driven and writes about that on his blog, his posts on The Seven Basic Principles of the context-driven school are great! Joep is also a great guy to hang out with (at least on a conference he is).

8. Romania: Jari Laakso – Software Testimonies

Jari is hyperactive on twitter and loves puzzles! He creates his own very challenging puzzles and blogs about that. Find him on skype and he will have you puzzling for at least a day. This guys like to get challenged, read this post about “18 Testing Challenges from Santhosh Tuppad”.

9. Scotland: Darren McMillan – Better Testing

Darren is been around quite a while and isn’t very active lately. But he is the king of mind mapping in testing. His blog post “Mind Mapping 101” has 53 comments and is awesome, just like “Essential mind mapping: Rapid test design”. If you want to do something with mind mapping come to my tutorial on Agile Testing days OR read Darren’s blog. He by the way also writes about other topics.

10. Sweden: Johan Jonasson – Testing Thoughts

Not a very original name for a blog since Shmuel Gershon uses the same name for his great blog. [Update: Johan changed the name to: “Let’s talk testing”]. Johan is one of the people behind Let’s Test and after reading all the posts on the conference he must have thought he is able to do that too, well have a look yourself. I like his post on “Thinking Visually” very much.

11. Sweden: Rikard Edgren, Henrik Emilsson and Martin Jansson – Thoughts form the Test Eye

These gentlemen were also highly involved in Let’s Test and are blogging for some time now. They get help from Torbjörn Ryber and Henrik Andersson who also write interesting stuff. This blog is stuffed with great posts, hours of interesting reading guaranteed.

BTW: download the two free books written by Rikard and Torbjörn! Both highly recommended!!

12. Sweden: Simon Morley – The Tester’s Headache

Simon has a blog since 2009 and I am reading his stuff since a year or maybe a little more. I met him at Agile Testing Days last year and had some great conversations with him. Simon has a sharp mind and that shows in his writings…

13. Switzerland: Ilari Henrik Aegerter – ilari.com

Ilari lives in Switzerland and does online coaching like James and Anne-Marie and he does a great job. Ilari is fun and writes interesting stuff. Have you answered his question in the post “Major Consensus Narrative, Asking Supposedly Hyper-Smart Questions and Being Context-Driven” already?

14. UK: Duncan Nisbet – Bespoke Testing

I met Duncan at Let’s Test in Sweden last May but before that we did BBST together and we are both in Miago-Do. Duncan is a polar bear: when everybody was cold in Sweden and was wearing jackets and sweaters, Duncan still walked around in shorts and on flip-flops. He wrote a nice post about working together on-line: “Collaboration In Testing”

15. UK: Tony Bruce – Have you ever danced with the tester?

I met Tony last year at Test Bash and over dinner I found out he is a great guy. Cheerful, subtle and fun. Tony is the driving force behind the test gatherings in the UK. Meetups of testers in a bar with short talks and lots of beer! One of his last post is great: “Which do you have? A job or a career?”

 

Adaptability vs Context-Driven

June 29, 2012 / / 35 Comments

Last week Rik Marselis send me an email pointing me to an article with the title “The adaptability of a perceptive tester”.  He added: “Have you read this article? Should appeal to you!”. The article is written by a couple of Dutch (Sogeti) testers. And they, so the introduction tells me, get together once in a while to discuss the profession of testing and quality assurance. This time they discussed some remarkable examples of their experience that perceptive testers (who are aware of the specific situation they’re in) adapt their approach to fit the specific needs.

I replied to Rik with the following email:

Hey Rik,

Nice article, I had already seen it. But adaptive or perceptive is not context-driven. I also totally disagree with the conclusion:
“Together we concluded that although TMap NEXT was introduced some six years ago it still has a solid foundation for any testing project since the essence of adaptiveness makes sure that any perceptive tester can collaborate in doing the right things at the right moment in any project and ensure that the proper quality is delivered to solve the problem of the stakeholders.”

TMap Next contains a number of dogmas (or rather is based on a number of dogmas) like: testing can be scheduled, the number of test cases is predictable, content of a test case is predictable, sequence of process, etc.
Therefore I think TMap Next is not usable in every situation. At least not effectively and efficiently. Being adaptive is good, but I can imagine situations that TMap Next has to be adjusted rigorously that the result is no longer recognizable as TMap. In addition: TMap Next says that ET is a technique: a good example of another dogma. And it shows me that TMap is not about testing but about a process and deliverables … Maybe I should write a blog about this.

Regards,
Huib

Rik replied with this email:

Hi Huib,

We really need to reserve some time to discuss this from different sides because some things that you say I totally disagree with. A conscious tester can handle any situation with TMap. I think whether ET is a technique or approach is really a non-discussion. TMap calls it a technique so you can approach testing in different ways in different situations. And since TMap itself is a method you cannot call ET a method too.

I think Context-driven means you choose your approach depending on the situation.
I think Adaptive means you choose your approach depending on the situation.

Perceptive means conscious, as you are aware of the situation, you can choose an appropriate approach. Well, it is worth discussing.

Regards,
Rik

Okay, so let’s discuss!

Exploratory testing
Let’s start with the ET discussion. What does TMap say about this? ET is a test design technique. And the definition of a test design technique (on page 579 of the book “TMap Next for result driven testing”): “a test design technique is a standard method to derive, from a specific test basis, test cases that realise a specific coverage”. Test cases are described on page 583 of the same book: “a test case must therefore contain all of the ingredients to cause that system behaviour and determine wheter or not is it correct … Therefore the following elements must be recognisable in EVERY test case regardless of the test design technique is used: Initial situaion, actions, predicted result”.

Let’s connect the dots: ET is called a test design technique. A test design technique is defined as: a method used to derive test cases. But ET doesn’t use test cases, not in the way TMap defines them. It can, but most of the time it doesn’t… Mmm, an inconsistency with image, a claim, expectations, the product, statues & standards. I would say: a blinking red zero! Or in other words, there /is/ something wrong here!

What is Exploratory Testing? Paul Carvalho wrote an excellent blog post simply titled “What is Exploratory Testing?” on this topic and I suggest people to read this if they what to understand what ET is. Elisabeth Hendrickson says: “Exploratory Testing is simultaneously learning about the system while designing and executing tests, using feedback from the last test to inform the next.”

Michael Bolton and the context-driven school like to define it as: “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to optimize the quality of his or her work by treating test design, test execution, test interpretation, and test-related learning as mutually supportive activities that continue in parallel throughout the project.”. Michael has a collection of interesting resources about ET and it can be found here.

So Rik, your argument “since TMap itself is a method you cannot call ET a method too” is total bullshit! It sounds to me as “there is only one God…”.

Context-driven testing
Don’t get me wrong, being adaptive and perceptive is great, but that doesn’t make testing context-driven. A square is a rectangle but a rectangle is not a square! Please have a look at the context-driven testing website by Cem Kaner. Also read the text of the key note “Context-Driven Testing” Michael Bolton gave last year at CAST 2011. In his story you will see that adaptive (paragraph 4.3.4) is only a part of being context-driven. I admit, it is not easy to really comprehend context-driven testing.

Do you think it was TMap Next that was the common success factor in the stories shared in the article… I doubt it!

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

The final exit of the test manager?

October 8, 2011 / / 10 Comments

Last week I attended the autumn event by TestNet. This was an awesome event (as always!) where Leon Bosma did a interesting talk on the role of the test manager in the future with the title “Test Manager: the final exit”. His slides can be found here (in dutch).

In his presentation, he focused on the question what makes a manager? He used the model of Quinn as the basis for all tasks/roles of a manager. Then he compares these tasks to the testing activities according to TMap. In this part of his talk he covers the role description, tasks in testing and its importance to the tester. Then he talked about the developments in the testing profession covering developments in approach, the testing craft itself and the systems under test. The latter coincided with the theme of this event “The Cloud”. In the last part of his talk Leon gives his view on the impact of these developments on the role of a test manager. I have summarized them in the table below.

Role From To
Director He determines what I should do I’ll decide what to do in consultation
Producer He makes sure I can do my job The team make sure we can our job
Innovator He comes up with new solutions We come up with new solutions
Broker He makes the stakeholders happy The actors make each other happy
Facilitator He inspires the team We inspire and build the team
Mentor He teaches me the craft I learn from other specialists
Coordinator He decides what to do when I decide in coorperation the team what to do when
Monitor He sees to it that I do the right things The team ensures that I do what is needed

So, is the test manager a dying breed or not? I think they are! With developments like agile it is obvious that the team will be more responsible to do planning, coordination and determine the test strategy. For that we no longer need test managers. I never really understood the role of a test manager in many projects. Why should we divide the role of the tester in test executer, test analyst and test manager? We don’t do this in the other disciplines in IT, do we?

I think it has to do two major reasons:
1. The immaturity of the testers and therefore the (wrong?) interpretation of the role tester
2. The career path in many organizations

Immaturity
A good tester IMHO “deals” with all aspects of his job, maybe in consultation with the project manager. The tester controls the entire process from writing test plans containing an appropriate strategy to the reporting to the Steering Committee. I know many testers who find it scary to facilitate a workshop (for example, product risk mapping) or to give a presentation (e.g. reporting to the steering committee). The unfamiliarity of the testing craft by other IT professionals makes it worse. Testing is a difficult discipline but most people in IT do not recognize that. A project manager is often unable to make a good estimate of the testing activites is his project. Let alone that he is capable of creating a proper test strategy. Acceptance criteria are very difficult to determine and test managers are often asked to take care of this.

Good testing is quite difficult. Traditionally, business analysts and developers have a relatively easy job. The analyst has only a few dependencies: he talks with stakeholders and writes that down. The developer only needs a development environment and he can do his work. Testing is often much harder: always at the end, started too late with fixed deadlines, organizing various test environments, the many procedures your organization has to prepare acceptance environments, different user groups who should be involved in testin, etc. A lot of arranging and organizing to do! Hiring a test manager is an easy thing to do. Especially if there are people you think the testing itself is not as interesting. Or even worse: if you are not so good at your craft… It is easy to grow (read: flee) towards coordination.

The interpretation of the test role
In a situation where dedicated testers are present, test managers are often needless. Some time ago I worked as a test manager at a customer. In that organization a group test managers were the only “testers”. Most of the actual testing was done by the functional application managers and the users. The test managers did the coordination, wrote test plans, made sure that the testing went as smoothly as possible and were supposted to coach the users. In my opinion this organization of testing is terrible. Sure, users are involved, but testing is a profession and that cannot be delegated to untrained users. Writing requirements or programming is also done by professionals! The users in this situation had a short training. Enough to do proper testing, right?

Test carreers
But who did invent the test managers role? And why? I do not know where the test manager role came from, but I have a suspicion. Testing in many places is still a role that “used” as a stepping stone to another role in IT (WRONG!). Because everybody can test and testers do not need a lot of training (WRONG AGAIN!) so he can focus on the next steps in his carreer. The knowledge and experience of the the systems he gains along the way may well be used in the rest of his career…

Of course a tester grows and his role will be different over the years. I see many junior testers who are doing far less than a senior tester. I often wonder why. The junior needs to learn the craft and he can learn it by just doing it! So let the junior tester do everything himself. Maybe under the guidance of a senior tester as coach. Learning is making mistakes and evaluating them with your (senior) colleagues.

There is only one role: Tester! Test coordinators are in my opinion just senior testers (foremen) responsible for a certain part of the project. One tester is happy to coordinate, the other likes the content. Ultimately, a good tester has mastered his craft in every aspect!

Imagine that after ten years you still want to grow as a tester. What do you do? This is very difficult in many organizations. The salary scales of a tester will not let you. Test manager is a common role in which testers grow. This is a curse for our profession: it makes people want to make money and grow quickly by leaving the role of “ordinary” tester and become test manager. Without focusing to become a great tester they are busy becoming managers. Too bad!

So, will the role of test manager disappear soon? I think not! The test manager is still needed in many places to fill the gaps created by bad testers not in control of their own job!

A blog about testing? Magnifiant!

June 16, 2011 / / 0 Comments

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 »

My website

http://www.huibschoots.nl

© 2024 Magnifiant: exploring software testing

Theme by Anders Noren — Up ↑