Life as a QA Analyst

What is it like to work as a manual software tester? Well technically my job title is QA & Testing analyst. If you are just getting started in coding or possibly exploring the idea to transition into a programming career it is a good way to get your foot in the door.

As a QA & Testing Analyst I work closely with the developers of an online product. Because we are on a monthly release agile schedule we have a pretty consistent monthly testing cycle. We perform functional testing in the dev environment for new features. We test those same features in the beta environment later on in the month. Finally when release night rolls around we are testing those same features in the product environment until 3am to make sure everything is running smoothly.

Our positions at Xactware don't require us to code or write automated tests. All of the work I have been doing with that has been strictly extracurricular. It seems to me that few startups are offering these positions - they typically expect their QA people to have coding experience with the ability to write automated tests.

I had no experience doing this kind of work before becoming a QA analyst. For the past six months I've learned a great deal of testing principles that I feel will serve me well in my future positions as a developer.

To be completely honest this is one of the least stressful positions I've ever held. It can be a challenge to find defects in the software but I can reassure you - they are there waiting to be found. Our release cycle and the amount of features that we tests as a team has felt very manageable for the last six months. I'm kind of craving a job that will offer more challenge.

Working as a manual tester has given me a great deal of opportunities. It will be a stepping stone to my eventual career in coding. It is not for me in the long term but in the meantime I am super happy I made the jump to QA.

Does anybody here have previous/current QA experience? Do you feel like it helped you achieve your goals? For other QA analysts who decided to make that their career I'd also be interested in hearing your thoughts. Keep the discussion going in the comments below.

Playing around with ASP.NET

I am an aspiring web developer. The last several months I've been learning C# and working my way around the .NET framework in order to get promoted to work as an automation engineer.

Turns out I can get going on the web stuff with my newfound C# skillz! Visual Studio is an excellent tool that isn't very hard to learn and it turns out ASP is built right into it to churn out quality websites.

For those not familiar with ASP.NET let me tell you what it is. It is an open source and server-side web application framework. It is designed for web development and you can make a wide variety of web pages/applications with the various frameworks. This solution comes from Microsoft.

My limited experience learning ASP.NET helped me realize something important. Web development, and development in general often involves taking a framework, adding your components, and tweaking the things that are already there. 

I've often envisioned software development starting out by staring down an empty IDE and building something from scratch. I'm sure many successful projects start out that way. But the many tools at our disposal often build out common parts of our application so we don't have to. Kinda cool!

While building a website I knew that I'd like to give users the ability to create their own accounts with an email and a password. Not only that, I wanted to add an email verification step to the registration process. Turns out all of that is already built into ASP.NET!

MSDN has a lot of resources to help you get up and running. Although a lot of tools are offered, there is a great deal of flexibility in how you would like to build out your web app. Do you want two-step verification? What methods do you want to provide a user to recover their account in case they forget their password?

I'll share the website on here when I'm happy with it. For now, let me drop some of the resources I've been using.

-Get Started with ASP.NET

-Get Started Developing with Visual Studio

- Create a secure ASP.NET Web Forms app with user registration, email confrimation, and password reset 

These are all straight from the source. MSDN is an excellent resource for everything in the .NET framework.

Vidya Gaemz

The year was 1999, I was eight years old, and it was bedtime. My dad was tucking in the sheets when he mentioned "at work we're making a new game console." I had no idea what he was talking about. 

"What is a console?" I asked.

"It's like a new Nintendo." He explained.

My eyes lit up. Instead of demanding the usual bedtime story I unleashed a barrage of questions. I was practically obsessed with my Nintendo 64 and it seemed almost too good to be true that my dad was helping make the next one.

He was talking about the Xbox.My family moved to the Seattle area when my dad took a job at Microsoft in 1995. He opted to join the Xbox team a few years later even when most of his coworkers thought it was a doomed project. He is especially skilled in 3D graphics programming and turns out they use quite a bit of that in vidya gaemz.

