Since a young child I have always been fascinated by computers and software. I always wanted to learn how to create programs and code but for a long time I did not know where to even begin. The advent of the internet and a dialup modem in my house led to a long term fascination with technology and a mind tuned to debugging issues and problem solving around flaws in software. I did not imagine that I would truly end up in software. Through a series of lucky events that led me to a wonderful marketing company in San Diego that gave me an amazing opportunity to take part in their software process.
Internet Matrix gave me the opportunity to take on the role of a Quality Assurance Engineer. At that point I learned that the role of the Quality Engineer is defined by the needs of the software development team and the skills of the quality engineer. When I first began my role I delved into as much automation as I could grapple with. There are multiple jobs that the Quality Engineer can fulfill and depending on the needs of the team this could range greatly. Feedback is the greatest responsibility for the Quality Engineer to deliver to Software Engineers. QE's have a singular role in understanding the big picture of where new features reside in the ecosystem of the business domain. Parsing, clarifying, and negotiating with product owners as to what is truly required for a product to be delivered to the customer. Ultimately everyone wants to end the iteration knowing that they all worked as hard as possible on working on the correct features that provide the most value.
The QE can provide that feedback anywhere along the process of software development from planning all the way to deployment of that new feature to production. The QE role is vastly underrated and misunderstood by software developers and oftentimes stakeholders in the organization. One of the biggest misconceptions is that QE's can only ever be QE's and never cross over into a development role. The QE role is a generalist/utility player and depending on their skills can excel in whatever area that they choose to focus on. Some teams benefit from QE leadership that has a strong alignment with the business domain and understanding of how new features affect process and flow of the mountains of existing process and flow. Other QE focus on broad software development knowledge, practices, test automation, task automation, and being that ace up the sleeve that can push the team's iteration over the finishline.
I struggle to recommend anyone advice on how to be successful as a QE that is not general career advice. Be easy to work with, focus on what's the biggest impact you can contribute at the time with your team, look for ways to suprise and encourage others, lead even if you're not THE leader, and communicate with your team members. Shadowing is a tough thing to do as well. Oftentimes I look back at successful iterations and think that the discussions were more valuable than the test code written.
One huge area of impact that QE's can implement is the creation of software tools. Oftentimes software developers feel constrained with the demands of the business. There is limited time and the business wants to prioritize their time on the biggest impacts to the business. While software developers want to make their processes smoother they skip making great tools to serve their needs. QE's can listen to the needs of their developers, product owners, or other roles and find a project that they have the freedom and latitude to complete and provide a huge impact to their team and their business.
The majority of software development is a team effort and communication is key to being successful. Unfortunately, bugs, flaws, and mistakes are a fact in the software development process. We might have hundreds of automated tests, static analyzers, load tests, and still we made the wrong feature. Or the team had the wrong assumptions or the communication broke down in the development of the infrastructure. As long as QE's are there every step of the way coaching and encouraging the team to keep making progress and delivering small quality features teams can be more successful incrementally. There will always be challenges at every level but if we can encourage that person on the team that brings a questioning and critical eye to a project the team and feature can only be better for it.
Top comments (1)
It is interesting you mentioned developers being constrained by business needs. I find that in QA writing scripts and programs to help you do your job is just part of the job, it is unfortunate that is not the case for development so often.