Some books say that if our projects are not “properly” controlled, if our written specifications are not always complete and up to date, if our code is not properly organized according to whatever methodology is fashionable, then, well, they should be. These books talk about testing when everyone else plays “by the rules.” This book is about doing testing when your coworkers don’t, won’t and don’t have to follow the rules. Consumer software projects are often characterized by a budget that is too small, a staff that is too small, a deadline that is too soon …
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
– Testing Computer Software, 2nd Edition, Kaner et al.
I’ve always been partial to that introduction; it matches my life experience. My own contributions to this area of testing include the idea of the ‘Boutique Tester.’ In other words, the tester air-dropped into a project, making contributions immediately and to the best of his ability. Sure, the tester will leave some artifacts, do some training, and try to leave the organization in better shape for next time, but his focus is on actually adding value to the project through testing right now.
Since I started writing and speaking about Boutique Testers, I’ve had several people approach me and talk about the business model. A few of them are doing it; making a living as freelance software testing experts. James Lyndsay refers to himself as a “Test Strategist.” James Bach just did a blog post and video on the role of the Consulting Software Tester, and my friend John Kotzian just changed his linkedin title to “Boutique Tester at uTest.” (He also just started a blog you might enjoy; check it out.)
Once you accept the idea, the next question that logically follows is “okay, but, um … what does a Boutique Tester actually do?”
I don’t want to be overly prescriptive; after all, what the Boutique Tester really does is “figure out what needs to be done and then do that.” But I’d like to at least give an example. So please allow me to paint a picture …
The sales work is done, the contract is signed, and it’s day one. The Boutique Tester arrives on-site. First he likely walks around, meeting the technical staff. He’ll watch what the technical staff is actually doing and how they report that to management. He’ll look at what story is told to the customer and the story that gets told when the customer walks away. He’ll get a copy of the software — or try to — and find out how often builds happen.
Now it’s the good part; time to attack the software. We’re quickly getting past what I can describe in one blog post. So …
Good news! I’m pleased to note that the folks at SearchSoftwareQuality have invited me to start a series of articles on how to attack software with little knowledge of the application, under time and staffing pressure. Nearly any type of tester can use these kinds of articles, Boutique, Contract, Outsourced, or Full-Time Employee.
I’ve already written an article on Quick Attacks for Web Security and have another one describing Quick Attacks for Web Applications coming up soon. From there we could expand to how to simulate perform more detailed, social attacks for systems security, or how to better understand the application under test, finding possible flaws in business logic more quickly.
What would you like to read about?