Friday, May 29, 2015

My Introductory Rant

Welcome! I'd like to introduce myself and give a bit of background as to why I'm starting this blog, and what I hope to accomplish. My passion for learning new things and asking questions has led me to currently focus around innovation in the Software Quality Engineering realm. I spent a bit of time in manual testing, but then I decided it was boring and tried my hand at automation.

So that is what I am currently trying to master. More specifically, I am trying to master being a mentor to younger SQEs (Software Quality Engineers) , while perfecting my own skills.

So far, I've learned that no matter how technical you think you are, no matter how many mad skills you think you've mastered (in the automation space), there are always things to learn. This is why I'm trying to share my experiences, because people sharing theirs with me, has taught me so much, I'd like to give back.

So Why Should I Continue Reading?
Welp, in this entry, I will talk about why as an automation engineer, you need your developers to speak the same language. Which I believe is an essential base layer requirement for a successful automation team, and successful automation system to exist.

How To Persuade Your Devs That Automated Testing Is Interesting
Easy. SPEAK THE SAME LANGUAGE! What does this mean? Be interested in their domain! In my experience, developers take to testers, if and only if, testers are interested in the development. To me, this was a pre-requisite which regardless of how technically uncomfortable, I had to overcome.

Becoming Technically Apt, from Scratch
I thought to myself, if I am to understand the dev world, I need to immerse myself in it, so I did. I attended code reviews, I wrote high level scripts, and tried to get more experience while achieving my test objectives. Queue the automation. At one of my jobs, even though my devs wrote in C++, and I wrote in VBScript and JavaScript, I educated myself in the tenants of OOP. I took an interest to the nitty gritty details of implementation and slowly became more and more comfortable with the implementation details of the fairly complex architecture of the app we were developing. These activities also had a positive side effect on my manual tests, since I was able to churn out more specific, high value tests. As I started understanding concepts and activities, I also started seeing gaps in my automated scripts and started re-writing them. I noticed that as my scripts became more complicated, I required more troubleshooting help from my devs and we became closer co-workers and started drinking beer and watching hockey together, which was awesome! Through the above activities, I established a relationship with the dev team, which allowed me to pick their brain about automation implementation, and provide me with a deeply technical understanding of the application I was testing.

If The Opportunity To Use The Same Language Exists, Jump On It!
But , as with all good start points, you accelerate quickly and eventually plateau. When I did, I decided I needed a change of scenery and eventually switched jobs.  I remember the first week of my new job. It dawned on me, that the automation which was promised to exist during my interview process did not, and I needed to take the charge on building it. So me being me, I initiated the process. This , I thought was an awesome opportunity to do things "the right way". I did a bit of research, and realized that I had a golden opportunity to establish processes focused around quality, via automation, in the same language as the app was being developed in. I pushed this concept, and although with a bit of resistance to change, was able to convince my team to write our automation in C#, just like our devs were doing for the app we support. This decision turned out to be a great victory for two big reasons. First, we now spoke the same language as the devs, and our entire team could use any of our devs as a resource, and second, there was a great amount of room for improvement of our testing code and approaches. The second point was very evident as I kept evangelizing the automation process, and devs would give their feedback on testing. We were able to build frameworks to support our efforts, and scale the introduction of automation to non-technical team members, which were before the framework, very scared of writing automation. The amount of change we have been able to foster, has been incredible. And I attribute it to the fact that our devs, support automation, since we are both talking C#.

So What? Should I Take Away?
Welp, from my experience so far, if you are a novice tester, or even an experienced tester, a conversation with a dev who wrote the app you working on is invaluable. And what I think you should do, is get on the same page as your dev team, by learning more technical implementation detail, while automating in the same language as it is written in. It just so happens, the last two go hand in hand.

Happy relationship building, and happy automating.

Over and Out.

No comments:

Post a Comment