I guess it’s that time again. What time is that, you ask? It’s the time when discussion/debate flares up over Context-Driven.I’m not going to weigh in on the whole discussion of pros/cons, value/distraction, etc. I am a consultant. I am Context-Driven (and not just as a tester, it’s simply the way I have operated since long before I was a tester and long before I became aware someone had coined a term and composed a set of principles around how I already operated). The license plate on my car says “CONTEXT”. It works for me. But my point isn’t to convince you that it’s right for you. My point is to address a comment that I frequently hear that *feels* very sad to me.
“Where I work, I don’t have the freedom or authority to implement all this Context-Driven stuff, so I guess I don’t get to be part of the club.“
I find this sad, because I don’t agree. It is my opinion that “Where I work, I don’t have the freedom or authority…” *is* a “driving context”, making smart decisions about what you are empowered to choose, and appropriately trying to inform/educate those who are “driving your context” that there are other options qualifies as being Context-Driven… at least to me.
What follows is something I drafted for an org that had recently decided that it wanted to adopt the principles of being Context-Driven, but didn’t want to inadvertently offend members whose context was largely dictated by decisions outside of their sphere of influence. Due to a wide variety of unrelated circumstances, what I wrote never got presented to the org & got lost and forgotten on my hard drive. I recently found it and wanted to share it with everyone because I think it’s valuable.
Please note, the document below is entirely the opinion of Scott Barber. It has not been reviewed, approved, sanctioned, dismissed, or debated by the folks who composed and maintain the principles of the Context-Driven School of Software Testing. They may agree, they may not, but that doesn’t change the fact that I believe these things. Also note that I’m 100% certain that this is not perfectly composed, doesn’t cover every possible situation, and if anyone wanted to adopt or “officialize” it, it deserves a healthy copy-edit and peer review.
Ok, with all the “context” and disclaimers out of the way, here is what it means to *me* to be Context-Driven.
All Roles:
- I understand that there are many different kinds of value that can be obtained from testing software.
- I understand that there are many variables that influence what test tool(s), technique(s), method(s), model(s), and/or approach(es) (subsequently “method(s)”) are likely to provide the most value in a given situation.
- I understand that the most valuable method(s) for my current situation may not continue to be the most valuable when any of the many variables related to that situation changes.
- I believe that when a situation changes, it is valuable to take pause and consider whether the method(s) I am currently using are still the best available choice, and adapt appropriately if not.
- I respect the diversity of methods available to software testers and believe there is inherent value in being aware of as many of them as I can.
- I do not discount or belittle a method simply because I have not yet experienced added value from using/applying it.
- I am not afraid to express that I feel that a particular method is unlikely to add value in my current situation, or did not add value in a particular situation in the past.
- I am skeptical of methods that claim to be valuable in all situations, claim to be a “best practice”, or promise to add value regardless of situation.
- I understand that situations change during the course of a project, and from project to project and I strive to adapt to continue providing maximum possible value in the face of changing situations.
- When the parameters I am given & my scope of control prohibit me from adding the value I believe I could/should be adding, I respectfully make my superior(s) aware of that fact and accept his/her guidance/decision.
Testers:
- I strive to understand the value my testing provides to my stakeholders, including:
- my peers
- my managers
- my developers
- my project
- my executives
- my organization/company
- my regulators
- the users/clients
- I strive to maximize the value of my testing to stakeholders within the parameters I am given & my scope of control.
- I strive to learn and understand many methods so that I am better able to adapt in the face of change.
Test Manager/Directory of Testing:
- I strive to understand the value my team’s testing provides to my stakeholders.
- I strive to ensure that every member of my team understands the value their testing provides to our stakeholders.
- I strive to maximize the value of my team’s testing to stakeholders within the parameters I am given & my scope of control.
- I strive to learn and understand many testing methods so that I am better able to help my team adapt in the face of change.
- I strive to train my team in many testing methods so that they are better able to adapt in the face of change.
Executives/Organizations:
- I strive to ensure my test directors/managers understand the value their team’s testing provides to stakeholders.
- I strive to encourage/enable test directors/managers to maximize the value of their team’s testing to stakeholders by thoughtfully and carefully setting their parameters & scope of control.
- I strive to adjust parameters & the scope of my control appropriately when my test directors/managers respectfully inform me that they are prohibiting their team(s) from making their testing more valuable.
- I strive encourage/enable my test directors/managers to train their teams in many testing methods so that they are better able to adapt in the face of change.
Contractors/Consultants/Trainers:
- I strive to learn and understand many methods and the kinds of situations in which they are likely/unlikely to add value to stakeholders so that I am better able to adapt in the face of change, advise my clients, and/or share that knowledge with my students.
- I strive to help my clients/students learn to adapt to provide maximum possible value in the face of changing situations within the parameters they are given and their scope of control.
- I understand that my skills/course material is not a good fit for every possible situation, I strive to advise my clients/students of this fact and help them make informed decisions about whether my services/classes are right for them at this time. And when they are not, I strive to help my clients/students find contractors/consultants/trainers that are better suited to help them meet their current needs.
- I advise my clients/students to be skeptical of methods that claim to be valuable in all situations, claim to be a “best practice”, or promise to add value regardless of situation.
Why {org} is “Context-Driven”
- Acknowledging that situations change during the course of a project, from project to project, from organization to organization, and from industry to industry; and
- Embracing the fact that testers need to be able to adapt to changing situations if they are to provide the most possible value to their stakeholders; and
- Respecting the value of diverse tools, techniques, methods, models, and approaches available for software testing; and
- Understanding that learning and understanding many of the available tools, techniques, methods, models, and approaches can help testers and managers of testers to adapt to add the most possible value to their stakeholders in the face of changing situations; and
- Recognizing that what is “best” for a tester today may not be “best” for that same tester tomorrow, and that what is “best” for one tester today may not be “best” for another tester, even when assigned the same task on the same team on the same day
{org} therefore believes that the most value that it can ethically provide to the broadest community of testers and their managers is to focus on making our services consistent with the 7 principles of the Context-Driven school of Software Testing, which are:
- The value of any practice depends on its context.
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project’s context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn’t solved, the product doesn’t work.
- Good software testing is a challenging intellectual process.
- 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.
About the Author
Scott Barber Scott Barber is viewed by many as the world’s most prominent thought-leader in the area of software system performance testing and as a respected leader in the advancement of the understanding and practice of testing software systems in general. Scott earned his reputation by, among other things, contributing to three books (co-author, Performance Testing Guidance for Web Applications, Microsoft Press; 2007, contributing author Beautiful Testing, O’Reilly Media; 2009, contributing author How to Reduce the Cost of Testing, Taylor & Francis; TBP Summer, 2011), composing over 100 articles and papers, delivering keynote addresses on five continents, serving the testing community for four years as the Executive Director of the Association for Software Testing, and co-founding the Workshop of Performance and Reliability.
Today, Scott is applying and enhancing his thoughts on delivering world-class system performance in complex business and technical environments with a variety of clients and is actively building the foundation for his next project: driving the integration of testing commercial software systems with the core objectives of the businesses funding that testing.
When he’s not “being a geek”, as he says, Scott enjoys spending time with his partner Dawn, and his sons Nicholas and Taylor at home in central Florida and in other interesting places that his accumulated frequent flier miles enable them to explore.