I recently made the following, Tweet:
This feels like a good starting point for a “definition of ready to test”. What other things would you check? Maybe you don’t want “Deployed” on there, because you do the deployments as part of testing?
Interested to hear your thoughts!
Not sure I agree, you don’t need to have code deployed to an environment if you can create a local environment with a docker container for example. For documentation, you do need to have good ACs to know what to test but if you don’t have that something has seriously gone wrong.
After having spent a few weeks listening to Clean Code and TDD and about professionalism in software development this should be added.
Because it is somewhat weird that you have a group of people that can “release” something they do not know the state of.
That being said we have had a few other candidates on that list.
The main crux of my point is that you simply don’t require a fully completed feature in order to start testing it, much less a completely documented and configured one.
I think the “Ready for QA” question is going to be different for diffrent products, teams and features. I am interested to hear other peoples exprience and opinion so I can help refine my own list.
It surely depends on the process you follow as far as how embedded and shifted left your testing is. It sounds like the process you describe is for testing to have the build “thrown over the wall” to them once a feature is complete.
Building observability in could be done alongside the development with testers involved, the same with configuring and deployment. Ideally as part of an automated process, but a lot of that could be done so that there isn’t much left over of testing after dev have finished.
It really comes down to the overall definition of done, rather than ready for test though which could include things like:
I agree with @sjprior - the list in the original tweet doesn’t sound like the org has shifted much to the left. Nothing wrong with that, but the expectations are going to be very different depending on how far to the left an org has shifted.
In my current team, we’re running most everything in containers, using mocks for dependent services, so you can generally spin up the world and test features locally. As @ola.sundin said, the feature appears to work as expected and doesn’t break anything. There’s also the expectation of unit and integration tests that verify the feature is working as expected.
We don’t actually have much manual testing these days - our test engineers might add a few e2e tests once they’ve reviewed the unit/integration tests that were added.
Get rid of the ready for QA column completely and have “In progress” 
Some ideas:
*Agreed with Dev the requirements have been met
*Discussed with Dev about “impact” e.g. regression
Definition of done.
When my team writes up a ticket and then finds we are blocked by another team, we are not done. The unit tests may work, but the integration is not done. It’s often not system-testable and delivers no business value until the day it is done. so it hangs over into the next sprint. “Deployed” might count as done, but when deploy is shifting sand and due to yet another party not done on their bit, it becomes a process problem. I worked in a company that designed their own hardware for a while, they consequently spent a lot more time being explicit about exit criteria, and used KAN-BAN for some lines and sprints for others. Back then, done was about multiple dependencies that everyone had to take responsibility for.
It’s only done when you can hand it to a salesperson is how I eventually came to see it.
Thanks all! Some great insights into your own processes and success in this area. Keep em coming I am listening and learning!
I floated this at my Retro yesterday. I don’t think it stuck, but I did manage to move the conversation back to “team owned” quality.
Sometimes just floating an idea works - people digest and then weeks down the line someone else comes back to the idea.
Team owned quality sounds like an excellent conversation.
