Hello community, I would like to ask you the following question, what activity should a tester perform in the 1st sprint?
If I don’t have the deploy of the project for testing yet, what should I focus on to optimize my time?
What kind of documentation should I prepare?
Thanks!
Study the requirements documentation available to you and any other sources of information about the product (could be project files, email communication, but also for example similar products that are on the market already). Identify places where the requirements are missing or ambiguous. Identify risk areas in the product. Talk to people - product owners, project managers, developers etc., in order to make sure that everybody is on the same page and that the requirements are made clear so that there are no misunderstandings. Help make sure that the devs are aware of risk areas and that these are covered in their implementation. Identify testability features you will need to better test the product and ask the devs to implement them. Get familiar with the tools and technologies used on the project.
In a nutshell: there’s more to testing than testing itself. A tester can help make sure those bugs are never written in the first place 
Very grateful for your help Eva. Any advice on how to identify risks or document them?
thank you very much
As well as the excellent points @baysha made above, I would add other things that would help you get ready for testing once the code’s available. Does extra work need to be done now so that once the code’s ready it will be deployed in a way that’s good for testing? For instance:
Beyond the environment plus pipeline leading up to it, you might need to prepare other things. For instance, the input data might take some effort to put together. This might need tools that don’t currently exist or need changing. You might need other tools too such as tools for resetting the system under test between one test and the next, or to give you a better idea of the state of the world after the code has run e.g. little awk/Powershell/Python/SQL/etc. scripts that look for important stuff in log files or database tables.
I’m not saying that any of this is stuff you need to create by yourself, but I suggest that it’s your responsibility to check for gaps between what you need and what you currently have. Who fills those gaps is another issue, that e.g. your boss could help with.
Also, I don’t think it’s realistic to assume you’ll get all this kind of thing done beforehand, i.e. you might need to create extra tools once you start testing and learn more about the system and how to test it. But it’s still a good idea to get as much done as you reasonably can beforehand.
Imagine the product with the mindset “what could go wrong?”
For example: there will be a field where the user can enter some data. What could go wrong with this field? And you might come up with risks such as: the user enters data in an incorrect format and the app throws a generic error; the user enters too much data and that makes the app crash; the user wants to enter the data using copy-paste or auto-fill and it won’t be possible; the user enters malicious code and is able to run it; etc. etc., you get the idea.
Personally, I then like to just talk to people, ask seemingly stupid questions and through these conversations gain a shared understanding of what those risks are and how they should be handled.
attend meetings
explore tools
communicate
be open
I’ll assume the project is not start from scratch.
You might see the gap that need to be filled in and it’s can be good starting point to help and contribute to the team.
When you say that you don’t have a build for the project, is the solution new or are we talking a feature improvement? If there is an existing product that will be involved then look at doing some exploratory testing. Open a document and note down things that you find about how it works, things that you don’t understand and also things that you’ve learnt around the wider tech/field.
As @baysha said, looking at requirements is really useful. Try and wrap your head about the stories and ask questions. A willingness to ask “daft” or “obvious” questions can be a real quality in testing so you may find that by getting the developers to explain things to you, you may guide them to identifying new challenges or gaining further understanding the work themselves.
The other thing that I’d recommend is asking to pair and buddy with developers when they are testing their changes,
I would take this and change it a bit:
There’s more to testing than the interaction with the product.
As many already stated here: You can prepare upfront for the interaction with, exploration of, the product.
By talking to other people, making some plans, preparing data tools etc.
On a basic level I see no difference in what I do in the first sprint compared to any following.
It might even contain more, because basis, perpetration than the following ones.
It is helpful to prepare your exploration of the product.
Don’t go with a t-shirt into the ice 