Pulp Fiction Testing

"I'm here to help. If my help's not appreciated, lots of luck, gentlemen." - The Wolf


I've had this concept in my head for a while. I feel like it fits the software industry as much as it fits the fictional mob world of Quentin Tarantino's classic "Pulp Fiction". Maybe it's a little far fetched, but stay with me here and let me tell a story.

It's about makers and fixers. Makers make stuff, and fixers fix stuff. Simple concept, mostly. It's an idea that coders are basically guns for hire. They come in, they get an assignment, they make the code. They ride off into the sunset, or collect their pay, or wait around for another job; whatever analogy you want to apply there, but they do the thing that needs doing. They make stuff happen.


Two guys, making things happen.

But then, in the process of making things happen, something else happens that was an unintended consequence of doing the thing that they were told to do.



"Whelp, broke that, coffee time!"

What happens then? If you are looking square at a problem that needs to be solved, or at least need to find a plan of action, you call up a fixer.


"Excellent coffee, thank you!"

The makers are no dummies here, they can contain the situation, maybe hide the bad code, parking it in a garage, out of the way, until someone can assess the situation and come up with another idea to fix the problem. You call in a fixer, "The Wolf", or basically a tester. They know the app. They know what will work with customers, they might even work with you to come up with a plan of action. They work with everybody to assess the situation and then help assign how to deal with it. They even do some customer service to smooth over things, because, what happened wasn't pretty, an no one likes to wait for information. They make some calls, get info to the right people, maybe call in other fixers to help out with specific issues that are time sensitive. The problem made is solved, or at the very least, the people it impacted are happy with how it was handled. Even the makers are all cool about it because they got information, and a plan and a place to get things done. Because it's embarrassing for everybody when a problem is visible, and if you can contain a situation, it's better for everybody that way. Well, in the case of code and software at least.

I know it doesn't work this way for everybody, and it might not work this way for most testers on a project, but I think it should.

I also think "The Wolf" types can be proactive. Analyzing things before they become a problem, getting out ahead of it. When the "The Wolf says, "That's thirty minutes away. I'll be there in ten.", he's working to get ahead of things, and being proactive about how to handle it.

 I think testing and raising the quality bar is one of the most important things a fixer type can do. "The Wolf" aka the fixer is representative of the level of respect I have for the profession of testing. Testers may be creating more work for those maker/developer types out there, but at the same time, they are raising the bar, setting standards, and being efficient and professional as possible. Also, they know where most the skeletons are located.


FIN



Comments

Post a Comment

Most Read Posts

Ready, Tester One? *GO!*

"I handed my passport to the immigration officer, and he looked at it and looked at me and said, 'What are you?'" - Grace Hopper (60 Minutes Interview) The Grace Hopper quote above always makes me think about my job as a tester. Companies that develop software know they need testers, but they generally have hard time figuring out what testers are and what skills they need in the role. There have many discussions about how testers can be more technical and at some point, coding comes up in the conversation. My response on twitter contained a few things on a list I have, which I created for a client, so they could have a checklist of skills. This checklist was a guideline to determine the skill level of the tester applicant. This is by no means a complete list and I would be open to additions to the list. Feel free to add those to the comments or tweet them to me. For clarity, I took the list of skills I had and broke them into levels. I like games and I lik...
Read more

Learning From Failure: The Tricky iOS Environment

"You build on failure. You use it as a stepping stone. Close the door on the past. You don't try to forget the mistakes, but you don't dwell on it. You don't let it have any of your energy, or any of your time, or any of your space."  - Johnny Cash There are times when our work, as a team, as testers on a team can give us insight into how we can improve things for the overall success of the product. Often those things are issues or defects which can present themselves at the most inconvenient times, in the most inconsistent ways. When we can learn from them and improve things for everyone on the team, the team benefits. When the team owns the defects and the testing strategy, not only the testers, then customers benefit as well. I was working remotely verifying a release and only had simulators and emulators to work with as I was testing mobile builds. Often folks mistrust builds which only use emulated software and not real devices for fairly good reasons...
Read more

Postman In The Pipeline: Newman Delivers

Image
  It's not me, it's the songs.  I'm just the postman,  I deliver the songs....  - Bob Dylan Recently, I've had the chance to work on a project with some other awesome folks which has involved creating a BFF - A back end for front end service. This allows the app to access several API and aggregate calls into something the app can use, or lets the app send information to the BFF for several APIs to receive. Part of the code coverage for the BFF was creating some simple tests with Postman around the business logic and interactions. Learning About Postman I did lots of reading. Lots of reading how others has done things (Danny Danton - big props for being a super help!). Eventually, I came down to a small set of tests which could give us some accuracy about our BFF pipeline and the APIs we were accessing with it. Postman has a couple of options for this, global variables, environmental variables, and plain variables. One of the first problems I came acros...
Read more