Start From The Past

After being in the computing business now for more than half a century, one thing worries me more than almost anything else: our lack of a sense of history. (Jerry Weinberg)

For a while now I’ve had a rule of thumb, heuristic, that I’ve followed when I’ve wanted to learn something new. I don’t actually remember if I learned it from somewhere or came up with it myself. Nevertheless, it’s been useful for me and I would like to share it with you.

Find Out Where It All Started From

If I want to learn something new, I will focus on the past and try to figure out where it all started from. This way I will lower the risk of being affected by Law of Raspberry Jam.

As for now, I think it’s most helpful if I share couple examples.

Case 1: Scrum

I wanted to know more about Scrum couple months ago. Considering the popularity of Scrum, its Wikipedia article is quite thorough. What’s most important, it has History section in it. Let me copy-paste the beginning of that section:

Scrum was first defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach” in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in the “New New Product Development Game”.[1] Takeuchi and Nonaka later argued in “The Knowledge Creating Company”[2] that it is a form of “organizational knowledge creation, […] especially good at bringing about innovation continuously, incrementally and spirally”.

After learning that, I went and read the paper. What’s interesting, paper didn’t mention e.g. sprints, daily stand-ups or backlog. It focused more on identifying characteristics. Characteristics that leading companies showed (in 1986). Later, while learning about origins of Scrum, I ended up watching James Coplien’s talk at Youtube: Patterns: The New Defacto Scrum Standard. I’ve seen it several times since then. Perhaps the thing that strike me the most, was that James said how Scrum had been affected by Toyota Production System (a.k.a. Lean).

Learning about the work of James Coplien also led me to Scrum Pattern Community & their published patterns. Based on all the previous, my current understanding is that Scrum is about identified patterns & in the end: Kaizen. Successful teams have had patterns that has been part of their success. Those have been identified and came part of Scrum. It also reminds me that every team has its own context that they operate on. This needs to be considered when trying to apply a pattern (e.g. daily stand-up) to yours.

Case 2: Agile

I’ve also activated with Agile lately (this year). Sure, I’ve been familiar with Agile Manifesto & its principles. That’s though quite simplistic & therefore it makes you wonder how to interpret it. That’s why I wanted to understand what people behind the Manifesto thought about it, when it was published. I found one good article about it where Martin Fowler & Jim Highsmith explained their thinking behind every point & principles. Good to notice how the article is from year 2001, when the Manifesto was published.

There’s a lot more, if you have time, energy & curiosity. Martin Fowler has an interesting article on his website from July, 2000, where he describes the New Methodology. Then there’s also an updated version of the same article from year 2005. I haven’t yet read those. But that’s where I will go next. These are the people who were behind Agile Manifesto, they are the ones whose thinking I want to listen, when learning about Agile.

I would be naive though, if I would assume that agile software development came to life 13 years ago (2001). There’s one great article that reminds us how people were doing things smartly already in mid-1950s. Here’s one quotation (by Jerry Weinberg) from that article (Iterative and Incremental Development: A Brief History):

We were doing incremental development as early
as 1957, in Los Angeles, under the direction of
Bernie Dimsdale [at IBM’s Service Bureau
Corporation]. He was a colleague of John von
Neumann, so perhaps he learned it there, or
assumed it as totally natural. I do remember Herb
Jacobs (primarily, though we all participated)
developing a large simulation for Motorola, where
the technique used was, as far as I can tell, indis-
tinguishable from XP.​​
​​​​
When much of the same team was reassembled
in Washington, DC in 1958 to develop Project
Mercury, we had our own machine and the new
Share Operating System, whose symbolic modifi-
cation and assembly allowed us to build the system
incrementally, which we did, with great success.
Project Mercury was the seed bed out of which
grew the IBM Federal Systems Division. Thus, that
division started with a history and tradition of
incremental development.
 ​
All of us, as far as I can remember, thought
waterfalling of a huge project was rather stupid,
or at least ignorant of the realities… I think what
the waterfall description did for us was make
us realize that we were doing something else,
something unnamed except for “software devel-
opment.”
 ​
Case 3: Testing
 ​
