Hi! My name is Alex, and I’m from Cincinnati, Ohio. I’ve been a software tester my entire career. I graduated from Miami University in 2008 with a major of Technical & Scientific Communication, which is a fancy way of saying technical writing. I don’t think anyone actually goes to school to be a software tester, but depending on your strengths and skills, it could be a perfect fit. That was certainly the case for me. I already had background in IT from my high school days when I got A+ and iNet+ certified, and I began my college career as a major in Systems Analysis. Even after I switched to Technical Writing, I continued to complement it with various technical courses that taught me databases, programming, and website design. Learning how to write technical information translated perfectly into a career where you need to learn how to use software quickly and be able to write out detailed test cases in order to test that software.
When I came out of college, my first job was with a consulting company called Sogeti. There I worked for several clients including General Electric, Ethicon Endo-Surgery, and Luxottica. After short gigs at GE and EES, I began several years of consulting with Luxottica that propelled my testing career forward. I learned several systems and became an expert with their point of sale software. I wrote manual tests, executed tests, documented and managed defects, helped define QA processes, and was the go-to person for any HP Quality Center questions.
About 4.5 years after starting at Luxottica, a colleague of mine began the QA department for a small local company and asked me to be the second member of that team. I left my consulting gig and helped him create new QA processes, implement tools, and define a new automated testing strategy. This is when I began learning automated testing in earnest with HP Unified Functional Testing (QuickTest Professional). I created a framework consisting of several “components” written in VB Script, which allowed us to run dozens of tests utilizing maintainable scripts. It provided significant coverage of several employee and customer facing websites. I also maintained a rigorous manual testing schedule for Agile and Waterfall projects. I tested websites, APIs, and mobile apps. Eventually, our team grew to 3 total onshore resources and 5 offshore resources. Initially, I only directed the automation activities of the offshore group, but eventually I took over all management responsibilities for the team.
For various reasons, I left that job for a new position for another small local company that created health care billing software. I was responsible for testing an oncology pharmacy product developed in .NET that used a Windows desktop application and a Windows app made for Surface tablets. Working in an Agile environment, I created, executed, and tracked all manual testing with a combination of tools including Jama and YouTrack. I managed my own test environment with Visual Studio, Microsoft SQL, and other tools. For automated testing, that company used SmartBear TestComplete. This was similar to HP UFT, but for the scripting backend you had a choice of several languages. In this case, we chose Python to do our backend scripting. Automating a Windows application was different than automating websites. It was a challenge, but I’m glad I had the opportunity to see how that could be done.
The former colleague of mine that initially pulled me away from my first job to start the QA department came calling again, and I was happy to join him at an education company where we pushed the envelope of automated testing and brought the QA department from an all manual testing shop to a Continuous Integration shop. Here I would help define the automated testing strategy for the entire company based on the work I was doing in my product’s scrum team. I worked on a computer adaptive testing product that was built with a combination of technologies, which included a front-end UI for test configuration, and two APIs for test configuration and test delivery. It was deployed with AWS using technologies such as Docker, S3, and SQS.
I worked very closely with development and devops to create a team centered around quality. My automated testing framework covered all facets of the product. Since the product was mainly written in Java, I integrated my automated testing into the build process the developers already created and wrote all of my tests in Java code. Using Java, Maven, Selenium, REST Assured, and TestNG, I built automated testing suites that had very thorough coverage. If the automated tests passed, we could be sure the product would work correctly with a high degree of certainty. With devops help, we were able to integrate these automated tests into the build and deploy processes. Every time a branch of code was deployed, the automated tests could be run. In some cases, it was required to run. We had a continuous integration setup that would kick in when any commit was done to the main develop branch. Once a commit was detected, a temporary environment would be spun up, the code was deployed to the environment, and the automated tests would be run against that new code. This gave us quick insight into any regression issues, and prevented countless issues that were not obvious during initial manual testing.
I am currently still working at this job. I remain the test lead on the computer adaptive testing product, and have moved in to an additional role within the automation architecture team. In this team, I expect to create solutions that will be utilized by all scrum teams. I will likely focus on training and presenting new QA technology and processes as well. It is a very exciting place to be, and even though we have come so far in such a short time, there is still a whole lot more to do. I hope to share some of what I learn on this site.
So that’s my background! If you are interested in contacting me, please go to the contact page and send me a message. Thanks for reading!