Now that we've been talking again about what context-driven might mean, I'm starting to realize that as a separate phrase from testing, it might mean less and less. There's one thing in particular, though, that it means to me - context is not an excuse for doing things worse than they could be done for a context-driven tester. But there's a lot of using context-driven as an excuse around that I'd personally like to make a separation from.
Two examples of using context as an excuse would be the following.
Giving in to obey a manager.
Some years back, I joined a new organization as the first ever tester they had had. The recruiting manager had studied testing enough to know that he felt he needs a tester, and that the tester should be managed by having her create and mark passed/failed some test cases. I could have done what the manager asked. That would be using context as an excuse: "the context of this organization is that I have to write detailed test cases that everyone can use to share testing work with the developers this way". But that is a bad excuse, and wouldn't be context-driven.
Instead, I pointed out that the test cases he had forced the developers to do had 53 pages of text and 3 specific pieces of information that were not obvious enough for me to know them on my week 2 at a new company. Wasted effort. I suggested than instead of me, the expert, writing test cases as he hoped, I could write detailed notes for two weeks of what I was thinking while testing so that he would have a better understanding of what I do when I test, because test cases were clearly something he was using because "how do I know you're even working if you don't mark test cases done?". I figured out what parts of documentation would be helpful in dual purpose: as part of the product, e.g. helping our sales team or serve us end user documentation as well as helping me keep track of testing. And for things with details, I would make a pact with developers on putting the stuff down in automation to save them from having to write useless and stupid test case documentation ever again.
Bending a methodology until it kind of fits
There's a lot of useful tools. Like Specification by Example. Surely no one can be agile without using it? If the organization isn't quite ready, let's use half of it. If the examples don't quite fit the format, let's not use any other format, because GIVEN-WHEN-THEN is the formula.
Or like TMap. Or RST. Or Scrum. Or XP. How much do we change these, before they are not the thing anymore? And if they are the thing, perhaps we're being context-imperial, not exercising enough of critical thinking of what actually takes us forward and what would be the best way to organize for inclusion of deep testing.
This is again on the excuses side, but erring on wishful thinking. I'd like to say my favorite acronym is actually a best practice. And I avoid the actual consequence of my inherent desire by repeating a mantra it depends. I can't really tell what it depends on, but I can say that the method that worked for me in my previous job and make me successful (or rich as I'm selling it) must be the thing that will save us here as well.
No best practices means just that. Seek for better. Experiment with something different. Sometimes it takes you backwards, sometimes forward. But no change is like saying we have nothing to learn in software development.
Being unethical
I added this third story based on a triggering twitter discussion. There was one more story I wanted to share. Some years ago, I was working on a project with a large subcontracting firm. We were creating bespoke software for a customer, and I was facing one of the most difficult project managers I've had the pleasure of working with. I was the test manager, and she insisted that if I ever had anything to report on testing, I would only report to her. With a lot of power of persuasion, I learned she always rewrote the reports, leaving my name but changing the message before sending them to our client.
No matter what I did, I couldn't then find a way to change that. I would talk with the client representatives directly, trying to mediate the problem of realistic information not flowing, seeking support in fixing what I felt was a dead end.
I failed, and I walked away. As I walked away, I had a long discussion with the client on how to handle project managers like that when they really wanted realistic information so that we could do on-time corrective actions.
My ethics are not for sale. Contextual factors won't make me lie. My life has better content than being pushed to a place that I strongly feel shouldn't exist in the first place. Walking away is part of it. It's not exactly context-driven to me, but it is something a professional tends to need to stay sane and true to herself.
Two examples of using context as an excuse would be the following.
Giving in to obey a manager.
Some years back, I joined a new organization as the first ever tester they had had. The recruiting manager had studied testing enough to know that he felt he needs a tester, and that the tester should be managed by having her create and mark passed/failed some test cases. I could have done what the manager asked. That would be using context as an excuse: "the context of this organization is that I have to write detailed test cases that everyone can use to share testing work with the developers this way". But that is a bad excuse, and wouldn't be context-driven.
Instead, I pointed out that the test cases he had forced the developers to do had 53 pages of text and 3 specific pieces of information that were not obvious enough for me to know them on my week 2 at a new company. Wasted effort. I suggested than instead of me, the expert, writing test cases as he hoped, I could write detailed notes for two weeks of what I was thinking while testing so that he would have a better understanding of what I do when I test, because test cases were clearly something he was using because "how do I know you're even working if you don't mark test cases done?". I figured out what parts of documentation would be helpful in dual purpose: as part of the product, e.g. helping our sales team or serve us end user documentation as well as helping me keep track of testing. And for things with details, I would make a pact with developers on putting the stuff down in automation to save them from having to write useless and stupid test case documentation ever again.
Bending a methodology until it kind of fits
There's a lot of useful tools. Like Specification by Example. Surely no one can be agile without using it? If the organization isn't quite ready, let's use half of it. If the examples don't quite fit the format, let's not use any other format, because GIVEN-WHEN-THEN is the formula.
Or like TMap. Or RST. Or Scrum. Or XP. How much do we change these, before they are not the thing anymore? And if they are the thing, perhaps we're being context-imperial, not exercising enough of critical thinking of what actually takes us forward and what would be the best way to organize for inclusion of deep testing.
This is again on the excuses side, but erring on wishful thinking. I'd like to say my favorite acronym is actually a best practice. And I avoid the actual consequence of my inherent desire by repeating a mantra it depends. I can't really tell what it depends on, but I can say that the method that worked for me in my previous job and make me successful (or rich as I'm selling it) must be the thing that will save us here as well.
No best practices means just that. Seek for better. Experiment with something different. Sometimes it takes you backwards, sometimes forward. But no change is like saying we have nothing to learn in software development.
Being unethical
I added this third story based on a triggering twitter discussion. There was one more story I wanted to share. Some years ago, I was working on a project with a large subcontracting firm. We were creating bespoke software for a customer, and I was facing one of the most difficult project managers I've had the pleasure of working with. I was the test manager, and she insisted that if I ever had anything to report on testing, I would only report to her. With a lot of power of persuasion, I learned she always rewrote the reports, leaving my name but changing the message before sending them to our client.
No matter what I did, I couldn't then find a way to change that. I would talk with the client representatives directly, trying to mediate the problem of realistic information not flowing, seeking support in fixing what I felt was a dead end.
I failed, and I walked away. As I walked away, I had a long discussion with the client on how to handle project managers like that when they really wanted realistic information so that we could do on-time corrective actions.
My ethics are not for sale. Contextual factors won't make me lie. My life has better content than being pushed to a place that I strongly feel shouldn't exist in the first place. Walking away is part of it. It's not exactly context-driven to me, but it is something a professional tends to need to stay sane and true to herself.
