Wednesday, December 06, 2006

How can a software tester shoot on his/her own foot?

Would like to know the self destructive or suicidal type of notions of the today's tester? Would like to know how a tester can shoot his/her own foot?

There are many ways – one of them is by “declaring” or "asserting" that -

Software Testing is an act of (whole or Part) Software Quality Assurance.
Few variations of above –

Software Testing = Software QC (quality control) + Software QA
Software Testing = Verification + Validation.


As an ardent follower or disciple of Context Driven school of Testing – I swear by following definitions or views

• Quality – “Value” to someone (Jerry Weinberg)
• Bug (or defect or Issue) – “Something that threatens the Value” (I am not sure about the source)
OR “something that bugs somebody” (James Bach)
• Whatever is QA – that is not Testing – Cem Kaner
• Testing – Act of Questioning product with an intent of discovering Quality related information for the use of a stakeholder (James Bach /Cem Kaner – I attempted to combine definitions by both James and Cem)

OR
• An Act of Evaluation aiming at Exploring ways in which the Value to Stakeholders is under threat (this is my definition – which discovered quite recently – open for criticism)

• Stakeholder – is someone who will be affected in success or failure OR actions or actions of a product or Service (Cem Kaner)

• Management is the TRUE QA group in a organization (Cem Kaner)

Now let us see how notions that assert to Testing as QA or combination QA and QC roles are self destructive or similar to shooting on ones foot …

1. The terms like QA, QC were appear to have barrowed from Manufacturing Industry – Can you measure and assess the attributes of software in the same way as you do for a mechanical component like piston or Bolt?
2. You can not control or assure Quality in a software By Testing
3. It can be more dangerous or costly to claim as a Tester that “I assure or control Quality by Testing” as it can backfire when you don’t.
4. Unless your position in Organization hierarchy is very high – you as a tester can NOT TAKE decisions about
a. Resources and Cost that is allocated for the project (Budget)
b. Features that go into the product (Scope)
c. Time when product will be shipped out of your doors (Schedule)
d. Operations of all related Groups - Development, Business, Sales and Marketing etc.

When none or most of above not in your hands – How can you Assure or control quality?

5. When you claim that you assure or control quality – others can be relaxed – Developer can say – I can afford to leave bugs in my code – I have anyway some paid to do the policing job Or others will say “Let those Testers worry about Quality, we have work to do” – Cem Kaner

6. You will become scapegoat or Victim when you leak Bugs (or issues or defects) go past you. One of the stakeholders may ask – “you were paid to do the job of assuring or controlling Quality – how did you let this bug(s) to product”

An interesting and relevant is reference is mentioned in Cem Kaner’s Famous article
The ongoing revolution in software testing

Johanna Rothman Says (as quoted in Cem Kaner’s article) -

Testers can claim to do “QA” only if the answers to the following questions, is YES
• Do testers have the authority and cash to provide training for programmers who need it?
• Do testers have the authority to settle customer complaints? Or to drive the handling of customer complaints?
• Do testers have the ability and authority to fix bugs?
• Do testers have the ability and authority to either write or rewrite the user manuals?
• Do testers have the ability to study customer needs and design the product accordingly?

Clear enough?

What is the way out ---?

Treat software testing as a service to Stakeholder(s) to help them conceptualize, build and enhance the *value* of a product or a service.

Be a reporter or service provider – Don’t be Quality Police or Quality Inspector of an assembly line …

8 comments:

Anonymous said...

I think what should be first attempted is to define QA & QC. What many organizations call QA is actually Testing? Since developers are thought to be bad testers, the testing job is given to someone else.
So I agree that testing is not QA -"QA" teams are rarely aware that QA can encompass activities outside of testing.

Anonymous said...

I completely don't understand what you are getting at (your poor english and improper grammar doesn't help).

Software testing is absolutely a _part_ of software quality assurance, by every definition I have ever heard of.

After reading your entry, I honestly have no idea the point you were trying to make.

Yes, there are many roles that go into quality assurance (testing being one of them).. how is asserting that the same as shooting yourself in the foot?

ya lost me.

Shrini Kulkarni said...

Dear Anonymous --

When making outrageous comments about my language and grammar, least I would expect is that I will have your email address or some reference to get back to you.

My English may be Poor (rough), my Grammar may be improper - I make sincere effort to improve it all the times. Note that my native language is not English. If you have positive intentions of making constructive criticism, share your email ID and send SPECIFIC comments about my language - help me.

