Interview questions for QA managers
21–30 of 33 posts
Re: Interview questions for QA managers
#22Hmm. I find proposed answers to these questions somewhat... unexpected. Lacking, in fact. They focus so much on technical ability, and seem to ignore the human side of being a manager. Starting with the first one... "1) Let’s say you are the first QA manager joining our startup. What are the first three things you would do?" The kind of things I'd expect to hear here would never be of the kind 'write a test plan'. An…
This has been added: "It is important for the QA manager candidate to ask questions of his own regarding the current process and the challenges facing the organization that led to the search for a QA manager."
The questions don't go into further details of managing and leading a team, there is a whole set of questions that are more tailored towards hiring a "QA team lead" - might be a follow on blog post.
Re: Interview questions for QA managers
#23Hmm. I find proposed answers to these questions somewhat... unexpected. Lacking, in fact. They focus so much on technical ability, and seem to ignore the human side of being a manager. Starting with the first one... "1) Let’s say you are the first QA manager joining our startup. What are the first three things you would do?" The kind of things I'd expect to hear here would never be of the kind 'write a test plan'. An…
I think these are great questions for QA leads, not the person who manages them.
Re: Interview questions for QA managers
#24I haven't worked in a continuous integration environment but why would that fall on QA?
Because depending on your level of CI integration, many of the automated tests that QA writes can be run as part of the CI process. Developers are really bad at maintaining CI systems, so it usually falls on the QA team to ensure new tests are included in the CI workflow. Ultimately, it's QA's job to certify a release. With CI, that certification is often done in an automated fashion. Thus, QA should have ultimate re…
Plus, good unit or component tests are generally written to validate architectural and interface assumptions, not so much business rules and requirements. That's what most people really run in CI, not so much full-stack systems integration or user acceptance tests.
The types of tests you would use to do heavy acceptance verification often don't run that well in CI due to either having ecosystem concerns that can't/shouldn't be mocked, or because they simply run too slowly (most UI test frameworks fall into this).
At the end of the day, everyone really needs to know how to do some level of testing, at least at to verify their own assumptions about the work they're generating.
Edit: and you don't necessarily use CI to validate a release--you do in Continuous Deployment, by necessity, so that covers a lot of HN's web startup audience for sure.
But my experience is the majority of other kinds of companies need a release acceptance pass to independently verify a final bundle against requirements.
The type of QA described in this document wouldn't mesh with a CI/CD-only organization anyway. In those orgs, just write the tests and run a code coverage tool. You don't really have a process step that would allow you to do much with this kind of documentation or rigor anyway, since it's build/push/results/deploy.
Re: Interview questions for QA managers
#25Pretty much stopped reading when the answer to the first question involved writing test cases. Testing does not have to mean churning out hundreds of test cases, they are inefficient and not that effective at finding bugs. If a QA Manager ( or tester ) had such a strong attachment to them then the interview would be over. Definitely stopped reading when answer2 was 'detailed test cases'
Re: Interview questions for QA managers
#26Re: Interview questions for QA managers
#27Most of this is pretty good. Some of this is a little old-school. There are a couple of things I disagree with, speaking from my own experience as a test lead. The biggest is the definition of "a good testcase." If you define your test cases at the specific UI widget level, they have to be updated whenever any UI change happens, period. Since you usually end up with a number of test scenarios for a given area of the…
Which organization do you work for? How long have you worked there? Take a few minutes to read over what you just wrote and see if it makes sense to anyone else besides you?
Re: Interview questions for QA managers
#28This doesn't seem right to me: > 3) How do you determine which devices and OS versions we should test on? > This should generally be an easy question for the candidate. Good candidates will point to app analytics as the best measure, looking for the most used devices for their particular app. Another good answer would be to check the app reviews where people might have complained about specific issues happening on th…
Re: Interview questions for QA managers
#29This doesn't seem right to me: > 3) How do you determine which devices and OS versions we should test on? > This should generally be an easy question for the candidate. Good candidates will point to app analytics as the best measure, looking for the most used devices for their particular app. Another good answer would be to check the app reviews where people might have complained about specific issues happening on th…
Not because they are among the "top devices" (though they usually are for each subcategory), but because it shows they have enough experience to have seen first-hand that a surprising amount of device and/or OS version specific issues that Android apps run into occur on Samsung/TouchWiz devices.
Re: Interview questions for QA managers
#30Earlier quoted context omitted.
I manage a QA team where there was none until very recently. If you have any reading on point #2 that you'd recommend, it'd be hugely helpful to me.
I'm not aware of any specific reading... but I'll share a few more thoughts: The key is to not make it a blame game. Every bug that is discovered on staging or production should (in theory) trigger a root cause analysis of some kind... because it means that one of the earlier processes failed. If you have manual QA people, it's mostly just improving the QA plan and adding edge cases and domain knowledge, but it can a…