Have you ever felt less respected or leftout as a test engineer ?
A quick peek at our own deeds and a look within.
Are you in the testing field and have ever felt that you or your team is not getting the same connect, respect and priority as the development, product, or other team members? Don’t worry, there are many other people too who are great quality engineers and felt the same way at least once in their professional careers !
First, let’s look at some pointers that will make you realize if there is some basis to your feelings or maybe it is just another misconception of your mind.
- You are not getting authorization permissions for code, dashboards, and tools.
- Your timelines are not prioritized for critical projects.
- Developers are not keen to help or transfer knowledge to you and your team.
- Developers do not take your bugs/reports seriously and make the release without fixing blocker bugs.
- You get the pressure of closing bugs with the reason of technical limitations without any explanation.
- You are not getting responses to your queries from other teams.
- Your suggestions on design, user journeys, and products are turned down immediately.
- You are not getting hiring approvals when the current team is overloaded.
- You are not recognized along with other team members for major releases and launches.
- You overhear other team members even questioning your existence on the team.
If you can relate to at least 2–3 of the above points, then you should definitely go on and read the next section where we discuss the possible reasons for others to have a bias against you or your work.
It is very important to go one level deeper & understand the possible causes of the above bias.
- Nature of the ‘Testing’ role
It is sometimes natural to hate testers given that the prime objective of our existence is to find faults and risks in the developer’s code and system! Also, any blocker bugs found by the testing teams end up delaying the project which frustrates the program and project managers. - Preconceptions in the industry & past experiences
Depending on past experiences, different backgrounds & preconceived notions about the testing and related role, there are different points of view resulting in their varied judgments. - Lack of ownership skills & curiosity to learn
This is the most common reason for this bias. Sometimes, testers become too much dependent on developers for small tasks like capturing logs, changing DB values, validation events, stage deployments, test environment maintenance, etc without having any sort of curiosity to learn these technical hacks and save developers time. This leads to the rightful biases against test engineers stemming from the over-dependence on developers thereby leading to more context switching and frustration at the developer’s end. - Not using facts and data to support our suggestions
Data is the best way to back any suggestion or improvement request made to the product teams. But sometimes it is possible for test engineers to get emotional and develop a deep passion for the product and then raise suggestions or blovker arguements without supporting data or logical facts that could easily hurt other team member’s ego and lead to judgements and miscommunication at work. - Unable to show (market) our work properly
Test teams are sometimes so engrossed in their day to day work duties that they fail to show their work properly to the other teams. Every improvement your team makes in automation, process building, stable releases, etc helps the overall stability and should be shared with development and cross-functional teams in a proper package thereby keeping the trust and required collaboration. - Silo tasks with no collaboration with other teams
Many a times test and automation teams work in silo without any overlap or collaboration with development & product teams, it results in an anti pattern . There is no point in working on processes / automating the tests of a product without understanding your potential users, it is bound to be undervalued and eventually fail.
As per my experience, quality engineers come with a clean slate and no baggage of preconceived respect which in fact is good and can be considered as an opportunity for us to build our own credibility & trust through our work and contribution to the product and project, which ultimately decides our value and worth in overall picture.
I t is difficult to measure ‘quality’ & the efforts put out by quality engineering team so objectively. Try out the below practices to build your role’s credibility and respect-:
- Engineering Productivity
As quality engineers, one of our roles and responsibilities is to improve the existing process and pipelines to increase the engineer’s productivity. Ensure not to waste anyone’s time on redundant tasks & focus on documentation, and KT sessions instead of asking for the same help time and again from your peers. The idea is to respect everyone’s time and receive due respect in return. - Cross Team Collaboration
Don’t run test improvement plans and automation projects in silo mode rather enable collaboration with cross-functional teams for all these efforts. They can provide some extremely valuable inputs for your automation scope and requirements thus helping you not to digress and stay aligned with the common goal. - Knowledge Sessions & Show Your Work
Plan knowledge sessions to introduce other teams & members to testing, its different types, your automation project architecture, infra & pipelines, and the impact that your team’s efforts have created on the overall product’s development lifecycle. This impact can be in terms of stability, velocity, or monitoring depending on your objective. - Talk and Build Relations
Build relationships with your peers and other team members. Sometimes a chat over coffee solves all preconceptions and communication gaps thus building more respect towards each other’s work and contribution. Remember, giving and receiving respect works both ways. - Build a Culture of Quality
Develop a passion for quality and talk about it in smaller groups, meetups, org-level meetings, townhalls and 1–1’s. This mindset is like a seed and takes time to blossom but all the efforts put in is bound to give fruits and flowers in the form of better culture and overall respect for everyone responsible for product’s quality. - Data-oriented approach toward impact analysis
Report the impact of your & team’s efforts with data-oriented facts clearly stating the impact it has brought to the overall business and product metrics. The more we align our tasks and impact analysis to the entire company’s business goals, the better we are bound to be valued and appreciated by the leadership and cross-functional teams. - Trust your work and never underestimate what you are doing
This is the most important advice since respect for your work starts from within. If ‘YOU’ trust testing and what you are doing, you will never accept any such behavior or mindset and point out any disrespectful event with dignity and order. But if you yourself don’t value the power of testing and test engineers, then there is little scope of earning everyone’s respect and being the central character in the tales of successful product launches.
I want to end this discussion on the note of self-worth realization and understanding the value of the contribution made by quality engineers to the overall organization’s success.
By the way, most of the time it is just an illusion and our own sense of insecurities that leads us to feel not equally respected and the solution to our feelings are hidden inside ourselves only.
Connect with me at https://topmate.io/sahil_puri for mock interviews, 1–1 mentoring sessions, SDET role career guidance or a casual chat on testing !
See you next time
Sahil Puri.(Youtube channel , Linkedin)
