In the field of contract software testing, you won’t always see eye to eye with the client. What you consider a critical bug, they might see as a non-issue (or worse, a ‘feature’). What you call a major security flaw, they might consider such a remote possibility that it doesn’t even deserve a mention.
You might ask how you bridge such a gap between your level of testing and the client’s level of acceptance and understanding of Product integrity and the testing process in general. The answer is simple:
You don’t.
It isn’t your job to convert the client to your way of thinking. Yes, you can contest a bug that they reject out of hand if you were technically correct to Report it. Sometimes they’ll accept it as valuable feedback, but most of the time they’ll just ignore any contested bugs. This is something that you have to live with.
You might ask how you bridge such a gap between your level of testing and the client’s level of acceptance and understanding of Product integrity and the testing process in general. The answer is simple:
You don’t.
It isn’t your job to convert the client to your way of thinking. Yes, you can contest a bug that they reject out of hand if you were technically correct to Report it. Sometimes they’ll accept it as valuable feedback, but most of the time they’ll just ignore any contested bugs. This is something that you have to live with.
No comments:
Post a Comment