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.

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.

Apple is a big reason why I'm here

Where do we find our inspiration? How long will it sit in front of us before we recognize what it is and what the Universe wants us to do?

I want to talk about two specific moments of inspiration that are related.

On June 2nd, 2014 I tuned in to the online stream of Apple's World Wide Developers Conference. For years I try my best to watch Apple announcements and keynotes live and that morning was no exception. This Developers Conference was unique where there was an actual focus on DEVELOPERS.

There was plenty of jargon being thrown around that I wasn't understanding. Instead of tuning out the noise, something stirred inside of me and I was intrigued. The audience gasped when Craig Federighi said "We've used Objective-C for 20 years, and we love it. But we wondered what we could do without the baggage of C."

"We have a new programming language"

I sensed that something important was about to happen. Apple announced Swift and announced soon after that the language was to be open source. The feeling in the room seemed to be electric and it was contagious.

The prospect of Apple creating a tool so powerful and complicated is fascinating to me. Its one thing to create phones, tablets, and computers but it never crossed my mind that you could create a language. Of course looking back its silly that thought had never crossed my mind, where did all of the other programming languages come from? What matters is that it was the first time I wanted to learn one.

Two days ago Tim Cook, CEO of Apple, came to Salt Lake City for a Q&A session hosted by Senator Orrin Hatch. A few years ago I got in an argument with Orrin Hatch about the Patriot Act (he wrote it) but that is neither here nor there. I went to the event and reunited with an old friend who showed me the ways of Apple long ago. I was happy that I had secured a couple tickets because I was on a wait-list for several days.

I was especially interested in Tim's thoughts concerning encryption and the future of augmented reality. He also claimed that Apple isn't interested in being the first to release a product, nor producing the most, but to make the BEST. I like that. Sure Apple's products aren't always the best but you can't argue that there is a significant level of polish to be found in everything they produce.

We may have snuck backstage only to be stopped by one of the Senator's aides. We still had our chance to say hi, shake hands, and my friend had his iphone case signed by Tim Cook in the hall afterwards.

Being in that room with such a large chunk of Utah's tech industry was electrifying. Once again Apple swooped in and inspired me to not just become a developer but to become a GREAT developer. I will carry these moments with me as when I inevitably get frustrated learning this stuff. My friend documented our adventure in his weekly vlog here:

Finally an opportunity to prove myself.

Tomorrow is gonna be big. I'm having my very first training meeting with one of the test automation team leads. There's been a lot of preparation leading up to this and its finally time to start proving myself.

This is a situation that all self-taught programmers eventually face. Spending countless hours of personal time coding through online tutorials, book problems, and side projects will finally culminate to the moment that you can show your stuff to an interviewer and potential employer.

This begs the question: "when am I ready?"

When working through a traditional CS degree these steps are typically a little more straightforward. Go to university, start out in the CS program, apply for internships junior and senior year, and upon graduation start applying for jobs. So what happens if you're 26 years old, have a pre-med bachelors degree, and realize coding is your true passion?

If I had all the answers to this I would be writing a different kind of blog. Maybe when I'm on the other side of this and hacking for a living I'll spell it out for you guys. I'm right in the trenches with you. And full disclosure, I'm not heading into an interview tomorrow. Things are quite as intimidating as that. My company needs more automation engineers that are familiar with the product and that have prior QA experience. I think they'll be a little more forgiving of my shortcomings than an average cold interviewer. But that day is going to come. The day that I walk into a white-boarding interview and answer questions about algorithms and FizzBuzz.

So back to the question that was begged for. When will you be ready? There isn't one answer for everybody but I have a couple thoughts on the matter.

Learn the syntax and the ins and outs of an OOP language. It could be Ruby, Python, C++, Java, Javascript, ect. I chose Python because I've heard its a very beginner friendly language. If you are interested in a certain type of programming career then research which programming language will be the most useful and go with that.

