Smart Contracts

Updating Solidity code and Testing a Smart Contract

Books on the Blockchain

Publica Self Publishing

Goodbye Contracting

Hello brave new old world...

Ruby-Selenium Webdriver

In under 10 Minutes

%w or %W? Secrets revealed!

Delimited Input discussed in depth.

Wednesday, 3 October 2007

The Future of Testing?

A message over at QA & QC Group, well made my blood boil slightly. Here's the question(s) and response I gave. Grrr... etc.

"I am working in MNC in India, Recently one of my team mates (PM level) told me that the future of testing is no scope, and he gave reasons."

To answer your question in succinct form, the future for software testing has never been better, the future is brighter than perhaps we suppose, it's brighter than we can suppose. Why?

1) If any software boom is down first the Companies fire Testers.
Wrong. This assumes the situation as it is now or was in the past, as it is in this transitional state, but you're talking about what the future holds. So this statement is wrong. The ones at risk are development, probably more like Technical Authors or Support Desk. The value the business derives from testing is eminently improved the more difficult the economic situation becomes. The logic for this is because there is a need to maintain a share of a shrinking market where the differentiator would be price and quality, yes in the singular because the are so linked. Testers are far cheaper than developers generally and in safeguarding quality are essential. Safeguarding quality ensures the total cost of ownership is reduced meaning a well tested product is a better investment. A product with higher quality means a reduced need for Support Staff there by bringing a greater saving to the business.

2) Developers can do our job + Coding.
Wrong. A simple reflection on the Division of Labour, Specialisation of Work theories will tell you that there will at some point be enough work and enough need for focus of effort by individuals who are particularly experienced in testing, to need people who's specialisation is testing. Turn this around, can testers also code as well as developers? We would always say No to this, we understand their specialisation, experience, etc. lend themselves to being developers who can test, just as it does us being testers who can develop. But the two professions are not fully inclusive.

3) In future comfortable tools are comming.
Wrong. This has been spoken of for many years and even the best of the Record and Playback tools fail at encountering the simplest of issues. This is the same logic as for the robots running their AI cleaning my house and making me a cup of tea as I type... I still don't have one. Even if we accept the suggestion that these tools become so all powerful they are acting like a tester, who's going to configure, run, maintain, mature what they do? Is this person by definition not a tester?

4) No investments on the Testing more?
Wrong. The very act of investing in the above in a desire to eliminate the tester is by its nature investing in testing. If we accept that the paradigm of how we currently define 'tester' will shift then you'll not get rid of testers. Again, what will happen is the boundaries between tester and developer will blur. I maintain it's the developers who are at risk in many areas.

All of the above statements your team mate made are based on the current paradigm of what a tester is. They are looking at what they understand the tester of today to be and in doing so are making statements about testers that were essentially existing yesterday. Being in the profession we're aware that the days of just hitting keys and clicking the mouse are over, it has been over for all but the most junior members of a test team for perhaps more than 10 years!

Today's and tomorrows tester is a much more technically savvy professional. They can develop test harnesses, stubs and drivers written in and interacting with a variety of programmatic languages, author complex data sets, work in an integrated manner with Agile teams on a level that blurs the boundary between tester and developer, use highly complex tool sets testing across the many components of the global system architecture and much more.

Today's and tomorrows tester is a professionally educated, examined and accredited professional, including but beyond that of a general computer science degree and some courses that a developer may typically have and soon potentially a member of a Chartered Institute. Putting them at the same level as Architects, Lawyers or HR professionals.

The key hitting monkey of yester year now uses techniques grounded in complex statistical and analytical mathematics, cognitive psychology and some of the best scientific research covering everything from computer technology to human logic.

As I said, the future for software testing has never been better, the future is brighter than perhaps we suppose, it's brighter than we can suppose.

Mark Crowther

Monday, 1 October 2007

Time Spend Analysis

I just posted a new paper on my website which reports the finding of a six week study in time spent by the QA team.

At the start of the study we agreed a set of Key Tasks such as 'Reading Test Documents' or 'Waiting on others', getting those involved in the study to agree the tasks and definition of them.
Then, for the next 6 weeks 6 staff recorded their activity every 15 minutes. At the end of each week the stats were collated and charted out to see where the department, team and individuals were spending their time.

The results were certainly interesting and gave some valuable insights, such as:
  • Team members in work for 7.5 hours a day don't test for that amount of time.
  • Test Managers are available for testing under half of their working day.

No, really. I bet these two insights are obvious to those who'd read this blog but on presentation of the data to the client there was slight disbelief. I had to show them the Daily Tracking Sheets to prove I wasn't making the figures up.

The study participants also kept an Issue Log to track non-bug issues and start to get a broader insight into what else was impacting their testing.

Have a look at the Papers section of the website for the paper and hit the Templates button for the 'Daily Tracking Sheet' and 'Issue Log' templates I mention.

Let me know your thoughts. Plenty of scope to make this study more scientific, what would you do or is this good enough for what we were looking to prove? Does it apply outside of the study group and make sense in your environments perhaps?

Mark Crowther, Head of QA Time Tracking