Suggestion to Increase your test efficiency.

The top management of the organization spends huge money on testing to get good return on investment, customer satisfaction and “good will”. Hence the quality of testing directly impacts all these factors.

 

A "Feel of Disappointment" or "Feel of Pressure" is seen when a bug is reported by the customers post release of your product. And every time a bug comes from the field, you are prone answer some annoying questions like,

    "WHY IS THIS USECASE NOT TESTED?"
    “ARE OUR TESTS NOT SUFFICIENT?”


The quality of testing takes its root from the quality of the usecases / testcases, documented and tested either manually or automatically. Now, you will have a question in your mind that the exploratory/intuitive testing is effective enough to bring out quality bugs. Yes, it has a lot. But the cons is,
- It all depends on one’s own expertise in the domain, technology and various other factors.
- It’s not practical to have all the team members with the expert knowledge.
- Most importantly, exploratory tests are not documented for regression. So a bug found in Sprint 3, solved and retested in Sprint 4, can get introduced in Sprint 8 and can go unnoticed.


Hence we have to get into some systematic approach to have effective and efficient tests that can be executed regressively. And yes, this is possible.


Usually when a requirement is provided to the test engineer, he/she intuitively thinks about the feature and start writing his own perceptions of the features as test cases. Now the test cases are all about his/her own knowledge level and thinking capacity. The reviewer of the test cases can add or correct a few test cases. Hence the derivative is very limited and could be possible that the tester has missed some aspects of the behavioral or usability related stuffs.

 

Here the change what is introduced is that, the collection of the use cases is actually done by a group and not by the tester alone. The group should always include the Subject Matter Expert, Product manager, Product Architect, Senior Developers, Developers, Automation tester and Manual Testers of that product.

 

So when all these people come together and discuss about the feature, more perceptions comes out based on their own expert level. These perceptions are documented, so that this becomes as the references for
- PMs to write the functional specification.
- Developers to develop the feature.
- Tester to write their test cases.

You can notice one change after starting to follow this setup. The bugs introduced by the developer will drastically reduce and the tests are very efficient enough to find bugs. But I don’t promise that there will not be any bugs coming from the customer post release. But comparatively, the count and severity of the bugs will be very low.


I’ll be happy to hear your words.

Views: 406

Add a Comment

You need to be a member of Software Testing Club - An Online Software Testing Community to add comments!

Join Software Testing Club - An Online Software Testing Community

Comment by Ash Winter on March 14, 2014 at 16:40

I'm not really sure I understand what you mean by an 'efficient' test? 

Plus I'm not sure making tests 'efficient' and the number of bugs found have a linear relationship?

Information about quality will show itself depending on who looks and how and when you look. Product n00bs often find obvious and/or gnarly issues, whereas pounding the same beaten path with regression scripts/automation can give very little 'new' information.

Add deterministic and exploratory techniques to your testing, communicate and collaborate early, then you have a chance of finding the most important bugs when it matters, but making statements like 'the count and severity of the bugs will be very low' is a dangerous game IMHO.


STC TEAM
Comment by phil kirkham on March 11, 2014 at 16:18

Thanks for the reply:

Depends on what you mean by 'test case' - if you're documenting it all down to the level of what button to press, what the expected result is for each step then it seems inefficient. Get everyone together and come up with a list of test ideas. Does it need to be more than a test idea? What do you mean by 'documentation'?

If you're using session based test management for your exploratory tests then there would be an output that could be used for 'regression'. Though if any bugs are found then I'd expect them to be turned into an automated test. I'm still not sure I really get your point on this? If I run an exploratory test do you want to be able to repeat this many times?

Comment by Sure N Dar on March 11, 2014 at 16:03

@Phil Kirkham:

Point 1: My focus is not mainly documentation. the focus is attacking the "test gap", which means the bug slipped out, could have been caught early during the test cycles. It's not practical to have zero test gap. But when many expert's knowledge put in together can increase the quality of the tests and can minimize the test gap. Yes, adding more test cases will inturn result in documentation. But at the cost of an annoying bug, i would say "It's Ok" for documenting.

Point 2: I did not mean that exploratory testing is leading to regression issues. As far as I know, there is no mechanism to do a regression on exploratory testing. The thinking process is different time to time for the tester when he/she is on the "hot seat".. If you are aware of any such mechanism, plz do share..

Point 3: My intension is not to put everyone to work on the tests. I just want people to add value to the tests. If their [expert's] participation is reducing a lot of rework and penalties paid by the company at the cost of good will, then i would insist... Yes, it requires a lot of change in mindset and takes a lot of pain in convincing people. But it is worth doing it.

Comment by Sure N Dar on March 11, 2014 at 15:37

@Madhava Verma: Thank you.

Comment by Madhava Verma Dantuluri on March 8, 2014 at 16:37

I agree with your approach of having all teams involve into use cases/acceptance tests design or review. This would definitely help QA to have complete test coverage.


STC TEAM
Comment by phil kirkham on March 8, 2014 at 13:23
Not sure I understand what your point is, are you saying there should be more documentation? I also don't understand your point about exploratory leading to regression problems?
Why can't everyone get together and work on the tests?

Adverts

Ministry of Testing

© 2014   Created by Rosie Sherry.

Badges  |  Report an Issue  |  Terms of Service