On December, 2013,  I wrote a blog post about history of software testing and especially how first software testing teams were formed. It’s a good description of how testers were starting to came into software development 50 years ago. Because they concluded that it would help if there were people who were focusing more on testing than others.
It’s good to note though that I’m talking about software testing. Testing, the mental activity of questioning in order to evaluate – that goes far back. I haven’t put that much effort on tracking the history of that yet.
 ​
While exploring the history of software testing I ran into different kinds of papers. One particular (Evaluation of the Functional Testing of Control Programs from 1967) hinted where the demand for excessively structured testing came from.
 ​
Other way to learn about the history is to ask from people who remember far enough. I asked for example from Jerry Weinberg about origin of test cases.
 ​
JerryWeinberg_TestCases
This is a good reminder of the context behind birth of test cases. While it may be beneficial to use them in your context 60 years later, do note that access to machines is not that abominable these days anymore. If that’s the case, other reasons for using them need to be considered. This same thinking should apply to anything that you’re leaning into & haven’t invented by yourself.
​​​
Try It Yourself
 ​
Next time you want to learn about something new (e.g. BDD, Specification by Example, Exploratory Testing, Lean, Unit Tests), start from its history. If there are few people who are behind it, try to find what they have to say about it. Or perhaps you can even ask from them via email, Twitter or some other way. This way you’re increasing your chances of understanding the subject the same way as the people who came up with it.
 ​
Good luck!
 ​
To show that I’m not alone, I’d like to end this to Martin Fowler’s words:
 ​
In order to understand something, I often find it useful to know how it came about.
 ​
Advertisements

Testing Quadrants As A Communication Tool

 

Screenshot at toukokuuta 15 23-13-23

 

Here’s a modification of Agile Testing Quadrants by Lisa Crispin & Janet Gregory (originally by Brian Marick). I’ve used this as a communication tool in our current project. As it might raise few eyebrows, let me explain couple things.

(Also want to mention that I’ve modified the Quadrants a bit from how they are actually on the project – i.e. what we are focusing on & what we are not focusing on)

Context & Background

I explained very briefly my current context on my previous blog post: Striving For Early Feedback

Besides that, I’ve had challenges with explaining what we (our test team of 2) is testing, with respect to all others on the overall system. Then I was listening Paul Gerrard’s talk (Agile Test Strategy) a while ago. There he mentioned Agile Testing Quadrants. Of course I knew them and had seen them several times before. I just couldn’t come up with the idea of them being useful in my current context.

Agile-Testing-Quadrants

I first used Crispin & Gregory Quadrants while describing our approach to one vendor. There was though many things that I didn’t personally see useful (e.g. Automated & Manual or ET being on Q3). Then I had a discussion with Jari Laakso on Twitter. After that discussion I realized – with the help of Jari – that I can modify the Quadrants in any way I want. And that I did.

Things I want to emphasize

With my modified Quadrants I want to emphasize basically 4 things:

  1. Our testing being a division between testing the expected vs. unexpected – Or in other words ‘Focusing on Expectations’ vs. ‘Focusing on Risks’
  2.  We are intentionally not focusing on testing certain things (e.g. unit testing) – but are aware of how that’s being done by certain people
  3. All testing is based on exploration – in other words: Learning. We don’t test for the sake of testing, but to learn more about our product with every test
  4. Testing mentioned on the top is about People and not only about Business. It’s about people whose lives our product touches (Marc McNeill – according to Dan North)

What was challenging

Perhaps the biggest challenge with Quadrants is that it’s quite challenging to fit different forms of testing there. For example in performance testing we might be testing the expected (e.g. explicit documented requirements), but also regardless of those. That would mean that performance related testing goes to many places.

In the end I found that that particular challenge was something I can live with. Considering I can emphasize those other things with the model.

What next?

I don’t know yet if I will continue to modify and improve the model to make it more useful while describing our testing approach. Or if I will use this model later on the following projects or companies. I might. Or I might not. What matters now, is that it makes it a bit easier (from my perspective) to explain what our testing looks like.

The Exploration of The Deep

TheDeep

