Interview questions for QA managers • Hacker News Board

Re: Interview questions for QA managers

#31

Post by bklaasen » Sat, Mar 07, 2015, 9:16 AM UTC

el_benhameen wrote: post #14

grandalf wrote: post #4

The issue of where to draw the line between developer testing and QA testing is an interesting one. I think it's best to answer it in reverse and start with a bug. Did the bug make it to production? Is it a critical path? Was it covered by the test plan? Was it covered by a functional/unit/integration test? Was it clearly defined in the product requirements? Was the behavior clearly defined as part of a business obje…

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.

The two books on systems thinking that I'd recommend are Gerald Weinberg's "An introduction to general systems thinking" and Donella Meadows' "Thinking in systems: a primer". Anything by Gerald Weinberg is eye-opening, if you haven't come across him before. He's the grand-daddy of modern thinking on testing.

If you follow the advice in this article, you'll end up with an inefficient old-school, documentation-heavy, dogmatic factory-style quality-police testing department, set up in opposition to your development team.

Re: Interview questions for QA managers

#32

Post by logunath » Sat, Mar 07, 2015, 10:30 AM UTC

May be any personal question which may express your sense on "compromise". If you say i am deep rooted with perfection, have a added value.

Re: Interview questions for QA managers

#33

Post by exelius » Mon, Mar 09, 2015, 1:52 PM UTC

geoelectric wrote: post #24

exelius wrote: post #7

Earlier quoted context omitted.

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…

That doesn't really work, though, because the test cases need to be updated at the same time a code checkin that would modify their assumptions happens or that checkin won't pass. Really, for the most part developers have to at least be skilled at updating the CI tests if not creating them in the first place. Plus, good unit or component tests are generally written to validate architectural and interface assumptions,…

If you build your workflow so that you build a branch with a certain user story, you don't merge back to trunk until the tests are also written. It's actually pretty easy to manage (at least with Git).

And you're right -- this is for a continuous deployment workflow, which many large companies are moving towards as a next step from Agile. Continuous deployment is ultimately a business capability; rather than have your product guys focus test features, etc. you can just use a hypothesis-driven approach to set up A/B tests and go with what works. This works even better if you're an old-guard company with millions of users already. It short-circuits a lot of the hand-wringing and political maneuvering around product features when you can say "Eh, let's just break off 5% of our user base and test both versions of this for a few days".