You have repeated your comment - at least 2-3 times "I don’t understand what you are getting". Do you think - that is better way of communicating?

I will write a separate post for explaining my stand on what I am getting at and why I say and assert that "Calling software testing as either QA (whole or part of it) or QC - is nothing short of committing suicide for a software tester"

Here is what I can offer you now ….

I am not sure what definitions you are referring to and your background to make these comments.

Further, I am not sure what your definition of “Software Testing” is – My definition is right there in the blog post – critique it.

I challenge you to quote those definitions (with proper references) that mix up software Testing and QA/QC. Let us debate on them. Traditional definitions that you seem to refer may be old or out dated. In the current scenario - I think there is a need to redefine and re-look those terms.

The sources I quote with respect to Software Testing and QA/QC are attributed recognized experts in Software Testing - Jerry Weinberg, Cem Kaner, and James Bach.

My assertion is that Software Testing is not part of Software QA for the reasons bellow:

• Software testers do not have control over the parameters like Budget, Schedule and scope of software product or service. Only those who have control over these parameters can “assure” “quality. Test can only report on quality related observations.

• If you insist that software testing is *part* of quality assurance – you are committing to something (even partly) that you don’t and can not control.

• You can not assure Software Quality by testing it – it has to be built into it.

• Lastly, in the current context of our discussion, I am not concerned about what software QA is – what I am sure is “software Testing”. As far as I know, that is not QA (even partly).

I expect you to come back and comment again …

Shrini

Shrini Kulkarni said...

Kadaba --

Defining what is QA and QC may be a good thing to do for those who belive in them.

For me, I am good with "software testing" and I know that is something different from QA and QC.

This will work me and many others in my community

Thanks for posting your views ...

Shrini

Anonymous said...

Hi Srini:

I congratulate you on:

1) making us all aware of the unique value and challanges behind software testing

2) ability to think, write, and be a valuable professional to the software industry in two or more languages

3) being brave enough to leave the honest but sad post such as the anonymous post above, so we can all put our own faults into perspective

I invite you and readers to visit my web site blog. It is new and focused on design, development, testing, marketing, and sales of components. Component oriented thinking, not object oriented thinking, may offer new benefits and challenges to testing - especially in the realm of federated reuse and real-time.

One popular multimedia/transcript/blog entry on my site is by Dr. Lee from UC Berkeley "Building Unreliable Systems out of Reliable Components: The Real-Time Story"

To watch lecture requires login/registration, but it is free, and you can remove yourself from our database if you choose to at anytime.

Ron Fredericks

The Avenger !!! said...

hi shrini,

i agree, now if i could only get my senior management to read this and understand that we are not "The inspectors", the production bug nightmare could be erased out !!!

Anonymous said...

This seems to be a popular topic theme amongst the testing community… here are my two cents from my experience:

Testing Software – Is verifying that software meets requirements – those requirements as defined by the Change Request that prompted them. It is also then to make sure that it does not create adverse affects to requirements implemented by all other Change Requests since the inception of the System. When there isn’t specific detail in the CR of how the software should behave then the tester should fall back on documentation that defines the standards to which all systems should adhere.

Regardless if testing is applied thought the software development lifecycle, testing comes after creation. Quality control on the other hand does not require creation; it creates and applies: standards, checks and critiquing to all aspects of the software development lifecycle from the inception capture of an idea into a business case.

In my experience without QC testers feel frustration as they feel that they are releasing software that meets all requirements defined by a Change Requests but that it does not meet there own personal standards i.e. they are personally applying QC control checks – which they have build up form there experience, but that are not recognised by the business as excepted standards.

Anonymous said...

This seems to be a popular topic theme amongst the testing community… here are my two cents from my experience:

Testing Software – Is verifying that software meets requirements – those requirements as defined by the Change Request that prompted them. It is also then to make sure that it does not create adverse affects to requirements implemented by all other Change Requests since the inception of the System. When there isn’t specific detail in the CR of how the software should behave then the tester should fall back on documentation that defines the standards to which all systems should adhere.

Regardless if testing is applied thought the software development lifecycle, testing comes after creation. Quality control on the other hand does not require creation; it creates and applies: standards, checks and critiquing to all aspects of the software development lifecycle from the inception capture of an idea into a business case.

In my experience without QC testers feel frustration as they feel that they are releasing software that meets all requirements defined by a Change Requests but that it does not meet there own personal standards i.e. they are personally applying QC control checks – which they have build up form there experience, but that are not recognised by the business as excepted standards.