Recently, I finished a project I was involved in for 2 years. I had the opportunity to allocate some time for doing an analysis, so I started to write down my ideas. The outcome was a nice and comprehensive retrospective, covering challenges I encountered during the project and lessons I’ve learned, which I would really like to share with you.
Since we’re talking about a long project and my ideas expanded on lots of pages, I decided to do a series of four blog posts that I’ll post during March.
The series will debut with how I started the project and how the first three months on the project were.
How did I start?
October 2013 was the month when I was proposed as a tester candidate for a nearshoring Pilot project for a German client. Why a Pilot project? Because I was supposed to go a lot to the client’s site in Germany, with the scope of gaining a relevant understanding of the business, architecture behind the system, the needs and problems our clients had, so that we could come up with improvement solutions and start testing. Based on the results gained in that period, the collaboration would have continued or not and the testing team would be enlarged.
I had an interview with the Testing Department Management, I was accepted on the Pilot project, et voilà: I found myself in Germany.
How were the first 3 months?
The first 3 months were challenging: there was a lot of coming and going to and from Germany, since the plan was to stay on site as much as possible during that period.
I was among the first testers on this Pilot project (the new testing team would expand over the following months), so I was introduced to the project by the German colleagues. I received presentations, trainings, tutorials about different topics of interest. Time was passing and I was starting to feel progress in my work.
I started to get more and more involved in the project, knowing the team better, participating in the meetings and getting involved in the regression testing of the product.
Oh, but let me give you some context about the project. By that time, it was called the “Desktop” project and implied an e-commerce online shop compatible with Desktop devices. The testing purpose was UI testing, functional testing, end-to-end testing and regression testing.
There were a lot of integrated systems behind that UI, for which I attended short introduction sessions. The goal was to get familiar with them, in order to have an overview of how the system and the processes worked together.
Coming back to my implication on the project, I fastly gained independence and my colleagues’ trust, facts that were reflected in the tasks I was receiving.
- Language barriers
I was not speaking German that well and my colleagues were not very comfortable speaking English. All the meetings were held in German, so it was hard to gain all relevant information. Also, most of the documentation was written in German.
What I’ve learned: In order to solve a problem, you first need to address it.
First, address the problem to the right persons, of course. Then, in order to see the problem solved, you need to be patient. Problems are not getting solved over night.
In this case, with patience, people changed and they adapted to the different conditions they faced. The language barrier was mostly solved only after the problem was addressed (to the right persons) and enough time passed. Slowly, the meetings started to be in English, colleagues started to talk in English. Appreciating their effort, I also tried to speak German when having chit-chats with them. The team in Cluj started to do German classes, as well.
- Cultural differences
Lunch time was the first thing noticed as different. My German colleagues were having lunch around 11:30, while I was used to having it somewhere at 13:00.
Another problem in this sense was how I was perceived by them. I was a newcomer, a stranger that appeared on the project, in their offices, canteen, requesting them to communicate with me in English.
What I’ve learned: People can adapt, as hunger comes while eating.
Different situations and contexts will place people outside their comfort zone. Every time this happens, people should be open to embrace the new and adapt with respect to it.
In this case, on the one hand I went to lunch earlier, so that I could be with my new colleagues. On the other hand, I tried to demonstrate that I’m an enthusiastic person, willing to collaborate and help them when needed. I tried to communicate with them, to gain their trust and in the end the initial problem was pretty much solved.
- Different beliefs (approaches)/different expectations
Coming from a small company that focuses exclusively on software testing, I had learned that continuous learning, investigation and effective communication are keys to success. There I came to meet some people that were having other approaches, hence they were having different expectations.
What I’ve learned: Communication is everything.
In our case, coming together and talking about these problems (explaining and giving examples of how things could be improved and how we reach a consensus) helped us all understand each other and become consistent in our views and principles.
- Knowledge transfer – organization and infrastructure
A number of people were due to leave the project as I came along, so we needed to transfer the knowledge, making sure that the current quality of the testing done there was not affected in a negative way.
The infrastructure for the knowledge transfer was not well organized in the beginning. Access to the system/to some of the apps was granted slowly, accessing the test system over the VPN connections was troublesome, receiving rights for different accounts lasted too long. Also, there was not enough documentation for the initial transfer knowledge, or if there was, it was in German.
What I’ve learned: Don’t wait for someone else to solve your problems.
Even when the problem concerns accounts, permissions, rights, and you know someone is supposedly taking care of them, ask for a status, don’t just wait for a fairy to come and tell you there’s a problem, a delay, or that it’s solved.
If it comes to documentation, start creating your own. Take notes when having meetings, calls, tutorials, anything you consider might be relevant.
Don’t be selfish, think about the new colleagues that will come on the project, as well. If you encounter problems, think of potential solutions that might help, or might reduce the waiting time for the others.
In our case, I created a list of things called “Required access for new testers”, containing all the accounts they needed to have and the people able to help them, another list of “Useful links” which should help them in the beginning, sent emails so that things would be moving faster for them. Also, I shared with them some of my meeting minutes notes and I tried to give an introductory presentation to some of them.
- Receiving tasks, without being involved in any decisional process
There was a period when I was assigned on some tasks (e.g. do a smoke test, do regression – but run these “X” test cases, etc…), but I was never asked for any input, or whether I had other suggestions. Also, I wasn’t involved in the process of taking these kind of decisions. Since receiving tasks and just executing them runs counter to who I am, I started to have a problem with that.
What I’ve learned: Get involved, instead of getting upset.
If there’s something that you do not like, besides addressing the problem, try to deal with that yourself, get involved. Don’t take it personally, but take the initiative, give feedback and come up with a solution that works for you, as well.
To solve that problem, I took the initiative and asked to be included in the meetings and plannings. I also proposed to have short talks with other colleagues for clarifying some aspects and deciding together how to split up the work.
One response to “Testing is all that and more: A project retrospective – Part 1”
Very nice initiative! I like a lot the last lesson, “Get involved, instead of getting upset” 🙂
Can’t wait for the next blog posts!