This article was originally written for Testing Circus magazine and was first published on page 29 in the September 2014 edition and can also be found here.

A few years into my career as a Professional Software Tester, I had been working at a company with some great people in a nice, outgoing, dynamic environment as a software tester on the test team – a team of about 6 people. I enjoyed what I did and even back then, I was a tester who was always looking to learn new things and make myself a better, more skilled tester. One day, my manager at the time approached me about an opportunity he had recommended me for – it was an opportunity to be a part of the Research & Development team at the company as the software tester. I had built a good reputation on the team I had started on and amongst some of the other teams and individuals at the company. He also believed that I needed a new challenge at the company, and I believed that as well. As it turned out, it was an excellent challenge for me. He mentioned that I would be learning a lot, things that would really enhance my technical knowledge as a software tester and that it would only help my career, an assessment I agreed with as well. I took a few days to think it over, after which I made the decision to accept the opportunity to join the R&D team. At the time I knew it was a decision that would eventually be great for my career and towards my goal be being a better, more technical, and a more skilled tester. Little did I know then what I know now, that my decision to join the team would have a tremendous positive impact on my career as a professional software tester. I was under a lot of pressure (most of it from myself), and the learning curve I faced was steep. Things didn’t go smoothly right off the bat, it was actually quite rough in the beginning, but as I continuously put in the work and effort, things got smoother and from there, things went great.

Joining a team of Developers

They were now my team & I was a part of theirs. Now for the first time in my career, I was a member of a team with no other software testers on it. Instead, the members of my team were primarily composed of developers, a scrum master, and a product owner (we worked within an Agile Scrum software development framework). This was a big adjustment for me. I had never worked on a team surrounded by people who weren’t software testers. I no longer had a test manager (or a test coordinator) presenting my test results and findings to stakeholders, I was doing it myself. On the same account, if a development manager or lead wasn’t in favour of information I had found, I no longer had a test manager to “shield” me in this type of situation. The “safety net” of being around and on a team full of testers, was gone. This was one of the best things to happen, it allowed me to grow as a tester and as a professional. There was a lot more responsibility on my plate now, but I saw it as a lot more opportunity.

I wanted to show & prove to them that I was there to make them look good. The developers I was now working with, my new team members, had never directly worked with me before. It seemed that they weren’t yet sure if I was going to be an obstacle for them or if I was going to contribute to the team. I wasn’t there to cause chaos for the developers, nor to waste their time having them read through tons of bug reports I had logged into the bug tracking tool. I wasn’t there to point out and glorify bugs I discovered due to coding. I wasn’t there to slow things down or get in the way of deadlines. I was there to make them look good – but it wasn’t enough for me to just say that to myself, or even say it to them. I had to show them and prove it to them. Over the course of a few months (and tons of work and effort) I did, but it took a lot time and a lot of learning.

Worked with them, and took the time to learn

I showed them that not only was I willing to work with them, but that I genuinely wanted to work with them and that I wanted to learn. I had a lot of energy and was really up to that task and I wanted them to see that. I spoke to the technical lead on the team and got his feedback about how I could approach the different developers and how I could become a valuable and contributing member of the team. He offered his insights, after which I thought about his recommendations and how I was going to go about putting my plan into action.

I wanted to learn more about the different components that made up the system that the team built from the ground up and continued to do development & testing work on. I asked the developers questions about the different components and how they were all integrated together, the data and information flows, and in which ways they were independent from and dependent on each other. When the developers took time to explain these things to me, I always made sure to take notes. I informed them that I would be taking notes so that I could review them later to better understand and so that I wouldn’t need to ask them the same questions again. I made it a point to review the notes towards the end of the day, or even on my way home which sometimes prompted me to ask further clarifying questions. One thing I found extremely useful when they explained things to me using the whiteboard, was to draw out the diagrams of components, flows, and business logic, and other important information. I always made sure to re-draw the contents of the whiteboard or even take a picture of it. This was one of the most useful techniques that helped me the most when I first joined the team, to be able to understand the technicalities and interactions between the different system components. It enabled me to ask better questions about the implications and risks of the development work being done. I was able to think of potential problems or things nobody had yet thought of within the system when discussing the development & testing efforts of new features. I was able to design my tests better, and do more effective testing because of the knowledge I obtained regarding the components, and the information and data flows between them. As a result, I was able to focus my testing and coverage, which enabled me to provide more valuable information from the testing I was doing, in the available time I had to test.

