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
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.