Struggles at the Beginning – Software Testers journal
We’ve all been there; either onboarded to a new project or a new company, and joined a team that either has never tested its product or which has no set testing standards. As a Software Tester, you’re and should be used to being the new kid on the block, always with a mind full of questions.
The ultimate question in this scenario is “Where do I stand as an individual Software Tester and how can I fit within the existing team structure?”
Below are some useful tips that are helpful in this situation:
Get the Baseline
Start with getting a view of the current state of the project. Go through the product vision, road map, backlog items and the development processes, figure out what the system does by creating mind maps and asking questions. This fosters and nurtures a good working relationship with the developers and product owners.
Communicate with people
Getting to know your team is one of the most important things you can do during your first few days in a new project. Not only will this help you understand their strengths and weaknesses, but it will also give you a better sense of how they work and what their expectations are for you as the tester. Take some time to introduce yourself to everyone on the team and learn about their roles in the project.
Communication is key when it comes to setting testing strategies for the project. It is useful because the quality of work improves as the quality of communication within the team increases. Getting feedback from developers and the product owner about the project can be started by asking a simple set of questions like:
What is the development process of the project?
What are the users' critical requirements?
What is working well in the project?
What are the most common problem cases?
Once you get answers to these basic questions, start observing how things are actually working and write them down.
The next step is to focus on setting the testing strategy for project and check how testing culture can be embedded in the team.
Set the Test Strategy
With product teams and developers, it’s good to have an open and collaborative discussion on current technical practices and tools. It not only allows us to share existing knowledge but also helps to gain insights and new perspectives.
Create the test artifacts including the Test Strategy and the Test Plan documents to explain:
How the step by step testing will be carried out
How the resources will be involved
What will be the testing lifecycle
What will be the test deliverables
How the bug reporting and tracking mechanism will work
Share the Testing Knowledge
Arrange the Exploratory Testing session and create the Exploratory Testing Charter with the time boxed approach to record the observations about the product under test. Time box testing approach and the exploratory testing in the initial days of onboarding helps to find the potential bugs and the risk areas in the product or application under test. The charters created during this stage can also serve as the product documentation because they explain how the application is working with various steps.
Mind maps are also one of the very useful tool for sharing the testing knowledge. Mind map is the visual representation of sharing the information with team and in this way testing will become a shared responsibility.
Pair Testing Session
Develop the approach of pair testing, where ideas about testing the product with the developers and the product owners can be shared. Listen to others about their ideas of testing and get to know what drives them. This session can be carried out with other fellow testers or the developers who are working on the same project. It will help in finding some early stage bugs and the edge cases for further testing.
Don’t be afraid to seek out help about the new features or even the already developed features, asking questions in testing is always better than assuming.
Software Testing is like the catalyst for change in the company because testers discover the truth about the product. As James Bach said: “Testing is a much more plastic process than development is. To create working code I have to write some code, but to be successful as a tester there is not a single specific thing that I am required to do except encounter the product. It’s all situational. I love that flexibility. I feel like a dolphin playing in a large ocean.”
So my friends, be that dolphin and start thinking out of the box.