A lot of times when I was providing information about the behaviours I was seeing during my testing, the developers would access the linux server to check system and error logs to get more information on what was happening. I took a lot interest in this as I was curious and wanted to see how they were further investigating what I was telling them from my testing. One day, one of the developers asked me if I had an SSH client on my machine and the accesses to log into the server myself. I was able to install an SSH client and get information on the accesses and permissions I would need to log into the server. Once I had what I needed, the developer took some time and explained the directory structures to me, and where some of the logs and files were located. They showed me commands I could use and how to use specific search commands to follow, and apply filters on for specific keywords I was looking for within the log files. I wrote down the directory structures, and the different linux commands they were using. It took me some time to get more comfortable navigating the different directories and using the different commands, but as I used them more regularly, and was able to find the information I was looking for, logging into the server to further investigate during testing, become one of my favourite skills to use from my arsenal. I was able to quickly and better investigate the causes of some of the behaviours I was seeing, and provide this detailed level of information back to the developers, who in turn were able to use the detailed information and quickly correct pieces of the code, or components where the problems originated from. The understanding of the linux server logs, in the context of our system allowed me to further investigate during testing and allowed the developers to focus on their development and less time investigating causes of some bugs and troubleshooting abnormal behaviours.

Pair Testing

My team and I worked in an open space concept, and in an open communication style atmosphere. As the developers and I got to know each other better, and got to know each others working styles better, they occasionally asked me to log into their local machines so that we could do some testing on new development items or bug fixes before they would commit their code and deploy to our development and test environments. I enjoyed this activity, it allowed for quick feedback and also saved us time instead of having to deploy, test, fix, re-deploy and test again later.

Other times, while testing and continuously providing quick, regular feedback (this was how we worked) the developers would come over to my desk, and we would test new features, existing features, and potentially impacted features together. This allowed us to look at the application or features we were testing from different perspectives and helped us identify and find bugs or the particular types of information we were looking for depending on our testing focus at the time. It was also fun and productive as one persons thought process often led to great test ideas from the other.

There was one developer in particular whom I tested with, at his machine without the use of any UI or tool, but rather by looking at his code. This was actually one of his ideas (an awesome idea), and it allowed me to contribute to the development efforts in an entirely new way. We would chat about what the code was meant to do and for which feature we were developing and testing, and we would go through the different code statements, conditions and branches and work together to think about which logic was covered, where and which cases were accounted for in the code, and work together to brainstorm and identify cases which possibly were not covered. This was an entirely new way for me (at the time) to be able to use my testing mindset and perspective to work together with a developer.

How I said things

Early on in my career, I often saw some (a small number) software testers approaching and informing developers that they had found some bugs in the application, in a tone and with a facial expression reminiscent of a smirk, as if they were bragging and shoving the fact that they found bugs due to coding, in the face of developers. I never quite understood this, nor grasped the concept. Furthermore, I remember seeing the faces and reactions of the developers and understood the animosity between developers and testers in some companies on some teams. I knew just from witnessing this, that I never wanted to be one of these testers (and for the record, the vast majority of the testers Iʼve worked with did not do this). I paid extra attention to the words I used, how I used them, and the tone in which I used them.

I never walked up to any of the developers with a smirk on my face and said something along the lines of “Hey Iʼve found some bugs in the application and broke your code”. I respected software and developers way too much. I considered the working and communication style on our team (open communication with a focus on quick and regular feedback) so that when I found bugs or something not working “correctly” I would always try to find as much information I could supporting the behaviour I was seeing regarding the bug and its extent. I made it a point to always tell the developers I was working with, in an informal way, and offering for them to come take a look at my observations at my machine. Depending on what the behaviour was that I was observing, and in which component it was likely taking place in, I often asked the developers if they had committed and deployed the code for that specific component or feature yet. I also learned the check in, check out and deployment process and system we used, therefore I would also go check myself at times. The point was, I was always communicating in an open manner and in a non-threatening tone. I focused on communicating in a helpful manner, for example, “Hey can we look into this a little further because something doesn’t seem right”.