Over the next few years I fell in love with not only the Xbox but video games in general. I always held several gaming magazine subscriptions. Every weekend was spent playing Halo split screen with my friends. I was hooked.

Video games are still my passion today. I own a Wii U, Xbox One, and Playstation 4. I'd like to build a high end gaming PC one day. My life changed that night when my dad tucked me into bed.

Why am I sharing this? I honestly think video games are a huge reason why I am interested in programming and learning how to code. Ever since I was little I wondered how developers could bring these characters and stories to life by writing lines of code. 

I've heard discouraging accounts of what it is like to work in the video game industry as a developer and because of that I'm not necessarily interested in pursuing a career there per se. I do have tremendous respect for those who do follow their passion and put in the work to make it happen. I've always looked up to my dad for the really cool work he put in on both the original Xbox and Xbox 360.

How have video games or other forms of media influenced your decision to learn how to code or eventually become a developer? Do any readers currently work in the video games industry? Tell us what it is like.

Thank you vidya gaemz for helping inspire me to learn how to code.

5 Things I Learned From My First Pull Request

Less than a year ago I decided, like many of you, that I wanted to learn how to code. Although I had next to no experience I was determined to learn enough to eventually land a full-time job as a software engineer.

Looking to get my foot in the door in the tech industry I left my job in nursing for a position in manual software testing. Right off the bat I was presented with the opportunity to learn test automation on my own time and eventually earn a promotion to work in a full time coding position as an automation engineer!

In addition to learning my way around Visual Studio, Git, and C# I also worked my way through the Pluralsight course Creating an Automated Testing Framework with Selenium by John Sonmez.

 After finishing the materials recommended by my manager I was free to begin writing tests, updating the testing framework, and submitting pull requests. I had to prove myself in order to get the promotion.

Was I intimidated beyond reason? Maybe.

Without boring you on the details I somehow managed to scrape together six automated tests accompanied by several small framework updates. The time had come to submit my first pull request to the automation team. 

For most teams a pull request is the opportunity for team members to review the code changes in your commit before they are merged into the "master" branch. Others may also call this a code review 

Here are five of the most important things I learned from my first pull request as an aspiring software engineer.

Study your coworkers' commits

When you first start out you'll most likely pull down the "master" branch of code that all of your team is working from. This will include the commits, classes and methods that have already been written. 

This is an extremely valuable resource. Most teams will want to keep most of their code fairly uniform by following the same patterns and best practices.

Before writing a single line of code I meticulously combed through at least a dozen test suites written by the other engineers. It was fairly easy to pick up on how our software tools were commonly used, how the testing framework could be implemented in relation to the the automated tests, and what an average pull request would look like.

Because I studied several examples of code written by more experienced engineers on the automation team I felt much more confident making my own contributions and ultimately submitting my own pull request.

 Keep It Simple Stupid

KISS. And no I don't mean kiss your manager's ass. I learned that when you submit a pull request/code review you are asking other engineers to take the time to thoughtfully read through your code before it is merged with the rest of the product.

When reviewing best practices for the pull request one of the engineers said to me "if I see a scroll bar on your code changes I will send it right back to you". He went on to say that this isn't ALWAYS the case but generally engineers don't want to spend all day reading through a large chunk of your code.

The key to keeping a pull request simple is to keep all code changes somewhat related to each other without too many modifications all at once. Not only will this show that you value your coworkers' time, in addition they will be better able to find bugs and make valuable recommendations for you with less material to review. 

Seek input from more than one engineer

When I first submitted my pull request I received feedback from one individual fairly quickly. He made a minor code change recommendation but other than that he said everything looked pretty solid! I was psyched out of my mind! My code was clean! Nothing could stop me!

I wasn't brought back to earth until a second engineer came along, reviewed my code, and sent me back a LIST of comments pointing out issues and bugs that I hadn't caught on my own.

