Hi all,
We’re continuing work on the Junior testing curriculum based on the Job Profile we captured with the support of the testing community.
We’re now in the process of going through each task and analysing them to identify the core steps we take to achieve them. For this post we’re considering the task:
Designing Tests
We’ve run a series of community activities including social questions and our curriculum review sessions to identify the steps we need to take to successfully achieve this task and have listed them below.
- Review documentation around features or ideas that are to be tested
- Reviewing code bases and changes that are to be tested
- Use various techniques and tools to identify potential tests to be carried out
- Formally or informally document test ideas for execution
What we would like to know is what do you think of these steps?
Have we missed anything?
Is there anything in this list that doesn’t make sense?
In an ideal world all the list makes sense but from experience I would say that the following does not really happen that often if you are a junior on a project:
- Reviewing code bases and changes that are to be tested
Hi, I’m also not sure about reviewing code bases but agree with reviewing the changes to be tested.
There is no mention of attending a 3 Amigos session (or similar) to discuss the requirements with the author, whether Product Owner or Business Analyst, and a more senior tester. I feel this would be something a junior tester would get involved in - they wouldnt solely focus on just reading documents. I wonder if thats worth adding?
Steve
Thanks for the feedback. I’ve made a small tweak to:
Reviewing code bases and changes that are to be tested
And updated it to:
Reviewing changes that are to be tested
There’s nothing to say that reviewing code base can still be included in those changes, but it does open up the task more.