Hoping I’ve got your attention by now, I invite you to discover the last part of my retrospective series.
Which was my influence within the project?
During the project, my activities (some were daily activities, others were sporadic, or only performed when necessary) were:
- Participating in the meetings relevant for me
- Gaining knowledge and understanding how the product will be used
- Analyzing project artifacts, like requirements, user stories, existing bug reports, other test results
- Asking questions about the product, clarifications and feedback
- Interacting with team members (testers, developers, leads, POs, PMs, etc…)
- Generating test ideas/scenarios
- Contributing to the test planning
- Discovering relevant/interesting flows through the application
- Searching for problems in the system
- Reporting problems
- Verifying fixes
- Discovering risks
- Contributing to the improvement processes
- Sending status reports via email
- Taking notes
- Mapping the product, with the scope of having an overview of the system/functionalities
- Getting access to different applications/tools for some of the new colleagues
- Generating test data
- My influence on understanding the client’s need to be informed
I learned from my past experiences that even if the client is not specifically asking for a status all the time, he wants to have transparency and he needs to be informed of what is happening.
Here are some things I did in this sense:
- Without waiting to be asked, I started to send statuses via email every time I felt it was necessary (status reports, bug reports, status regarding testing progress, dependencies reports, etc…). I was also signaling risks from the moment I identified them.
- Having a natural way of communicating things, I also influenced my colleagues to communicate with the client more clearly and in a more structured manner.
- As I saw some of the bugs were not so well written (some were written in German, some had an ambiguous description, some were not coherent at all and developers were spending a lot of time on understanding them), I wanted to give a relevant example of how bugs can be well written, easy to follow and reproduce by the developers (both German and Romanian ones).
- Advocated for team members to get more involved in the meetings (Plannings, Demos, Retrospectives, Clarification meetings, etc…).
- My influence on maintaining transparency within the team
We were a big team and things were not pink all the time. We also needed transparency within the team (at least, within the testing team) and I knew we can improve that.
Things I did:
- I proposed and organized direct discussions with the colleagues (when things were not working well/as expected) with the aim of identifying the problem and finding solutions. Avoiding to impose my own solutions, I was taking the discussion in the direction of finding a common conclusion.
- Working well in a team, I turned out to be a good coach for my colleagues. I was telling them when they were making mistakes, while I was helping them understand what the problem was.
- I advocated for the fact that even if we were split teams across different locations, we should consider ourselves a team and the entire project as teamwork.
- I focused on the quality and I’ve tried to show that addressing clarifying questions avoids misunderstandings and ambiguities.
- Documented everything relevant that was happening on the project (from daily notes, meeting notes, statuses, feedback I needed/received, questions, clarifications I needed/received, test ideas/scenarios for the user stories, improvements, etc…).
- Often did a retrospective analysis to detect what went well and what not so well, trying to come with ideas/proposals to improve the practices.
What I’ve learned: Get out of your bubble!
Being very focused on what I was doing, I had periods when I was forgetting to interact with the team. When working in a team, it is important from time to time to interact with the other colleagues (just talking to them, finding out what they are doing outside work, find out about their background). Interhuman relationships are very important when working among people, becoming a key for building trust, relationships and good collaboration.
Sometimes I addressed my questions straightforward, aspect that might have been interpreted as harsh by others. I learned the way of addressing questions should be adapted with respect to the speaker.
Communication problems are a sensitive topic. The way you address this topic should be done according to the person/s you are having the problem with. Also, I’ve learned that in most cases the problem should not be escalated, but there are situations when there’s no other solution.
- My influence on organizing work
We had a lot of things to do during a sprint. We needed to organize ourselves well, to take initiative in planning our work.
Things I did in this sense:
- Took the initiative for doing the plans for the sprint testing, or regression testing.
- Prioritized the tasks and focus on one at a time.
- Informed myself from the beginning of a sprint about the functionalities targeted to be implemented in that sprint, for increasing the work efficiency once the functionalities were implemented.
- Asked for access, accounts, rights, etc. for some new colleagues.
- Organized meetings – video conferences, for colleagues or for myself, when needed to clarify something with the business/other developers.
- Build credibility within the team (testers, developers), so that colleagues could refer to me for product/business knowledge/flows/etc.
- Talked to my tester colleagues about testing, about the importance of taking notes.
- Advocated for changing the “Test Cases” mindset.
- Proposed to have a grooming meeting together with the developers before the planning of the following sprint, in which all of us could add value to the overall understanding of the upcoming story.
- Contributed to the proposal of reorganizing our sprints.
What I’ve learned: Take breaks, reflect, experiment – and encourage others to do that as well!
Before taking the initiative of doing testing plans, I should go back to testing resources that could help me (e.g. I could go back to to the BBST Test Design Techniques and think what and how I could apply from what I’ve learned there).
Besides focusing on my daily tasks, I should keep in mind to overcome the drawing away from technicality (see my colleague’s post “Bad Habits during Testing Activities”).
Being very focused on what I was doing, I forgot to take breaks. I learned defocusing is helpful. Take a moment and enjoy the ride, take breaks, focus, defocus.
I’ve also learned that reflecting upon things that happened on the project (testing processes, other things occurring within the team) is essential. Take more time for that!
In the future projects it would be helpful to try and involve the developers in the testing process – at least for 1-2h/sprint, with the benefit of discovering what they implemented in a sprint, from a user point of view. Also, it could help in understanding the product better and make developers more responsible for the features, since they will see the things from a tester’s point of view.
Is this “The End”?
Even if the novelty I previously talked to you about was keeping my enthusiasm up, I pragmatically analyzed myself on several occasions and realized that was only a provisional motivation and satisfaction.
Thinking more analytically and in a less sentimental manner, I felt that something was still missing. I was part of a great and friendly team, I was satisfied with my work, I knew the project well from a business point of view, but I felt I had been standing in my comfort zone for too long a while (couple of months, I mean).
Therefore, I decided to change that. I wanted to deviate from the safe pattern, I needed a new plan, maybe a new professional achievement, I wanted to reach a new level of performance, and I was aware that for all that I needed to find time and support to make a change. So, I chose to leave the project I had been involved in for the last 2.2 years.
After announcing my decision, people understood the reasons I wanted to do that, so I had no obstacles to overcome on that side. I was happy about that, but then, the sentimental part came into the scheme. It was not so easy to overcome that one. Having worked together all that time as part of the same team, we had come to trust each other. The relationships built with the people involved in the project were important to me and I didn’t want to forget them.
In the end, besides the knowledge I gained during this project, the challenges that got revealed along the way, besides the effort I put into arguing for some aspects, the notes I took during those days, I feel the experiences and the connections with the people are what I’ll be taking with me.