It has been awhile since I’ve written and its mainly because i have moved into the “academic” side of testing – delivering software testing courses for Software Education in New Zealand. As a result i have been busy travelling and delivering!
One of the main things that I’ve noticed during the course delivery is the degree of separation between a junior test analyst and someone with more experience. At the end of the day, it appears to come down to how many more stories or experiences that someone who has been in the *game* longer has to draw on. This lead me to think about a quote from W.Edward Deming:-
“Experience by itself teaches nothing.” This statement emphasizes the need to interpret and apply information against a theory or framework of concepts that is the basis for knowledge about a system. It is considered as a contrast to the old statement, “Experience is the best teacher” (Dr. Deming disagreed with that). To Dr. Deming, knowledge is best taught by a master who explains the overall system through which experience is judged; experience, without understanding the underlying system, is just raw data that can be misinterpreted against a flawed theory of reality. Deming’s view of experience is related to Shewhart’s concept, “Data has no meaning apart from its context” (see Walter A. Shewhart, “Later Work”). – http://en.wikipedia.org/wiki/W._Edwards_Deming
From my perspective, the more “battles” one has been in, the more experiences to draw from (even if one has “only” been in one organisation) and to some extent, the approach of the test analyst (Agile, Automated, Exploratory, Scripted, UAT etc) may not been as relevant as it serves to broaden the range of ones knowledge.
When i first started testing, one of the theories that i held/learnt was that testing breaks software. When i was asked what i do, i would often respond “I test software by breaking it”.
Over time, associating with different projects and talking to many people, i view testing as Archeology – we sift through the dust and dirt using whatever approach is necessary to uncover the bugs – the software is already broken – we look for clues to find where these may hide!
Therefore, as testers, it is up to us to find our theory – whatever or wherever that may be. Seek to learn, broaden your skills and then apply this theory when getting your hands *dirty* . This will help to broaden our experience and maybe, just maybe, our individual value as a tester!
BTW – I’m currently reading an Introduction to General Systems Thinking by Gerald M Weinberg – so I’m beginning to walk the talk!
I have become a fulltime trainer working for Software Education in New Zealand ( www.softed.com ) delivering software testing courses. As i’m now sitting more in the Academic space as opposed to the Practioner space, I have been given the opportunity to meet many different people, with different backgrounds, looking to gather new ideas to use in their testing jobs.
Some people won’t do much, if anything with this new knowledge (it’s human nature after all especially when the work pressure comes on) but some will. It is these testers that will hopefully feel inspired to share their thoughts and ideas with us all.
The internet has made us a very small, very connected global community and each thought expressed or shared (particularly in testing) is a thought worth considering. Maybe you have discovered a new idea with regards to testing or maybe even reaffirming an existing idea (and adding your own wrapper around it).
To those testers that i have met or to those people who may be reading this and haven’t yet considered creating a blog, please rethink. Your thoughts are valuable and your ideas are at least worthy of expression and/or comment.
I would to *hear* them – please let me know if you do!
The following is a response i sent to Kit who commented on my blog on ‘Insufficient Testing’ ….
Thanks for your comment. It’s almost a catch 22 situation. One of the principles of testing (according to ISTQB) is that Exhaustive Testing is impossible – I agree but the question is how much do you test and when do you know enough is enough?
For a complex system my thoughts would center around risk and priorities as your starting point. The approach or method used would ultimately rest on what level of auditability you must provide to the Business (they ultimately make the decision to go or no go.) Personally I would still use Exploratory Testing (if I was ‘allowed’ to) because in my experience I would be more likely to find something of value more often than through scripts.
However, in saying that, if the test team is involved right at the beginning of the project through walkthroughs, reviews or inspections (or any other type of review)than clarification and understanding will no doubt increase amongst the testing team with regards to the system.
After doing a Wikipedia search on Dr. Deming, one of his quotes is quite applicable to software testing… “Acceptable Defects: Rather than waste efforts on zero-defect goals, Dr. Deming stressed the importance of establishing a level of variation, or anomalies, acceptable to the recipient (or customer) in the next phase of a process. Often, some defects are quite acceptable, and efforts to remove all defects would be an excessive waste of time and money.” It is known that major commercial software often ships with known (and unknown) defects – MS Windows, Firefox v2.0 etc – its is reasonable then for the business to decide how much of the ‘risk’ they wish to carry. Testers should provide the necessary information to enable business to make that decision (good or bad).
At one New Zealand bank that I worked in, the test team I became involved with tried hard to exhaustively tested everything in a very complex application. The upshot was that one release took almost 12 months to ‘complete’ testing (there were other factors involved – personnel, political and management)BUT I guarantee that they could not say that that application was bug free. So I guess that leads to the second question – how much is enough?
James Bach says “When I exhausted the concerns of my internal critic (and external critics I asked to review my work), I decided it was good enough” (refer http://www.satisfice.com/articles/how_much.shtml).
NASA’s software safety standard (http://satc.gsfc.nasa.gov/assure/nss8719_13.html) NASA-STD-8719.13A September 15, 1997 – Section 3.4.5 says “The test results shall be analyzed to verify that all safety requirements have been satisfied. The analysis shall also verify that all identified hazards have been eliminated or controlled to an acceptable level of risk. The results of the test safety analysis shall be provided to the ongoing system safety analysis activity.” What then is an acceptable level of risk and acceptable to whom? Risk is then defined in this document as “…As it applies to safety, exposure to the chance of injury or loss. It is a function of the possible frequency of occurrence of the undesired event, of the potential severity of resulting consequences, and of the uncertainties associated with the frequency and severity.” Also in the document under section 1.4 Tailoring it says “….The tailoring effort shall include definition of the acceptable level of risk, which software is to be considered safety-critical, and whether the level of safety risk associated with the software requires formal safety certification.” Therefore at the end of the day , it’s a business decision taken within context of the business. As testers, we can test complexity within the context of the project and report back our findings – it is then up to those charged with making the ‘big’ decisions, to make them – or not!
Jared Quinert – a proponent of ET from Australia said “…a lack of testing – that insufficient testing requires some co-conspirator to cause a project to fail?
Sadly, nothing stops people trying. Googling ‘”insufficient testing” project failure’ goes some way to demonstrating this.”
So i did….try googling “insufficient testing” and see what comes up. There are, according to Google, 493,000 references to insufficient testing. This then begs the question – What is insufficient testing?
I worked recently within a test group that was fixated on exhaustive testing – they literally wanted to test everything and anything (and with good reason i might add – the situation i.e. context – surrounding them was NOT conducive to a co-operative approach. The harder the test group tried the more they got blamed.) It was hard to changed that mindset because they had litteraly been burnt in the past. What this meant was a huge overhead in terms of time. This group is the opposite of insufficient testing because they wanted to do everything.
However, it is a fact of life (this has been well documented in a number of articles, blogs etc) that software testers cannot find everything. Software is complex (ask NASA), software can be daunting and despite testing things do go wrong – just ask the US Air Force
“While attempting its first overseas deployment to the Kadena Air Base in Okinawa, Japan, on 11 February 2007, a group of six Raptors flying from Hickam AFB experienced multiple computer crashes coincident with their crossing of the 180th meridian of longitude (the International Date Line). The computer failures included at least navigation (completely lost) and communication. The fighters were able to return to Hawaii by following their tankers in good weather. The error was fixed within 48 hours and the F-22s continued their journey to Kadena”
Was this fault because of insuffcient testing or was it the result of other factors? In my experience of failed projects, insufficient testing usually isn’t the cause rather a lack of cohesion between PM, vendor, BA’s, developers, testers – each group assumed a territorial stance and placed their ego in the way.
As Gen. Colin Powell (ret) says ” never let your ego get so close to your position that when your position falls, your ego goes with it.”
Often there was some sort of conflict or barrier (whether declared or otherwise) that existed in which the leadership group was unable to break through. Disharmony in a project team will definitely achieve less with more.
So then is insufficient testing clearly a fault of the test team?
Sometimes it is.
If the team was not aligned to the Project goals and was off on their own agenda then yes. However, if there are external influences involved then insufficient testing may be a symptom of a bigger problem.
I recently read an interesting blog entitled ‘How can i become a better Tester’ – http://thoughtsonqa.blogspot.com/2007/12/how-can-i-become-better-tester.html
This was my comment i left…
Enjoyed your article. I agree – its mindset (quality), its information gathering (read, read and more reading….asking questions…be involved)and finding that mentor who you can clicked with. Sometimes, when as a new tester, we can be blinded by the bias of that mentor so i would add – ‘When you are ‘ready’ question yourself, your understanding, your toolbox and then define yourself in the testing space’ – the trick is knowing when you are ready!
When i first started testing i was sure that testing was <b>ALL</b> about test scripts, test documents, writing documents and more documents because that’s how it was. Today, my thoughts and process have changed dramtically compared to when i first started testing but those earlier experiences shaped my thought processes today!
Great blog John!
Which got me thinking – how do our experiences shape our thought processes and ‘steer’ us towards one method or another? For me embracing a more Exploratory approach was a logical evolution in the testing space. It allowed me to be creative yet structured at the sametime – it increased my toolbox – and i gain immense satisfaction from this approach to testing. Why? Because when i was involved in the more traditional form of testing, i got to the point that i wondered what is the point to what i am doing….in other words i began to question myself and re-examined the ‘tools’ i had. That’s when i became open to different methods to testing.
If i wasn’t as receptive or i wasn’t at that questioning stage, i doubt that Exploratory testing would’ve taken off for me as it has!
So sometimes, it comes down to timing as well as being open to new ideas!
I was reading a book from master coach Pat Riley entitled The Winner Within. This book has been around for a number of years (1993) and Coach Riley discuss his philosophies that make up a successful team. Coach Riley knows what he’s talking about – he’s was at the helm of the 1980’s LA Lakers World Championship basketball teams, the New York Knicks and the 2006 Miami Heat championship team.
Most of us belong to some sort of team. And while we may not always get on with others, we are some what reliant on others doing their job, playing their role. Its no different from testing. Whilst we may be perceived as being negative (‘Your job is to break the system’), we still play a vital part. If we then are able to look at the big picture and synergise with the (project) team as a whole then we are able to produce quite effecient results.
You see this all the time in sports where a very talented team just can’t seem to get it together. I once coached a basketball team that, individually, were quite brilliant for their age group. But as a team they just couldn’t take the ‘I’ out of team. A championship team (or for that matter a good team) is a team that is able to synergise well together – their is no ego only healthy respect for each other. BA’s working with Testers and developers in harmony to produce something extraordinary (one government department i worked for worked exactly like that and yet another didn’t because there was a wall between the testers, BA’s and developers – literally and figuratively).
One of the ways to build this teamwork is founded on trust. It drives us, it helps us, it builds confidence in each other and in others. It enhances who we are and yet at the sametime if we trust and are trusted then we are more likely to ‘build up’ then tear down. A divided house cannot stand.
As Benjamin Franklin states on the signing of the Declaration of Independence “We must all hang together, else we shall all hang seperately”
Recently i have posted a couple of replys on the Microsoft Software Test forum – http://msdn2.microsoft.com/en-us/testing/default.aspx – click the link entitled Software Testing Discussion Forum.
There are a couple of posts on Test Strategy and Test Plans and what they are. Quite often the two terms are interchangeable and used indiscriminately. A Test Strategy (according to ISTQB) is the document that describes the methods of testing or the how. Whether this document is pitched at an enterprise level or a project level is open to discussion but essentially the Strategy is projecting ideas over a longer period of time.
The Oxford Dictionary defines Strategy as “… a plan designed to achieve a particular long-term aim” and as such looks at the ‘bigger’ picture.
A Test Plan describes the ‘How’ at a lower level. IEEE 829 (on which there is much debate on the revision currently being voted on) introduces the structure of should be incorporated in the plan. It is comparable to tactics which again according the Oxford Dictionary is “…an action or strategy planned to achieve a specific end.”
Whether you use either or both terms or documents is up to you. As testers we sometimes become involved in paper wars and become document heavy at the expense of efficiency and effectiveness. Whatever process you follow the key for any test document is effective communication.
Bj Rollison – a Test Architect at Microsoft (http://blogs.msdn.com/imtesty/about.aspx) sums up what happens if we stop thinking about how and what we use these documents for…”The only testers who stop thinking critically about tools and the application of tools we can use in the appropriate context are testers who have a limited understanding of the overall responsibility of testing, and know even less about the tools they are tyring to use.”
Great quote – i totally agree. Whether its a Test Strategy or Test Plan, it is a tool whose purpose is to serve us and guide us in our testing activities.
If you are responsible for producing said documents, please be critcial in your thinking and look at the best way to communicate to all those involved in your sphere!
The 2006 NBA season the Phoenix Suns Strategy vs. the LA Lakers was “…Phoenix’s strategy against the Lakers this season has been to contain everyone besides Kobe Bryant, and it’s worked. Bryant had 39 points in the first meeting and 37 in the second, but no other Lakers player scored more than 17 in the two games and the Suns simply outscored Los Angeles, averaging 114 points.” – Yahoo Sports.
There is your Strategy, the plan is how each Sun player played defense against their man.
Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.– Sun Tzu
Welcome to my first blog on software testing – hopefully one of many!
Testing is an exciting intellectually stimulating discipline to be involved in. I have been in the ‘game’ now for over 8 years in Wellington, New Zealand. I have worked in both the private and public sectors and over that time, my knowledge and understanding has been shaped by the experiences i have come across and the ‘teachings’ i have absorbed from other practitioners, organisations and learned colleagues around the world (Cem Kaner, James Bach, Brian Marick, Bret Pettichord among others). The combination of these things have shaped my view and understanding of testing as i know it today.
One of the greatest, if not the greatest martial artist of the 20th Century – Bruce Lee – espoused his philosophies on martial arts through a framework called ‘Jeet Kune Do’ (JKD) or Way of the Intercepting Fist.
One of the theories of JKD is that a fighter should do whatever is necessary to defend himself, regardless of where the techniques used come from. This is like testing – should we subscribe to only ‘one way’ or one technique to test software when there is a multitude of methods that may suffice? Should we follow the ‘classical mess’ (scripted testing) or become ‘formless like water'(Exploratory testing)?
Don’t get me wrong – test scripted pre-arranged testing has its place and it works – i have no qualms about that – I’ve been there, lived that. The only voice of dissent i have is when so called Test Practitioners disregard any other way of doing it. I worked once for a bank in which i prepared a paper on the benefits of exploratory testing – especially used in a complementary way with expected mode of scripted testing. It never gained traction no matter how much i tried – the Test Manager went as far as to say “…it doesn’t work and you’ll never find anything with that.”
I beg to differ.
As you can tell, i am an exponent of the Context Driven school and Exploratory testing. However, i know and recognise the need for scripting and i am comfortable with that. The trick is seeing what you test in context of what you are doing and what you are trying to achieve.
You may be familiar with the following – its applies whether you Exploratory test or not…
THE SEVEN BASIC PRINCIPLES OF THE CONTEXT-DRIVEN SCHOOL
1. The value of any practice depends on its context.
2. There are good practices in context, but there are no best practices.
3. People, working together, are the most important part of any project’s context.
4. Projects unfold over time in ways that are often not predictable.
5. The product is a solution. If the problem isn’t solved, the product doesn’t work.
6. Good software testing is a challenging intellectual process.
7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Have a great week testing!