What Did I Learn From My First Year Working as a Quality Assurance Engineer?
The key mindsets that I learned from my first working year.
I started my journey as a Quality Assurance Engineer right after graduating from university. I went through a six-week internship program to finally get my first full-time contract.
Do you know what that means? It means I will be a part of the team that will build real software. I had a mock project experience (that’s what I like to call it), being involved in a project under a senior QA who guided me during my internship. It was tough, fun, and a comfortable experience until one day I was assigned to a real project.
Now I was no longer the intern who could make mistakes. There was a lot at stake. The pressure was real. For the next year, I would go on making a lot of mistakes, repeating them on a lesser scale to finally correcting them, until I finally learned and grew.
I was happy making mistakes in my early stages (though my PM wasn’t), I had the luxury of being guided by some of the best professionals in my company. I got a chance to become better at what I do and the moment I became comfortable at something, I’d either be assigned or myself take something else to push myself. Every problem solved meant an increase in my skill, and the reward was added experience. Mistakes became a necessary setback that helped me move forward once I corrected them.
There are some key mindsets that I learned in my first year as a Quality Assurance which I would like to share.
They are:
- Your primary job is to know how to break the software by any means
- Test frequently, you never know what you might have missed
- Ownership and team spirit is far greater than technical skills
- You are the focal point that connects the business side and tech side
- Connect with the project as an end-user
- You are not going to know everything, just ask
Your primary job is to know how to break the software by any means
We may know all the details around testing but it’s useless until we can break the software. Break it before your users do. Cliched but often underestimated statement. There are times when you need to overdo stuff, don’t be afraid when that time comes. Even if fixing the feature or something else like design may not be immediately required or not required at all, understanding the cases that could potentially happen is necessary.
Breaking a software is not restricted to functionalities or features, the concept applies to the front-end (UI/UX) as well or other elements. The first task I did as a professional tester was design verification. To be able to conduct design verifications, I spent weeks learning design, knowing why something that the user is going to view exists in the first place. Learning design concepts was one of the best achievements of my life, as now I am able to understand how each software component interacts with the user.
Knowing the concepts of design helped me suggest a lot of improvements to the application. As a tester, it should be our primary focus to make sure that the user experience is flawless and that is not just limited to functionalities.
It’s always better to go beyond what you would have actually done while testing an application. There are many things that are covered when you give that extra push. You are challenging every mind that has contributed to building that piece before it comes to your hand and it is up to you to find flaws.
Go beyond what you usually would.
Test frequently, you never know what you might have missed
My first project was a new project, an idea that freshly arrived at our company. I was involved in the design and discovery phase of a project. The application was not that large in size. During our first month, we had created roughly a few pages. Often I would test a feature and once it was okay, I’d continue other works for days. Little did I know that every day some new codes were being pushed and it impacted the previous features of an application.
My testing or rather lack of testing caused something that would later create a negative impact on the project. I’d find the bugs just 1 day before a release and because of that, the developers would have a busy schedule where they would have to both fix the bugs and complete the sprint tasks.
My Project Manager urged me to complete a full testing cycle every day. The software was not that large so I could test it manually in a couple of hours maximum.
With that little change in my schedule, either I’d be finding bugs quickly being able to provide feedback quickly or there would be no bugs which were certainly a win-win. Now, the issues that occurred because of code refactoring were easily identified and our efficiency multiplied.
Testing frequently certainly assists in providing quick feedback. This is the reason automation is preferred in large scale projects.
Ownership and team spirit is far greater than technical skills
This isn’t just restricted to the software testing space. It is universally applicable. Your work and identity are associated with what your team produces at the end of the day not how much tech knowledge you provided to the team.
Technical skill is a must-have but that is something that can be acquired with time. Ownership and teamwork are ethics that require constant practicing only if you put the first step towards it. You polish and nurture them over time.
Having ownership means that if you are assigned a task, you are going to make sure to do it in the best way possible. If you don’t have the skills, you learn them.
One thing my senior, a developer whom I was close with told me about ownership:
“Think of ownership as owning a farm, you plant seeds to it. you make sure the gets everything it needs, water, pesticides. In the end, the effort you put towards the plantation determines the quality of food you will eat later”
Team skill and ownership are the most underrated qualities. In the end, it’s a sense of trust, comfort you provide to the people you work together with.
You are the focal point that connects the business side with the tech
As a QA, you are the pivot point. You know all the requirements. There are specializations in a team each individual with their unique attributes and values they bring to the team.
A project manager/ product manager communicates with the respective stakeholder and brings in the requirements which are to be implemented into a working product, a development team is responsible for implementing it technically and so on.
As a tester, it’s your role to make sure that every aspect ranging from tech to business is fully aligned. We distribute the respective information across the team which encourages healthy communication amongst team members, making sure the information is transparent.
Connect with the project as an end-user
In the world of software, user experience (UX) is the king. As a QA it is our job to not only focus on making sure the functionalities of the software work but also looking at the product from the eyes of a user. Surely, we may not have the background knowledge required for an entirely new domain, but a little effort can certainly pay off well.
You don’t have to be an expert in any domain that you are given, just know enough to have a conversation about it. In the internet era, that should not be difficult. When you view the product as an end-user, you are saving one of the most valuable resources, time. You can then suggest changes.
Learning the domain, getting into the mind of an end-user while using the software is something all the testers should look forward to as a software tester. You will add more value in the long run. We have all used a multitude of software and we know what a good experience looks like. When you see the product from a user perspective, you will notice more than you usually do.
Personally, I am a curious guy. I like to learn different facts about a range of domains. Being a tester gives me the luxury of capitalizing on that hobby. Know that people are not going to support this idea but still do it. I implemented this habit in my testing practices and I was able to provide valid arguments on why an idea I suggested is valuable to the product and how it will impact the users providing a better user experience.
You are never going to know everything anyway, just ask
A team is made up of people, each with their unique roles. Each individual is responsible for bringing a different value to the project. I was trying to learn everything which was frustrating. When we had client calls, our team and the client would come together and discuss what features to build, how the implementation will be, and by when the feature will be delivered.
I used to try and take note of everything. I was forcibly trying to know everything until I hit a brick wall. I literally knew nothing. I discussed it with my project manager. He gave me a suggestion which I implement to this day. I learned to only focus on what’s necessary to me for example the requirements. Trying to learn everything in lengthy meetings would make me go crazy.
It was after then that I noted only the things that were necessary to me and for everything else I just go ask someone who knows it. Regardless of how silly a question may be, it is always good to have answers.
Knowing the key details would only help me leverage my work in the coming days. I would ask the developers how they implemented their codes, how the data is being handled, basically anything related to their expertise. I would ask the designers why something was there the way it is. Either I would get the answers, which helped me learn more, or we would both not know the answer, which was positive. We could ask the client why he wanted it.
Conclusion
It’s been 1 and a half years working as a QA. I am fairly new to this domain. The above tips are something I learned over a period of a year, my first year working as a QA. These are the key mindsets that I am implementing and will continue implementing over the course of my career.
Some of the key takeaways from this article are:
i) As a tester, it’s our job to either break the software and have it fixed or at least know how the software behaves when exposed to a certain scenario.
ii) It is necessary that you test the software frequently to make sure new changes do not impact the software adversely.
iii) Building strong ethics is more important to build trust than strong technical skills. Have a sense of ownership and always be there for the team.
iv) You are the focal point of the project. Ensuring there is harmony amongst the team, making sure everyone is on the same page is something a tester needs to do. Bridging the gap.
v) Think of the project from an end-user perspective. Learn about the domain, its users, and what you offer for a project will skyrocket.
vi) Learning to prioritize what to be involved in and what to divide for your teammates is crucial. Do not hesitate to ask questions for there is always someone who knows something better. Questions in the early stage helps prevent potential casualties.