Once you start feeling somewhat comfortable with the syntax start doing side projects. These should start out small and slowly ramp up as you continue to learn how to use new tools and techniques. These side projects and the material they cover will by far be the most important thing prospective employers will see so make sure you take it seriously. Lots of good ideas for side projects can be found HERE.

Take the projects that you are proud of and put together a portfolio, preferably on the website Github.com (more on that in a future post).

Once you've amassed a sizable portfolio focus your attention on interview prep. Interviews in this industry are unlike any other. You will be expected to demonstrate not only your knowledge but your ability to think on your feet under pressure. There are a lot of resources to begin prep. My recommendation (based on very little experience) is working through the book Cracking the Coding Interview.

After some of the more difficult problems become solvable, you're ready to start applying for jobs! Because of the lack of degree and experience you'll want to apply to a lot of them. By a lot I mean dozens every week. You'll get interviews, you'll rock the interview, and you'll lock down the job I just know it!

I'd like to get more in depth on each of these steps as I continue to write in this blog. In the meantime, wish me luck for tomorrow!

OBJECT-ORIENTED PROGRAMMING

Last month I finished The C# Player's Guide. My boss plopped it down on my desk one morning in July. "You'll have to get through this book before you'll start pair testing with the other automation engineers." Challenge accepted, hefe. In about a month I got through each short chapter and came out the other end with a heck of a lot of C# smarts. 

 The first half of the book has a C# syntax flow where everything makes sense and has a clear progression where the last subject builds on the next one. Then thing start getting crazy. What I was surprised from the book was how abstract the concepts were getting. The simple explanations of C# syntax such as variables, classes, methods, and loops gave way to subjects such as inheritance, method and class overloading, aggregation and composition, and interfaces. There was a clear tonal shift and I was having a difficult time imagining the situations I would use the concepts that I was learning without more context.

Part of my issue in reviewing these things is that at the time I though thy were specific to the C# syntax. Boy was I wrong. It turns out that half of this book was reviewing OBJECT ORIENTED PROGRAMMING PRINCIPLES. The examples they gave for each principle was written in C# but could have easily been written in VB.NET, Python, Ruby, C++, Objective-C, ect. Have you ever heard the notion that it's easy to pick up a new programming language after learning your first? It always blew my mind that developers claimed to be applying and accepting offers for positions that required them to write in a language they had no experience in. Now it is starting to click.

I'm kind of embarrassed to admit that I didn't truly understand what object oriented programming meant until a couple weeks ago. I've been familiar with the term for quite some time but I just kind of told myself I had a basic idea of what it means. Boy was I wrong again. 

OOP vs. FP

There are two major methods to programming - object-oriented and functional programming. My little experience has shown that the trend is strongly going in the direction of OOP. Major languages such as Ruby, Python, C++, Java, C#, VB.NET, Swift, Objective-C, are all OOP. Other languages that you may have heard of such as Haskell, Perl, Lisp, and Clojure are used in FP. 

Object-oriented programming is based on "objects" which work as data structures that hold data  in the form of "attributes" and perform actions through code known as "methods". The idea is that users use common parts of the program, however they often work various "instances" of these common parts. Each bank account, user profile, game save, and food order hold common functionality but different data. An object can be created and maintained for each particular situation the user requires. You can begin to see how this  dynamic form of programming can be powerful in the hands of developers.

Functional programming is a different animal but in the end strives to accomplish a lot of the same things as OOP. My understanding of FP at the moment is only what the internet tells me- I've never been hands on with it. Using FP is designing and building the structures and elements of the program by evaluating mathematical functions. FP typically avoids changing-state and mutable data. An example of mutable data is something that can be changed after it is created, such as a password for an online profile or a heart rate tracher on a smart watch. Many consider FP to be a much more procedural and cumbersome coding process.

My bias and lack of knowledge/experience are painfully present in this article. But isn't that beauty of starting out? You'll see me write plenty more about OOP as I continue learning how to make awesome shit with Python, C#, and soon Javascript. Six months from now I'll look back at this post and laugh and I wouldn't fault you for doing the same now.

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