I haven’t blogged for a while and main reason for that has been Claire Nouvian’s book: “The Deep”. The book contained one specific article by Dr. Cindy Lee Van Dover that led me to studying a lot more about deep-sea exploration. That article was called “The Exploration of The Deep”.

Earth’s Largest Living Realm

I knew basically nothing about deep-sea exploration before I started reading Claire Nouvian’s book. Now when I’ve spent time reading it, I realize that oceanographers are our modern-day explorers.

The difference between today’s adventures and those undertaken by Columbus or Livingstone lies in the equipment: submersibles and remote-controlled robots have replaced caravels and slide rules. (Claire Nouvian)

Especially the ones focusing on the depths of our oceans, are often the first ones to visit those places. Interesting fact is that there has been more people on Moon than on the deepest known place of our oceans. According to Wikipedia, there have been 12 men on the Moon. On the other hand there have been 3 people (Jacques Piccard, Don Walsh, James Cameron) on the Challenger Deep, in Mariana Trench.

At 150 m depth, 99% of sunlight has been absorbed by water. Below 1000 m, it’s total, inky blackness for all.

The deep sea was long considered as a lifeless world. British naturalist Edward Forbes declared in 1858, that life could not exist below 300 fathoms (~550 m). This statement was later discredited by Sir Charles Wyville Thomson, who was, according to Wikipedia, chief scientist on Challenger expedition. Challenger expedition laid the foundation to oceanography. Dr. Cindy Lee Van Dover described Thomson’s expeditions on the book.

Over four years, Thomson and his colleagues scraped the seafloor with trawls and dredges at depths of up to nearly five miles and recovered more than 4000 new species of marine life. The dredged-up animals were often mangled almost beyond recognition, but they were nevertheless precious specimens that revealed hitherto untold tales about the rich diversity of deep-sea fauna.

There were limits to what could be inferred from these samples; they often provided little insight into the way life on the seafloor looked, or into how the animals might interact with one another. To paraphrase explorer and humanist Théodore Monod, attempting to understand life in the deep sea using dredges is like aliens trying to understand life on Earth by blindly dangling a hook from space and retrieving a cockroach, a t-shirt, and an iPod.

Trawls and dredges allow us to measure the biological diversity found in the deep sea — they are still used today for species counts and other statistics — but they are almost useless for understanding animal behavior in natural settings. To achieve this goal, one needs to observe organisms in their environment. (Dr. Cindy Lee Van Dover)

Current estimates about the number of species yet to be discovered from deep sea vary between 10 and 30 million. On the other hand, number of known species populating the planet today, whether terrestrial, aerial, or marine, is estimated at about 1.4 million. This explains why deep sea truly is Earth’s largest living realm.

Crossota sp., a deep red medusa found just off the bottom of the deep sea. Image courtesy of Kevin Raskoff, California State University, Monterey Bay.

Crossota sp., a deep red medusa found just off the bottom of the deep sea. Image courtesy of Kevin Raskoff, California State University, Monterey Bay. Via Flickr, Creative Commons License.

If someone is thinking now what deep sea actually means, according to Wikipedia it is the layer that is on the depth of 1800 m or more.

I mentioned earlier that below 1000 m there is total, inky blackness. This is true and also far from reality. Reason for it being far from reality is bioluminescence. Dr. Edith Widder wrote on the book about bioluminescence.

There are only a few creatures on land that can make light. Fireflies and glowworms are some of the best-known examples, but there are a handful of others such as some earthworms, click beetles, snails, centipedes, and fungi. These, however, are relatively rare and they do not play a significant role in the balance of nature.

By contrast, in the oceans there are so many animals that make light that there are vast regions where as many as 80 to 90% of the animals collected in the nets are bioluminescent. In the ocean bioluminescence is the rule rather than the exception.

Bioluminescence occurs in all the world’s oceans from surface to bottom and from coast to coast. Appreciating how animals use their lights is important to understanding this ecosystem that represents more than 99% of our biosphere. Various light-producing chemicals extracted from different animals have also proved enormously valuable in medical and genetic research. Living lights in the ocean are beautiful, mysterious, useful to humans, and absolutely essential to the animals that possess them. (Dr. Edith Widder)

