Sometime in June 2016 I joined the IFS project as a Tester. That was 23 months ago!
I started in Worth as a back-end developer, but the project I was working on demanded a snr developer and I had to be replaced. At the same time the IFS project needed a tester and thought to give it a try. I wasn't happy that I wouldn't develop anymore, but testing was something new, worth exploring!
And this is how it started, I prepared my environment using my boss' credentials, I didn't even have my own yet, as I had not yet officially joined the team and the customer did not know about me.
By then the testers were the ones running the Acceptance tests for the developers before merging any pull request. So Michael, the tester who guided me in my first steps in Testing, suggested I would join before the end of the sprint, so that I could help out with the PRs, that had to be merged before the "code cut off". And so it began! The last day of a sprint, without even having my own account I joined IFS as a Tester. By that time, the code cut off was always on a Friday, all the last PRs had to get in and then we would merge development to the acceptance branch, run all the acceptance tests and then deploy to the UAT server, smoke test it, and then to production. If all good! If there were tests failing we would have to fix them branching off the acceptance branch. Well that part is still the same with now, 2 years later. The only difference is, that now we can deploy on any day we want, plus the deploy can be done during "normal working hours". By then the infrastructure guys and the testers were staying long Friday evenings for the deploy to happen.
When I first joined IFS the team was huge! Before joining, I was a bit afraid on how is it gonna be working in such a huge team. Will I get to know and work with everybody? Surprisingly, when I joined the IFS team I felt a warm welcome. The team, although its size, felt really as a team. Michael & Ewan gave me their guidance on how to test IFS and this is how it started. But also had great team leads, great communication with the developers, the infrastructure guys, the business analysts, the content and the UX people. Everyone in the team has his own role and is responsible for the job they deliver. But at the same time, they are willing to share their experience, help each other out and learn from one another. We are working together to deliver a project that we are proud of. But in the end, the product we deliver is not the Innovation Funding Service portal, is us; is our team, that we are most proud of. IFS is a safe place where people enjoy working together, learn from each other and improve. And I am very lucky to be part of it.
Very quickly I learned to be a tester, learned from others and in my turn shared this knowledge with many different testers that passed from this project. I started enjoying being a tester, learned to see the project from a different angle. What it means to have less bugs, be more secure, perform adequately when there are many users. But also what is required to be accessible by different people, what it means to be user friendly and how important it is to have the right content.
Then I realised that I became obsessed with my job. This passion about quality and the care for details, in combination with my developing knowledge helped move forward and become good in what I was doing. The project started speaking to me. Yes, speaking! "Click here" or "Try this path, there is a bug", "Try it!", I could hear it saying to me. Have raised lots of tickets! I know it sounds evil, but it is honest to say, that I took pleasure in discovering bugs. Haha!
But it really does not matter how many tickets you raise or how many lines of code you write. (Forgot to say that part of my job, is to write acceptance tests and thus write and maintain this part of the code.) What is important, is to improve the project, to catch issues before they hit production. But also to teach the other team-members to think in a similar way. Help testers improve their testing work, help developers test their code before they deliver it to you, or think along with them while they develop. This way the product becomes more robust.
When you find issues and you move tickets to Done, is productivity. When you enable discussions raising the right questions, or boost things to happen because you are there, then this is called generativity and it is equally or even more important in a tester's job.
And believe it or not, sometimes succeeding more comes from doing less. Don't rush to give the answer, let others discover it. Give the space and the time to enable others to do more.
I've learned that as testers we don't need to only bring sad news, but also good news. I got to work with many people in the team, developers or not. I got to see the job they deliver, but also learn their personal flaws and skills. There are many occasions I am proud of the people I have worked with and I tried to show it. I am sorry if I have not shown this enough! At first I was hesitating, working in another country (in the Netherlands and not in England), but also having a very important customer, we had to be very careful of what we were saying. But I learned to be confident and be vocal! Dare to speak out and say the things my colleagues did well. Speak about the feature they delivered, the code that was written, how well they explained something or organised an event.
I learned to be more and more curious. But also in order to do my job well, I had to understand partly the job of others, thus I started being involved in Pull requests and ask questions. My team-members were always happy to explain, and of course proud to share what they accomplished. If you ever need to learn about something, go for it! Study, search, ask! Do not wait for permission, do not wait for others to include you, 'cause you only restrict yourself. Join that meeting of the java-devs, where they are speaking about ZDD or about Pact Testing, because this is how we learn and how we can be more useful members in the team! Be the change you want to see.
The IFS project and the people in this team that I love and will always be happy to work together again, taught me to be a tester. So what is the role of a tester? As I have learned at the Test bash conference by Maaret, a tester is:
catalyst: a person that sits with others so that things of importance get done.
conscience: that is doing the right thing, that is brave to be vocal.
cheerleader: saying the good news, spreading a positive vibe.
critical thinker: daring to doubt, thinking out of the box, asking right questions, thinking ahead.
I am gonna miss you all. I have learned a lot and I want to thank you for that!
I started in Worth as a back-end developer, but the project I was working on demanded a snr developer and I had to be replaced. At the same time the IFS project needed a tester and thought to give it a try. I wasn't happy that I wouldn't develop anymore, but testing was something new, worth exploring!
And this is how it started, I prepared my environment using my boss' credentials, I didn't even have my own yet, as I had not yet officially joined the team and the customer did not know about me.
By then the testers were the ones running the Acceptance tests for the developers before merging any pull request. So Michael, the tester who guided me in my first steps in Testing, suggested I would join before the end of the sprint, so that I could help out with the PRs, that had to be merged before the "code cut off". And so it began! The last day of a sprint, without even having my own account I joined IFS as a Tester. By that time, the code cut off was always on a Friday, all the last PRs had to get in and then we would merge development to the acceptance branch, run all the acceptance tests and then deploy to the UAT server, smoke test it, and then to production. If all good! If there were tests failing we would have to fix them branching off the acceptance branch. Well that part is still the same with now, 2 years later. The only difference is, that now we can deploy on any day we want, plus the deploy can be done during "normal working hours". By then the infrastructure guys and the testers were staying long Friday evenings for the deploy to happen.
When I first joined IFS the team was huge! Before joining, I was a bit afraid on how is it gonna be working in such a huge team. Will I get to know and work with everybody? Surprisingly, when I joined the IFS team I felt a warm welcome. The team, although its size, felt really as a team. Michael & Ewan gave me their guidance on how to test IFS and this is how it started. But also had great team leads, great communication with the developers, the infrastructure guys, the business analysts, the content and the UX people. Everyone in the team has his own role and is responsible for the job they deliver. But at the same time, they are willing to share their experience, help each other out and learn from one another. We are working together to deliver a project that we are proud of. But in the end, the product we deliver is not the Innovation Funding Service portal, is us; is our team, that we are most proud of. IFS is a safe place where people enjoy working together, learn from each other and improve. And I am very lucky to be part of it.
Very quickly I learned to be a tester, learned from others and in my turn shared this knowledge with many different testers that passed from this project. I started enjoying being a tester, learned to see the project from a different angle. What it means to have less bugs, be more secure, perform adequately when there are many users. But also what is required to be accessible by different people, what it means to be user friendly and how important it is to have the right content.
Then I realised that I became obsessed with my job. This passion about quality and the care for details, in combination with my developing knowledge helped move forward and become good in what I was doing. The project started speaking to me. Yes, speaking! "Click here" or "Try this path, there is a bug", "Try it!", I could hear it saying to me. Have raised lots of tickets! I know it sounds evil, but it is honest to say, that I took pleasure in discovering bugs. Haha!
But it really does not matter how many tickets you raise or how many lines of code you write. (Forgot to say that part of my job, is to write acceptance tests and thus write and maintain this part of the code.) What is important, is to improve the project, to catch issues before they hit production. But also to teach the other team-members to think in a similar way. Help testers improve their testing work, help developers test their code before they deliver it to you, or think along with them while they develop. This way the product becomes more robust.
When you find issues and you move tickets to Done, is productivity. When you enable discussions raising the right questions, or boost things to happen because you are there, then this is called generativity and it is equally or even more important in a tester's job.
And believe it or not, sometimes succeeding more comes from doing less. Don't rush to give the answer, let others discover it. Give the space and the time to enable others to do more.
I've learned that as testers we don't need to only bring sad news, but also good news. I got to work with many people in the team, developers or not. I got to see the job they deliver, but also learn their personal flaws and skills. There are many occasions I am proud of the people I have worked with and I tried to show it. I am sorry if I have not shown this enough! At first I was hesitating, working in another country (in the Netherlands and not in England), but also having a very important customer, we had to be very careful of what we were saying. But I learned to be confident and be vocal! Dare to speak out and say the things my colleagues did well. Speak about the feature they delivered, the code that was written, how well they explained something or organised an event.
I learned to be more and more curious. But also in order to do my job well, I had to understand partly the job of others, thus I started being involved in Pull requests and ask questions. My team-members were always happy to explain, and of course proud to share what they accomplished. If you ever need to learn about something, go for it! Study, search, ask! Do not wait for permission, do not wait for others to include you, 'cause you only restrict yourself. Join that meeting of the java-devs, where they are speaking about ZDD or about Pact Testing, because this is how we learn and how we can be more useful members in the team! Be the change you want to see.
The IFS project and the people in this team that I love and will always be happy to work together again, taught me to be a tester. So what is the role of a tester? As I have learned at the Test bash conference by Maaret, a tester is:
catalyst: a person that sits with others so that things of importance get done.
conscience: that is doing the right thing, that is brave to be vocal.
cheerleader: saying the good news, spreading a positive vibe.
critical thinker: daring to doubt, thinking out of the box, asking right questions, thinking ahead.
I am gonna miss you all. I have learned a lot and I want to thank you for that!
Well said, thoughtful post. We'll miss you too :)
ReplyDeleteDuncan
Enjoyed reading this!
ReplyDelete