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.

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.