Photo by NOAA's National Ocean Service via Flickr, Creative Commons License.

Photo by NOAA’s National Ocean Service via Flickr, Creative Commons License.

Majority of deep-sea animals create their own light and that makes bioluminescence the most widely used mode of communication on the planet. Théodore Monod described this (bioluminescent) masterfully on the book.

Two things used to leave Kant awestruck: the star-studded sky above him and the morality within man’s heart. Had our philosopher taken a dive in a bathyscaphe, he no doubt would have added a third ‘wonder to the world’ to his short list: the fairy-like ballet of bioluminescent sparks that dot the abyssal night. (Théodore Monod)

Tools for Exploration

Because of the challenging conditions of deep sea, it took long before first explorers descended into the unvisited depths. In year 1934, deep sea pioneers William Beebe and Otis Barton, reached the depth of 923 m (according to Wikipedia). 26 years later, as mentioned earlier, Jacques Piccard and Don Walsh became the first to explore Challenger Deep, in the Mariana Trench. 0855409They went there with Trieste, bathyscaphe designed by the Swiss professor Auguste Piccard (Jacques’s father). Trieste was a sort of deep-sea elevator that could go up and down, but not horizontally. This limited a lot its ability to explore in the depths. Nevertheless, it was first piece of technology that enabled us to reach the deepest known place on our planet.

The ALVIN submersible begins its descent to the bottom. 2006 May 21.
Photographer: Gavin Eppard, WHOI.
Credit: Expedition to the Deep Slope/NOAA/OER.

Trieste inspired others to invent more sophisticated submersibles. Examples of these are AlvinArchimède and Nautile. Submersibles like Alvin, could move freely on the ocean instead of bathyscaphes, which extended our ability to explore the deep sea. Alvin can dive to 4500 m currently, but there are plans to increase the maximum operating depth to approximately 6500 m.

According to National Oceanic and Atmospheric Administration (NOAA), Alvin can remain submerged for 10 hours under normal conditions, although its life support system will allow the sub and its occupants to remain underwater for 72 hours.

10 or 72 hours may sound like a lot, but when you consider the 2 hours that it takes from Alvin to dive to its maximum depth, and another two hours back. You realize that large portion of its time is spent on going up and down. Also, according to NOAA, Alvin and Atlantis (the ship) costs $30.000 per day, which makes it an expensive option. Because of these and few other reasons, many scientists use ROVs (Remotely Operated Vehicles) and lately AUVs (Autonomous Underwater Vehicles).

ROVs can remain submerged several days because of the cable powering them from the surface. They provide visibility for explorers by transmitting video in real time. You can also take samples with mechanical arms. One of the most famous ROVs is probably Kaikō, built by the Japan Agency for Marine-Earth Science and Technology (JAMSTEC) for exploration of the deep sea. Kaiko was the second vessel that dived into Challenger Deep, since Piccard and Walsh went there on 1960. Unfortunately, Kaiko was lost at sea on 2003.

U.S. Navy photo by Mr. John F. Williams (RELEASED). Via Flickr Creative Commons Search.

U.S. Navy photo by Mr. John F. Williams (RELEASED). Via Flickr Creative Commons Search.

Despite the usefulness of ROVs, there are though disadvantages and perhaps the biggest one is the cable that is required for operating the vehicle. Partly because of this AUVs (Autonomous Underwater Vehicle) have been, and are being, developed. These could give us the freedom that ROVs lack of. There’s still though long way to go until AUVs replace ROVs on exploring the ocean.

Dr. Cindy Lee Van Dover wrote about the usage of technology on the book. This quotation was one of the primary reasons why I became interested of deep-sea exploration.

Since the discovery of hydrothermal vents in 1977, the pace of exploration in the deep sea has steadily increased, fueled by the finding of novel adaptations to extreme environments and by the gain of fundamental insights into how our planet works.

Our increasing ability to access the seafloor with new tools and sensors promotes and enhances exploratory activities. Tethered and untethered robots are now the tools of choice for many of the challenges faced by deep-sea explorers.

Nevertheless, the construction of two new human-occupied submersibles, one Chinese and the other American, underscores the anticipated need for a human presence on the seafloor for the next half century. (Dr. Cindy Lee Van Dover)

