Everything SQA

The Eventual Tester

I’m not much of a futurist, but I do have an optimistic view of the type of solutions technology will eventually solve, especially if those solutions meet the most basic of our conveniences. For example, take a look at your TV remote. This thing has evolved way beyond changing just channels. In fact, I’m beginning to think that I can use my remote to check my blood pressure, level some shelves around the house, and with a little adjustments, use it to walk my dog a mile or two.
Speaking of conveniences, QA testers are just that, as long as schedules are met, bugs are found before customers find them, and nonfunctional requirements are validated through performance metrics, etc., etc., etc. …   So are we to expect changes in the development community to improve this ubiquitous convenience?

Eventually.

One way that this can happen is by turning everything that a QA tester can do into a programmable, always accessible, and extremely affordable form of automaton. Imagine a HAL-9000 without the sensitivity chip, wrapped up in a Java class, and you have the perfect tester.

I’m Tester9000.

My not so unique theory is that if we can think, then so will our computers eventually. And with that thought, we can create more thinking components, helpers, modules, agents, and the list goes on. So, why not build the perfect tester to boot? When you think about it, we kind of have the foundation to these things now. Look at the effectiveness in building a continuous integration framework with unit tests. Has anyone heard of JUnit?

JUnit is not independent, it still requires the developer (or tester, if lucky) to define the Test for the class, build the code to support the TestCase, and then integrate all of this into a TestSuite, and incorporate this (Maven, ANT, or Eclipse) with an automated TestRunner, and review the results. But the magic of this is that it can be done once, and reused over, and over, and over again. This can be integrated into future TestSuites, and simplify the unit test needs without much of a compromise. But I can see improvements on the horizon. Here’s a far fetched one… code we develop may someday be able to test itself?  Personally, I think that we are way too far from that possibility - but not that far - and I do wonder what will software testers become in the near and relevant future?  Speaking of code that could test itself – this reminds me of the thought that we will become more of a “paperless society”, where we assume that with all of this technology, we will eventually need less paper. In a way, there is some truth to this, as we watch newspapers slowly die off as more and more people seek information through digital means. Look at your first generation iPad. Tell me that you’d rather have ink on your fingers verses using your iPad, and I’ll call you an [expletive] liar!

That question still remains…will technology establish a sufficient and viable solution that can eventually phase out the hands-on tester? Per Ray Kurzweil, is the singularity truly near?  With the semantic web growing on the horizon, and the possibility of test frameworks extending beyond the unit test model, IDE’s may become the all-in-one utility – just like your remote control.  You add in Moore’s Law, and we’re on the fast track to meeting our first real Terminator.

Job terminator, that is.

So what will it take to stay ahead of the curve? Well let’s keep an optimistic eye on the truth of the matter; and that there is something uniquely positive about having an actual tester involved with application development, even in an agile world. Software testers will still be required, but we need to adapt and evolve even faster. And if it isn’t known, testers are already evolving and adapting beyond the savvy manual test guru with a variety of test management and automated test tool experience. A new breed of testers have established street cred from being high-end bug finders on crowd sourcing test sites. Some testers even attract attention by writing detailed, yet eloquent blog posts to share QA knowledge (so that someday they will have enough material for a book - wink, wink). Even with this change in the tester’s skill set, when it comes to building a solid QA test team in-house, most tester’s have to demonstrate expertise that extend beyond the typical paradigm. For example, any given query of a posted QA job asks that a tester have some working knowledge of a variety of unit test frameworks. And If interviewed, the tester would have to write a sample unit test case that could fit in a hypothetical continuous integration. It wasn’t that long ago that unit tests were produced solely by developers. In fact, most unit tests are still produced by developers, but you wouldn’t think that if you were looking for QA work today.

So what’s the bottom-line?

The bottom-line is that testers should continue to evolve, and be prepared to adapt to the disruptive shifts in the way that things are typically done.

To put it in simple terms - pay attention to the changes around you. Understand that everything we do today is not exactly what we will do tomorrow. Strengthen your technical knowledge with the direction that QA is going. It seems like it was yesterday that I had a bag of tricks; inside was WinRunner and LoadRunner, and tucked on the side was Test Director.  That bag is gone. Today, I eat Selenium for breakfast, lunch and dinner, and I wash it all down with WATIR. Tomorrow, automated test cases may come pre-constructed, designed to work with web services as well as user interfaces, and all of this would be fully integrated within the development environment, nested somewhere deep in the cloud (wow – this is deeper than I thought!) In addition, you should strengthen your background as if you were a developer.

Testers can no longer act like developers;  testers will need to become developers who act like testers.

The job requirement bar will raise so much higher than today’s standard, so be prepared to see more and more requests for developers with testing backgrounds.  There’s no cause for alarm here. If you’re new to QA, then that should encourage you to start improving your background in that arena. If you’re a person like me, who kind of blurs the line between development and testing, then it’s time to start looking at management.

-arterberry-

Visit » Joel On Software
Visit » Sander’s Beyond Agile Testing