How to report suggestions to developers while doing a software testing?

Question

Here is the scenario, Our testing team suggested so many things while they performing testing. They have been reporting these suggestions as BUGS. I mean there are creating tickets under the category of Bugs.

Actually, these are not even discussed with the client or confirmed as requirements or included in the sprint. And they are including these suggestions in weekly bug reports as bugs. I told them we can't consider these suggestions as bugs since they were not even developed or requirements confirmed by the client.

Then the testing team told me, this is the procedure in the testing process, and all the tickets including bugs and suggestions will create under the bugs category. I don't think it is the correct method.

I told them to keep all the suggestions in an excel and then will discuss them with the client. once it is confirmed will develop and then they can test it and raise the bug if there is any. Please let me know what is the professional method to report suggestions from testing team to developer/cleint.

Answer 1

1. Practically in software development process keeping something in excel is not recommended when its for whole team.
2. One can always use for personal stuff but as mentioned in question, for enhancements or suggestions this practice can be avoided
3. Instead, we can create enhancement task and have it in parking slot
4. Idea is to have it available in front of eyes so can be consider while planning sprint
5. Small correction, This suggestion/enhancement is not only for developers but should be presented to whole team
6. In agile methodology everyone has leverage to share view point and enhancement and suggestion can be part of it

Answer 2

A few points:

• "this is the procedure in the testing process" For starters, there is no such thing as "THE testing process". Developing testing strategies is part of the work of a responsible tester and should be adapted to the wider context. Probably they are talking about "THEIR testing process".

• What is a bug? A bug is the realization of a risk - a characteristic of the product that threats the value of the product to some person. We develop products with the expectation that they will be valued by the people who matter - and sometimes, while learning about what we built through exploration (aka testing), we may uncover ideas for new characteristics or risks that we may not have thought of before or may not have made explicit before (it was only implicit knowledge). E.g., we may realize our product doesn't work on smaller screens or for blind people - although we never thought about having these users. This will cause a bad experience for these users. We can then consider what we need to do about this bug (risk realized) - we may decide to move on or shift our plans to cover this risk.

In principle, it's part of the tester's debriefing session to inform interested people about these situations, so they can make decisions.

But, of course, it may be agreed that the tester shouldn't / don't need to explore these ideas, for instance, adhere strictly to a checklist of previously explicit points.

I would suggest coming to an agreement with the testers about the scope of testing, so they (1) won't be wasting their time with exploration that it's not of interest to their clients and (2) won't get frustrated by constant conflict due to this lack of alignment.

(Images from Michael Bolton's talk A Ridiculously Rapid Introduction to Rapid Software Testing)