One thing I am commonly asked, both by technically and non-technically skilled people, is exactly what I do at my job. First of all, I’d like to take a side note and say that I do not typically talk about my job on my open blog. However, I am not specifically talking about my employer per se; but rather, I am talking about my own skills and what I do and a daily or weekly basis.
Officially speaking, my job title is unfortunately named “SQA Engineer”. As many other professionals in information technology, my title does not accurately describe what I do. My job title would be more accurate if it were “Test Automation Engineer”; however, even that title may be inadequate. When people think of the title “SQA Engineer” (that is to say “Software Quality Assurance” Engineer), they think of someone who does just that: ensures the quality of software. Someone with the title “SQA Engineer” frequently writes and execute tests on a given piece of developed or partially-developed software. When you think of “SQA Engineer”, you typically do not think of someone who has computer programming skills. “Test Automation Engineer”, on the other hand, typically refers to someone who takes already-written test cases and automates them. That is to say, one or many people have been manually clicking through an application to ensure it isn’t broken; the automation guy typically uses record-and-play tools to automate that manual process. A “Test Automation Engineer” may have little or no programming skills at all.
I say “unfortunately named ‘SQA Engineer'” because, as I say, it does not properly describe what I do or the type of experience I am getting. It does not describe who I am, and I worry that it may lump me into a specific subfield, and future prospective employers won’t consider me for other types of jobs based on their assumptions about my experiences. I want to spell out exactly what I do here.
I do spend the vast majority of my day programming
The first and most important thing I’d like to spell out clearly is that I spend the majority of my work day writing code. Not spaghetti code in some product-specific funky-script, but well-documented object-oriented code in actual high-level programming languages. Although I do have record-and-play tools to use at my discretion, other than learning how to use these tools, I have never used them in actual practice. I write and maintain tens of thousands of lines of code that tie together multiple automation tools into an all-in-one automation framework that can operate across multiple applications and platforms. The majority of this code is written in Java; it also includes a amounts of Perl, C, C++, and C# code. I’ve even written some Objective-C code and done some web programming.
I maintain a framework that uses a number of tools and libraries
As I said, most of my code is written in Java. The framework I use primarily runs inside Eclipse and/or IBM Rational Functional Tester, but not exclusively. The majority of the framework is not coupled with RFT and instead uses pure Java and external JARs. I tie in other automation tools that better suit automation of other platforms, such as .NET and mobile devices. The framework also makes use of .NET Framework UI Automation. DLLs are written in MS Visual Studio and utilized within the framework. In additional to automation tools, I also use pure C and C++ to automate using windows.h. Mind you, all these tools and libraries are tied into the same framework which I maintain.
I work closely with other groups
The typical “Test Automation Engineer” just receives specific tests from a manual tester and automates them. This is not my primary purpose. In fact, I have frequently been the only tester on entire applications working only with developers. This means that I myself have had to become familiar with the application, develop my own test cases, manually test, and write automation. However, for the most part, my purpose is to write the framework, which provides easy to use methods for anyone to write and execute their own automation, without programming or automation knowledge. It might be me, a QA person, a developer, a business analyst, or even offshore groups. The point is that my time is best spent writing code and being creative, while someone else can actually write the steps used in the automation. I teach these people how to use the tools I write and assist them when needed.
I do create GUIs
The person who actually schedules and runs the applications (sometimes me, but usually someone else) receives an graphical user interface from me, so that they can select what automation they want to run, when, and where.
I have also written mobile launchers that allow me to start automation right from my mobile phone over 3G.
I write distributed systems and maintain computer labs
Where does the automation actually run? Usually not on my clients’ machines. I set up and maintain physical and/or virtual computer labs that automation runs on (think disk cloning). I use tools such as VirtualBox and VMWare to build these computers, and I maintain physical boxes. The clients’ machine running the GUI and the machine(s) running the automation are all tied together with distributed programming, usually written in Java RMI.
I generate reports and live feedback
I have heard it said that “automation does test anything unless you create checkpoints”. This statement is not true in the framework. Every single possible action in the framework has some sort of PASS, WARN, INFO, or FAIL conditions. No checkpoints are necessary, but can be added if they are wanted. I do not use the reporting tools included in the automation tools. Instead, I program my own reporting system. The reporting system provides feedback on every single action performed during automation. If something did not pass, it may explain why and provides a screen-shot or even a video capture of exactly what happened. This information is provided to the user in different ways, depending on the desires of my clients. The most common way is email/web. My automation framework generates email reports and also uploads web reports and attachments to web servers that we also maintain. I also provide live feedback to the client while the automation is running, in the form of RMI test prints, VNC views, and even feedback sent to mobile phones. The client can stop or check what the machine is doing right from the GUI, without having to log into the automation machine itself.
I do work with database systems
I frequently write SQL queries into my automation for data verification and environment cleaning purposes. A number of different database systems have been used, depending on the application.
I do lots of research
I like to stay versed on the technologies I may have to test. This means I do reading and tutorials on technologies I may use in the future (Flex, HTML5, mobile operating systems, etc). I like to know about these technologies, not just what I need to know to automate them.
I don’t just automate for testing
Most of the automation I have written has been for testing purposes, but not solely. I have also written automation for other purposes. For example, I have written automation to pull thousands of documents from a web server that we had no direct access to. Automation is not just for testing, after all.
I don’t just sit around after work, and this isn’t the first job I’ve ever had
Of course, I do want to point out that even though this is my first full-time job, before this, I was in school for six years getting a bachelors and masters degree. I didn’t go to school to learn to be a tester, and in fact, I never did any sort of application testing while I was in school. I jumped into testing and was writing automation code within a week. In graduate school, I was hacking kernel code, writing my own programming languages and compilers, writing distributed and parallel code, and exercising process schedulers. So, I’d like to say that “SQA Engineer” in no way summarizes my skills and experience as a Computer Scientist.
I also spent four years as a part-time computer support specialist. I was building computer labs, maintaining computers, consulting and advising, setting up peripherals, building networks, removing malware… on and on.
I use Linux, MacOSX, and Windows frequently (and I’ve used other operating systems, as well). I have maintained a personal website, and designed and created websites for some other organizations for over 10 years. I am fluent in web programming (LAMP); I use PHP, Perl, MySQL, JavaScript, CSS, HTML with ease. And I am fluent in a long list of FOSS applications.
I may even have some skills outside Computer Science. I have a good knowledge of Mathematics and Statistics. I am well versed in the latest goings-on in the Medical Informatics field. I am also an Amateur Astronomer, and I hopefully have some knowledge there. Lastly, I am a musician, although unfortunately a bit out of practice currently (but stay tuned).
So in summary, “SQA Engineer” isn’t who I am. It’s just what’s listed on my paystubs.