test objects design

I was reading Johana Rothman’s slides from “Hiring Yesterday’s Testers” (PDF file) from PNSQC 2004. I shall quote the Slide 11 titled “Need for Frist-Class Testers”

- First-class testers provide information about the product underdevelopment and test

- Testers have at least three sets of customers

1. Developers

Testers write tests before code is written

Testers find problems early

Developers are more interested in creating fewer defects

Developers have more flexibility about when and how to fix problems

2. Product users

3. Company managementTesters discuss risks, not stamps of approval

There is a whole world of assumptions in this slide. I think one could write a page book just based on this slide alone. To define a tester is to see someone whose job it is to bridge the gaps of disparate worlds, to switch vocabularies, languages; from taking code to talking design to talking measures; communicating with different worlds in their own native vocabulary.

At the same time a tester would need to be well versed in a body of knowledge of a particular business domain software is building. For example If I don’t know how ’stop’ or ’stop limit’ stock market orders are executed using an online brokerage I would be a useless tester of that feature even if I know how to do boundary value analysis. I would need to know a bit about being an ‘Investor’ who is actually using the brokerage trade tool to set up ‘limit’ or ’stop limit’ orders on a system and I would need do know about Ask and Bid spreads and how they trigger orders on NASDAQ and NYSE or AMEX. Domain knowledge is the first thing I would jump on as a tester. Only after that my skills as a tester are useful. Domain knowledge is tacit knowledge for most but testers need to externalize it to build test scenarios.

If my customers are Developers then I need to know how to read the code with them. As a tester my job is to create Use Cases, scenarios, Stories, whatever it takes before any code is ever written to find out ambibuities in system design. I can then go over those stories with developers who are going to implement them. A developer can’t just read few lines of requirements and start coding. This will lead to disaster.

Yes, my customers are product users. Then I need to be versed in Usability Interface Design because this is all black-box approach for them. This is where User Stories is a common agreement for Acceptance Testing. I need to stand in two worlds. One of Developers looking at the code and one of Customers looking at UI only. On top of that Management wants to know risks, measures, results, costs, Return on Investment. Discussions on approach to testing and sunken costs as well.

On top of this I need to be a toolsmith. Well versed in OS interoperability, run SQL queries, discuss missing data with DBAs, run regression tests to verify the last snapshot of scenarios passes, document changes, retest changes etc… etc… That’s a lot.

It’s a complex job to be swiftly moving from domain to domain, jumping language barriers, speaking different vocabularies given different worlds a tester communicates with every day. - It’s an exciting intellectual complex work. And if this Sotftware Development is a cooperative game of invention and communication then it’s pretty exciting as a tester to support that game with my skills.

Technorati Tags: Agile Testing