Input for "Definition of ready for QA"

[Anne Sofie]

Hi – I need some input from you all. I have tried to search the google god for input but haven’t had any luck.

I sometimes have trouble getting enough information from the developers about the features I’m about to test. We have acceptance critirias and I’m present at all scrum events – but sometimes you need more in depth information as to HOW it is implemented in order to be able to know where to test and how. Often I just get “empty” issues in my inbox with just the title.

I have been asked by the team to provide them with some form of  “Definitions of Ready for QA” so they’ll know which information to provide. I just think it is very dependent of the feature in question.

I need your input – how do you do it in your teams? Should tasks from dev to qa be given face-to-face or…?

I’m only part time in the team – but as I said I’m present at all scrum events.

[Melvin]

From my point of view, always is better that the QA Engineer is involved, if possible, in all the process of software development, from inception to the release, in this way the tester will have a better understanding of the feature to test.

A lot of constant communication with developers and Portfolio/Business team is also highly advisable in order to have present the different point of views of what is needed.

“Ready for QA” or “Ready for testing” can be a very subjective topic, and can depend of developer perspective of fundamental code being ready. The problem is that developer not always can imagine all the real or tricky scenarios to test, because probably is needed domain knowledge and business perspective.

Recommendation is to call a meeting involving developers, business, and QA team, in order for the developer to explain what he/she has implemented and discuss the different point of view of what to test, etc., getting the inputs from Business, Engineering, and other experienced testers. This can be an iterative process, in general you will get more understanding of the feature as you test, and more scenarios can be covered.

Regards.

[Darwin]

Most of the time it depends on the team you are working with. In my team, we always groom a task before moving it to the current sprint. While grooming, the project manager or the person who manages the scrum board will make sure there are enough description and acceptance criteria added to the task and will make sure it is self-explainable if not it will be made clear to everyone and doubts will be made clear.

Beyond that, there is also a requirement document and design files as a point of reference to most of our stories.

While working on a task when it is “Ready for QA”, if there is any behavior which I am not sure, I will post my question to our team through the communication channel or to the person who developed the task. If at all there is something more which I cannot figure out over the communication channel, furthermore  I will ask for clarification in our daily standup.

“Definition of ready for QA” for me is when a pull request for the task is been reviewed and deployed to staging/test environment to test 🙂

[Author]

Posts