Current technology promotes and enhances our exploratory activities. This is the reason why technological advances are crucial for deep-sea exploration. It’s good to though remember that even though our exploratory activities are performed with the help of technology, we as a humans are still the ones that decide what to explore and how to interpret the data gained from our explorations.

I actually sent an email to Cindy Lee Van Dover, where I asked about the “anticipated need for a human presence on the seafloor”. I wanted to know more about the benefits of us being down there on the submersible instead of ROVs and AUVs.  She hasn’t replied yet.

National Oceanic and Atmospheric Administration (NOAA) – Ocean Explorer

When I started searching more information about deep-sea exploration, I quickly found National Oceanic and Atmospheric Administration’s (NOAA) Ocean Explorer website. The website is dedicated for providing information on NOAA’s ocean exploration activities, especially those being undertaken via funding from the NOAA Office of Ocean Exploration and Research.

It’s amazing how much information you can find from specific explorations. There’s mission plan, science objectives, mission log, photos, videos and introductions of people who are participating the explorations. All these create an interesting story about the explorations for people like me. What thrilled me the most though, was Ask an Explorer section. This gave you the chance of sending an email to Melissa Ryan, who would forward it to explorers. I just had to try this and was highly satisfied with it. I received thoughtful answer in few days.

Question fromAleksis, Finland
You seem to gather a lot of information with technical equipment (data, images, video). How about traditional note taking? Is there a need for taking notes with either pen and paper, or perhaps a laptop? If yes, what kind of notes?

Answer from:Brendan Roark, Assistant Professor, Texas A&M University
Yes, we take other types of notes. For example I take notes on my laptop of our position, what the bottom looks like, what organisms are present, technical problems and other important events like the first sighting of a coral during the dive or cruise. We use these notes to write our dive summaries. I also take pen and paper notes on a printed version of our dive map to help me keep track of where we have been.

There is also the IM chat room that logs all of the notes all the scientists make. We use all these notes and data, both the data, images, video and transitional notes to do our daily dive reports and web summaries. We also have pre and post dive meetings via conference phone to discuss and plan past and future dives, so that is also a more traditional form of communication.

I recommend that you explore NOAA Ocean Explorer’s website, if you’re interested any of the things I’ve written so far. For that matter, you might also want to check out their Youtube channel which contains many fascinating videos.

Space: the final frontier… Or is it?

When I was perhaps 12 or 13 years old, I used to investigate the craters of Moon with my telescope. Whole space was that large, mainly unexplored, territory that fascinated my mind. I watched movies of astronauts and read books about our Solar System. Needless to say, Star Trek was natural continuum for all those already mentioned.

Now, 18 or 19 years later, I’m genuinely surprised that we know so little about our oceans. More importantly, many of us don’t know that we know so little about them. There are millions of species to be found from our oceans and many of those can teach us valuable things in research (e.g. medical and genetic).

Lately the focus has been calibrated more toward the deepest places of our oceans. News about race to the bottom of the ocean support this. One can think about the motives of the people involved with missions like this, but it reminds people about the ocean and how little we know about it.

Cindy Lee Van Dover started her career on the year (1982) that I came to this world. Among many other achievements she was a pilot-in-command of 48 dives with submersible Alvin. She was the main reason for me ending up writing this blog post and studying about deep-sea exploration. It is appropriate that I’ll end this post to her words.

Man has observed less than 1% of the seafloor; the challenge lies before us. During the twentieth century, the deep sea became accessible. In this twenty-first century, the deep sea will become known. (Dr. Cindy Lee Van Dover)

Three Days of Kobayashi Maru

Those of you that have not watched Star Trek, are not probably familiar with Kobayashi Maru. Wikipedia defines it like this

It is a Starfleet training exercise designed to test the character of cadets in the command track at Starfleet Academy.

Rescuing the civilian vessel Kobayashi Maru is the notional primary goal in a simulated battle with the Klingons. The disabled ship is located in the Klingon Neutral Zone, and any Starfleet ship entering the zone would be in violation of the Organian Peace Treaty.

