Maximum Effort! - Deadpool Your Way Through Testing



When I first thought how the Deadpool movie could be tied to testing, I was taking the whole idea, even the movie, too literally. (There is a joke in there somewhere, I just know it!)  A scene in the movie, prompted this initial take on the direction of the article, but really wasn’t the “AH-ha!” I was hoping it would be about Exploratory Testing. (Though if you’ve seen the movie, which I do recommend, I still think my initial thoughts on Exploratory Testing might be entertaining.)

I mentioned this to my manager and he brought up a point that is now the basis of this article. (Thanks Heath!) Superheroes have powers of some kind, and Deadpool’s power, possibly his greatest power, is to break reality, break the fourth wall and talk to the audience directly. He can talk to his creators directly. He talks, a lot. The character is constantly communicating his flippant, sarcastic points of view to everybody regardless of where you exist. 

I’m not advocating being flippant and sarcastic at work, though if you have a good manager and team that you work with, they might appreciate it more than others. I'm also not advocating shooting your dev team when you find defects, even if that seems really tempting at the time. Mostly, the example I’m looking at here comes from a couple of perspectives. Deadpool is aware of his audience, aware that he is a character, and aware that he can affect things on multiple levels. This state is very similar to what a tester should try to achieve in their testing career. 

A tester should be aware of their audience, even when the rest of development focuses on the software or whatever is being created. The tester should know what the creation is, and be aware of how the audience will receive it. Testers should act as different characters within the development world. Whether this is the diplomat, the communicator, the user, the hero, the sidekick, the plot device; testers should be aware of what and even who they are in the process at that point in time and act according to that nature, then know when to break it, to play with it and even move on to a different character or persona. A tester should affect things on multiple levels. From the development stage, to the ship day, to the interaction with users using the product you helped create, or even a competitor’s product, you can affect how your environment takes things in, processes it and then project that back out to the world at-large.

Inside of the product, a tester should have a wicked set of skills to test their environment. While Deadpool knows he’s a character, he does have martial art skills, weapons skills, and tactical skills to help him deal with that environment. Deadpool is also versed in the latest and greatest of pop-culture, but still understands how history can play a part in current events. Testers should be creating their own tool box of things to build skills dealing with the environment they currently working in, and skills that keep a tester moving forward and current in on career path, whatever that might be.

I want to talk about the types of communication in Deadpool. The movie was communicating on so many different levels. Inside the environment of the movie, communication wasn't really important until Wade changed to Deadpool and those caused dynamic changes in the movie itself. From the constant dropping of Easter eggs to the fans and even to Ryan Reynolds fans, but also character dynamics where communication became important. This, to me, seems like a great example of a system under development, which once released, takes on a whole different life of it's own. Even the creator isn't in control any more. Deadpool is his own being. What's cool about Deadpool is that he can communicate back to his creator and influence the creator. Software does that on different levels with different people. Customers using the software communicate defects, change requests, usage issues, and outages, just to name a few. Developers can get feedback from tests and the code itself. Testers can gather all of these things and look at the bigger picture, investigate and then disseminate information as it becomes relevant.

While it might be nice to solve a defect with a bullet, unfortunately or fortunately, software development takes a little more finesse.  The industry is always in flux, always changing. Change with it. Take the opportunities to grow and become a bigger voice. Be the advocate for the story inside and outside the company you work for. Be an advocate for yourself, your team, and the customer. Be a Deadpool-like in your testing. Go break shit for the better.


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