If there is an Epic to be delivered in 30 days but the developers have not provided any deliverable and it's already day 1, how can testers ensure timely and high-quality delivery? What steps should testers take to ensure a timely and high quality delivery?
Delivering of a high quality product is a responsibility of the team, not of the QA member. You just get ready to execute tests when they hand over built features to you:
- design tests
- prepare environment
- prepare scripts to generate test data
- fill in test templates if you use any (like test plan)
You can also report the risk to product owner and to your team.
This sound as job interview question...
My answer would be: I learn about new features, analyse potential risk areas, come up with test plan - what to test first and how. If all that was done in sprint planing, then I would pair with developers.
There is a fair amount to decompose in this question, but ultimately, agile is based out of Lean principles and that means some of these things should be happening:
Small Batch Sizes
In modern software development, looking at a deliverable of a month is huge. Even teams that are really new to this usually get that down to a week if they put their mind to it. Experienced teams are creating working increments every hour or so. Smaller increments helps keep everyone engaged and validates the increment of work so you don't spend time building on broken foundations.
QA Engineers aren't simply bringing the ability to write and run tests into the team. They are bringing a different perspective. While developers train to find the solution, QA trains to find the unexpected. No product has ever been made better by delaying one of those perspectives. You want them both in the conversations about how the team will build the product from minute 1.
Contrary to common belief, Test-driven Development, Behavior-driven Development, and other test-first approaches aren't actually about testing. They're about focused, efficient, robust development. Developers should be doing this and you can help them.
If you're in Scrum, it's Just the Team
If you are practicing Scrum, the Scrum Guide makes these two points about the team:
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,
- Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
If the developers aren't including you in the conversation now, and/or they expect you to take the burden at the end, the team is in direct conflict with the tenants of Scrum. Now, I'm not usually one for dogmatic stances, but empirical evidence has proven this out: one of these models has a high success rate and the other has a low one. Operating as one team has demonstrated a clear empirical advantage.