Quality Assurance at AppFolio Property Manager 2021

QA-logo.png

An AppFolio engineering team typically consists of three to five software engineers, a product manager, a UX designer, and a QA engineer. Within our agile-based teams, the QA Engineer is in a unique position. The QA engineer can have a wide range of experience across different domains due to the cross-functional responsibilities that the role requires. Depending on the team and situation, the role’s breadth of knowledge overlaps with the product expert, voice of the customer, developer, product manager, agile coach, scrum master, customer support, and site reliability engineer. Within AppFolio Property Manager (APM), a QA Engineer has the potential to impact their teams much more than in an organization where the QA roles are specialized as a Software Tester, Automation Engineer, or QA Analyst. Great people make a great company is one of our company values and keys to continued success, and it works best when a QA Engineer can contribute as a generalist.

In many organizations the definition of QA Engineer defaults to Tester with distinct spots where they contribute to the development process. They find bugs. They wait for discovery and discussions to happen first. They wait for UX designers to create their mockups and prototypes. They wait for the product manager to decide the features and the team to provide the acceptance criteria. They wait for software engineers to write the code. They wait for their turn in the product development process. They wait for the work to come to them. At AppFolio, we prefer to have the entire team collaborate throughout the product development process with QA Engineers on the team promoting the quality mindset from discovery and design through supporting production applications. 

While quality assurance at other software companies can operate with a singular testing focus, AppFolio’s entire product development process involves QA Engineers. Quality assurance is not an end of the assembly line task for us, it demands constant questioning, discussion, and considerations throughout each sprint. Quality is always at the forefront of the QA Engineer’s mind, not only during the testing phase. We look for curious and creative individuals with diverse backgrounds and problem-solving abilities, knowing that they will influence and shape our product development process and idea of quality. When it comes to maintaining quality in our engineering organization, our QA Engineers’ domains for quality should pertain to teams, processes, testing, and people.

The APM QA Engineer Mindset

An important part of the role is understanding the QA mindset at AppFolio. It influences how we approach our work and responsibilities. We find that a quality mindset encompasses more than testing. We emphasize curiosity and creativity. Curiosity compels us to ask “why?” and then continue to ask questions in every step of the development process. Creativity can provide a different outlook when identifying risks and assumptions. A curious and creative QA Engineer can help their team succeed beyond testing. Applying quality at a higher level means a QA Engineer has an impact on addressing the needs around teams, culture, and the organization. The way we see it, a QA Engineer is a servant leader within their team.

The APM QA Engineer as a Servant Leader

As a QA Engineer, servant leadership is integral because we are first and foremost a support role within our engineering teams. QA Engineers do their best to help the team succeed in any way possible. This allows for an open mind to approach any number of issues. We focus on supporting the software engineers, UX designers, and product managers within our team. We also mentor other QA Engineers to reinforce the mindset and culture. It is a positive feedback loop that keeps teams, individuals, and the overall engineering organization growing in a healthy way. A QA Engineer is the glue of the team working in all capacities to figure out how to continually improve communication and facilitate the work being done. We have a commitment to the team’s success. Being a servant leader means wearing different hats and adjusting responsibilities that the role may require as priorities and teams change.

APM QA Engineer Responsibilities

Product Knowledge:

The cornerstone of the best QA Engineers lies in their APM product knowledge. As the product’s scale continues to grow with weekly releases, a team’s QA Engineer becomes more indispensable as a product expert even across features distant from their team’s focus. Product knowledge can also include technical understanding of other apps and services that support APM running smoothly. It has a domino effect. Teams have more context in their domain and can better identify the risks that accompany development there. Additionally, the QA Engineer’s product knowledge minimizes assumptions and potential bugs so when features and functionality are discussed, developed, and tested, there is confidence of due diligence done and clear collaborative efforts in quality through the entire process. By leveraging product knowledge during grooming, testing, and demos we can voice possible user concerns and contribute ideas that result in an overall better user experience.

Identifying risks and reducing assumptions:

