Should Software Testers say that functionality is “working fine” or should they say that “it seems/appears to working fine or looks good”?
As a blackbox tester, while giving my testing status to the management, i usually refrain from saying that a particular feature, enhancement of defect is "working fine" and say that it seems/appear to work fine, as of now. Is it unprofessional or not a good practice to say these words?
What matters is that you are able to effectively communicate the current state of the software in test to your leads and management. How you communicate that information will depend on your workplace culture and any regulatory requirements your employer needs to meet.
The biggest potential issue I see with the way you are currently communicating status is that it implies a lack of confidence in your testing – even though everyone here knows that we can never be 100% sure a bug fix or feature implementation is working correctly. People in management tend to prefer overviews with decisive statements.
Some suggestions for you to consider:
- Risk – what risks do you see if the item is released with no further testing?
- Coverage – What proportion of the known paths through the feature/bug functionality has your testing covered? How do these relate to the 80/20 rule (80% of users will focus on 20% of functionality, so your testing should be heaviest in that 20%)
- Known Issues and Workarounds – What if any problems with the feature/bug fix are you aware of and what if any workarounds exist to deal with those problems?
- Confidence/Comfort – How comfortable are you with releasing the software as it is? Very comfortable? Not at all? This might be a very broad gut-level guideline, but it can be a useful heuristic to give your manager/lead.
- Green/Yellow/Red – What is the current status of the software in test?
- Green – There are no known issues
- Yellow – Known issues could cause problems
- Red – There are serious problems that need to be addressed before moving on.
- Known Issue Metrics – How many critical issues remain unfixed? How many major issues? If your employer has rules about not releasing with known bugs above a set severity level, this information is important to communicate.
Depending on the circumstances, I will use any or all of these heuristics when reporting test progress. I tend also to keep it to stating facts, for example: “All known paths through Feature X have been tested. There are no outstanding bugs reported against Feature X.”
In the ideal world you as a tester should say “The actual behavior of the application under test corresponds to the given requirements”.
However to make that ideal situation having the place you at lease need those “requirements” which have to be comprehensive enough and unambiguous. This is quite hard to achieve in the real world especially in “agile” environments.
This is also dependent on the current phase of the project. Saying “it seems working fine” is okay on the early phases but it is better to avoid on the final stages.
It is also worth mentioning that whether you say one opr another it would not change the actual state of the app. You should take that into account and in the each particular case you should keep the balance between the stakeholders assurance and your reputation which your words, deals and results compose.
“Working fine” and “seems to be working fine” will be interpreted identically, it’s obviously based on your personal observations when it’s you saying it.
If you want to improve report quality, say “X thing did Y, as expected”. Then developers know if your concept of “fine” is the same as theirs.
I was a lead of an Agile-ish dev team for a couple years. The environment was pretty informal, and for me I would understand either of the statements you’re giving as the same thing.
What communications did arise regarded the following:
- If a tester says, “It looks fine,” do they mean “It looks fine so far but I’m still testing” or “I finished all test cases” or “I finished the first set of test cases I was focusing on so that’s all I’m thinking about, even though there’s a lot of other test cases that need to be covered”? Similar miscommunications arise when e.g. there’s 3 apps and a DB deploy required to finish a feature and the tester has only covered some of those, but the manager’s asking about all of it.
- Are the manager and the tester on the same page about the expected scope of testing and what is/isn’t critical to test?
If you’re working with a very new or very-unfamiliar-with-software manager, then the difference between “it works” and “it seems to be working” might possibly need to be explained re: what software testing can accomplish, but the bigger question is whether you’re answering the question the manager is asking. And I think you might not have this question if you and the manager were on the exact same page when it comes to what exact testing is being performed, because otherwise you could just say that your test cases worked without wondering if they thought you were over-promising on how defect-free the software was.
Kate Paulk’s answer above has a really methodical way of breaking down what’s going on, but for an informal conversation IMO it would probably be better for you to ask the manager what they’re most concerned about and tell them what you have and haven’t tested related to that.
Anyone in a decision-making position should already understand that those two statements mean the same thing when spoken by a tester. If they don’t, someone needs to help them understand what software testing can and cannot accomplish.
“it seems/appears to working fine” shows lack of confidence.
When a tester says that a functionality is “Working Fine”; it’s implicit that it’s “with respect to the requirements”
The best thing to say is “Working fine” or “No. Not shippable because of XYZ reasons”. If somebody tells says that a feature “appears to be working fine.”, then the manager’s question might be “Are you not certain?”
- Be on top of requirements
- Ensure that you have all the clarifications and there are no open questions
- Do not ignore non-functional requirements
- if you see any risks, share them upfront
I do believe that there might be some bugs that even testers might miss. But once testers have tested a functionality, there is some level of sound agreement or disagreement with respect to adherence to the requirements; that is expected.
Which I believe; is perfectly fine.
More likely then not there are still defect to be found but this factual true is not really useful and can cause anxiety.
Two different ways to put “working fine” are “All the tests passed/are green” and “I found no defects”.
If you think that the test coverage of the functionality is low you should say so to the Test Manager.
I think a tester should be more precise regarding the status of testing done for a giving feature\bug fix. Saying either “working fine” or “seems/appear to work fine, as of now” gives no indication of the level of testing that has been done.
Something like this I think gives the management more information
- We have run X test cases
- Number of passing = P , Number of failing
- Limits of the testing performed \ areas not tested
- Recommendation (e.g. done, include, more testing needed, etc.)
Our Awesome Tools
- Check your IP Address precisely
- Online JSON Formatter with Syntax Highlight
- Online CSS Minifier Compressor
- Database Administration Tutorials
- Programming Tutorials & IT News
- Linux & DevOps World
- Ebook Reviews
- eSport Matches, Skills Tutorials & News
- Entertainment & General News
- Check your public IP Address precisely