QA Interview question tutorial — leveraging outside tools

Most quality assurance or engineering departments struggle with the classic build vs. buy question. In fact, the team itself is subject to this question. The choice on whether or not to interview and hire an analyst or to hire outside consultants is an important one for most companies. But it’s worth remembering that not all companies think about these questions in exactly the same way. Different organizations will have different competencies that allow them to optimize for certain outcomes.

Start-ups are small companies facing dual constraints. They often don’t have the resources of larger corporations so it’s difficult to hire a team of engineers to build small projects or deploy resources to acquire tools that may not be used frequently. It’s also difficult to make a risky bet on a contractor when spending finite money. This kind of company is expecting flexibility from principal QA hires. A candidate that can use multiple open source frameworks will be able to excel. A non-exhaustive list of such tools includes Selenium, Appium, XCUITest, Espresso used in conjunction with languages like javascript/typescript, python, swift, Kotlin, Flutter, etc.

Larger enterprise level companies will be looking for specialized engineers who have a history using specific frameworks. They are looking for prospective employees to demonstrate that they can fit in within an existing system as a team player. Even large companies may just be starting in automation testing so the key to hiring is understanding if a new and expensive initiative will be understood by other members of the development team. The key tools to understand are reporting and business intelligence resources so that it’s easy to communicate results and testing practices.

The common denominator in both positions is an in depth acquaintance with QA technologies. In conversation with members of the testing community a frequent complaint I hear is the number of tools a new engineer has to acquaint themselves with is far too high. Even the hardest working analyst will never be an expert with every tool. In addition to the languages and frameworks themselves, there are CI/CD tools, different device providers, and data tools. Oftentimes these tools interact in complex ways with distinct APIs that are difficult to learn.

It seems the immediate and obvious way to have success is simply to learn as many of these tools as possible. If you are able to become an expert with every tool or at least as many tools as possible then you’ll have no problem acing the interview and working at a large corporation or a start-up. This is a brute force approach based on rote memorization.

There is another, easier path. The most successful people I’ve encountered in testing don’t have an encyclopedic understanding of every tool but instead are obsessed with finding the best tools and mastering them. They love predicting what tools are going to rise to prominence in the future. This is a “smarter-not-harder” approach that seeks to understand automation frameworks at a deeper level so that the tradeoffs can be understood in decision making.

It’s crucial to understand what the general capabilities of tools are and then based on this understanding find out where they overlap. These kinds of tools will rise in importance and employers will reward a deeper familiarity with select important tools with higher salaries. These kinds of tools also simplify communication and make it easier for others to understand your process.

To provide an example for one of these, consider our dash-boarding and reporting tool at Tauk. While it’s possible to spend countless resources and hours building something similar in house or to recreate it via the use of APIs and rigging together different BI and data products it wouldn’t be as easy, cost-effective, or as useful for communication. The benefit of a tool like this is that it allows an SDET or QA to be armed with easily digestible data when presenting to a manager, developer, or even those outside of the technical branch of a given business.

The added benefit is that it reduces the work required of the SDET or analyst because they no longer have to use dozens of tools to create a unified dashboard. Such an answer could be used in the standard STAR(situation, task, action, result) method for interviewing to describe how you could make strategic decisions about resource allocation. The situation is testing, the task is representing data, and the action is adopting a unifying tool, and the result is effective communication and more bugs fixed.

Please reach out to the Tauk team or reference other blog materials if you have any questions about the materials in this article. The documentation for Tauk itself can be found here: https://tauk.notion.site/tauk/Tauk-Manual-2605152bd0a74707a095df0f0cfd6625