The approaching cadet crew must decide whether or not to attempt rescue of the Kobayashi Maru crew – endangering their own ship and lives – or leave the Kobayashi Maru to certain destruction.

Overall you will be put into a situation where you have – seemingly – no-win scenario ahead of you. Test will test how you will handle the situation. As there is no one right solution and you are under pressure, your actions will reveal your weaknesses (and strengths).

My personal Kobayashi Maru (a.k.a. Rapid Software Testing -course)

Last week I spent three days at Rapid Software Testing -course held by James Bach at Helsinki. After the course I realized that the course was like Kobayashi Maru. Lots of different challenging tests that had us go through situations that didn’t have one right solution. We didn’t have to sacrifice our crews, but we had to figure out how we can test our products as well as we can with our given resources.

The tests (or challenges) also revealed a lot about ourselves. At least it did in my case. I was lucky to have some sort of reputation which led to James knowing me in advance. This on the other hand led to me being given more challenges than perhaps anyone else on the course. Someone might see this as a negative side, but I thought (and still do) I was privileged to participate to those. So what did those challenges reveal about myself? At least these things:

  • I can control myself rather well when being questioned and criticized (to certain degree)
  • Even under pressure I can solve problems
  • I’m able to listen other peoples suggestions (by colleagues for example) about solving the problem
  • I need to have deeper knowledge of testing techniques (in a level that is available even under pressure)
  • I have a habit of forgetting details under pressure so I need to make sure I have resources that help me coping with my weaknesses (e.g. screen recording and notes)
  • I need more experience of different testing problems
  • I need to create (or find) heuristics that help me perform under pressure and when dealing unfamiliar subject
  • I especially need to develop my ability to ask questions that help me perform the task given (this is related to previous one)
  • I need to stop making assumptions! (About things that matter)

Assumptions

Photo by Jacob Bøtter. Used under the Creative Commons license.

If there is one thing I want to raise out of the course, that is definitely making assumptions. The problem that I faced again, again and again during my challenges.

I kept thinking about it and especially why I ended up in that assumption trap several times.   First I realized that when we are under pressure, we are not thinking logically always about the situation. I mean stopping for a minute and think what we are being asked of. The challenges that I was given – and face in my job on daily basis – ask me to solve something. Before you can move into solving the tasks, you need to be rather confident about the fact that you have understood the given assignment as the one who gave it understands it.

If someone asks you to “test this door”, you need to be sure that the door you are going to test is the one you were being asked to test to. Secondly you want know what the person who asked you to test the door really wants. What sort of information is he interested of? Does he want that through that door needs to be accessed 24 hours 7 days a week? Or that it is enough secure to keep people from breaking in? If you just jump into testing the door, you will make assumptions on the purpose of your testing and the needs of the person asking for the testing.

In the end assumptions are a tempting and easy way of doing your job. It’s so tempting to just go with your assumption instead of having the trouble of asking the questions that will test your assumption. But as testers it is our responsibility to test our assumptions. Because if we don’t do that, who will? How can we held our heads high and look back with confidence if we haven’t saw trouble of testing our assumptions? Think about it the next time you discover you have been following an assumption that led you into trouble. What question should you have asked and what point?

Impossible is possible

McFadden, Strauss, Eddy & Irwin (public relations firm) for Desilu Productions.

Wikipedia tells about James T. Kirk’s attempts to beat the Kobayashi Maru:

James T. Kirk‘s back-story defines that he took the test three times while at Starfleet Academy. Prior to his third attempt, Kirk surreptitiously reprogrammed the simulator so that it was possible to rescue the freighter.

This fact finally comes out in Star Trek II: The Wrath of Khan, as Kirk, Saavik and others appear marooned, near death. Saavik’s response is, “Then you never faced that situation…faced death.” Kirk replies, “I don’t believe in the no-win scenario.” Despite having cheated, Kirk had been awarded a commendation for “original thinking.”

Kirk doesn’t believe in no-win scenario and therefore he will find a way to solve a problem, no matter what. As a tester I want piece of that mentality. We have to respect the laws and act ethically, but otherwise there is a lot room for creativity and bending the rules. Even as simple as asking the programmer if he can provide us a logging functionality for a product. An act that can help our testing a lot but is not an option for several people. Or they don’t see it as an option (“it’s impossible” / “he will never do that!”).