I also learned when to bring things up. We worked in an Agile Scrum development framework, therefore I made sure I was always explicit (yet respectful) in my updates. If there was an issue I had discovered that would require some additional time (more time than usual) for the developer to come to my machine so that I could show them my findings, along with supporting information from my investigation, I would mention it in the morning stand up and ask a timeframe in the day that we (together) could look into it further. I think this showed the team that I wasn’t just finding bugs, reporting them and cleaning my hands of them – but that I wanted take the time to show them, and work with them to resolve them. If there was a discussion I had with a developer the previous day, and I was still unsure of the outcome of the discussion because it still somewhat contradicted my understanding, I would bring it up at the morning stand up (so that it could be brought to the attention of the correct people to be taken offline). I would explain my initial understanding and where the contradiction still remained based on what was discussed. This helped with transparency and for the whole team to chime in, and open up the discussion to determine if we were indeed all on the same page with the same understanding. In some cases we discovered that understanding on some things weren’t completely unanimous. Most importantly, it didn’t attempt to put anybody on blast. The approach I used in my communication with the team helped me become a welcome member of the team, and be recognized as contributing member and team player.

Got to know them

Just as I was extremely passionate about Software Testing and was always looking to enhance my skills, the developers on my team were equally passionate about Development. Over time, the understanding of being truly passionate about oneʼs craft allowed us to have an even better understanding and respect for what the other did.

What they believed in and practiced as Developers

Some of the things I spoke about to the developers on my team were their backgrounds as developers, where their interest in software and development stemmed from, how they got started and what they believed in and practiced as professional developers. It was interesting to hear the types of systems that they had helped develop before they had started working at the company we worked at, what types of industries they had worked in, what coding related work they did on their own time, and how they were increasing their knowledge and skill level. I had numerous discussions with them about their thoughts on information technology and software, this made for great and very insightful conversations. What made the conversations even more interesting was the fact that my discussions with each of the developers was different with each individual given the fact that their interests, backgrounds, coding they did outside of work were unique. Over time this led to a friendship between myself and each of the developers, unique friendships (that exist to this day even though we donʼt work together anymore).

Going out for lunches

From time to time I also went out to lunch with the developers on my team, often on a one to one basis. This allowed us to informally chat about the projects, the user stories and features we were working on, different partners we were working with and how that was going, as well as technical implications and decisions. This gave us a chance to brainstorm about the aforementioned topics and get into deep discussions about them. If the lunch was with the technical leads on the team, they always made sure to ask about my feedback for testing matters, and again that led to great informal discussions regarding testing matters in the context of our team. Over time working with the team, and the manner in which I did, focusing on integrating myself as a valuable and contributing member of the team and taking the time to get to know the developers, helped me build credibility (within the team) and build a great trust level amongst the members of the team – all of which helped us run like a well oiled machine and at the same time, having fun learning from each other and working together.

Final Thoughts

As I mentioned at the beginning of this article, I knew this would be a great opportunity for me to accept, but little did I know how great the opportunity would actually turn out to be, considering the amazing impact it ended up having for me as a professional and as a software tester. The things I learned, both on the technical and software side, as well engaging with and working on a team with individuals who were not just software testers, was superb. The experience was invaluable – to this day one of the greatest work experiences of my career so far.

I have worked at different companies, and on different projects with different teams and different developers under different conditions. At my current place of employment, I work very closely on projects with both software testers and developers, and have a great working rapport with both my fellow software testers and with the developers. I use many of the things I learned and applied in my experiences, on a daily basis, and encourage other testers on my team to do the same (I try to tell different testers in different ways as everybody has their own style). At my current place of employment the efforts have led to a cooperative, productive, and fun working environment. My efforts have also been recognized by others. Iʼve been told by my managers that the developers on the projects I work on enjoy working with me, given my testing skill, and how I engage them throughout the projects we work on together.

Working well with talented teams composed of individuals in different roles, focused on different activities is extremely important as companies are slowly starting to realize that testing isnʼt something that should be done alone, or after development is complete, but rather that testing is actually an important and valuable activity that goes hand in hand with development. As this becomes more common, it will be important for software testers to evolve and learn to enhance their skills and how they work with other members of the team – and I donʼt mean just other software testers.