I realized with all the talk I did a couple of weeks ago about PNSQC, and all of the talks I witnessed and participated in, I didn't talk very much about my own talk and, specifically, the Poster Paper presentations I made. I have to admit, when I took on the challenge of giving a Poster Paper presentation at PNSQC, I was doing it more out of curiosity than anything else.
The topic in question was my presentation of "Balancing Acceptance Test Driven Development, GUI Automation, and Exploratory Testing". I'd presented this paper in a 20 minute format at CAST, with Q&A following. I'd presented this talk in an hour long format, with Q&A following, at Agilistry, so I was really curious to see... could I deliver the same message, and get across the same essential points, with just 5 minutes of engagement, and could I do it multiple times?
The answer was very interesting, and not at all what I expected.
Instead of me delivering the same talk multiple times, each person or group of people would engage me in a different way. Each wanted to have a different discussion about the same material. What was also interesting was that the areas that I thought were the most important would still have some relevance, but an idea that I offered as a "take away" and kind of a small "well, you could do this" became much more pronounced. The little takeaway, I realized, was the real kernel behind what I could do. That little kernel has, I think the potential to be something much bigger, and frankly I'm interested in seeing it become something bigger.
What's that kernel? The idea that we need to take a different look at test automation. So often, we do A to B tests. We set up tests to run a number of scripted scenarios. We run multiple examples of essentially the same scripted tests. In my presentation, I likened this to a train. Sure, with randomization, you could switch the order of the containers and the order of the cars, but they're still behind an engine, and they are still taken, on the rails, from Point A to Point B. If we go along for the ride, the view rarely changes.
As part of my presentation, as an off handed "takeaway", wouldn't it be interesting if instead of treating our tests like a train, we treated them like a taxicab? What if taxicabs were our operational metaphor? Imagine making our tests so that they could take us to the deepest darkest corners of our applications that we test. Once we reach those mysterious back alleys, the cab lets us off... and now the fun begins. What is it like to work on a system where a user has just logged in 10,000 times? Suppose you had a way of filling in every single visible text field on a site, and each confirmation took you to some place you might never have considered?
I thought the idea was interesting. The participants at PNSQC, each time I delivered the conversation, kept pushing me... tell me more about this taxicab! How could we use it? What would we have to do to set such a thing up? How could we develop such a setup? The truth is, I don't have an answer for that, at least, not yet... but I have to say I am itching to see how we could do it!
Had I just presented my talk, that taxicab element might still just be an interesting theoretical tidbit. Now, after so many discussions with so many different people, I realize this is something that could really change the way that test automation is both perceived and performed, and I'd love to be part of that reality. I often said I'd need a good reason to want to dig deeper into programming beyond necessity; it would need to be an authentic problem that fascinated me. I may have just found it!
No comments:
Post a Comment