During the RST-course I had several moments where I did not use all my resources. I was too busy trying to figure out the solution inside my head. When instead I should have considered how I can get the answer without figuring it from scratch myself? Who has the information? Who can help me? Asking for help is not sign of weakness (to a certain degree). Not being able to ask for help IS a sign of weakness.

I also gave too much respect on my thoughts about what I can do and can’t do. Who is stopping you to do whatever you prefer (with respect to laws and ethics) to solve the problem in hand? And if you are being stopped, at least you have tried and learned something.

De-Focus!

Last thing I wanted to mention from the course is de-focusing. I’ve found it to be rather powerful technique for varying your testing. First of all frustration is the emotion that

Creative Commons Attribution

triggers de-focusing. When you are frustrated and don’t see progress in your testing, you rely on de-focusing. Find pattern in your previous tests and then violate that pattern as much as you can. Prefer MFAT (Multiple Factors At a Time) and vary your observations as well. Observe for sections that you previously did not. Imagination is the limit here.

I witnessed several times during the course that de-focusing helped to solve a problem and will use it on my work also. It can be as simple as using random numbers or help of a colleague, but breaking the pattern is the point.

Few words about James Bach

I’d like to end my post by saying few words about James Bach. I had heard a lot of things about James and knew his reputation as an aggressive and difficult person. At least that’s the impression I had. Before the course started I had a hunch though that James can’t be as bad as his reputation is. I mean, who would hire him as a consultant?

And my hunch was correct. I felt that James was probably the best teacher I’ve had. Amazing amount of knowledge and experience of our field and also entertaining, but demanding style of teaching. I talk about teaching, but he actually enabled me to learn. I had my hard times on being pressured by him but accepted it as a way to learn more. And, boy did I learn. Still have those moments of hard questioning by him clear in my mind. Because of those experiences I was able to find immediately after the course few critical bugs in my current project.

I hope I’ll meet James again at Let’s Test 2013 along with all the other great testers. All these people like James show me the journey I still have ahead of me as a tester, but also motivate me to surpass them.

How to rid the world of all bugs

…And Now for Something Completely Different…

How to rid the world of all bugs? It’s easy!

1. Become acknowledged software testing expert

2. Develop a new method for finding bugs

3. Wait until the software testing world really starts to take notice of you

4. Jolly well tell them what to do

5. Make sure they get everything right (processes, standards)

6. There will never be bugs any more!

Bye-Bye,

P.S. Monty Python – How to do it

Discussions on Twitter (I)

Saturday night (Finnish time) I witnessed interesting discussion about testing between Michael Bolton, Iain McCowatt and Pete Walen on Twitter. They were discussing on how people can’t distinguish good and not so good testing. At one point discussion was dying and I jumped in as I felt there was more to juice from it. I took screenshots of the discussion, but be aware that some tweets are missing as I felt that to make the flow of discussion more balanced, I needed to modify it little bit.

Here we go:

At this point it seemed that the discussion was dying and I wanted to see it continue as I found this subject highly interesting.

After this I tried to forward discussion on different direction. I wanted to think more about the big picture and trying to figure out why and who we are really testing for.

After this I went to sleep and continued next day the discussion with Michael Bolton with few tweets. Here are just few of those that I found most interesting. If you are interested all of them, go to my Twitter profile :)

 

Final words

When I was talking about making money (or profit), I was trying to explain that if the company goes to bankruptcy, there is nothing to test. So the focus should be on how we can by any means available shape the product via testing so that it helps (sell, perform, making profit, whatever you call it) our company.

Actually this is more of a statement: “Anything that distracts or blocks us doing the testing in the way we see it done optimally, is not just hurting our testing, but in the end, our company and its ability to survive. ”

P.S. Thanks for Rosie Sherry for the tip of adding tweets to blog post.

P.P.S If you are wondering the ‘(I)’ after the topic, that’s a Roman numeral referring to that this will not be the last post about discussions on Twitter.