Concern
I have a concern. We online testers have one thing in common: we care enough about our craft to take the time and read these blogs. That’s all very fine. However most testers, and this is based on my perception not research, most testers do not read blogs, or articles, or books or go to conferences, to workshops or follow a course. Well some of those testers do, but only when they think their (future) employer wants them to. And when they do they go out for a certificate that proofs they did so.
Becoming a tester
Regardless of where we start our carreer, be it in software engineering, on the business side or somewhere else, most testers start out with some kind of introductory test training. In the Netherlands, where I live, most of the time that means you’re getting a TMap, or sometimes an ISTQB training. And my presumption is that you get a similar message on what testing is everywhere:
- Establishing or updating a test plan
- Writing test cases (design; procedures; scripts; situation-action-expected result)
- Define test conditions (functions; features; quality attributes; elements)
- Define exit criteria (generic and specific conditions, agreed with stakeholders, to know when to stop testing)
- Test execution (running a test to produce actual result; test log; defect administration)
But there are likely to be exceptions. For instance at the Florida Institute of Technology where Cem Kaner teaches testing.
Granted neither TMap nor ISTQB limit testing solely to this. For instance TMap starts of by defining testing as: “Activities to determine one or more attributes of a product, process or service” and up to here all goes well, but then they add “according to a specified procedure”. And there is where things start to go wrong. In essence the TMaps of the world hold the key to start you testing software seriously. But instead of handing you down the knowledge and guide you to gather your own experiences they supply you with fixed roadmaps, procedures, process steps and artifacts. All of which are obviously easy to use for reproduction in a certification exam. And even this still could still be, as these methods so often promote, a good starting point to move on and develop your skills. Unfortunately for most newbies all support and coaching stops once they passed the exam. Sometimes even facing discouragement to look beyond what they have learned.
Non-testers
To make matters worse the continuing stance to make testing a serious profession has brought line managers, project managers, other team roles and customers the message that these procedures, processes and artifacts not only matter, but they are what testing is about. These items (supposedly) show the progress, result and quality of testing being undertaken. Line and process managers find it easy to accept these procedures, processes and artifacts as measurement items as they are similar to what they use themselves according to their standards. So if the measurements show that progress is being made and that all artifacts have been delivered they are pleased with the knowledge that testing is completed. Customers or end users go along in this but face limits in their belief of these measurements as they actually experience the end product. Like testers they are more aware that testing is never really ended and about the actual information about the product and not about testing artifacts.
So?!
New methods and approaches such as agile testing have brought the development roles closer together and have created a better understanding for the need and content of testing to both the team and the stakeholders. Other approaches, like context driven testing, focus more on enhancing the intellectually based craftsmanship of testing, emphasizing the need for effective and efficient communication, the influence of context on all of this and that software development is aimed at solving something. And thus the aim of testing is shifting from checking and finding defects to supplying information about the product. Regardless of this however and inspite of how much I adhere to these approaches I think they have a similar flaw as the traditional approaches. Like TMap or ISTQB neither of them go outside of their testing container enough to change the management and customer perception. They still let management measure testing by the same old standards of counting artifacts and looking at the calendar.
Challenge
I think we as a profession should seek ways of changing the value of testing to our stakeholders. To make them understand that testing is not about the process or procedure by which it is executed nor about its artifacts, but about the information and value to achieve business goals it supplies.
I myself cannot give you a pret-a-porter solution so I challenge you, my peers, to discuss with me if you agree on this vision and if you do to form a new approach for this together. I will gladly facilitate such a discussion and deliver its (intermediate) results to a workshop or conference at some point.
Arborosa 
I would want to say that I have a very context driven approach to what I am doing at my company regarding quality work. And since that goes through all the way from management to the projects and developers we need a common value driven platform.
I am also very keen on this not being about counting artifacts using old standards, but to find ways of visualizing and managing the expectations of quality in our products. These need to be shared among customers and development team. I have blogged about my first steps here, with more to come over the next months.
http://happytesting.wordpress.com/2011/12/01/organization-wide-test-strategy-step1-deriving-our-quality-values/
Thank you for the challenge, I think I am on the right path here. And if you see me going down the same drain, please question me about it.
LikeLike
Hello Sigge,
I think we face a similar challenge in converting our company from more traditional viewpoints on defining software development practices and success to more practical and realistic ones. Having read your article I think you are already further at this then I am at my company.
Partly this will be due to a very dissimilar company structure. My company is the international diveision of a large bank and that division itself already counts 15,600 fte in 29 countries. Obviously I would not have to change al of them, as most do not work in IT, but even my head office IT unit alone counts several hundreds of people.
We are currently changing from a derived from TMap oriented approach on testing to a mix of agile and context driven testing. This is progressing slowly but steadily and as things go in a large unit not all departments follow in the same pace or enthusiasm.
Your blog post has given me new footholds to proceed at my own company. Thanks for that. I will try and keep you informed on my progress and will follow yours.
LikeLike
Hi Jean-Paul,
Very nice write up. You raise some very valid points, with perhaps the exception of the in our out testing camp being so clear cut, which you most likely hadn’t intended to communicate in your writings anyway.
Would you not say though that it is about raising awareness to those asking for such traditional approaches? When I am asked for something which I don’t think would be the best use of my time, I usually discuss it in a two stage process:
1. What exactly are they asking for and why? It could be that what they are looking for is not actually what they are initially communicating.
2. If I think my time could be more beneficial for them elsewhere, I can communicate alternative, more effective approaches to them. For example, I never write test scripts, but I can produce a map of risks or concerns which will be more easily understood by stakeholders, generated quicker, with improved results. I can show them how much more beneficial this will be in terms of time, maintenance and coverage easily.
People often ask for traditional artefacts, because they are not aware of alternative solutions. I honestly think if communicated properly, most of the time, an intelligent stakeholder would take the more effective solution, as long as the cost wasn’t significantly higher, which with traditional methods, almost never is.
So for me it’s all about awareness and down to the tester, team, manager or whatever to stand up for what they believe in.
Thanks for sharing,
Darren.
LikeLike
Hi Darren,
I do agree that awareness is one of the most important steps in starting with alternatives. Both in the sense that one needs to have awareness of alternatives and awareness of purpose to be able to value these alternatives.
I think however for changes to occur and alternatives to be used awareness needs to be followed by the desire and the ability to change also. Even though a manager might be aware of the benefits of a change she might not have the desire to go allong with the change unless there also is a clear benefit for her also. This treshold can be overcome with proper argumentative communication if the manager then also has the ability to follow up on the change. In the organization where I work line managers, process managers and project managers are themselves part of a procedural framework. So in addition of finding an alternative for me as a tester/developer I need to help the manager to get the alternative endorsed at their level and up also.
Thanks for your comment.
Jean-Paul
LikeLike
Hi Jean-Paul,
You are very true, the bigger the company the more difficult it is to push for change. Still though, there are ways around this. For example a change might appear major initially higher up in the food chain, but that’s not to say that it can’t be trailed first in a controlled environment, to prove positive outcomes, prior to communicating it with others.
When I worked with a medium size company (Sword Ciboodle) who only had around 150 employees at that time, change still came with resistance. So obviously you had to prove techniques first, prior to asking others to adopt them. For me this was fantastic! A safe environment to learn. Should it not work out, it wouldn’t matter. I would try the next idea I had and move on.
See my post on Proactive Testing (http://www.bettertesting.co.uk/content/?p=253). That was one of the many changes I made happen there.
I certainly agree though, for some companies, it is impossible. You have to be willing to listen to your employees and not adopt a dictatorship regime, that sees anything but your views rejected.
Thanks,
Darren.
LikeLike
An interesting Twitter addition to the blog:
@sbarber @Arborosa Suggested refinement: #testing means raising awareness about value (and threats to it) to someone who matters. By: @michaelbolton
With answer:
@michaelbolton @Arborosa I’m trending toward “product value & business risk”, but I like your refinement & our thinking is congruent. By @sbarber
LikeLike
I think this is a very important topic! I’m utterly agree with your points. In my still young career as a software tester I have the option to work in a company which testing department is in a state of flux. Together with my colleagues we should show our developers, test managers and stakeholders how “modern” testing has to be done. I’m also a fan of the approach of context driven testing, rapid software testing and all these stuff. But I think that it is a long long way, to show them, that the “old” methods of testing don’t fit in our modern and “agile” world!
I want to invite you to follow my new blog about testing: thespiritoftesting.wordpress.com
Kind regards from a passionate tester from Germany
Ralf
LikeLike