By James A. WhittakerGoogle is hiring. We have openings for security testers, test tool developers, automation experts and manual testers. That's right, I said manual testers.xyz ?' The answers help us judge a tester's instincts, but after reading many hundreds of these interviews I have noticed marked patterns in how testers approach solving such problems. It's as though testers have a default testing framework built into their thinking that guides them in choosing test cases and defines the way they approach test design.Input Domain Framework treats software as an input-output mechanism. Subscribers of this framework think in terms of sets of inputs, rules about which inputs are more important and relationships between inputs, input sequences and outputs. This is a common model in random testing, model-based testing and the testing of protocols and APIs. An applicant who uses this framework will talk about which inputs they would use to test a specific application and try to justify why those inputs are important.Divide and Conquer Framework treats software as a set of features. Subscribers begin by decomposing an app into its features, prioritizing them and then working through that list in order. Often the decomposition is multi-layered creating a bunch of small testing problems out of one very large one. You don't test the feature so much as you test its constituent parts. An applicant who uses this framework is less concerned with actual test cases and more concerned with reducing the size of the problem to something manageable.Fishbowl Framework is a big picture approach to testing in which we manipulate the application while watching and comparing the results. Put the app in a fishbowl, swirl it around in the water and watch what happens. The emphasis is more on the watching and analyzing than it is on exactly how we manipulate the features. An applicant who uses this framework chooses tests that cause visible output and large state changes.Storybook Framework consists of developing specific scenarios and making sure the software does what is is supposed to do when presented with those scenarios. Stories start with the expected path and work outward. They don't always get beyond the expected. This framework tests coherence of behavior more than subtle errors. Applicants who employ this framework often take a user's point of view and talk about using the application to get real work done.Pessimists Framework starts with edge cases. Subscribers test erroneous input, bad data, misconfigured environments and so on. This is a common strategy on mature products where the main paths are well trodden. Applicants who use this framework like to assume that the main paths will get tested naturally as part of normal dev use and dog-fooding and that the testing challenge is concentrated on lower probability scenarios. They are quick to take credit for prior testing, assume its rationality and pound on problematic scenarios.
If we are not interested in an interview, can we still be involved in the study? I'd like to be involved in studies whenever I can!
ReplyDeleteI would like to be part of the effort. I would add the following types I have seen:
ReplyDelete1. The "clueless" tester - someone who thinks testing is easy, anyone cand do it, and does understand the true complexity (we don't hire these).
2 The "one way" tester - someone has been testing for a while, but has one "hammer" (framework?) they use over and over and over, miss errors, and don't understand there are many ways (we try to educate them).
3. The "automation" tester - someone who thinks the tools will save them, all you need to do is create automation, they are very good at automation, and the tools "framework" is sufficient (we want these people but need to expand their view).
James, I would like to participate in this study, is it still possible?
ReplyDeleteWould like to participate in this study.
ReplyDeleteWhats next?