Background
It was a little over a year ago when I embarked on my journey to become a software developer. I knew I wanted to work in this field and I desired to start somewhere so I could grow my skills while in school. Through hard work, and God's direction, I found a local business that was hiring web consultants to help customers create drag-and-drop websites on the company's platform. I loved helping others find solutions when they were struggling with difficult tasks. My desk still has a few gifts on it which were sent by customers as a thank-you for assisting them.
After working a few months as a web consultant, a position in quality assurance opened up. I put in for the opportunity, and after testing and interviewing, I was selected for the promotion in the fall of last year. Since then, I have discovered how much I truly enjoy working with software and creating great products for others to use.
What I Do
As a quality assurance specialist, I have a few different tasks I am responsible for. My company is small enough, that I oversee many tasks by myself, but large enough that there is a large customer basis from all over the world. Sometimes, others in the company assist me with testing large products. In my role, I get to work closely with other teams and assist them when they might need extra help. I am responsible for mostly manual testing of the software before it is released to the production environment. I am not able to share all the details of my job, as it would violate company policy.
My Primary Role
It is my responsibility to be at the center of all of the company teams to ensure a quality product for our customers. However, I work most closely with the developers and designers. I have learned that testing is much easier when I can review the specifications the design team set out for the developers. This helps me locate areas that may be problematic, and communicate issues to the development team. I have also learned that not always can specifications be followed, so sometimes it is best to communicate with the developers about why they crafted an item in a certain way. Thankfully, I work with a great group of people who are alright with challenging one another. A question about why someone took a certain approach is not seen as an insult, but as a learning opportunity that allows us to produce the best product we can.
My second largest role is to respond to issues, or bugs, in the production environment. By way of research and testing, I get to investigate what might be causing the problem, as sometimes the problems are caused by misuse of the product. Other times, there are bugs in the software. It is my role to document these bugs and relay the urgency in which they might need to be fixed to a project manager. For example, it is essential I make sure our customers can receive payments through their websites, as this is the sole source of income for some artists. A day with income can be a huge deal to some of the larger businesses. As a result, a bug in the payment system would likely take priority over all other tasks assigned to the developers.
What I Have Learned
Quality assurance has given me a great advantage in my software engineering studies. Every day, I get to work with the entire lifecycle of software and see it to production. I have learned areas where issues can hide within the software and how to address these issues. I am grateful the developers are willing to take the time to explain why something is malfunctioning. This has helped me improve my projects, grow my knowledge base and adapt to technologies I have not experienced yet.
Here is a list of some of the most important things I have learned so far:
Patience is Key
It can be super easy to overlook a problem if you do not spend time on it. Other times, it can be super easy to make a big deal out of something, when in fact the issue was created by your own doing. Taking the time to slow down and think through problems creates less work for other teams and yourself.
Communication is Needed
Before I even begin testing, I am presented with specifications to assist my testing plan of the software. I have learned that it is essential to ask all the questions I might think of during the specifications meeting to avoid assuming something, and getting it wrong. Even during the testing process, I have learned to be in constant communication with the design team and developers to ensure the software is working as intended.
Test Plans Help You Achieve More, Faster
It is very easy to get lost in the testing process of a major project. When an issue occurs, it is essential to document what triggered the issue. It is difficult to do this if you can't remember the steps you took to get there. Test plans take time at the start, but they are well worth it. I use Google sheets more than anything else to develop my test plans. They allow me to quickly share the plans with others in cases where I need their help. A simple test plan which allows you to jot down testing scenarios as you think of them can be a huge help in uncovering and solving issues.
Be Prepared
There are often times when the developers or one of my supervisors will ask me detailed questions about a bug. It is easiest to explain the issue based on its impact vs priority. An issue may have a low impact (misspelling of the company's name on the home page), but this would be a high-priority issue because misspelling of the name might confuse customers. On the other hand, a high-impact bug might be a button that does not click because it impacts all customers, but it is a low priority because there is another easily accessible button that accomplishes the same task. Explaining issues in this sense helps clarify the urgency in which a bug might need to be fixed.
Screen Recordings are a Must
It is so much easier to remember the specifics about bugs when you can review screen recordings, or screen captures, of the issue. A screen recording helps the developers in that they can view the issue without needing to re-create all the documented steps in the bug task. It also assists in the testing process once a fix has been provided because it can be easy to forget what a bug looked like if you last looked at it a few weeks ago.
Overall
This is just a brief overview of what software quality assurance looks like and some things I have learned. If you are interested in this line of work, I would encourage you to try it out. The work is not physically demanding, but it can be mentally challenging at times. For the most part, quality assurance is very rewarding. It allows you to see your work help others succeed. It is always my goal to do the best I can with testing a product to help lighten the load of others. By helping to produce a quality product. I am learning more than I ever have about software engineering and I am very thankful for my experiences.