One of the most amazing things about working in the technology and software world is that this industry advances so fast that I have no real idea what software/technology I’ll be testing on and writing about in 10 years time.
10 years ago I hadn’t really heard of cloud computing, now I’m testing call centres hosted in the cloud. 10 years ago I was just starting to test on web apps, now it seems everything is available online.
Almost every article I read is about testing web apps, using web testing tools or some form of web based testing service. Combine this with the general mobile phone uptake trends you have a very mobile, very web, very technology heavy future. Add to this the lowering of barriers of entry (cost and availability of technology) and it wont be long before we are facing option paralysis when deciding which configuration to start testing on first.
As more people adopt modern technology, whether willingly or not, it’s clear a wider array of technology and applications will be moving online and mobile providing us with numerous challenges of not only testing the functionality but also the human factors (or ergonomics) side of our apps and the devices they run on.
Self service (by end users) is also becoming a big selling feature and with mobile devices being just as powerful as many desktop devices it’s clear we have a future dominated by mega massive selections of devices to test against, all running on varying degrees of network capability used in a mind melting variety of contexts. Add to that the seemingly natural way in which the future generations have perfected the art of managing multiple devices and we can quickly see how testing may need to evolve to keep up.
So my domain knowledge of the product and industry will need to evolve to keep up with technology and trends, this hasn’t changed much. It’s always been the case.
But also my approaches, test tools and ideas about testing will need to grow, shift and evolve too. But also too my test environments will need to evolve to keep up with the relentless progress of technology and communications. In fact, some test environments may just need ripping apart and rebuilding. And for some, this could be the biggest testing challenge they will face.
So how do you see your test lab or your test “approach” evolving over the next 10 years?
Image courtesy of : http://www.flickr.com/photos/levitateme
Hey, I didn’t know you had a picture of my PC! Funny, I’ve been thinking a bit about this today, but in the form of regression testing and digital media. My new client is a digital media company and they work on a campaign basis. Once its out there, its life is two to three months and then hey presto, it disappears. Because of this, the need for regression testing is minimal, so how will that impact the testing? Certainly, it makes me question the need for automating tests for regression purposes.
Hi Anne-Marie,Interesting point. This is exactly the way testing can/will change. I still think the need for automated regression could still be there. However, the tools used to automate and the methods employed will need to be low cost and rapid. Record and Playback? I’ve used that before for a campaign that was a one-off with a short shelf life.Depends how the project is run. In my experience it was an agile project so the higher level of automation, the higher the level in confidence we had to make changes and the more we could rapidly deploy. It was a hoot.Interesting thoughts though and no doubt there will be countless views on whether regression testing would be required and whether or not it should be automated.Thanks for commenting :)Rob..
Hi Rob,The major change that has already happened but missed by many is that a single program is no longer a single main subject under test. – Because any program is an integral part of a complex infrastructure that includes software, hardware, …, and people – and thus affected by a vast number of factors, including oil prices and weather conditions. It’s not a single black box anymore. It’s more like a black cat inside a black box inside a dark room on N-storey building where rooms and whole floors are moving around.The first step of the approach is to recognize the change happened.Thank you,Albert Gareev
Hi Anne-Marie,”[…] they work on a campaign basis […] Because of this, the need for regression testing is minimal”That’s an interesting conclusion! It pulls the following assumptions:* each project is created completely from nothing. No single line of source code is reused;* each project is built in a single effort. No refactoring, no iterations; no deployments on series of test environments;* each project is delivered with no or cosmetic bugs only OR there is an ultimate confidence that fixing a single feature does not require regression testing of the whole functionality;* each project is designed so that it is perfectly compatible with all versions of all web browsers, so no cross-browser testing is required;* each project is delivered on an infrastructure that perfectly complies with the all performance and scalability expectations, known upfront and unknown yet; as well as the infrastructure can surely withstand any code/module changes, if any.To find out are these assumptions close to reality, I would consider the following that requires further investigation / discussion with a client.A. If they use a solution provided by a third-party company that is accountable for a product, and conducts the majority of development and testing activities. B. If (A) is true. How much flexibility and customization is allowed in the third-party solution. Are the specific scenarios that your client is going to use well covered in testing?C. If (A) is true. What kind of change / update request process your client has in place (or planning to have)? Whenever you find a bug and the vendor provides the bugfix, who is accountable for regression testing and in what scale?D. If (A,B) is true. Does the vendor perform functional regression testing of the custom scenarios or cross-browser testing as well?P. How important are stress/performance requirements? Is there a need to keep up with a performance baseline of expectations? Thank you,Albert Gareev
Hi AlbertInteresting original comment but hasn’t that been the case for a long time? At least the time I’ve been a tester….Thanks for commenting :)Rob..