My take on future of testing has always been – in fact I think it is the current state now, that:

1. Testing is not just functional GUI testing
2. Desktop apps are a thing of past
3. With the advent of Web 2, SOA, Cloud, etc. it is getting more and more technical
4. Performance
5. Security
6. Usability
7. Integration
8. Automation
9. …are the areas where the testers of today need to develop skills in

I have interacted with all kinds of testers, testers from different schools, contexts, methodologies, level of experiences, and most of them specialise in functional testing. But if you would really like to be future-proof – then I think Technical Testing is the way forward.

To add fuel to the topic Goranka Bjedov did a great presentation recently at a conference in Wellington: STANZ

In the presentation she shares her past experiences in software testing, especially last couple of years of her life when she comes across some hard reality of life/software quality. And she ends her presentation with the following summary:

1. We can reduce dev time (and costs) by writing productivity tests
2. We can bring in quality by adding smart system tests in right places
3. Think performance, scalability
4. Think usability
5. We can reduce number of machines needed in dat centers
6. We must start calculating and communicating the value of our work (dollar amounts)
7. We must stop being the cost center

The good thing about them is that the interviewees are not restricted to people from just one part of the world; neither to at what stage of their career they are at. We have just released our 25th episode of TWiST. We’ve had participants from all over the world who are at various stage of their career, though most of them are pros and have been around for a while.

My role in this is to identify potential speakers/interviewees from down under and organise recording sessions with Matt. I am also the co-producer of the show. Here are direct links to podcasts from down under:

• TWiST #11 – with Jared Quinert and Brian Osman
• TWiST #17 – with Marlena Compton, Oliver Erlewein and Farid Vaswani.

This is the link to a bonus podcast where I interviewed Geoff Horne: http://www.softwaretestpro.com/Item/4879/Bonus-Thursday/Software-Testing-Test-and-QA.

These podcasts are a great source of knowledge and helps one learn from other people’s experiences. If you are a tester then I’d highly recommend you subscribing to these – TWiST.

Happy Listening!!!

There were some great minds present there and my general feeling was no one is in this industry to just earn their bread and butter, but also because they love the art of testing and care about it’s future.

In addition to various presentations we also had some open discussions and the topic that got everyone excited was ‘Certification’ or ‘Degree’ in Testing.

Carol Cornelius did an interesting presentation on certification. Which as expected was received with mixed responses. Interestingly one of the attendees also raised a concern why don’t we have a university degree for Testing?

There were some other concerns as well like:

• Google is developing a car which drives itself – in future we might have softwares or development platforms which may *test* itself?
• The other common consensus seemed to be that with lately technology changing so drastically and quickly there is a growing requirement for technical testers.

Talking about degrees/certifications in testing – my take on it is yes having a degree in software testing would be a great benefit to the testing industry and hopefully we will have one in future. This degree may cover all types of software testing methodologies, technologies and terminologies. It is then up to each individual what (s)he would like to specialise in. Isn’t this what happens with other degrees or certifications like Chartered Accountant (CA) – people do these courses and then go on to do different stuff?

Certifications are a good start but I think we need some hands-on, practical, detailed curriculum for a full-fledged Degree in Software Testing.

The only issue I have with exploratory testing is business continuity – what happens if someone else after you needs to come and do the job? I’d say the the tester should maintain at least some documentation to allow that.

Some people when you say you do exploratory testing immediately think ad-hoc testing. I suppose because there is less emphasis on obvious structure and at the end there is little tangible evidence of testing performed.

But in my view, there’s a lot more to exploratory testing than wandering aimlessly through an application looking for bugs. As well as mentally challenging, it requires a lot of self-discipline.

Here’s why you need self discipline:

1) You need self-discipline to test the parts that are not as interesting to you, or not as fun. It’s easy to overlook and ‘forget’ them when other parts are more appealing.

2) You need self discipline to give each bug the time it deserves before racing off to find new ones. Time to analyze, examine and understand. Only then, can you go and look for new bugs.

3) You need self-discipline to write up bugs when they are found, instead of leaving them until later or when you feel like it.

In my view, in exploratory testing, as in many other ways of testing, its the mission and the stakeholder that count and their needs must come first.

What’s different is that instead of relying on documents and reports, you need discipline to make sure you meet those goals.

Source

Image Source

I quite agree with his post and there are certain things that I would like to comment on and those are:

• I totally agree that “Automated software testing ‘is software development.’” and all the managers need to accept and understand that. Therefore an automated tester may demand and does deserve an equal salary package as his software development counterpart.
• I think it is quite difficult to come up with a measurable ROI on automated testing – but thats my understanding. Though it goes without saying that automating any testing is going to payback in future.
• There are always some managers (business and project) who do not understand importance and advantages of automation.
• Upscaling of team members is also very important and every testing manager should invest some time on training the team to understand the ROI of automation and take smart decisions on what tests to automate.