Testing Idea
This morning in the shower I was thinking about collaborative testing (Yes, this is a normal thing for me). I was thinking about some of the things humans are good at doing together than machines are not. One of those things is prioritizing and eliminating unimportant tests. Those decisions take subjective information.
It is very common in testing to target tests to areas of change either code changes, or feature/product changes (what is new or altered). We use this practice on a daily basis. It is more difficult to use across multiple products and/or silos.
My idea today was what if I could simplify? Could I make a visual respresentation of the areas of change over multiple products? What information would have to go in to make it useful over time? In my context, it would be impossible at this time to compile all of that data on a build by build basis, but what if I could compile it at milestones, or even just for the release in general? Would it be useful if not precise? I think it would be a good guide as long as we knew it was just a general pointer (that way), and not accurate turn by turn directions.
I even started thinking about how it would be possible to automate for updated build to build information, but of course, I reminded myself that automation isn't my talent or interest, so while it may be possible, I'm not the right girl for that job. However, I do love maps. I'm one of those females who can not only read and fold a map, but who can navigate the roads of New Zealand, Italy, or any country we might be travelling. I have a compass on my keyring (shout out to Rick Steves). Each time I travel with other people, I make sure I have the map and say, "I'm the navigator!" Seriously. My family even refers to me as "The navigator" sometimes. When testing with other people, why are we not using more overall maps? What is this idea? Map based testing? Ha!
Have you used such a method before or heard of a team using this? I talked to one person about it who wasn't excited, but I think it is likely I wasn't expressing the idea in any detail and the discussion turned to feasability of information collection across multiple teams (human issues).
I'm thinking of the idea more from a scientific perspective. It's more of a "what if I had ___ thing? Would it help me?" Can I get ________ thing is a different discussion all together.
It is very common in testing to target tests to areas of change either code changes, or feature/product changes (what is new or altered). We use this practice on a daily basis. It is more difficult to use across multiple products and/or silos.
My idea today was what if I could simplify? Could I make a visual respresentation of the areas of change over multiple products? What information would have to go in to make it useful over time? In my context, it would be impossible at this time to compile all of that data on a build by build basis, but what if I could compile it at milestones, or even just for the release in general? Would it be useful if not precise? I think it would be a good guide as long as we knew it was just a general pointer (that way), and not accurate turn by turn directions.
I even started thinking about how it would be possible to automate for updated build to build information, but of course, I reminded myself that automation isn't my talent or interest, so while it may be possible, I'm not the right girl for that job. However, I do love maps. I'm one of those females who can not only read and fold a map, but who can navigate the roads of New Zealand, Italy, or any country we might be travelling. I have a compass on my keyring (shout out to Rick Steves). Each time I travel with other people, I make sure I have the map and say, "I'm the navigator!" Seriously. My family even refers to me as "The navigator" sometimes. When testing with other people, why are we not using more overall maps? What is this idea? Map based testing? Ha!
Have you used such a method before or heard of a team using this? I talked to one person about it who wasn't excited, but I think it is likely I wasn't expressing the idea in any detail and the discussion turned to feasability of information collection across multiple teams (human issues).
I'm thinking of the idea more from a scientific perspective. It's more of a "what if I had ___ thing? Would it help me?" Can I get ________ thing is a different discussion all together.
Maps are about the highest-density information presentation form that our brains can handle; in fact, we've got a whole huge chunk of our brain dedicated to handling it. The trick is to figure out how to apply the factors in such a way that it's most useful.
Reply to this
I love this idea. I've been thinking about a similar (read:exactly the same) idea. I would love to have a map after each build that shows the changes.
Then after a while I could start associate each change with areas that are risky (lots of calls in, lots of calls out, complex logic)
I'm not sure you even have to automate it at first. Just carry an architecture diagram with you. When a change is proposed say "Show me the affected areas" and then shade/color them in. After a while you will be able to link changes to the build change logs if you have them. You might even be able to go down as deep as method calls.
Great Idea. Good to know I'm not the only one with crazy ideas
Reply to this
Hey Adam! I'm so glad that you've been thinking about this too. I've been brainstorming about some baby steps along the way (half measure) that could help me evaluate the cost and usefulness of this idea.
I'm planning to approach this from the human side and work on it from a NOT code perspective. So, as a tester, which functional areas have undergone the most code change in the last milestone, or 30 days. Right now, shooting for by build isn't possible in the time I have. I figure even monthly I could get an idea of how useful it is for improving test efficiency.
I'm very interested in anything you find on the automation/code changes side. I'd be thrilled to collaborate and share note with you if you want to work on this!
Reply to this