Preface
British physicist Robert Hooke published Latin anagram in year 1660:
ceiiinosssttuv
No one managed to though figure out what it meant and therefore it took 18 years (1678) until he revealed the solution to it:
Ut tensio, sic vis
Which can be translated as: As the extension, so the force.
Hooke’s law is a law of elasticity and Britannica for example defines it like this:
For relatively small deformations of an object, the displacement or the size of the deformation is directly proportional to the deforming force or load.
At this point some of you might be wondering why I am explaining the law of elasticity here. The reason is, that I think it is a great methaphor for an online course I just attended. The course is BBST Foundations and it is held by the Association for Software Testing. It lasted one month and I’m still waiting for my final grade (pass/fail) for it.
In my opinion, the course was like a spring. The more I put effort on studying and interaction with other students, the more the course gave back to me (and hopefully to others as well). I can also assure that I was far from reaching the elastic limit of the course.
Via Dolorosa
Before I move on to explaining all the things I loved about the course and what I’ve learned, I want to say few words about the journey and especially how hard it was for me.
Few months ago I tried to google information about this course, and especially the amount of time it will take, but I did not find much specific details about it. Sure I found estimations that said it will take 10-40 hours per week, but those were just numbers to me then. I want to bring up how it was for me and not just numbers, but also pure examples from daily live of mine.
(Photo: Creative Commons / Stuartpilbrow)
I knew that the course would be challenging as I have family (fiancee and less than 2 years old son) and a job that requires, at the moment, early wake ups. I did not still estimate well enough the impact that the course would have on my daily life. Because I did not want it to take away time from my son, I did not do the course when he was awake (09AM-09PM). When you add the fact that I had to get up to work every morning 0445AM, you will notice that there was not much room for the course.
I was fortunate to go with a bus to work as I could do the assignments there. Then I also used the weekend mornings (got up 05AM, when others woke up 09AM) and during evenings when son had gone sleeping. But this took quite a lot of the time away from me and my fiancee, which I found troublesome.
In the end I was sleeping on the average 4-6 hours per night and it started to eat me inside. Actually now that I had first Monday since the course ended, I overslept 4,5 hours this morning and I thought if my body just decided to take the sleep debt I had kept building.
You might be also thinking why I participated to the course. But I can assure you, that it was still worth it. I had such a strict constraints in my life that it made the course more challenging to me than it did for other people. I still believe though that I managed to make it an experience that gave me and others a lot. I feel more capable as a tester now than I did before the course.
Evolution
Previous part went through the pain I had to go through in order to evolve. This part goes through about how I have evolved as a tester because of the BBST Foundations -course.
First of all, BBST Foundations requires you to participate into thinking practical and difficult software testing problems. Besides that it also requires you to participating into discussions about these practical problems. I noticed through the course that participating into the discussions was perhaps the most fruitful way of learning.
This photo belongs to: Smithsonian Astrophysical Observatory
Other thing that strike me on the course, was that there were so many problems and assignments that seemed in first glance rather simple, but after a moment they grew out to be anything but simple. I thought though that it was a sign of a important skill, noticing things. Specifically noticing problems that are hiding behind assumptions.
I also learned how effective diversity can be for facing problems. When there are people with different backgrounds and thinking, you will receive several interesting varying approaches besides your own. George Dinwiddie once tweeted that
The roof don’t leak because the holes in each layer don’t line up with each other.
This came after we asked about ways of managing confirmation bias. He referred to having people with different backgrounds. I noticed that with my own eyes while discussing about difficult problems during the course. Solutions to problems vary as much as the people who you ask them from vary with their backgrounds. But more importantly the opinions about what actually is the problem vary to the same degree. This is the power of diversity.
The course also had five fundamental topics that serve long time as pilars for my knowledge about testing. These were: Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard. They cover a vast amount of information and I have not yet finished all the material we were either required or recommended during the course. My plan is to do that in the near future. That will take time though as recommended readings included several books.
Summary
I think I could sum up things that I personally learned from the course. I want to though highlight that these learnings are based on my experiences. They might change when time goes on, as I will go through the material again. My learnings are also probably different from other students and even from the learning goals of the course.
Before I list things I learned, I want to mention that I highly recommend the BBST Foundations -course. It will require you to give a lot, but in exhange you will evolve as a tester relatively to the amount of effort you have invested on it.
What I learned from BBST Foundations -course:
- Diversity is a good thing.
- Challenge assumptions.
- Five fundamental topics (Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard) and vast amount of knowledge under them.
- Interaction and discussion are powerful methods for dealing problems and defining what the problem actually is.
- Facing practical testing problems is mandatory for evolvement as a tester.
- Context defines our testing strategy.
- Express myself in a more effective way and think the content of my writings through outline.
- Testing is never perfect. I am never perfect (nor I should aim at perfection). Outcome is a compromise made under the constraints we have.
Flow of Testing 
Here’s a challenge for you:
What is the point of using two terms, “information objective” and “testing mission”, instead of going with one of them?
Hi Rikard,
You asked: // What is the point of using two terms, “information objective” and “testing mission”, instead of going with one of them? //
Excellent question and I’ll gladly accept the challenge. I will admit immediately that I had to think about this a while and I believe it makes your question a good one. Here are my thoughts about this question.
The way I see this, is that the two terms support for each other. Information objective tells us our higher level aim(s) or goal(s). Mission on the other hand can be a more specific goal, a goal that helps us achieve the information objective.
Our information objective can be for example “Block premature product releases.”. But our mission to achieve this information objective can be “Find bugs that could cause shareholders to reconsider releasing the product.”.
Going with one term would leave our goal too abstract for individual tester in any given moment of time during our project. Mission helps our team aim at right direction with more practical approach. On the other hand using solely mission would most likely damage our larger goals and blur the big picture in the long run.
I hope this opened up my thoughts about this matter. As I mentioned earlier, I had not give too much thought about the difference between information objective and testing mission. Therefore I’m open for opinions or disagreements.
Regards,
Aleksis
Hi Rikard (Hi Aleksis :-)),
Along with @GeirGulbrandsen, we talked over your challenge on twitter. My initial take was that information objectives and testing missions were somewhat close of strategy and operative, this is, testing missions are the operative tasks you need to complete to achieve an information objective, that is your strategy, your goal, what drives you.
I supported my theory on the basis that, apparently, one information objective can contain several testing missions. Using your provided sample “Block premature product releases” I can relate to it several possible testing missions like:
* Ensure the product’s main features are bug-free
* Verify that some performance requirements are achieved
* Review the translations for messages and dialogs are available
* Make some final usability review
* …
But I confess I ended the discussion with a sort of a bad feeling (“mal cuerpo” in Spanish). I think that (one of) the tricky points of this matter is the generalism of the words being used (I am thinking of “objective” and “mission”), that make them easily interpreted but in a subjective way, leading to a narrow idea of the concept (my idea, your idea…).
Regarding your idea of similarity of the terms, now I see that the sample missions I provided can be turned into information objectives, more specific, like… “Verify that some performance requirements are achieved (so that we can set up an initial release, otherwise it should be blocked)”; testing missions that are part of / help achieveing an information objective, so really close from being an objective itself. At this point, it breaks me the idea of testing missions not being an information objective, because drives in the opposite direction (that they are different things), so my final question (to all) is…
Are there information objectives that are not testing missions?
Challenging, and confusing…
Cheers!
Pingback: Five Blogs – 5 September 2012 « 5blogs
Hi Aleksis
I think we are on the same page, and hope I can give some material for further thoughts.
Your example “Block premature product releases” should probably rather be “provide decision support for stakeholders”,
and with a matching mission “Find bugs that could cause shareholders to reconsider releasing the product” they are so close that I think one of them would suffice.
Or rather, for the test team, in practice, the testing mission would be enough.
But for managers, information objectives are more inviting to discussion; they put focus on “what information do we want from testing?”
Also, the two terms are very close for people that believe that testing is all about providing information (e.g. context-driven community.)
Everybody doesn’t look at testing this way, so in those discussions, I would choose “information objective” to make us talk about the same thing.
Finally, testing mission is a bit broader. Example: “reduce the cost of testing” could be a testing mission, but not an information objective.
But, according to me, the major usefulness of two terms is that one of them is better for different audiences.
Cheers,
Rikard
Thanks for the great reply for my thoughts around these terms. I really liked how you highlighted the usefulness via audiences. I sometimes forget that there is not only context-driven world of software testing. I’ll try to process this further and perhaps a blog post might be useful also.
I also started to read your eBook ‘Little Black Book on Test Design’. Really extensive and gives me a lot of ideas in my current project (first one as a software testing consultant).
Regards,
Aleksis
Hi Rikard, Aleksis,
Don’t you think the mission “Find bugs that could cause shareholders to reconsider releasing the product” is very broad?
How does it help us?
I thought the purpose of thinking in terms of objectives and missions was to help us focus, and then it is not very helpful to define either of them as “Do everything”.
In the example of “Block premature product releases” I would think it more useful to see how you can break that up into more focused missions to hopefully cover more grounds to meet the objective.
What about:
Mission 1: Explore new functionality
Mission 2: Evaluate performance
Mission 3: Get real world users feedback on user interface
(this is still fairly vague and just an example)
These missions will probably need different tool and techniques, and provide different types of information while still contributing to the same information objective.
While it is always interesting to find information about things that threaten the value of the product in general, there might be certain information objectives that are more relevant than others at various stages of the project. My understand of the objectives and mission is that they can help you think about what you are doing, why, and to focus on that aspect for now.
Geir
Hi Geir, Aleksis, Mauri
Words are rich, isn’t that wonderful!
To me (I might have read Kaner/Bach material too much), a mission should be big and guiding for the whole effort. Kaner said you should have one at a time, I think people are capable of several.
Your examples, Explore new functionality/Evaluate performance etc. are more like tasks in my vocabulary, and could be transformed to test strategies with some details for a (hypothetical) project:
* We will start by exploring each new functionality, using our skilled testers expertise to quickly find important issues, and areas for further evaluation.
* We will compare technical and perceived performance with the baseline from version 3.2, keeping an eye on other things that might happen.
* The customer focus group will be extended for the upcoming release, and it is important that they give feedback on the new user interface. We will also sample some other types of users and ask them about the look’n’feel, and usability.
I suppose it’s a good thing to have many words to adjust what you say to whom,
The reason I started thinking about the original question is that using both information objective and testing mission is more difficult to teach.
Cheers,
Rikard
Pingback: Comparing BBST Foundations Courses | Flow of Testing