I started reading science fiction as a preteen, fascinated by the different worlds, the different people and all the possibilities. That was a long time ago and I am still fascinated by “What If” stories. Eventually, I found a job as a software tester and “What If” became “what would happen if I”.
The curiosity that drives some teachers and some bosses crazy is better accepted in IT. On the development side, the curiosity that drives innovation gives us new languages, new technology, hardware changes that work faster, better ways to store data and on and on. As a tester too, curiosity was suddenly a benefit. Whether in test cases, test scenarios or user stories, the “what would happen if we”, “how else could this be done” and “could you use it for” questions can prevent problems before the application is released to the users whose vision is always different from ours.
I don’t see a lot of innovation in testing these days. Part of that loss comes from separating the roles. I think some of it was lost when we created a role called tester, decided you needed working code before you could test and that applications from vendors should work as they are delivered. This is true in some circumstances, for example when you buy a simple standalone application. If the product is customizable or integrated with other systems, it needs to be tested as customized and in combination with the systems it connects to, as well as with the data your company uses. That testing, and the problems it always identifies, surprises enough people that it seems testing is often skipped and almost always done in a hurry. This is one area where innovation in testing might produce a better experience for the user.
How can we create an environment that enables innovation? What do we need to do differently to come up with more new ideas? What if you had the space and the time it takes to think, to try something new, to collaborate with your teammates? Could you find a better idea, a better way? Not every innovation is completely new. Sometimes we make small steps. Is there a small change you can make to a test framework that will make it run faster? Sometimes we vary how we work. Session based exploratory testing (invented in 2000) uses a time box and a function; thread based exploratory testing follows a thread from beginning to end. Each was a new idea when it was first used by someone who had not heard of it. The first time I heard of thread based testing, I was amazed that it had a name. Some of your innovations will be new to you and familiar to others.
Collaboration is so much easier to do remotely now. Chat tools connect us to the person we sit beside, the one on the other side of the office, the one at home and another across the country. We are learning to respect time zone differences. I hear myself saying I talked to someone and later realizing I used email or computer chat. I chat with a friend half a world away as one of us starts work and the other goes to sleep. And each of us has different ideas, different experiences, different backgrounds that enable innovation. While I value time face to face, I value the ability to work together more. When I first dealt with a distributed team 15 years ago, it was primarily in Dartmouth, Nova Scotia. The test manager also had one tester a few hours away in the Annapolis Valley and one in Saskatchewan. He told me that to him “remote is remote is remote.” A lot of innovations have created an environment that makes it easier to collaborate and we have adapted to that. For most of us, it is no longer scary.
What if we believed we could innovate and were encouraged to do it? Belief in your own ability continues to be recognized as one of the things we need to encourage in children to help them do things well. Adults are harder; some of us are overcoming years of disbelief. Athletes visualize themselves winning. Can a tester or a team or a company visualize a situation differently and then act on the new vision? Can we be open to the changes it would take to do that? I believe we can, if we are prepared to try. In one environment I worked in, we cut testing and defect correction time significantly by inventing what one of the developers called “test influenced development”; the testers give the developers a list of the sort of tests they planned to run before the developers started to code, not the exact test, simply the high level idea. It isn’t a radical idea now, but it was then.
What about the time it takes to innovate? Wouldn’t the innovation itself save you the time it takes to create it? What if we were rewarded for finding a better way instead of for doing less testing or for working longer hours, for thinking, as well as for action? IT has always been expected to innovate. We have the ability or we could not do the rest of our jobs well. Where we also have the time and the encouragement, what can we create?
I have a friend who says lazy people are responsible for all the progress in the world, that hardworking people are willing to keep doing the same work for as long as it takes. In the current IT environment, we are seldom given enough time to continue to test the same way we did 10 years ago. Because of changes in the technology and the usage, the old methods can miss problems we need to find. The new apps are harder to test, not easier. I believe we need to make time to create the innovations that will allow us to deliver the quality of work that we all want to see. I believe we can create them. Will you help?