I manage my career (and much of the rest of my life) with 5-year plans. This one (my sixth, I think) is a bit late. I adopted my last one in 1999 so the next was due in 2004. It took longer to converge than I expected but, at last, I think it’s done.
The 2006 plan is an incremental shift from 1999.
- Since 1999, I’ve developed a new instructional model for teaching that seems to work well at school and might transfer well back to the workplace.
I think this can be a foundation for an open courseware curriculum in software testing that people can self-study, study informally with peers or as a workgroup on the job, or in guided online courses. I think we can build an open courseware community to support, develop and facilitate courses like these.
- Since 1999, the biggest innovation in commercial software testing education has been in marketing–more people are using “certification” to sell courses, sometimes at stunningly high fees. Pay a lot of money, take a short course that helps you learn how to pass the test, pay for a test that some organization with a fancy name approves (maybe an organization that was created for this purpose) and get a fancy certificate that some employers would treat as authoritative evidence of competence in testing. I went to some meetings of trainers about this, read a lot of email, decided that the schemes that I saw didn’t have much merit but probably wouldn’t do much harm either. But they’ve been making a lot of money, and with that, they’ve gotten a lot better at marketing. Hey, Villanova University even offers a MASTER CERTIFICATE IN SOFTWARE TESTING. It looks pretty official, from a university that emphasizes its accredition on the same page (it is accredited, but I doubt that the Certificate Programs fall within the scope of the academic accrediting reviews). Look closely and this Master Certification is just a couple of short courses that lead to an industry certification.
- This is great marketing. But what does it do for the field?
- Do you really achieve competence in testing by taking a couple of commercial short courses in testing and passing a test?
- Is competent testing really so trivial that you can develop competence in only a couple of commercial short courses?
- Can you develop skill in these courses, or measure skill in these tests? How could you? If not, why should we treat these as indicators of competence in a skilled field?
I think it’s time to create a new model for certification in the field that focuses more on the benefit to the community and the advancement of the field and less on the marketing advantages. Some colleagues and I have started a project to create Open Certification for software testing.
- One of the cool ideas of the 1990’s was test-first programming. I started teaching this at Florida Tech as part of our Testing 2 course, on programmer testing, with two colleagues/students (Andy Tinkham and Pat McGee). Part of what I’ve been learning from that course is how to teach programmers how to test their own code. But the breakthrough for me was that teaching test-first programming is a great way to teach new programmers how to program. So, I’ve started teaching first year students how to program in Java, requiring them to use Eclipse and JUnit.
- I’ve taught this course once so far, had some good experiences with students who had failed a previous programming course.
- I don’t think test-first programming is for everyone–I think there are strong cognitive style differences among people and that test-first probably works best for folks who learn better by doing than by reading or listening and for people who think more effectively when they build from the details up than from an abstract model down. But that includes a lot of people, and universities squander (flunk out or drop out) about 40% of the students who take first-year programming.
I think there are a lot of good, diligent, motivated black-box testers who want to learn how to program and how to apply that to their testing. I think that the next generation of testers will have to have programming skills. Test-first might be the way to help some of our generation develop skills that have eluded them. Can we create useful instructional materials for test-first programming that support self-study online? I don’t know, but I have some ideas that might help.
- As a final note, it might be time for me to leave Florida Tech. There are a lot of reasons to stay–it’s been a good home so far–but Becky just finished her Ph.D. and her career opportunities in Florida look limited. I would also enjoy working in a community that had more of an IT base than a defense contractor base and in a school that had a stronger emphasis on social science (and thus more opportunity to collaborate with those researchers), even if this meant sacrificing some of the excellence in science and engineering that I’ve enjoyed at Florida Tech.
The core of the 2006-2010 work plan is to help improve the state of the practice in software testing, by building the community and developing an online curriculum in software testing that is accessible everywhere in the world (that probably means free, or cheap) and supports significant growth in skill and insight. It’s an ambitious goal. I won’t fully achieve it, certainly not all of it in 5 years, even with an increasing group of collaborators who have inspired parts of this vision and/or will take parts beyond what I could ever achieve. But I do think we can make a lot of progress against it.
HERE’S SOME BACKGROUND
In 1999, I had to choose an emphasis–law or computing:
- I define my career in terms of a field, “safety and satisfaction of software customers and developers.” Legal, psychological, technological and commercial considerations come up in almost every issue in that field, so I end up doing work in all of those other areas.
- To develop competence as a lawyer (while managing 40 people during the day), I had to reallocate my discretionary time from programming to law. Then I graduated, got caught up in the development of the Uniform Computer Information Transactions Act, the Uniform Electronic Transactions Act (which became the federal law, E-SIGN), and an update to Article 2 (law of sales) of the Uniform Commercial Code, and wrote Bad Software (by far my best, but least commercially successful, book).
- To support the legislative work, I shifted my business model from work as a software development consultant and as an attorney who specializes in computer-related commercial law, to include a lot more commercial training. The training brought in far more income and more client appreciation than anything else, but it also exposed some interesting challenges that I hadn’t considered. I’ll come back to that.
- The legal work was satisfying, I had an impact–even got elected to the American Law Institute–but it didn’t pay the bills. I had to either shift full-time into law or return focus to the technical work. My technical training and consulting paid well, but there were technologies that I had to catch up on, and problems that obviously belonged in my area if I wanted to claim to be continuing in a serious way in the field. They needed a full-time commitment too.
Ultimately, I decided that I could do more good, and have more fun, focusing on software than law. As a lawyer, in the current polical climate, my work would be defined more by the bad proposals I would fight against (some have become law; maybe I could have had a small impact on some of their details). As a technologist, I could wrestle with some complex educational problems and maybe develop a new model that could benefit the field.
The problem is that we need a new generation of software testing architects and we don’t know how to foster them.
Most of the widely used testing techniques, much of the current “tester attitude” were widespread back in 1983, when I got my first job in testing. Sadly, most of today’s commercial training in testing — including the industry standards and the syllabi for certification of software testers–are also stuck in 1983 (or maybe the 1970’s, when the key techniques and attitudes really developed).
Unfortunately, the technological and societal contexts have changed. In the 1970’s, when I was learning software engineering, a large computer program was 10,000 lines of code. Business code was often written in COBOL, a language designed to be readable even to business managers. A tester who really wanted to could read ALL of the relevant parts of the program, identify ALL of the relevant variables, and probably trace most or all of the information flows. These days, even your cell phone probably has over a million lines of code (several have over 5 million).
It’s great to lovingly handcraft every test, but in the face of programs this large, the tester gets (proportionally) so little done that even if the technological risks were the same now as before (different risks call for different types of tests), the tester who does things the old way will find her work irrelevant simply because she can’t do enough in the time available to make a difference to the quality of this large a program.
We need new models that improve our productivity by several orders of magnitude.
Sadly, the most popular test automation tools perpetuate the old styles of design and test and improve productivity only marginally. People spend big bucks for the small improvements in productivity and project control, and these improvements are often not realized with GUI regression automation. Some of the tools–test case managers that want full and independent descriptions of each case–probably make things worse.
To break out of the rut, we need to think in new ways, to use the technology in new ways. For that, we need advances in theory and practice that go beyond what testers can easily learn and reinvent on their own (or with a few friends) on the job.
Traditional commercial training provides no (0.00) help with this. Commercial short courses are fine vehicles for exposing people to new ideas, but not for developing new skills or exploring new insights in depth. People need time to play with new ideas, challenge them, try them out, learn how to apply them, and for some of the brightest, learn how to go beyond them to the next ideas on the new path. There is no time for this in a three-day or five-day course.
Universities provide a much stronger environment for this deeper and transformative learning.
Unfortunately, universities don’t provide much education in software testing–certainly not enough to foster a paradigm shift.
In 1999, I decided to find a university that would welcome efforts on software testing education that were focused on having an impact of the practice of software testing in the field. That was the core of the 5-year plan. In 2000, Florida Tech welcomed me, I moved to Melbourne, and have had six fascinating years learning (and help others learn) a new set of skills.