How to Build a Strong QA Practice for IoT
Developing a strong IoT QA testing practice involves at least two central components: hiring the right people, and building a process that empowers those people to make the biggest impact. Here are some guidelines for each:
Qualities to Look For in Your QA Lead
The person you choose to spearhead your QA practice should have the following experience and qualities:
- Experienced in manual testing of web and mobile apps
- If your team must frequently juggle multiple IoT development projects, look for someone with agency experience.
- Familiar with the following tools: Xcode, Android Studio, and Charles Proxy or some other debugging proxy tool
- Good exploratory testing skills
- This is the recommended focus for extreme programming (XP) regarding manual QA. Extensive regression tests do not constitute a lean approach and are not recommended with XP.
- Experience in refining acceptance criteria for job stories and identifying unhappy paths/edge cases for testing
- Experience in writing high-level test cases for "smoke tests" that cover critical paths/user flows in a product. It's important to find a person who has the ability to see the bigger picture and doesn't get lost in the details.
- Background: I've often seen experienced QA professionals that don’t have agency experience spend too much time on less important things. They are used to being able to spend all day, every day, focused on just one product. In an agency work environment, this is not sustainable.
- Nice to have:
- Test automation experience or interest in learning it (using frameworks like Selenium, Appium, Jest, TestCafe…)
- Performance testing experience (Load testing, Stress testing, Soak/Endurance testing, Spike testing, Scalability testing)
- Security testing experience
- Note: this is a very specialized field and it’s usually difficult to find a person who’s good at this as well as the other items above. To do proper security testing, you may need to hire a security testing specialist.
Where Your QA Lead Should Engage in the Development Process
Experienced, driven individuals are often as successful on your team as you allow them to be. Below is an outline of when and how your QA team should be involved during the product development cycle:
Your QA team should:
- Identify risks in proposed architecture, user flows, and designs.
- Identify opportunities to build certain debugging functions into the test builds that will speed up testing and save time later (e.g. mock responses, easily switch test environments, simulate certain edge cases).
- Help write/refine detailed acceptance criteria for job stories.
Note: QA doesn’t need to spend a lot of time in the planning phase. Attending planning meetings and spending a handful of hours to review documentation and provide feedback should be enough. The important part is to make sure the QA team is included in the process,
The QA team will:
- Create high-level written test cases based on acceptance criteria and designs.
- Test stories as they are delivered and update test cases with Pass/Fail/Blocked results.
- Engage in ongoing exploratory testing, refine test cases as needed when new issues are found, and talk to engineers about including them in automated tests.
- Maintain a lean smoke test suite for delivered features.
- Execute smoke tests from previous iterations at the end of each completed iteration to catch any possible regressions.
Supplemental Practices to Deliver High-Quality Products
Going back to the idea that quality assurance is everyone’s responsibility, it’s important to note that QA works best as a companion to mature development practices that your team is already using. A few examples of these that we employ at Very include:
As the name suggests, pair programming is a development approach where a pair of programmers collaborate on a single workstation at the same time (which can be done in-person or remotely via screen-sharing collaboration tools). Pair programming is known to improve quality control because each developer can challenge the other’s assumptions and fill in potential knowledge gaps.
With a test-driven development approach, you write your software test before you write the actual production code. You develop with specific functionality in mind, as well as how that functionality will be tested so that the testing itself will be a more seamless process when the time comes.
While these practices will likely increase the quality of your software output, they won’t replace a QA team and practice. To deliver the best products for your internal or external clients, begin with the guidelines outlined in this post.
If you’re looking for an IoT development team committed to quality, check out our team at Very today.