As a relatively junior tester, I wanted to share a few of the lessons that I’ve learned so far—the good, the bad, the unique and the likely familiar. So far, I’ve learned more than I could possibly have imagined. It has been a challenging and a very enjoyable roller coaster ride.

I’ve been on two big projects so far. The first project was with one of the UK’s biggest media production companies and the second was with one of the world’s leading event management companies. The way each of these companies approached testing could not have been more different.

Lesson #1:  Team location matters

The first lesson I learned was how the location of the team(s)—i.e. whether they are on the same site or on different sites—can impact communication and project performance. The media company had a huge office, where the teams, which spanned different departments, would be scattered across different floors. Although we worked closely with third-party developers, they were based on the other side of town, which naturally caused a communication barrier. Even though we’d have a conference call once a week for a catch up on defect statuses, new updates and regression packs, it still wasn’t enough. This led to lots of misunderstandings, some defects left outstanding and an eventual delay in the project. Clearly, there was room for improvement in their approach towards testing.

Lesson #2:  Agile helps keep everyone on the same page

The second lesson I learned was how an Agile approach can help testers. In stark contrast to the approach at the media company, the event management company had not only all the testing and development teams under one roof, but also they were taking an Agile approach. We’d have an internal stand up every day to stay focused on daily targets to ensure we achieved our sprint targets. Regular stand-ups were perfect for the team as we could adjust our targets to fit in with any workarounds as unforeseen circumstances can occur. Not only that, it helped us set new targets to tackle new obstacles instead of letting issues or defects cumulate. I was starting to understand and see the benefits of working with Agile. I did my ISTQB course before I joined my first project so the concept of testing was fresh in my mind. But throughout the projects, what I learned in the course became very clear and evident in our day-to-day work.

Lesson #3:  Beware: office politics can play a large role on a project

The third lesson I learned was that office politics can have a surprisingly big impact on the test team. Every project has some unique challenges and some familiar ones, so I suspect many of you will relate to my next story. My team had been doing System Integration Testing for a few years on the Event Management testing project. There was a ‘rival’ team who would always compare their work to ours, who always used our testing results as a way of measuring the standards of their results. The problem with that was they didn’t even know what requirements our tests covered. In other words, they had no clue what we did. One day, the project managers were scolded for delays in the project. This had a knock-on effect for all teams on this project, and this was when the office politics/war began. This rival team decided to claim that they did 80% (!) of our test coverage. Understandably, we were quite fed up with their constant malarkey so we directly challenged them. Eventually, that 80% figure was reduced to 10% test coverage, of which some of those 10% tests weren’t even automated. Needless to say, this dynamic provided an unnecessary distraction from the task at hand.

Lesson #4:  Test automation makes a world of difference

The fourth lesson I learned was that test automation is a smarter, faster, and better way to test. On the media company’s project, I was given the task of executing the regression pack. The third party developers would release the fixed defects along with new updates once every week or two. Only then would we execute the regression pack. I would spend a whole week completing all of the regression manually when it could have taken less than 2 days if automated. Doing each test manually and individually was painstakingly slow. In theory, regression testing should be tackled as often as possible and with automation, that allows you perform regression as often as you want. In comparison, all the tests on the event management test project were automated and we would execute nightly runs. This was a form of regression as after every defect raised or fixed we would follow it up with a nightly run. This practice is so beneficial to the project because it saves time, effort and money while being more thorough.

Both projects had their pros and cons, but overall, they were both good learning experiences for me.  The more variety of experiences I get, the better Test Analyst I’ll become.

Ilyas Yaqub