Without that second pair of eyes I would have possibly merged several code changes that would have caused issues down the road in our product. Not only that but I learned several ways to integrate my code with testing tools that I didn't even know we used.

This is just a wild guess but if you don't get a list of comments tacked on to your first pull request then you are probably not getting the feedback that you need. Either that or you're just the next Kevin Mitnick.

Eat a big slice of humble pie

Did I feel slightly defensive when I first laid eyes on the many comments critiquing my code? I'd be lying to you if I said no. The feeling was fleeting, however.

I learned more in the five minutes it took to read and understand the engineer's suggestions then I learned in the the last day or two of coding on my own. She mentioned tools that I had never heard of that turned out to be extremely important for the tests I wanted to run. 

It's a very human urge to shrink away from criticism. It's hard to put your work out there, especially as a beginner, and open yourself up to the judgments and opinions of your peers. I found some useful advice in John's video Don't Be Afraid To Look Like an Idiot.

You will be served many slices of humble pie. This is a GOOD THING.

DEBUG DEBUG DEBUG

This last part may seem obvious to you but I cannot stress it enough. Test your code before submitting your pull request. You'll most likely pull down the "master" branch of code to merge with your changes before wrapping everything up in a pull request. Test your code at least one more time after that before submitting.

After seeing the suggestions from other engineers to improve my code I was eager to make those changes and commit them as quickly as possible. What I didn't realize is that by making the suggested changes I was causing conflicts with the existing tests I had already written. My tests began to fail after I had already committed the changes.

Whenever you make code changes, even changes that are suggested by more experienced engineers, test your code afterwards to make sure everything is running smoothly. If it's not then adapt as you see fit and don't be afraid to get help.

You've taken your first step into a larger world

Getting through my first pull request was just the beginning. There will be many more to come.

Take my advice with a grain of salt, after all I really only have ONE pull request under my belt, but I sure learned a lot from that experience. Seeing the automation manager eventually approve my pull request was a very satisfying feeling.

Do you have any advice or best practices you'd like to share for new programmers when submitting pull requests or putting up work for code review? Let me know in the comments.

I submitted my first pull request today

This year Xactware turned 30. We've been rocking the insurance software scene for a long time. One of the reasons I initially got my foot in the door at Xactware is because they employ a significant number of manual software testers. No coding experience required. Months ago when I knew that code was my future I began to look around Utah County for manual testing positions so I could get started somewhere. Among all the startups that I perused it seemed that they were only interested in test automation engineers. 

It makes sense why manual testing positions are few and far between. Code written by an automation engineer can do the work of dozens of manual testers in a fraction of the time. Not only is it more efficient but in most cases the test results and feedback are more accurate and beneficial in churning out a better product. 

Just a few years ago Xactware finally started  taking automated testing seriously. Only a month ago we named our first Director of Test Automation. I personally believe that there is no better time to get into automation at this company than right now. Imagine the impact I can leave on the products I'm testing while we are all charting new territory in automation.

From day one I made it clear that I want to work in automation and now the day that I accept that position feels closer than ever. 

I took a huge step towards becoming an automation engineer today. For the last three weeks or so I've been meeting an hour or two every week with one of the test automation managers. He's been really helpful and patient by walking me through the process of writing simple tests and building/updating the testing framework.

I wrote six tests and I added two pages to our testing framework and damn am I proud of that. We managed to get all of these tests to pass and the framework updates and additions I made are solid. After cleaning up the code, pulling down changes from our remote repo, merging my additions with those, and finally pushing everything back up to the remote repo... I was ready to make my first pull request. Pressing that button felt like I had stepped into a new world and it felt good.

I never imagined that just getting my foot in the door of a tech company would afford me so many opportunities or that I would find so many people to help me along the way. If you are interested in learning how to code and eventually making a career out of it consider a manual testing position or something similar. Make your aspiration to move on to bigger and better things from the beginning. Hopefully you will find as many opportunities as I have at Xactware.