Being Asked to Give an Unexperienced Student an Overview of a Test Strategy, What Would You Do?

This is exactly the situation I encountered lately: my boss asked me to help a young student to get a feel for what is needed in a test strategy. I got three hours to do so and 15 minutes preparation time.

On top, the student was not yet informed about what he needs to learn. Apart from supporting some unit tests, the student had no idea about testing. We also did not know if he will be encountering V-Model or agile in his project to come.

So we had to be open to everything!

My Choice

First Hour: The Concept of the V-Model

I used a more or less generic V-model as an illustration of the close relation between requirements and tests. I won’t be explaining here the V-Model, but list those concepts, I was able to explain using the V-Model, that I think need to be considered in a test strategy

• Requirements need to be validated and verified AND YES THIS IS A TESTERS JOB!
• The test strategy needs to align to the decomposition and composition strategy of the design and development
• The test strategy also needs to align to the integration strategy of the application
• It is relevant to discuss with an architect and be close to the development lead in order to align the expectations which tests to do on which integration level
• Shift left! If you miss a flaw during business design, it only will be detected during system test (according to the model). If you did not test your error messages right on web service level, you will have an unacceptable effort during process tests
• In order to create a maintainable project, it is very relevant to have traceability between requirements, tests and code
• A quality gate is meant to improve mutual understanding (and not to punish the service provider)
• What to do, to stay with the testing pyramid and not end up with a testing ice cream cone
• I could not resist to point out, the HPE got a great tool out there supporting the V-Model: ALM

Second Hour: Testing in an agile world

Obviously, the link between V-Model and the agile world is the idea, that in a sprint there are somehow many little V-s. And there is more. As I did not have much time I picked the first presentation I found with Google, by Lisa Crispin from 2009. I have the feeling, that also agile moved on quite a bit, but she has in there a good basic explanation of the four testing quadrants. And this is what I used for “my test strategy” (apart from all those organizational und communicative differences an agile approach brings)

• Tests to improve the product are relevant
• Involve the end customer as early as possible
• Explorative tests are not just playing around, but should be organized sessions, with a mission. Maybe use/identify tours or heuristics.
• There are many non-functional tests to be considered, and I explained some of them
• Then we discussed some time how the decomposition and composition might work in the quadrants and how the good old test levels could be placed into the quadrants
• I also had to admit, if this is all the job of the “tester in the team”, this seems like an almost impossible job. This increasingly when the tests get less functional, and the more potential influences from outside the team come up.
• As Lisa Crispin mentioned a few tools in her presentation, I pointed out some of the basics of gui automation

Third hour: The Governance

Not knowing how large the project to be will be, I then decided to explain some aspects about the roles and responsibilities in testing. Luckily one person can take several roles, and will, depending on the different project organization available. For this topic I used an existing test concept from a former project of mine. That had more than 100 pages, so I tried to concentrate on the following points:

• Make sure to have a common understanding of roles and responsibilities defined
• Make sure to have a common vocabulary defined
• You will never be able to test everything. So design an approach for reduction: risk based testing
• You will have different test types in different test levels
• You will need an environment for executing the tests
• You will probably need quite some tools to support your testing, from CI Tools, from static analyzers to test execution and maybe reporting tools (Oh well, here is HPE ALM quite great again… 😉

Do you need a document for all of that? Well that depends…

What did I miss out?

Right afterwards, I was worried about all those things I did not talk about. I guess the first issue that came to my mind was that there are so many test types out there, out of which the most relevant ones to be picked. And probably so much more. I added a little reading list to my “class” to cover some of the remaining stuff, but I wonder if I got the REALLY IMPORTANT STUFF.

What do you think: what would you have done? What did I miss?