When talking to other testers, I love to hear where they come from and where they are heading to on their testing journeys. Listening to those personal stories I search for similarities I can related to, as well as contrasts I can learn from, getting to know the person better on the same time. In the next couple of posts I want to share some milestones of my personal testing journey with you.
When I suddenly became the tester on my first development team in 2010, I was a bit scared. We were a small startup company so there simply was no other tester anywhere around. No one who could tell me what I should do, or mentor me on my way. I started by checking any related book we had in our small team library. The few I found served at least as a starting point, but weren't as helpful as I wished for. So I proceeded to learn by doing. Started thinking about what I planned to test for the upcoming backlog item, noted my assumptions, compared them with the actual behavior, searched for answers to my open questions, listed other things I wanted to try, talked to the team, retested fixes, and so on. That worked out well enough for the beginning.
Still I felt there's something amiss: My boss advised me that a tester should be independent from the development team. Seated me in another room, separated from all the others. It was a strange situation and I felt left out. To make it even worse, his expectation of an agile workflow was that the dev team implements a release candidate during one sprint and I test it during the following, while the others (surprise, surprise) already work on the next backlog items. I thought this could not be the way to go and searched the internet for advice. And found lots of it!
So I triggered some changes. I quickly moved back to the development team room to work as closely as possible with our programmers. We all agreed to give it a try and have testing integrated within the same sprint. I planned my test cases during sprint planning and discussed them with my team mates upfront, helping us all to a shared understanding. My tasks were on the same board, and a story was not done until it was tested and issues were fixed. As it happened, I was not only responsible for testing, but also for our user documentation. Inspired by an article by Sarah Maddox how technical writing was done the agile way at Atlassian, we also added having updated user documentation to our definition of done.
All in all, we shortened the feedback cycle heavily. But still, I struggled with two points in particular.
First: I had a great team around me. Some colleagues patiently sat with me and explained technical stuff where needed so that I could test things easier. Other colleagues, however, kept telling me that I would not need to know about technical details, so why wasting time? As I saw that the shared knowledge helped me a lot with testing, I learned that I always have to check myself what I need and what not. The same applied for being invited to meetings. When I hear someone telling me today that I don't need X or don't need to do Y, or don't need to attend Z; it makes me sit up wide awake. Mostly this is exactly what I need to help my testing!
Second: Our regression tests were only manual at that time (besides some unit tests). So to have a potentially shippable product at the end of our two week sprints we reserved the last two days for regression testing, finalizing documentation, etc. Guess what happened: Our programmers got bored and continued working on new things which introduced a bottleneck in the next sprint as they were (again) going faster than the rest of the workflow. With the rest being me, taking care about both regression testing and finalizing our documentation. This was the time when I got hold of the well-known and invaluable classic "Agile Testing" book by Lisa Crispin and Janet Gregory. And they advised: Share the pain. Have the whole team feel responsible for quality. So I convinced the developers to share the manual regression tests with me. You probably heard people saying: You ask a developer to do the same thing twice and he will automate it? Yep, that's exactly what happened, heavily shortening our manual regression test duration.
As a team, we learned a lot more besides that. We learned to heavily inspect and adapt our collaboration. We got a first notion of what agile is all about. We also learned what financial safety means. In the end, our startup didn't make it; though our product had great potential, there was no market for us. But personally, I took a lot from these exciting roller coaster years with me, getting started on my testing journey.
No comments:
Post a Comment