There's an interesting discussion going on at the Association For Software Testing discussion list on non-functional testing. Basically, Danny Faught thinks the term is weak and is looking for alternatives. I happen to agree; here's my reply:
Danny Faught Wrote:
>Yes, "non-functional" is a rather bizarre term, though it seems to be gaining acceptance.
Yes, that's kind of a weird term. Personally, I have a problem with "requirements" in most commercial organizations. I have worked in organizations where the requirements process is followed to the letter, the documents are created, and someone comes over to the engineering group and asks "How long will this take to build?"
We reply "Well, as written, about two years. But if you take out bullet points C, F, and G, I can do it by myself in about a month." And, magically, there is a new version of the document with C, F, and G removed.(*)
If that was the case, could we ever really say that C, F, and G were "Required"?
Non-functional testing has the same problem. It is lingo that doesn't -quite- match up with common sense English. Now, I have given up on trying to correct the requirements term; it's just too entrenched. Now, then again eliminating non-functional ... we might have a shot at that.
I like Para-functional.
--Matthew Heusser
(*) - I am exaggerating for effect here.
Thursday, February 01, 2007
Subscribe to:
Post Comments (Atom)
4 comments:
Matthew,
All testing is in some way functional. That's why the term parafunctional has quickly grown on me. I like it. I think it is a better description than "non-functional" for all that other stuff we do that is not specifically "functional".
Your questions about what is "required" ties to a major question that I have to constantly ask myself as a tester: What are the real requirements? My answer is likely to differ from that of other stakeholders: E.g., product management, development, the users.
I used to expect to have clear requirements for everything I tested. (A product of me getting my start in testing as a 3rd party enforcer of standards compliance.) I have come to realize that not all requirements are written and that not all written requirements are real requirements. Scope and implementation often change without official requirements document changes. Managing these changing requirements is a difficult task.
As testers, we need to find and report the "right" information to the "right" people in the "right" format. It is figuring what is "right" that is difficult.
:)
Thanks for the nice post!
Blog messages are really good, keep up the good work. Folk, find information on software QA and testing in http://softwaretesting-faq.blogspot.com/
great post!
Post a Comment