How applying to another company made me a better tester
I always say that a good professional has to be always in the market. Has to understand how the industry is shifting, what other companies are looking for, the new roles that are emerging and think about your career. Obviously, during the process, you start questioning if your current role is the one you really like, and usually apply to a position that better fits your current needs and expertise. In this case, I applied for my dream position but got a negative response during one of the last steps. But we are not here to talk about my failure now, so let’s focus on why the experience made me a better tester for my employer at that moment instead.
So, at that point, I just stopped fearing at my workplace. I started being honest when I don’t share the decision, openly giving feedback no matter where it comes from. I started saying no when I get asked to do something that I don’t see value on, explaining to them why that other approach would be better. I spent loads of my spare time reading and learning, trying new experimental (new for me) approaches in any area I wasn’t comfortable with the results. I started giving me the luxury of going bold spending the time doing what I think would deliver better results (I.e. getting involved with the user testing, UX designs, etc.). It has been a time of high risk and high gain so far. I made the assumption that I’m here because of my skills and my knowledge, so I don’t have to convince anyone prior to taking an action as long as I think it’d improve our processes, product or moral.
One of the examples is saying no when I was asked to automate every piece of testing for our GUI. I’m a Software Developer in Test, I believe that automation (or how I prefer to call it, software tools for testing as described by James Bach) allows to enhances quality in lots of ways, for example providing an exhaustive safety net to prevent regressions while building an extensively updated documentation; but, at that time and with that team, only focusing on automation wasn’t going to give us the value we needed. Instead, I focused my efforts on building a minimum GUI automated checking suite, while spending the rest of the time giving feedback on the product prior to the release through exploratory testing session, an informal way to centralise and share it (a Google Sheet instead of the usual Jira bug tracking), pairing with the developers doing a quick demo after the feature was done and involving everyone who volunteered (ranging from designers, stakeholders, operations..) to give feedback about the features, experience and suggestions (using myself as a hub to deal with duplicated feedback, fixes already on the pipeline and reducing noise). I would have never tried this if I wasn’t spent some time on the recruitment process learning about exploratory testing, if I still feared to say no or if I didn’t question my expertise considering areas outside automation.
Other areas where I feel it affected my job was dealing differently with each team, considering in each situation how should I approach the Quality. Previously, I tried to standardise how the company deals with Quality, but every small development team had different levels of involvement with Quality and my energies (as the only QA) were limited; so I found way more valuable to trust the approach of the ones who already see quality as part of their deliverable and dive deeper in the cases where changes were needed. In some cases, it only took the time of slightly changing the output for a cleaner reporting, reviewing their progress and offering consultancy and guidance; using the majority of my time addressing processes and assessing the Quality of the deliverables for the teams who needed more help.
This situation taught me that working in an open environment where you don’t fear about being questioned about your decisions (either if it’s because the company culture, or because you stop fearing to be fired) makes me a better professional, especially a better tester. For me, tester’s duties consist on questioning every process and methodology in order to change them to delivering higher quality products, hopefully leveraging the development process during the journey.
I was in a recruitment process because I felt that opportunity would be more enjoyable and enlightening. That mean I needed to either change how I was working to enjoy it more and learn as much as I could, or get sacked because stakeholders didn’t like the new approach. Either way sounded like a win for me.
May the force be with you, Gino