- In the Agile way of working is there a need to write detailed test scripts…
You might decide to use test scripts, but generally speaking I don’t find much use for them. It will depend on your context. If you do this you should be able to justify its cost with how these scripts serve your test strategy.
…or can testing be done off the back of the test conditions/acceptance criteria?
Acceptance criteria and test conditions are insufficient to describe what you might test. Besides, what you do is exploratory and what you learn from the tests you do might lead to new risks, new ideas, and new tests. I don’t really know what “test conditions” are, but acceptance criteria are criteria by which whoever authored them thinks that the story cannot be considered done unless they are complete. If all acceptance criteria are met then the story could still not be fit for purpose, or still have problems. This arises from “all criteria not considered” plus all tacit criteria (e.g. “computer should not crash when code is run”). If that doesn’t convince you consider the fact there are infinite criteria. Any criterion you can think of I can say “okay, but what happens if you do that a second later” and it’s a different criteron - maybe that doesn’t matter, but then we’re in the position of guessing what matters given any change in any number of factors. Then combinations of those factors. You get the idea.
There are a few ways to approach testing something when given a story. One way would be to think of risks and then go and see if you can make them happen (e.g. “I think that the software may not handle weird data very well” or “I think that the software may not behave as I’d like when it’s run for a long time”). Another way would be to explore the product considering elements of the product (screens, code, media files, inputs, functions, etc) and thinking of risks that might apply to them. Saying that, use the acceptance criteria to your advantage. They are clearly important to the team, so should be considered when testing. Maybe it’s a suitable candidate to be augmented with a check in an automation suite.
- In terms of test execution, is taking test evidence necessary in terms of screenshots?
If you’re going to take evidence consider what you’re doing it for. If you’re not under pressure to prove you did something then don’t waste any time or energy doing it. That being said screenshots can be awesome for communicating a problem (via a bug report or just messaging someone), comparing two states of a screen to look for problems, remembering settings while you work on something else, recording what you did in your test notes if you’re writing test notes, and so on. So use screenshots, don’t let screenshots use you.
- How does exploratory testing tie in with the above and does this replace any of the above?
Exploratory testing is a way of describing an approach to testing that leverages its exploratory nature by treating testing as parallel test design and execution, giving short feedback loops between what is learned and what activities happen. That doesn’t explicitly exclude or include any way of recording or reporting that testing. That’ll depend on you, your preferences, what serves your test strategy, what environment you’re working in and so on.
Hope that’s helpful!