For me, agile testing is much less siloed than previous “schools” of testing at a high level.
I struggle to articulate what I think agile testing is at a lower level. I feel that agile testing is one role that helps to unite all of the other roles across a team. I need to work with our UX developer to understand why the designs are the way they are. I need to understand our target market and what they might want from our product. I need to work with our developers to ensure that they understand all of this too.
Of course, with testing you need to ask a lot of questions:
What is the risk of this? (to the business, the user, the other stakeholders)
Why are we doing this? (the feature, the test, using a tool)
Who is this for? (the product, the documentation, the automation)
I don’t think those questions change from agile to non agile environments but I think the speed that the answers for them are needed changes.
On the Dojo there are pages of resources for agile testing that I don’t think I’ll get through before the end of the challenge. I’m hoping that one of these pages helps me to get together a more detailed explanation of what agile testing is.
In the meantime does anyone have a better explanation of what agile testing is?
Janet Gregory and I asked the testing & agile communities to help us define agile testing. We’d never thought of doing a shorter definition - we tend to write hundreds of pages about it, with a lot of help from our friends! Here is the definition we came up with, with a lot of input from others: