People of WePay: David Clarke, Director of QA
What is a valuable lesson that you have learned from your career in high-tech startups?
I would say investing in great partnerships and relationships is the foundation of building great test software. Collecting early and frequent feedback about the products you are building is also important not just externally, but internally as well.
The pressures to build and deploy high quality software are significant in a continuous delivery model. Being careful about the product you are building, also means you have to be clear and thoughtful about how you intend to validate and deploy your product. The hard questions to answer are around who will manage it, maintain it, and improve it. Having great partnerships guarantees that you have initial users and a virtuous feedback cycle. Effective collaboration guarantees a virtuous feedback cycle where every contributor understands the the how, what, when, and why of the software being built.
As an engineer, what made you interested in testing versus creating?
What got me interested in testing was my first software engineering role where I was a founding engineer for a desktop application similar to Skype. One of the most memorable moments was when I accidentally took down the whole platform with a small code change. This was a very humbling experience, but one that I definitely learned from. Going forward, I spent a lot of time writing code and finding ways to test the software that I had created. This initial work led me down the path of becoming more proficient in building tests and understanding how to structure them. This got me into testing and I have not made another mistake like that again.
Testing is not just prevention of mistakes, but it is also creation. I have noticed that testing engages both the left and right parts of the brain. You need to be able to imagine a testing infrastructure that will flex / change in the right ways, but at the same time you have to get out into the organization, gather requirements and gather insights about what is important.
For companies working on building a strong quality assurance program, what recommendations would you make? How do you define what your standards are and criteria to consider?
First, you need to identify the purpose of the quality assurance team. If your answer is simply increase release quality, then you need to think deeper. Clearly defining what you want and then hiring great talent are two sure ways to start building a strong quality team.
You need to consider several questions. What are the core parts of the platform that must to work? What are the requirements for software that you ship? How often do you want to ship software?
The quality team at WePay has developed it’s criteria by analyzing our customers workflows. What are the features and functionalities our customers can’t afford to not work? What are the core competencies of your company? Identify what must work, label those as high priority, and begin to step back to understand your platform from a customer’s perspective.
It is clear that you have extensive knowledge on WePay’s product and business. When communicating with internal and external stakeholders, how does your approach to communication differ?
We are constantly in the mindset of our external stakeholders. Quality assurance is their advocate, making sure that they are provided the best solution and making sure that all important questions are addressed before launching a feature.
Internal stakeholders are different because their interests may or may not align with external stakeholders. They may just be trying to get their software out the door. Our job in QA is to paint a bigger picture as to what the customer needs and how that relates to these internal stakeholders.
How exactly do you test and evaluate quality of our product?
The quality team is involved in two sets of actions to test and evaluate the quality of our product. We build testing tools to assist developers in testing their own services independently. These are tools like code coverage, unit testing, static code analysis. We truly believe that by surfacing the best tools to our development team, we can have the greatest effect on the quality of the platform. Secondarily, we test our service as a customer would use our platform, verifying that all of the APIs continue to work as expected. How we evaluate the quality of the product is a matter of matching use cases with our test cases to see where potential gaps might be.
How do you de-escalate a heated or challenging situation?
At the end of the day, the goal is to release the best software for your customers. Aligning around what you are trying to do, instead of arguing over who is going to do it or how it is going to get done is the best way to de-escalate any challenges that you are facing. By creating common goals and teams that are aligned to accomplishing those goals it can help move the ball forward and establish trust.
Can you share an interesting story or example of a flaw you experienced in quality at some point as a consumer or end user?
I think the most fond memory I have of a quality problem is from using the iconic NES game cartridge. The cartridge would degrade with use, and this would make your games unplayable, either the game wouldn’t load (blue screen), or you’d get all kinds of pixels being rendered on the screen.
The interesting part about the quality issue was the different behaviors that it would create. People would of course have the routine of blowing into the cartridge or using cleaning solutions, but it also created far more interesting routines where people were turning on / off the power, hitting the top of the NES gaming system, smacking around the cartridge, all to get the system to work.
None of which I’m sure the original developers expected, but provided some value to the end user to get their system to work.
My takeaway was that you not only have to think about what will happen when things don’t work, but also how do you build good behaviors for your customers when things don’t function as expected.