SRILU BALLA - QA Lead, Duke-Energy
TESTING A BROKEN BUILD
Have you ever found yourself in a situation where you identified the new build you got is broken, you notify the Developer about it and get a reply that it will some time before they can get you a new build? Right then a senior member of the team suggests to you, to test the build further to find any issues before you get the good build, (her opinions is this saves). You explain it is a waste of time to test with a broken build or bad data since you will get false negatives which will need to be cleaned up in future which will cost time and chaos. The senior member suddenly stops suggesting testing and give you a look that implies “you are lazy, smart ass, know it all”.
Have you ever found yourself in a situation where you could log into any customer account in Production without even knowing the password? You report it and the developer closes it saying that is how the new architecture works now.
Have you ever found yourself in a situation where you found un-encrypted passwords? So, you report it and the tester who tested the feature in the past closes the ticket with the justification that “un-encrypted password” was not mentioned in the requirements and so he did not miss the bug, or this is not a bug.