Thursday, March 01, 2012

Patterns in weakness in approaches about testing

I was reading this testing round table discussion and thought this might a blog post. Here I go...

To me, the biggest weakness is the perception or idea about what testing is  and why it is required.

Here are few examples as how companies treat testing.

1. Something that is avoidable to large extent or even can be eliminated if they could get their programmers and analysts get spec and code exactly right. The lousy work that these folks do during SDLC - creates need for testing.

2. Quality Assurance - Straight out of the box comparison with manufacturing assembly line. For these folks, testing is all about process and nothing else. If you get process right - you are done. It does not make any difference who does and when - all they need is to get process script right.

3. Building quality from the grounds up - A variation of #1 above - a growing group of people think that if you have automated tests (checks - actually) you don't have to really worry about testing. You are building quality from the ground - you cannot test quality but need to build it right? poor testers will not define and manage testing (under the name QA)

4. Testing? What? The whole team approach. This is creation of Agile model. Here, testing is everyone's responsibility. There goes "testing" out of the door as a specialist's job. When testing is something anyone in the team does - it is like any other project task.


5. Dont forget - this popular rhetoric - Testing (phase) is dead - That is biggest weakness in approaches about testing.  What else can be the biggest weakness about something other than saying it is dead?


Whole idea of testing is dead is around these beliefs and notions (test yourself if you agree or not)


1.  Testing (phase or role) makes developers complacent - a safety-net - remove it to make developers responsible.
2.  with so much focus on automated unit testing, test driven development, continuous integration - developers are producing quality software anyway
3. Finding problems is no big deal, we know where problems are (this is what James Whittaker said in his EURO STAR 2011 keynote). So do we need what testers for?
4. With cloud as popular software delivery model - you don't bother about bugs leaking. Time and effort to fix and turn around bug is ridiculously LOW - why bother testing?
5. What for you have crowd sourcing? Beta testing? - throw your stuff to users - let them use and tell us where are the bugs (there should not be many as we are group of smart developers and we know where the bugs are)



Thus,  the weakness in testing arises out of how we think about it  and what we want it to do for us. Thinking idealistically about how software is made and used, applying models from other fields without properly customizing them and removing or de-emphasizing the human element in the system  - are the key patterns of weakness in testing approaches





What do you people think?


Shrini

8 comments:

Unknown said...

I agree on almost all of the points. The mindset towards testing on its usefulness is the biggest risk for testers and testing community than anything else.
Like recently I had read(and couldn't help writing a post in my blog) Facebook has no dedicated testers. If you see the job requirement of a tester in the prestigious product development companies like MS,Yahoo,Google or Amazon etc the most sought after skill-sets are automation,scripting not human(manual) testers.

Buu Nguyen said...

Great post, Shrini. I'm even more curious about your response to each of those "notions", which I can see some truth in them. Do you plan to have a follow-up post?

Buu Nguyen said...

Great post, Shrini. I'm even more curious about your response to each of those "notions", which I have to say I can see some truth in them. Do you plan to have a follow-up post?

Shrini Kulkarni said...

>>>> If you see the job requirement of a tester in the prestigious product development companies like MS,Yahoo,Google or Amazon etc the most sought after skill-sets are automation,scripting not human(manual) testers.

This has been going for a while now. Historically programmers did all "testing" that needs to be done. But there were testers along the side as well. They did testing but also were very programmer friendly. Their universe was about testing that used automation as tool not as only means about testing.

It is very disappointing to see folks in the companies very sadly equate testing to /only/ writing code.

Is it a time to (re)define what (manual) testing?

Shrini

Shrini Kulkarni said...

@Nguyen

>>> I'm even more curious about your response to each of those "notions", which I have to say I can see some truth in them. Do you plan to have a follow-up post?

Writing a followup post is a good idea. I do have my responses to each of these patterns.

You make an interesting point about "truth" in these notions. These are patterns of weaknesses - when you connect weakness to truth, they dont quite match up. We might be talking about different perspectives and point of views here.

Let us wait for my "responses" post.

Thanks for commenting

Shrini

Phil said...

Your viewpoints on testing are quite interesting. Sure software testing, viewed with other paradigms needs to be taken with a grain of salt. And, with agile development methods, some think there is no need for formal testing, just let the developers and testers work together, and test as they go, do the sprint, and if it comes out the other end 'working', then that's good enough. However, the goal is quality, not 'good testing', so quality should be baked into the product from the organization's mindset. That means defining, identifying, and measuring 'defects' that occur in the entire product development process. Defects occur outside of development and testing. And from the customer's viewpoint, their thinking on quality goes far beyond the realm of zero defect software. Even if the software has no bugs, it can still be 'bad quality' right? The reason is that quality comes from more than the software (working or not working). Quality and hence defects can be in sales, requirements, as well as customer service. So 'testing' in these areas must be done as well. The difference it that the defects are just outside the realm of what we normally think of as defects.

Savita said...

I agree with your points.

I also like to add that very few tester's shows willingness to learn, read or try to experiment new...

Very good post :-)

Unknown said...

There are various loop wholes in testing and sometime it has not been taken seriously to impplement at each phase of SDLC life cycle. Testing results better if performed at each stage of development.
360logica