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.

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.

What the hell is version control?!

Learning how to code on your own can often be a lonely endeavor. Myself and many others work full time jobs in addition to self-teaching code through tutorials and books on our own time. It often isn't feasible to regularly attend classes or coordinate with others to work through projects.

 I can really only speak for myself but the majority of the small projects I work through to master specific concepts are done by me and only me from start until finish. Because of that I wasn't even aware of the concept of version control until somewhat recently. Once I understood the importance of it I sincerely wish I had covered it earlier on.

The spare time that I devote to coding is with the intention that I will one day (hopefully sooner than later) accept a job as a full-time software engineer. The thing is, the coding I'll be doing as part of a development or test engineer team will vary GREATLY from the practice work that I'm doing now. The key part to that is working as a TEAM. Until now all of the projects that I've completed have only involved one person - ME. When you work as an engineer for a company you typically are not the only person assigned to work on a product. So why does that matter?

If you've learned even a little bit about code you've seen that even small errors can cause HUGE issues in code. Now think about the fact that several different engineers are all simultaneously writing code on the same product. How will your code interact with Joe Schmoe's code? How will you share your code among team members? Are there ways to predict how your code will interact with the rest of the solution before you implement it?

The answer is YES. The answer is VERSION CONTROL.

Modern version control almost always means Git. I was aware of Github and it's uses as a budding developer long before I began to understand how Git itself is actually used. I am not an expert in Git, in fact I've hardly used it professionaly at all, but I would be happy to list some great resources to learn git.

• Lynda.com - Git Essential Training with Kevin Skoglund - This six hour course masterfully explains the history and concepts of Git and provides an excellent example of how it is used
• Codecademy.com - Learn Git - This course is only two hours and focuses more on git workflow
• Github.io - Git Tutorial - Github itself provides a tutorial! Learn at the source!
• Learn Git Branching - My future manager in automation testing recommended this interactive course to become a Git ninja. Seems more interactive than the others.

After delving into some of these resources take a gander at the image below. If it makes some sense to you then you are going in the right direction!

In closing I want to encourage you to begin impletmenting git commands in your projects. I don't care how small the project is or if you are the only person to ever even see it, having these concepts in place will do wonders for you when you finally find yourself working with a team.

"You want a seriously righteous hack... you score one of those Gibsons man." - Cereal Killer

Hackers (1995) is a silly film in a time where hacker culture and computer science thrived only in the fringes of society. It marked the beginning of the Internet Age.

Now it's 2016 and hardly a week goes by without a new headline detailing the latest massive hack. Apple, Google, and Microsoft keynotes announcing new electronic devices, operating systems, and apps dominate the water cooler conversation. Software and computer science are at the center of our progression as a human race. There have never been more resources for us to learn the craft.

My name is Ryan Johns. I am 26 years old and I live in Utah. I graduated last year from Brigham Young University with a BS in Exercise Science. BS is an accurate description of my experience at BYU....but I probably don't need to get into that. When I graduated I had plans to apply to physician assistant programs across the county. I worked in a rural hospital for nearly a year before sending out applications. Over the course of that year, with the intention of cultivating Plan B in case I didn't get accepted to PA school, I began to grow interested in working as a software engineer.

I experienced an awakening like no other over this past year. Instead of dragging my feet towards a career in medicine, I discovered a passion for turning an idea into reality through coding. PA isn't on my radar anymore. Becoming a kickass developer is.

Two months ago my son was born. Our first kid. He is my inspiration and my motivation to get this career on track.


So what have I done? And what am I planning to do? In my spare time I have learned C# and Python programming languages. I landed a job as a QA & Testing Analyst at an insurance software company called Xactware. Currently I'm just a monkey manual tester..... but not for long. I'm training to take the role of Test Automation Engineer. It will be a solid step in my journey towards developer. Then next year, starting January 17th, I'll start a 9 month web developer course + 6 week externship through the MATC, a local technical college in Lehi. The best part is that it is paid for by Xactware. I think that will be exactly what I need to put me over the edge towards developer badassery. To sum things up:

INSPIRATION:

• My Developing Journey Blog - Brian Douglas' story and blog are the direct inspiration for this website.
• Code Newbie Podcast - Excellent podcast that focuses on transitioning into a coding career without a computer science background
• What is Code? - Wonderfully crafted issue of Businessweek written by Paul Ford that covers everything from coder culture to basic understanding and the syntax and structure of code
• AlphaGo and Move 37 - Machine learning went to the next level this year when Google's go playing algorithm beat the sitting world champion, Lee Sedol
• Elon Musk - Tesla, SpaceX, and OpenAI will change the world forever

GOALS:

• Lock down Automation Engineer promotion by the beginning of 2017
• Code for 3 hours every day
• Fill in GitHub repository with diverse side projects
• Complete MATCH Web Developer course in 2017
• Accept offer for full time developer position end of 2017/beginning of 2018
• Hack the planet

RESOURCES

--Finished--

• Python Course on Codecademy - I thought it was meh. Whenever I got to the practice problems I felt pretty lost. Not sure if that was on me or the material
• Automate the Boring Stuff with Python - Fantastic book, great application of the principles and very beginner friendly. The PDF is free online!
• The C# Player's Guide - Extremely beginner-friendly book that is not only great for C# but also great for anyone trying to understand the principles of object-oriented programming
• Lynda.com Git tutorial- excellent tutorial on the basics of git and version control

--On deck--

• Selenium and automation framework tutorials on Pluralsight
• MATC Web Developer Program
• Not to mention the ugly red book that won't fit on a shelf

Don't be mistaken. I'm still a novice. But I want to be accountable and I hope that this blog will be helpful to mark my progress to the internets.