Mitigating risks and reducing assumptions doesn’t necessarily mean “test better” when the story is ready to test. That would narrow and limit the QA Engineer’s contributions. Since we are involved in testing and most development phases, it is important to stay in the loop every step of the way. Being involved in team discussions and customer calls during product discovery allows us to contribute to grooming stories and setting weekly goals before any code is written and deployed. Bugs will occur and when they do, we have processes in place to ensure we respond and learn from them both as an individual QA as well as during team retrospectives. As an effective communicator, knowing how to write out bugs not only for developers, but for business teams like onboarding, implementation, and services helps to promote trust and set customer expectations by keeping all stakeholders informed with regular updates. Continually learning the product over time in the role provides the team with a more varied perspective regarding risks and assumptions within the current set of stories groomed.

Testing:

When it comes to testing, a curious and creative QA Engineer will excel with exploratory testing. We use it to surface problems, reduce assumptions, and drive our own learning. We combine an understanding of the user experience, product knowledge, technical skills, and automated tests to deliver features and functionality designated as “done.” The test cases, acceptance criteria, and assumptions are verified at the QA engineer’s discretion and choice of tools. Occasionally, test cases, acceptance criteria, and risks are not obvious, so we value a QA Engineer’s curiosity and creativity to snuff them out and bring them to the team’s attention. Sometimes, this can mean demoing the story with the team to review all changes that will be merged. We firmly believe in this creative approach to testing and every QA Engineer has access to the same tools and environments that a software engineer does. Testing is a review of the team’s combined effort from grooming to release, with the goal of assuring that users receive the best possible experience with new features and functions going into the existing product.

Releases:

Releases fall under QA’s purview in terms of tracking when new features and functionalities are delivered to customers. QA Engineers are the team’s source of truth for release dates, tracking sprints, enabling experimental features (what other companies may call feature flags), and determining which customer segments are included in feature rollouts. QA Engineers can exercise judgment and raise concerns with the team when merging features might pose problems with the user experience, affect migrations, or conflict with other teams’ changes. Being aware of releases means staying cognizant of software updates and maintaining constant watch over quality of the product at large. When it comes to bugs, being able to determine the severity, the dates the bug was released and found, when the fix will reach customers, and whether patching is necessary requires QA Engineers to stay on top of the moving parts of our continuous release cycle. Monitoring production post-release is important to track feature usage data, ensure any exception errors logged are addressed, and make sure new features work as expected.

Technical:

Since we have access to the same tools as our software engineers, technical acumen helps. A basic understanding of Ruby, SQL, databases and migrations, internal tools, Git, and automated tests allows us to support the team better. Git experience allows us to manage the process from merging feature branches, creating release branches, and scheduling deployments to customers. We can cherry-pick bug fixes, schedule releases for non-APM apps, write SQL queries to gather data for the team to inform the decision-making process and check assumptions, and use understanding of automated tests to focus exploratory testing. In some cases, we contribute to technical groomings or code reviews. To go further than that, our knowledge of AWS, infrastructure, and APIs allows us to apply the QA process to backend engineering teams. There is no limit for a QA Engineer to how more technical knowledge can help better serve the team.

Headlights of the Team:

This is the one that may register the least initially, but it comes from being a servant leader. It requires time and experience being immersed in a team to understand the people dynamics, process, and blockers that might appear. It might mean bringing up difficult topics in team retrospectives or in one-to-one meetings. Developing strong communication and empathy helps a QA Engineer understand people, situations, and psychological safety on teams. QA Engineers can also be the one to observe their team’s processes to identify where work is slow, if bugs are affecting productivity, if stories aren’t sliced small enough, and if we are addressing customer feedback adequately. Taking these concerns back to team retrospectives for example will let the team tackle these problems sooner rather than later and not let them grow into major blockers.

Keepers of modern agile:

QA Engineers share the duty to promote a healthy culture and development best practices based on agile guiding principles. While trying to embody these principles, we leverage development to deliver value to customers faster, eschew waterfall development tendencies, and promote AppFolio engineering culture. 

Onboarding and mentoring:

This is an essential part of growing the QA mindset, AppFolio engineering culture, and setting expectations for all QA Engineers joining our company. QA Engineers are not placed on a team by themselves on day one. Rather they have another QA Engineer as their mentor. They learn the product and their role within the team over a span of one to two months of onboarding, setting weekly goals along the way. They learn about the resources, tools, and help at their disposal through pairing often with their mentors. Multiple QA Engineers can pair and track the progress of the new hire over the onboarding period to make sure they are fully supported. Great QA Engineers support each other so that they can learn how to best support teams when they are on their own. The onboarding and mentoring process is never complete and is regularly evaluated. We constantly try to improve it so that new hires are set for success from their first day and during their entire tenure.

