Members

Groups

You're NOT supposed to get outside of your box!

This is the story of bug reporting.

The story began one day when QA Engineer (automation consultant) first time connected to a service module that was signed for functional test automation. Typically, some exploratory manual testing is a good thing to start with. As a part of investigation it's also recommended to look under the cover to see HTML structure and scripts. It's proven quite useful if you want quickly identify areas with a potential defect like field value validation (implemented with a front-end script).

This time expectations were fulfilled.

First, in the hard-coded (defined right in the code) sequence of restricted characters some discrepancies were found and immediately tried. Voila, first fails: "9.0" + "1,5" isn't supposed to be "10", and "1.1,5" isn't a number at all.

Second, one critical field (it supposed to be a unique digital code, like account number) was not validated at all, and submitting combinations like "angle bracket" plus wrong code effectively broke the security allowing to bypass the web page, and see on the next one half-parsed HTML with some secured information that regular user is definitely not supposed to see.

Since the build was on UAT already, and the previous build was in Production, the Character notified QA Lead and Developer of the module of a high impact issues discovered.
So here is the scene we begin from.

QA Lead.
"Why did you do those negative tests? We need to automate only positive tests.
We have an outsourcing company that performs security testing for us".

Developer.
"You, testers, are supposed to do black box testing! You should have not looked into my code!"

QA Engineer.
"..."

I left the Character’s reply undiscovered because I’d like to substitute my thoughts here, and I invite everyone to express theirs. I’m only asking not to drive in a judging direction.

“Quality is everyone’s responsibility”, so what would you do in that immediate situation (as well as going forward in given environment) to make your personal contribution and bring a change, no matter how small it would be?

If someone wants to take other sides’ opinions (i.e. Developer’s, QA Lead’s, etc.) you’re welcome too.

Tags: advocacy, black-box, bug, defect, report, responsibility, testing

Views: 2

▶ Reply to This

Replies to This Discussion

Permalink Reply by Michel Kraaij on August 1, 2009 at 1:08pm
QA Lead.
"Why did you do those negative tests? We need to automate only positive tests.
We have an outsourcing company that performs security testing for us".

Developer.
"You, testers, are supposed to do black box testing! You should have not looked into my code!"

QA Engineer:
To the QA Lead: "Why do we need an outsourcing company when we have the capacity and knowledge to do it our self?"
To the developer: "You, developers, are supposed to care about the quality of code. Lets talk about that first."
To the projectmanager: "We should have a little talk about the togetherness and effectiveness of this project team."

Yes, i would be very blunt about these topic. It's my way of working. I don't mind stepping on some toes to eventually get a quality job done.
Permalink Reply by Mohan Bhardwaj on August 3, 2009 at 1:07pm
Well Said MIchel. In an organization we work as a team. As a team member it is a responsibility of every team member to take care about the quality. When everything like Security Testing, UAT etc can be done in the same organization then what is the need for outsourcing company.

In the time of recession each and every resource should be utilized properly.

If Developer is making such statements about his code then he/she is definitely careless in his/her work. If a tester is technically sound, he has the right to check the quality if code.

Testers should always be open of any kind of suggestion about Quality, which can lead to better end product.

Regards & Thanks,

Mohan..
Permalink Reply by Roshni Gawandi on August 3, 2009 at 5:04pm
Nice story Albert....
I have faced the same issues in my testing career & when I was a fresher I was asked to keep mum on such issues.
Little did I know then.. but now the picture is completely different whenever I test for negative cases my PM goes gaga over it. Still there are many people in my organization who make a mess for each n every bug reported. And when they get on our nerves, we ask them to put a mail saying - Please test only as a formality. No bugs accepted. All are known issues.
When we say this, everyone comes back on the track & we are able to do our testing effectively.

Regards,
Roshni.
Permalink Reply by Mohan Bhardwaj on August 3, 2009 at 7:13pm
This is the case in every organization. Some politics keeps on going everywhere.... Keep urself diplomatic...

Regards,

Mohan..
Permalink Reply by Jayaseelan Jagaraj on August 3, 2009 at 9:02pm
To the QA Lead:
Because I Tester, never care whether it is positive or negative tests until it stop questioning the quality of the product.

To the Developer:
Because (atleast) I (am trying to) care about the Quality.
Permalink Reply by !ndra on August 4, 2009 at 9:22am
QA Engineer:

As we all know, QA itself stands for Assurance of Quality. So, there is no question of compromising or overlooking some issues when it come to the Quality of the Product. It’s quite common to undergo in such scenarios for anyone who is involved in testing/QA.
The matter of fact is how he/she can handle this situation and make it work. Anything that irks the 'END USER' is WORTH solving it ASAP before the customer reports it (It can be anything such as UI changes / typographical / positive tests /negative test / security / validation messages etc). But in this process one should never be arrogant and should deal with true team spirit to achieve the High Quality Product.

And I won't step back when it comes to the quality or perfection of the product to think outside of the box. As a Tester we supposed to look everything in-detail and do the justice to the company and more over to the deliverables.
Permalink Reply by Albert Gareev on August 6, 2009 at 8:35pm
Thank you everyone for your detailed comments, analysis, and personal experience shared!

I have nothing to add to immediate reply by Jim Hazen.
For a QA Engineer's contribution to an overall project quality attitude my suggestions are the following.

1. Going extra mile
It has begun already in the example given since negative tests were not the objective. So the next step would be to document and e-mail defects discovered or submit into defect tracking system. At first it could be ignored or even met offensively but with the time it may become an established practice.

Another good practice is expanding the original test data set provided by QA. With a low effort here the coverage could be greatly extended. (Of course, low effort advantage is gained only with a properly developed data-driven test scripts).
The best candidates here will be boundary functional tests and SQL validation tests.

Personally I have an experience establishing automated boundary testing within the Functional Testing phase while originally scripts were intended for positive Sanity Testing on UAT phase only.

"Verba volant scripta manent". Or documentation, documentation, documentation. Whether it's test cases written nowhere but shown to you by QA or BA, setup or validation procedures, any other knowledge or analysis - it's worth to take a time to write it down in a soft copy (and share it with the team).

2. Knowledge forward and knowledge transfer

Under "knowledge forward" I meant sending within the team short e-mails with a various quick tips, articles, advices, and checklists. It doesn't have to be a personally created document.
I have a positive experience with this practice.

As for knowledge transfer, it doesn't have to be an officially scheduled session. Sometimes 5 minute sharing of ideas or practices (or just asking the right questions) can make a team mate thinking of the ways to raise the bar of quality.

Thank you.

RSS

© 2012   Created by EDISTA.

Badges  |  Report an Issue  |  Terms of Service