I recently attended my first software testing conference (Test Leadership Congress in NYC) and it reminded me that in order to continue learning we must share what we know. In the future I hope to write about my first steps into leadership and automation coming from a manual testing role, to share with others progressing in their careers not only my successes but also my failures and what I learned from them.
Note: I will be writing about my experiences at the test leadership congress in a future article in which i’ll speak to the value of volunteering at a professional event as a pathway to understanding quality through the service of others.
Because this is my first story on Medium I thought I would start my journey here by sharing my “Quality as a Culture” talk I gave at the company I work for, Workframe, when I was newly hired.
Quality assurance leaders play a crucial role in business by ensuring that products meet certain standards of quality. They plan, direct or coordinate quality assurance programs and formulate quality control policies. They also work to improve an organization’s efficiency and profitability by reducing waste.
So what does that mean?
Quality assurance’s job is to hold two ideas firmly in their minds at all times. Given infinite possibilities what is the worst thing that can go wrong. Secondly, imagining the software as it could be, on its best day, and formulating strategic initiatives to help make that a reality.
We are advocates for the customers voice during the software build cycle as well as a communications manager ensuring that internal voices are heard and amplified where necessary.
We concern ourselves with the past, the present and the future — attempting to understand where we came from and where we are going. The point of which is to help identify areas of risk to work towards minimizing them.
If we are very good at what we do we also understand that the role of a quality assurance engineer is to understand that no matter how many times we look at code, our biases and assumptions about use patterns will only cover 75% of the applications testing. Maturity in the role means that we recognize this fact and attempt to create feedback mechanisms and software release gates that create ever finer filters through interpersonal communication between teams.
We are naturally curious people, and we love learning all we can about the software and the company to which it belongs. Because that wide breath of knowledge will help us uncover more secrets our software keeps closed off to other people. While there may be no ego in the reporting of a bug, there is great pride in the application of our curiosity on an infinite number of puzzles waiting to be solved. Can we predict user behavior based on information given to us? Can we understand areas of strain with individuals or in the codebase that could use relief through process change, extra focused efforts through automation, or simply offering a helping hand?
In times like these I like to think of quality assurance less as a technical role, though we are required to understand the application of technology in business and engineering, and more as an ambassadorial function.
We are the bridge between technology and people both internally and externally and we understand that quality begins first with the company and then the individual. The game is understanding how each person in a company contributes to its success so that strategic initiatives can be put in place that align individual and company goals, and the steps it takes to get there.
No one person can understand all there is to know about a product because that information is vast and constantly changing, but together we can help to position ourselves and our software as leaders in our industry by the act of collaboration and information sharing as long as we always keep in mind that quality is cultural and with our combined expertise anything is possible