Every start of a (new) sprint, the development work of the user stories starts. At that moment, for the tester(s) there is no software to test, hence the development work just started. That does not mean that the tester(s) can relax and wait until some piece of code is delivered by the developers and start testing at that moment. When the sprint starts, the testing work starts too. It is not execution work but preparation work.
As I’m a proponent of Session Based Exploratory Testing, I start my test preparation with writing my session reports the moment the work in a sprint begins. As a tester, I do an intake of my test work. i.e. which user stories are we developing within the sprint, collect some user story specific information and the details of the test environment. I write three session reports for this;
– an intake session report with information of the user stories within the sprint.
– a survey session report where I collect more detailed information about each user story within the sprint.
– a setup session report where you collect all the information of the test environment(s). Here you also can put the target release information for the sprint
When this information is collected and clear for everybody, you can start with the risk assessment of each user story. You have some requirements, some acceptance criteria’s and some information about the definition of done. This is your starting point of doing the risk investigation of a user story. Extra information you are looking for is where the software is changed or newly introduced, something you can ask the developers. You can also ask the the visual designer for some screen layouts related to the user story. It is also possible that the business analyst has formulated some feature files (BDD- or Gherkin-scripts).
With als this information you can define the areas where to test and come up with test ideas. Als this information you put in an analysis session report. For each user story you can create such a report.
These four reports combined are you test plan for the sprint. When you are finished with this, you will be a few days further in the running sprint. Perhaps the moment you finished your preparation, the developer can deliver the first parts of the software of the user stories which are developed. The right moment to start your first deep coverage test sessions and the first lines of code for the automation scripts if needed.
So to conclude; when the sprint starts, your testing starts too.