Hiring:

The hiring process for QA Engineers is owned by QA team from managers and leads to engineers. QA Engineers involved in interviews constantly ask themselves, what’s going well, what isn’t, and what can we do better with the interview process. We are not afraid to scrutinize our interview structure and exercises. We receive feedback from interviewers and interviewees, and work hard to ensure the people we hire meet our criteria for culture fit, mindset, and career growth. We have open conversations to examine what we can learn from other companies’ interview practices. The interview process usually has multiple parts that evaluate a candidate’s problem-solving ability, willingness to learn, and general creative thinking.


Many responsibilities are listed here and the best among us may be able to do all of the above, but more often than not, it is that a QA Engineer here knows how to adapt and tap into different skills depending on their team or the QA organization’s needs at the moment.

Who We Are

In QA, many of us have quite different backgrounds and are united by our ability to think creatively and curiously. We share the QA mindset even with differing experiences and starting points into the role. The varied responsibilities mentioned in the previous section demonstrate how we bring our range and experiences to QA. Here are a few current QA Engineers’ growth and paths in our organization.

  1. Topher H. began his AppFolio career as a QA Engineer, right after graduation from UCSB with a Computer Engineering degree. His technical background and QA mindset allow him to take ownership and direct our entire production release train. Topher functions as a strong individual contributor on his teams while being invaluable to the QA engineering organization managing significant parts of the QA Engineer interview process and invested in growing the careers of the several QA Engineers reporting to him. Topher works on both feature and infrastructure teams, able to adapt to any team’s given needs. 

  2. Sam P. worked primarily in the Oil & Gas industry before coming to AppFolio. From his previous career and experiences, Sam has a strong background with risk management, data analysis, managing client expectations, developing internal software tools, and project management. Sam leads his team’s technical groomings, comfortable with both navigating the codebase and exploratory testing for testing, releases, and discussions. He currently supports our engineering teams working on machine learning features within the property maintenance space.

  3. Anna G. started out in APM Customer Success and eventually transitioned into the QA Engineer role after a few years. Anna brings a wealth of product knowledge to engineering after spending years directly supporting our customers and their businesses. She is able to identify risks early in the process, knowing how all moving parts of the software work together from the user interface and database. As a tech lead within the accounting domain, many of our engineering teams focused on accounting initiatives benefit from her expertise and advice.

So Anyway…

A QA Engineer has many tools to support other individuals, their teams, and the organization. A successful QA Engineer has not only testing skills, but an aptitude and willingness to improve in other responsibilities and skills, including leadership, culture, ideation, processes, business strategy, computer science, product management, customer service, and hiring to name a few. It is unique and empowering that a QA Engineer at AppFolio has so many avenues for growth.

For a QA Engineer at AppFolio to be successful, a persistent curiosity and willingness to learn are a daily requirement. Each day, week, and month involves a varying degree of responsibility that ranges from mentoring, testing, leading teams, interviewing and hiring, managing projects, collaborating cross-functionally, learning about product improvements, and more. The value of our role lies beyond simply “tester” and has the marks of a generalist that can plunge in and adapt as a specialist depending on the situation. In all instances, quality is our primary concern from top to bottom. We know a little bit of everything and then lean in to where our teams and the organization need us most to ensure we are uplifting those around us to deliver the best they can, including ourselves. Come join us or reach out to learn more. 

Books we have read, referenced, or would suggest:

  • Agile Testing Guide by Lisa Crispin and Janet Gregory

  • Think Fast and Slow by Daniel Kahneman 

  • Dynamic Reteaming by Heidi Helfand

  • The Lean Startup by Eric Ries

  • Creativity, Inc. by Ed Catmull

  • Leaders Eat Last by Simon Sinek

  • Range by David Epstein

  • Inspired: How to Create Products Customers Love by Marty Cagan

  • Good Strategy, Bad Strategy by Richard Rumelt