This is expanding a little on a post I made back in October of 2009 on my personal blog. I have been an advocate of the approach of considering yourself as an entrepreneurial consultant in whatever line of work you happen to be in, whether you actually are a consultant or work for a company and are on their payroll. As I was musing about what I’d want to call my consulting firm, I came upon the idea of “Dread Pirate Roberts Consulting”. Understand, I didn’t actually use that term, because Dread Pirate Roberts is a name closely associated with a beloved movie, but it was the idea behind it that has stuck with me.
For those who are fans of the movie "The Princess Bride" you will know this character. He was portrayed by Cary Elwes (the alter ego of "Wesley") and the foil for many of the characters to go up against. The parts of the movie I remember the best were his quips when he and Buttercup were walking through the Fire Swamp and he was describing how he became the Dread Pirate Roberts. I'll not spoil the whole setup for the perhaps two or three people out there who have not seen this movie, but there's a section where the "Dread Pirate Roberts" takes in Wesley by saying "well, I've never had a valet before, so let's see how this works, but be warned, I shall probably kill you in the morning" (paraphrased).
I've long thought on this quote and wondered "what would I do in my everyday life if I had that as a way to work and to live, the notion of 'work hard, work well, do what you can, I shall probably kill you in the morning'"? How would you do things differently? How would you approach problems? How would you approach projects?
This gave me a simple idea to play with in my work life, and something that allowed me to make a basic order of operations to maximize my effectiveness. I call these "the DPR Consulting Order of Operations" as relates to testing. the goal is to maximize effectiveness and make sure that I get in order the things I need to do because, hey, he'll probably kill me in the morning.
Management Directive: Let’s face it, when we are working for someone, as a consultant or a direct report, whatever work is most important to our stakeholders needs to be our primary focus. Note, that doesn’t mean “do whatever the stakeholder tells us to” or “go along with everything the stakeholder says”. It means that our primary responsibility is to find out what the single most important thing to our stakeholders is, and once we have done that, make sure that it gets done. If the number one thing is to “ship the product on time”, we owe it to our stakeholder to tell them everything that we know that could delay that possibility and offer what we could do to make sure that doesn’t happen. Notice I didn’t say “cut corners to meet the deadline”. When you are a consultant, you are paid to tell the truth about a situation, to the best of your ability, and help make sure that the project is a success. As a consultant, you have to be willing to be the bearer of both good news and bad news, and the directive may change. Be prepared for that first and foremost.
Bug Database: In my world, the bug database is the hive where most of my activity revolves. When I write and revise test cases, it comes from interacting with the bug database. When I want to find out where we actually stand in the cycle, I look to the bug database. When a project has a new build, or a new set of features, the bug database is my primary source of information, even more so than requirements documents, especially when those bugs come from requests in the field from customers; while requirements may say one thing, customers needs and demands may not jibe exactly with what has been put into the requirements document. In this case, the bug database trumps the requirements document, unless the stakeholders decide otherwise. My mode of operation is that I review all issues, determine if there is enough information to be meaningful to the developers, and likewise determine if the fixes have enough information to be meaningfully tested. If not, I have the choice of improvising and seeing if they have been fixed, or I can have the developers clarify what they have done to fix the issues and get specific thoughts on what to test. It is not an insult to have developers give clear guidance to what they have fixed and to make recommended use cases to test the fix. I cannot use that as my *only* method of validation, but I personally appreciate it when developers give details about a fix and what to look for, rather than to say “this has been fixed” and offer no other comments. As a tester, you should hold developers accountable for the changes they make and request guidance where necessary as to how to test what they have fixed (where possible).
Test Plan and Test Results Documentation: Many would put this first in their ordering. I put it third because I feel that it actually follows on from the information supplied from the first two. Please note that this ordering is never 100% absolute, but is a general flow of responsibility and action. Test Planning happens all the time, not just at neat little intervals. Test Documentation also incrementally changes over the course of a project; initial reports may be very informal, while project closeout will require a much more detailed and formal report of testing deliverables. All must be developed along the continuum. For me, my best test cases rarely come out early in a project, they are coaxed out in the intervals of builds and issues fixed and discovered while looking at those fixes. Going back and adding to test plans from this process is valuable and helps make testing documents and test cases stronger (it’s also the reason why I write almost all of my test plans in Excel rather than using a word publishing document or a Wiki. When I am ready to submit a completed test plan, *then* I put them in a more formal setting).
Test Scripts and Test Automation: While many would want to put this higher on the priority list, I feel it’s important to get the clear view of what you are testing first, and then work to automate things once you have a good understanding of what is supposed to happen. From there, test oracles can be established, data for applications can be thoroughly defined, and the tester can make comparisons to state which values should appear (if so, PASS) and which ones should not (else FAIL). I believe in using an unscripted approach at first, so as to get a feeling for whatever product you are working with. The scripts come later, and with that I mean the flow of operations, the user stories, all of the things necessary to interact with the application on a meaningful level with a high amount of certainty that you are covering what users would, and then some. The automation factors come later, and I will confess is often a late in the game item for me, or is something I focus on when I have clearly identified the expected behaviors of a variety of inputs.
Environment Maintenance and Update: The test lab, or test environments, have to be maintained, so any steps I can take to keep these up to date, with fall-back to previous states, and making sure that I have everything on tap to run with. To use my Dread Pirate Roberts paradigm, Environment Maintenance and Update is the equivalent of making sure a ship is ready to sail. Yeah, I know this stuff is really obvious, but this blog has to do with my own realities and what I have learned from them, so bear with me if I talk about some stuff that potentially has a huge “well, duh!” factor. To this end, I make sure that I have whatever tools are necessary to make sure machines can be deployed rapidly, set up as quickly as possible, and do not require a lot of hand-holding to get into a testable state. There’s no way to get rid of all the tedium, but certain tools such as MagicDisc, MagicISO, nLite and a collection of ready-to-go ISO images helps minimize the time required to set-up environments, and the judicious use of check-points allows a user to quickly get to the environments I need as quickly as I can.
BONUS Section: Read a Book a Week: Pick a non-fiction book, related to testing, or engineering, or software development, or marketing, or personal development… anything that will help you develop additional domain knowledge, and commit to reading a book every week. The time is not exact, but it’s a good goal to encourage people to get into some new ideas, challenge their current methodologies, and see if there is something that you can learn from in the vast world that’s out there. The answer, at least to me, has proven to be “you can learn from many sources, and many disciplines will help you sharpen your testing saw, even when the book in question has nothing to do with testing”… at least not at first. You will be surprised at how many books you can read on many different topics that will help hone your testing skills (I’ll be sharing some examples in the coming weeks :) ).
Here's wishing you all great days and great efforts, whatever they may be. May you not be killed in the morning... oh, and do your best to avoid the R.O.U.S.'s, too ;).
No comments:
Post a Comment