The Domain Is The Thing!

 “Time is a game played beautifully by children.”
― Heraclitus, Fragments

I had an interesting experience this weekend. A friend of mine contacted me and asked for some ideas to help her daughter learn about testing video games.

Think about that for a minute. I've had a lot of kids, including my oldest nephew ask about game design and creating video games, but my friend mentioned testing. Testing as a career. Testing as something that happens with a technology genre most kids are introduced to first.

Games and tech have had a long marriage and they have shepherded many a child into the tech industry with ideas of creating or designing games for the next generation of kids.

This isn't a new thing either. A friend of mine from my second grade class showed me game designs he had created on paper after I had shown him some of the stuff I was writing. We were 9 years old. Personal computers were barely an idea then. I know he was talking about the Atari or arcade games, but still, he was really sure of what he was going to do. I think I wanted to be a nurse, much like my mother. I don't know what he grew up to be, but I ended up being more drawn to computers and technology that I ever dreamed of at that age.

Finding Your Domain

These are suggestions for any tester who is asked the question, how do I get into an industry or area of knowledge and how do I test it. (This could also help with a career day if you volunteer to present for your child's class.)

Here were some of my suggestions:

- Study things outside of computer science like art, anthropology, psychology, history, music or even politics. Games have such a wide range of topics and ideas these days anything could be applicable.

- Computer science is always a good sector, but in the world of games, understanding graphics, design and design elements are a huge help, even if you are only involved in the back-end code.

- Graphics engines, monitor/display types and resolutions, basically any hardware you can find out about and a game could be played on. The more you know about it, the more you understand.

- Read technical magazines about game styles, gaming tech, gaming computers, basically anything that would collect information about not only opinions on the game play, but opinions and information about the hardware the games are meant to be played on.

- Fastest way to learn code is to do it.

For kids, I generally suggest to parents the Kano. It's a great little computer module based on Raspberry Pi and includes a lot of great visual content that allows users to "code" in a more visual manner. Adults can use it too, but it's definitely a good place for kids to start.

For adults, I have been suggesting FreeCodeCamp.com - you are walked through the basics of what you would have to do to be a full stack developer. When you have completed the challenges, you have about 400 hours of development time under your name, along with projects you create along the way.

Understanding Your Domain

While some of this is domain specific, you can certainly apply them to basically any software development job your child could ask about. Technology and science are so vast and specialized these days, most topics or domains have a lot of journals, articles, blogs and even TV shows dedicated to the topics. Encourage them to find their favorites and learn.

Half Way To Testing

After your youngling does all of the research and understanding they could possibly manage, they can research testing.

Testing to me is like the icing for the figurative cake of development. It covers the cake and depending on the cake, it's in-between the layers too. All the reading and research informs you how various things interact between each other.

From the processor to the graphics cards, knowing about what is interacting with the software at a given time, and when, can give you a lot of ideas to test a video game, and that's just the functional parts. Apply that to other domains and you can easily see how this knowledge can inform testing. 

This is the VALUE that testers bring to the table every time. When you know even a hint of something about the area you are working in and use that to inform your testing, you can be an extremely powerful member of the team testing the software or hardware. 

Even answering a question about game testing could lead them to do amazing things which their technical skills will have been honed for from an early age. The idea of this makes me excited for the future of testing and what the next generation of testers will be doing.

Test Bash Philly 99 Second Talk - Leap, Don't Look

Credit: Jeffrey Veregge - http://www.jeffreyveregge.com

Leap, Don't Look 

Superheroes have to start somewhere.

They learn over time.

They have complex stories.

They do things at times we all wonder about.

They do things we wish we could do ourselves.

A short time ago, 

I wished I could write more, 

I wished I could speak more, 

I wished I could learn and grow my skills.

I did a lot of wishing. 

I wished for people to understand my viewpoint, 

or at least give me credit for the good ideas along with the dumb ones.

I wished my life was more interesting than it was.

I wished.

One day, I stopped wishing and I did.

It was a small step. 

Just a tiny one. 

I wrote an essay for a contest about how much I loved Ministry of Testing and Test Bash.

In two years, I've gone from wishing to doing. 

I've traveled more, 

I write more, 

I've learned more and continue to do so.

So Leap, don't look.

Do, don't wait.

Don't let fear of failure and what if's stop you.

Be your own superhero.

Testers thrive on doing the impossible, 

testing the edge cases and the boundaries,

finding the mysteries in the black box.

If you aren't doing the same thing in life, 

even in the smallest way, you might be missing a very significant part 

of why you are a tester in the first place.

Mel's Rant: Non-technical Testing Is An Oxymoron

"The true delight is in the finding out rather than in the knowing." - Isaac Asimov

Somewhere in the the distant past, like a decade ago, manual testing wasn't considered non-technical. It was actually considered to be a very technical job in which someone doing the testing had to understand computers, operating systems, command line syntax to access everything from the directory to error logs, and a million other things that started appearing in the computing ecosystem.

Fast forward to present day, manual testers everywhere are being called non-technical because they don't practice automation on a regular basis. 

When did understanding computers become a non-technical thing? 

We don't call business analysts non-technical. They produce technical writing and information necessary for developers and testers to understand how code is supposed to be created and work. 

We don't call customer service reps non-technical. They deal with customers that are even less technical savvy than your average four-year-old on a daily basis. They manage to bridge the gap between the "helpful tips" people get from their computers, the internet, and the compatibility issues each system presents which they interact with. They have to know how to get to log files, operate a command line, understand where to find different parts of browsers including subtle differences between versions. 

Why has the notion persisted that manual testers are not technical? All testing starts with a manual effort, no matter who does it. 

The conversation we should be having, or asking, should be: "What is your level of technical ability?" If you can demonstrate a technical acumen, especially if you start off in testing and go into a business analyst role or start in a customer service background and go into a tester role, then you are technical. Your technical abilities should be based off of your skill set, and what you can do. 

The other part of the argument often is that anyone could read test cases and testing scripts and test an application or hardware. 

I don't think this is the case. Maybe in another ten years when we've all lived with computers from birth, then maybe that argument might be valid.

I think (the thought is based on conversations not actual proof) the idea comes from the game testing realm. Companies like Blizzard and Zynga hire testers who play the games. They don't necessarily hire testers to actually think like testers. But, they are still technical. They know the games better than anyone. They often they know them well enough to understand where the gaps are in the game, what breaks it, and what hardware is the best to run various games on. If that's not technical knowledge, then I'm not sure I understand the definition of technical. 

I've heard time an again that folks in a game testing role are not technical. I think that's an excuse to pay someone $12 an hour instead of a real wage. Unfortunately, the rest of the industry has bought into that idea.

I was phone screened by Zynga once. They were interested in having me as a tester. I described what I did and they went silent for a moment. The person on the other end spoke again and said that I was too technical for the QA role. I might make a better fit as a manager or a lead. I was surprised considering I had been a tester less than a year at the time. 

Their business model and practice requires a large amount of manual testing. That might have changed, but I doubt it. Because of the graphical nature of most games, manual testing will always necessary to companies in the gaming industry until they figure out how to automate random, interactive, graphical responses (which might or might not happen with machine learning - but we have to wait and see). 

I've interviewed with other places that have given me the equivalent of a developers test and was told I wasn't technical enough to be hired in as a QA. That's OK too. 

I am a coder by rote. I mimic patterns and copy/paste with the best of them. I have some fundamentals but I don't practice them often enough for me to completely avoid running to the internets to look things up. I at least I know where to find answers and usually what they are for. It's often been good enough for automation. It's maybe not good enough to start an automation framework by myself from scratch, however, I'm working on it. I'm getting better. Maybe at some point I'll be able to set up and tear down a whole infrastructure by myself with an automation framework and all the goodies included. Those are goals and I'll get there in time. I have faith in that.

The conversation we should be having in the industry as testers, and with people who are also in the industry but are in other roles is: where your technical skills are at? Not "Are they non-technical or technical," because computers are inherently technical, period. The idea that you would call any position in a software development organization non-technical is crazy pants! Testing, even manual testing, is a technical endeavor. It might be the foundation of the testers skill set, much like using an IDE is for developers, but it's still a skill. And it's a technical one.

Surviving A Change In Your Work Status

Don't Panic!

From Hitchhiker's Guide To The Galaxy

If you are reading this not long after the event of your layoff or firing, don't worry, you aren't alone. Also, it's not the end of the world either. Sometimes the worst things that happen are a huge chance to re-evaluate everything and make bold decisions.

I was recently laid off. It's not a happy situation for anyone. Some may revel in escorting people out the door, but for the most part, everybody is uncomfortable with it.

There is a lot of anger and resentment that can come up. Feelings of rejection or remorse. Those are all very common. If you are on the other side of the coin, where suddenly you feel like a weight is lifted, life seems a little easier, or just more bearable, maybe you knew you should have, could have, left that place a long time ago. But some sense of duty or sheer will to prove that you could offer value and help make things better kept you there longer than you should have. It's alright. Either way, you are free to go off to new endeavors.

Melissa's Tips for Surviving

First, take time to just breath. If that's a week or a month, that's OK. You might have some savings or severance that lets you relax a little and recharge, do that. Unemployment can also work in this direction, letting you find the right job to apply for and do interviews, but take care of you in the process. The trick is not to stay in this state of relaxation for too long.

Second, make a list of things you never found time to improve upon, work on, or go to involving your career. Whether that's writing articles, or brushing up on the latest in ReactJS, working through a bootcamp, reading a book or finding meet-ups. Doing this allows you to keep your skills sharp and your knowledge base on par with any other applicant in the job market. It might even give you an edge in some instances. It can also help tremendously when you are trying to network and understand how the market is shifting and what skills are valued in an ever changing industry.

Look at different industries too. Switching careers can be a large task, but not unheard of. I've done it before. All it takes is making an inventory of your talents and interests and then pivoting to one of those. It's remarkable what experiences we can take from one industry to the next just by seeing them in a different light.

Third, don't get discouraged. Or desperate. Over time, that gets harder not to do. And if you apply for a lot of jobs, but don't find exactly what you are looking for or don't get an offer, it can be hard on morale. That's when you need your network and meet-ups the most. Start a project from scratch, volunteer to work on projects that allow you to practice concepts you didn't have time to do before. Mentor other people in the job market. Keeping your spirits positive and keep yourself motivated. Get a workout routine, go to yoga classes, make new friends.

Fourth, you might be stressed about budgets and incomes. That's OK, but don't let that become a blocker to getting things done that help your well-being. Find ways to trim down the budget but still have your needs met. Are you used to going out for lattes everyday? Maybe buying a small espresso machine or switching to store-bought cold brew is the answer. You still get your caffeine fix, but at a cheaper cost point. Think about the stuff in your place, can you trim it down? Get on Craigslist or Let Go and sell the things that have been gathering dust, are little used, or just aren't that important to have anymore. If you want to go all out, have a garage sale and really make some deals. This can get you ready for your next adventure as well as clean your house of things you haven't had time to deal with until now.

Finally, be open to possibilities. Be open to moving. Be open to new ideas. Be open minded about opportunities. The simple fact of letting yourself see where you could be if you changed perspectives is something that people over look, but shouldn't. It takes bravery. Unknowns are scary sometimes, but sometimes those unknowns are the best opportunities to move forward.

*As of this post, I am currently working at ThoughtWorks in Dallas, TX

Evolution Is Hard - Testing Is Evolving

"Are you ready for the next evolution?!"

- Master Chief, G.I. Jane

I think it's finally time for me to put some thoughts out there about this "Death" of QA, of the Tester role, of Testing. 

Testing is and always shall be part of everything a human does. That's simple freaking science. We test. We explore. We question. We gather information. We record data. That will never change, ever. Whether a group of people or one person does it, that question is a moot point as well. If you look at any time in history when leaps of logic, science, the arts and even industry happen, there are any number of people involved. There is always at least one. There will always be someone testing whatever there is to test however it fancies them. 

Quality and the level of how well something is done will always be a concern at some level. And depending on whether it's burritos or rockets, there's a level of tolerance which everyone agrees to. When my burrito falls apart, I'm not happy. When it's rockets carrying billions of dollars worth of payload, not to mention human lives, then having critical failures is unacceptable. We have testers in every other industry, why is software moving to eliminate this role?

Well, believe it or not, it's not being eliminated, exactly. Automation has certainly taken a huge chunk out of the need for manual testing on a regular, routine basis. I don't know anyone in the testing industry that isn't happy about that. I don't have to log in to make sure it works. Great! Now people can write scripts that makes sure login works with 500 users at the same time. Awesome! Test security threats! Test infrastructure! Excellent! Here's a bunch of tables which should work together and store a massive amount of data at the same time and the structure should be optimized to deal with several different types of user information, forms, payments, and searches. Test it! *Dies and goes to testing heaven*

Testers, the role, QA are not dying, we are evolving. We are called different things now, like Data Analysts, Performance Analyst, Security Analyst, Automation Specialist, Technical Analysts - We didn't go anywhere, we EVOLVED. 

Like the rest of the industry around us, we are quickly specializing and branching out into different things. There are still a lot of testers doing actual manual testing out there. Companies don't want to admit it, but they are using crowd-sourced testing more and more. They are taking the same money they would have put towards a department of manual testers and then using it on crowd-sourced sites, user feedback groups and even outsourcing. 

This isn't anything new. Every industry has come to this point. Companies try moving things around to make it faster and cheaper. They have to balance making the app, supporting and deploying the app and usually the last slice of the pie is for testing/customer support. 

Like customer support, jobs are being moved around to figure out where companies can still make money but people still feel like they are being supported and understood. Customer Service is a major factor and companies understand that if they cut too much or push too much to a company outside of their own, people get pissed. Yet, those same people want cheap, fast customer service included with whatever software package or device they have purchased. 

Manual testing is now in that same boat. Trust me, people are still doing this kind of testing, it's just moved out of the building and into someone's hands who isn't privy to day-to-day operations of the company itself.

Automation and testing are the gateways for junior developers. When I've had conversations with new developers, I always recommend automation positions. They know the languages, have a good set of skills to build something and companies don't really know what they want other than they think automation will fix or speed up everything. And it's true, once you reach a critical mass of certain types of automation. And folks that come out of boot camps are the most prepared to write scripts and build frameworks just to show they have what it takes to maybe, at some point, move into a developer role. 

Anyone that says testing or testers are a dying breed aren't looking hard enough. The role we used to inhabit which have served as some quality gatekeeper might be eliminated. We, as professionals might not be QA any more, we have probably become something else, or at least we are starting to. Testers, as part of the software development industry, should be good with that. We've been labeled a sub-par group in the development world long enough. We can evolve into something more. We can take our unique talents and technical skills and mind set and start carving a path and forging it instead of picking up the scraps development "tosses over a wall."

Learn about data handling. Learn to code anything. Learn to automate anything. Learn deploy. Learn to test for performance issues. Learn to test for security weaknesses. Learn to test accessibility and usability. Learn project management. Learn to specialize. Learn a little bit of everything. 

Evolution is about adaptation. Testers adapt faster than any group of people I know. We can move from one project to the next because we have basics, but we may or may not have the particulars. We learn them as we go. We use them as we need them and then move to the next thing the industry develops. While developers could be described as members of a band, testers are the jazz players, the non-conformists, the ones that look for the unique in the unexpected. We adapt. We evolve. 

So the next time someone says testing, testers or QA is dying, just tell them to wait, they haven't seen nothing yet. 

My November Goal: "And Now For The Rest Of The Story"

My personal goal for November is to answer a question first and then ask if the person wants more of a story or explanation of why I gave the answer I did. This is my personal goal based on feedback. I was made aware of the round about way I approach my answers, thinking I have to give an explanation up front for everything I'm going to say when a person doesn't have context.

So for you reader, you have a choice. You could leave with my stated goal, and maybe point out to me when I ramble on too much or don't get to the point. Or you can read...

"The Rest of the Story"

If you grew up in a rural area, you probably know about Paul Harvey and the "Rest of the Story." They were usually fifteen minute segments which were often played mornings and weekends on many a rural radio station. Harvey would speak to his audiences with a lilting voice and an emotional tone that came through the radio.  Sometimes the stories were funny, sad, or taught a lesson, but they always had the same format: the hook, the commercial break, and then the rest of the story.

I was first introduced to Paul Harvey working as dish washer every morning from 6 AM to 8 AM before my morning freshman Biology class. Harvey would come on about 7 AM, and then the station would go back to the upbeat rock it played that kept me slogging through all the dirty dishes tossed into the service window.

That fifteen minutes annoyed the crap out of me. It stopped my mindless drone like work and interrupted my steady beats which would keep me going in the morning. After a few months of this, I learned to keep time by the interruption. I started looking forward to the segments. I would actually stop the dishwasher or time the dishwasher noise to make sure it didn't drown out the radio.

I eventually realized what Harvey was doing with his voice and descriptions. It was a style of storytelling that drew people in, whether they wanted to be or not. You couldn't help yourself after a while. It just happened.

In college you learn the art of using the right amount of BS and actual fact to get through any number of projects. Some of them, you become completely immersed in, others you could care less about, but the story or project needed to be done to get the grade. Sometimes I would pick topics I knew well and could expand upon, others I would research late into the night and then wonder how I would make a coherent, thoughtful, organized paper of the mess of journals, books and quotes I had amassed.

Somewhere between Paul Harvey, writing college papers and eventually working in mass media, everything became a story to me. I had to be able to tell a story in 30 second bites. I had to speak witty things over the intro of songs. I had to write a compelling story about a business and how they resurfaced bathtubs. I had to create headlines that would draw the reader into the story.

Through all of that, I think my answers to questions became longer and longer and I felt compelled to tell a story, on cue if need be, to any question asked. I've even had friends remark on the fact that I would tell these long winded stories that seemed to not have a point, or would get to the point finally and it would be anti-climatic - the story was better than the point I was trying to get to. Or they were so bored with me talking, they wanted to murder me with sarcasm if it only created a point out of the words I spoke.

I didn't realize, in certain circumstances, it's very annoying. Much like I was annoyed with Paul Harvey breaking in on my musical morning, I had become the very thing that annoyed me. I had become the storyteller and mostly, I had a witty, funny things to say. Other times, I just annoyed the hell out of people.

In mass media, it's a very useful skill to be able to create something out of practically nothing. To wax poetic on lawn care and make it interesting. To find the story in the most mundane things like carpet cleaners and shoe repair.

Jump forward to my current career working in the software industry, and no one wants a story, unless they ask for it. And sometimes they do ask. They do like to hear the history behind the process or discovery because it's interesting to see where things came from.

My problem is that I assume they always want "The Rest of the Story." without the commercial break, or the hook. And maybe it's my own desire to have all of the history or all of the story that I offer that has my narrative first.

Like as an example: "Here is this workflow, which goes like this and then I decided to do this and on a whim I added this. OH and this is where I found the defect!"

OK - so it's not that bad, most of the time. Often, I've filed the defect and then everybody wants the explanation they are too busy to read, which I wrote in great detail in the defect card. So one by one, I demo the defect over and over until it's so smooth I could practically do it with my eyes closed. To the product manager, to my manager, to my developer, to my DevOps guy, to the senior architect, to other testers on the team, to content design, to whoever else gets involved with the defect. They usually don't read the defect, they run to my desk and ask for "The Rest of the Story."

I've never pushed back on this behavior because it fed into my need to tell the story, and to extrapolate and expand and explain why the defect could have gotten in there, why it might have happened, why people are interested in it, how critical it is to the product to be resolved, what I can do to help resolve it and on and on.

I realize now, it's a built in behavior I've been cultivating for a long, long time. I'm a born storyteller. When you come to me and ask a question, or tell me to show you something, I'm going to do it because I LOVE, (seriously, in all caps, to the max) LOVE, telling the story. It demonstrates value at that very moment. It lets people see what I'm seeing.

What it doesn't do is put or push the quality back into the hands of people that need to understand why something I've reported is a defect. My personal feeling on this kind of occurrence, now that I understand more about myself and this habit, is that it's removing the responsibility for understanding the problem. It enables the assumed idea that quality is always with the testing group, but it's also keeps responsibility for a defect with testing, regardless of who the defect is actually attributed to.

My Plan of Action

A) Questions in Conversations.

• Try to answer the question first without elaboration.
• If elaboration is requested, try to make it meaningful and succinct. 

B) Direct Questions.

• Listen to the question.
• Ask for clarifications.
• Answer the question.

C) Long stories or explanations.

• Warn people before launching into a story or explanation which might take more than 30 seconds to explain.
• Offer the explanation but be OK with having the person turn it down or defer to later.

D) Dealing with quality issues.

• Don't demo the bug unless absolutely necessary. Pair with person asking for the demo.
• Expand on the explanation where necessary. Don't explain when not requested. 
• Be mindful of long winded explanations.

E) I will try to not apologize when I do speak too long or wander down the storyteller path.

Fear not reader. I don't plan on trying to snuff out this storytelling skill. I want to shape it into something more useful, more thought provoking and more engaging when it is used. I want to get away from "Here she goes again" and move to "OH, this is interesting." I might not get there in one month. I may never hone my storyteller skill the way I want to, but knowing about a habit, good or bad, is half way to the goal already.

And That's The Rest of The Story

Geek Mental Health: Therapy & the Art of Learning No

“You treat a disease, you win, you lose. You treat a person, I guarantee you, you’ll win, no matter what the outcome.”

 - Robin Williams

Where to begin a story with such a heavy title is always a little daunting. I thought for a long time about publishing this in a more private space, but I feel it's necessary to do it here, where people can read and identify with my struggle and their struggles as well.

I can't say that I've been successful over the years dealing with emotional issues and relationships with coworkers. They have been some of the hardest relationships to deal with all throughout my professional career. A lot of this has to do with upbringing, schooling, and my own personal baggage about what I perceived about myself and what I perceived the other person thought about me.

Life has not been easy. I don't say that to garner sympathy. I say it simply to set my perspective. I know, rationally, others have suffered much more than I have. I know rationally that I can acknowledge that suffering, and my own and find that really, it was not the most tragic or horrific of what the world has available for experiences. But, this experience is my own, I finally understand more about how I got to this point than I ever did at any other age of my life.

Codependency

There are at least two types of codependent people. The first in the constant victim state. It's the state someone lives in where everything happens to them whether it actually happened to them or not. It's a state of need that never gets filled, always feels empty and can't seem garner enough love and attention to feel valued. 

The second type is the fixer, the white knight, the people pleaser, or simply the "yes" person. I am the second type, the more passive, the less willing to say no, the gal that does it all, the one that will volunteer first no matter what is going on in my personal life. I have to fix things, rescue the fallen, swoop in and save the day. It is what I've always done best.

It's built up from a lifetime of learning a reward/response system, where in my head, cutting off my own arm is rewarding and I shouldn't complain about it, I should just do it, regardless of the damage to myself. My brain literally gets off on this kind of reward, a kind of self-harm, where my own physical and mental needs are second to someone, or to anyone else and what they need.

This can be reinforced in so many different ways, from the jobs you take, to the friendships which are formed, and even the intimate relationships you involve yourself in. These all feed into the reinforced notion that to give everything is what makes us the best, most perfect self we have. In giving we prove to everyone that we are worthy of that relationship, or job, or paycheck. Our worth is not focused on ourselves but only how much of ourselves we sacrifice for the cause, whatever that cause may be.

Mental Health & The Tech Industry

There are a lot of jobs were your mental health comes second to the job on a daily basis. Doctors, lawyers, nurses, teachers all have to deal with this in several ways. I'd like to add a large number of tech workers to this as well. The IT industry used to allow for a set pace and measured out progress. Once the computer game industry sped delivery up to a breaking point, the industry started to look for ways to develop at a much faster pace. 

This now leaves us with terms like Continuous Development and Continuous Delivery.  It's promising to a hungry tech world that there will be a constant 24/7 stream of new, shiny code just waiting for us to use, misuse, hack and then drop for the next release of bigger and better things. 

While many companies are taking a decent amount of time to get their products to market, they still release  with a lot of patches, a lot of updates which usually happen immediately after the initial download of the product. The market is flooded with mobile games which can be downloaded, played and uninstalled in a matter of minutes. 

{ If you doubt the affects the gaming industry had, watch the documentary called Atari: Game Over. The developer of the E.T. game, Howard Scott Warshaw wrote the game code in less that six weeks. The game was blamed for Atari's eventual demise. Not long after, the industry blamed Atari's downfall on E.T. and Warshaw. Warshaw later became a licensed therapist and now councils many who work in the tech industry.}

It's awesome in a lot of ways, but the downside is the cost to some of the people involved who are brilliant but become burnt out way too quickly and leave IT for other industries less demanding of their time and allow for a more creative pace. If you don't leave, there are other harbingers waiting for you, especially in the mental health department. 

The industry has made strides in trying to balance the work load and life, but in some corners, there is still a lot further to go. Depression and substance abuse are not the only mental health animals we should be worried about in the IT industry. The industry should also be worried about the more subtle problems, sometimes easier to hide problems many of us have like anxiety, OCD, autism, ADHD, ADD, social awkwardness, social dysfunction, eating disorders and even codependency. Many of us with these traits have figured out coping mechanisms do deal with the worse episodes. Sometimes they involve owning too many pets, other times they can involve more self destructive habits.


For me, learning skills of how to say no and protecting myself from pushing past a breaking point were not easy things. I still don't like saying no to people. I don't often think of myself first. What has been a good crutch for me are my dogs. I find it easier to tell people I can't do something because I have another responsibility. They keep the "yes" me in check at times. I can also compromise better because of them. I can say things like "I can do that, but I will need time to make sure my dogs are OK, is that OK?" Often, that small amount of time to check on them gives me the space I need to recharge, keep worries at away and do an effective job.

What my dogs can't help with is the "yes" part that pops out during meetings and in conversations where I constantly have to try to solve the problem at hand, even if I'm not the best person to do that. I blurt out the first thing in my mouth or my head. I have an extremely hard time stepping back from that instinct. I have to constantly monitor myself to make sure I'm not stepping on someone else's voice, or that I'm not just talking to talk. I empathize too much. I listen too well. I hear the pain in someone's voice and my first instinct is to offer help instead of helping them help themselves.

 It's the constant need to want to please and help people which made me a great customer service person and makes me really good tester, but sometimes it's annoying to teammates and other folks in meetings. I've learned to wait, repeat what I'm going to say in my head and if it doesn't make sense or the moment's past, then I let it go. Or I can ask for a redirect in the conversation to get back to that point if what I think is really important and I want to talk about it.

The other side of that "yes" trait is the ability to speak up and speak out. I don't stay quiet, I call out issues when I see them. I make it known when I'm not happy and when others aren't happy. I track down problems. I try to track down others who can help with those problems and work with people to get to the root and figure it out. It lets me be a very effective problem solver and someone that likes to get things done. Those are all very positive traits from codependency. I try very hard to keep those while mitigating others that are more troublesome.

The Challenge Is Ongoing

When you live with any issue, whether it's physical or mental, and you finally get fed up with what it does to you on a daily basis, you seek out help. For me, it was somatic therapy which helped to put me in a better mental balance. It helped me understand why I say "yes" to so many things and how my "no" was broken by circumstances mostly out of my control.

It taught me to recognize my emotions instead of bottling them up in a dark, safe place until the space was too full to manage and something broke. The emotion didn't matter. It could have been anything. 

It has taken several years and a lot of work to figure out what exactly I needed to understand about myself and what I need to work on which would allow me a better balance in my relationships with myself, with my work, coworkers, friends, and family.

There are moments of excitement I still blurt out things without organizing my thoughts, where I say "yes" in the moment rather than thinking my answer through. I've  gotten a lot better at catching myself when I do this. It all takes practice to re-frame your wants and needs to be center and in focus rather than keeping them barely in the picture. I still struggle with feeling selfish for the smallest things which most people don't have qualms over in the least. Hopefully I will get to the point that it doesn't seem weird to me to say "no". With any challenge, as most people know with mental health issues of any kind, you take them one day at a time.

The Tech Industry Takes Notice

If you weren't aware of it, starting on October 3rd, there was a whole week for mental health in the IT industry called Geek Mental Health Week. There are a bunch of great articles, hashtags, and events during the week to highlight mental health in the tech industry. It's the third annual Geek Mental Health Week held for the industry.

I recommend checking out the articles at Geek Mental Health, and even checking out the community and podcasts at Geek Therapy. Also check out Open Source Mental Illness online or on twitter @OSMIhelp. These are great organizations that work in the tech community to bring awareness to the struggles the industry has with mental health issues.

If you are struggling with thoughts of suicide please contact your national hotline:

                                       International List of Suicide Hotlines

The NeverEnding Story & Why I Don't Always Do What I'm Told

I'm not typical rebel. I don't purposefully set out to piss people off. However, I've lived most of my life with people telling me or commenting to me in one form or another that I can't do this, or I'm not capable of doing that because of something they see, or perceive, that I refuse to acknowledge as a limitation.

We all have an inner strength that can propel us forward to do some pretty amazing things if we can wade through an amazing amount of bullshit first.

Swamp of Eternal Sadness

It's the equivalent of trudging through the Swamp of Eternal Sadness. The first 100 or a 1000 steps can be OK, but there is some point that one of those steps breaks you down where you nearly give up until a version of your Luck Dragon saves your ass.

Going to work everyday can turn into your own Swamp of Eternal Sadness, or worse, the Nothing, with the wolf chasing you. I've lived through different managers from different careers telling me I'm too opinionated, too loud, too angry, too something-that-annoys-someone and I immediately try to modify my behavior, only to have things become worse, because I'm not true to myself and people instinctively know that. They don't know what the manager told me, but they know something is up. 'She's acting different', their eyes seem to say. They don't like the difference, and they are not sure what it is. Often, it translates into a lack of confidence and a loss of trust with my coworkers.

Some of my best managers have taken those traits and steered them into more productive endeavors. "What are you upset about, is there a solution we can work on?" "Learn about public speaking!"  "I get that you are angry, how can we work on this to make it better for everyone?" "Keep speaking up, everyone else is too quiet in meetings, maybe they can emulate you." "Have you practiced listening skills lately?" "What could we change going forward that would be a positive impact for everyone?"

I'll be the first to admit that I'm an extremely passionate person about several topics. It's those topics specifically which can result in wonderful discourse and learning or disastrous heated arguments in which neither side feels validated but rather violated. Some people call them triggers, which is true, they can be. I like to call them learning moments. Whether positive or negative, I take something away from that exchange. I learn from it.

The Last Grain of Fantasia

What I try my very hardest to avoid now is muting what I see as a valuable part of myself.

I was given advice recently on how to dress and act during an interview. It was from another professional and friend that meant well, but the more I listened, the more I realized that the advice she was giving me, wasn't me.

I talked to other friends and professionals, and I found, it wasn't just her giving me this advice, it was a large majority of people who were telling me similar things.

• Don't wear bright colors
• Don't be emotional 
• Be pleasant and don't speak first.
• Don't talk about failures honestly
• Don't be completely honest
• Play the power game
• Make eye contact but not too much
• Don't be yourself. 

I hadn't asked for advice on interviewing before. I generally do fairly well, but this was an important one, and I was pretty nervous and excited about it. I wanted to put my best self forward. Other advice I received was more positive.

• Don't lie
• Be exactly who you are
• Be comfortable
• Be engaging
• Talk about the best and worst things in your career honestly

Fear can be a healthy or unhealthy motivator to do something or to change something. I, thankfully, have developed a better sense of self over the last few years. I perceive I understand what my own personal positive and negatives are. I also think I can use those to my advantage and challenge myself with my own flaws. The first list speaks of fear and not being true to who I am. The second list, the list I followed, spoke to me. It was confidence, experience and trusting the people that were interviewing me. I realized that I couldn't work in a place that would want me to act like that first list in an interview. I don't know that I've ever followed the first list of rules either. It just doesn't put the best version of myself forward, emotions, characteristics, flaws and all.

My mistakes, my personal flaws, my imperfections are exactly what I use to make leaps forward in my life, in my career, in my own personal goals. Lest you think my ego is getting in the way, and I'll admit, it might be, I take these things very seriously. I don't immediately or automatically convert these flaws and mistakes into 'wins'. Over time, I think, and study, and I seek help in some cases. I work through issues using them as challenges to overcome, discover, and reinvent myself. Allowing space for something new. Allowing that, yes, I have some limitations, but what can I do to work past them? Should I work past them? Can I use them as they are? Are they limitations, or what other people have told me are limitations and I've accepted them as such?

In Ken Norton's newsletter, he writes about Jazz musicians and provocative competence. He states over and over that musicians, at the top of their game, were constantly looking for that mistake that wasn't being explored or exploited. They were always pushing themselves to do something new, barely structured and fairly off-script. The biggest motivator I see from these examples is self-reliance and self-confidence. They understand what their own strengths are and use those, and even sometimes they use their weaknesses to bring something new to the table, and to their profession. They also use this to help others around them, allowing others to follow or even lead from that opening they created. It's willingness to throw the routine out the window and become uncomfortable with what might happen next.

To have the willingness to walk into the Swamp of Eternal Sadness with confidence, trusting that somehow, you can make it through to the next challenge. Hell, you might even save the day.

That's No Game! It's a Project Management Trainer!

"A strong woman looks a challenge dead in the eye 

and gives it a wink" - Gina Carey

About a week ago, I bought a game called Planetbase. It was part of a Humble Bundle I purchased with several other games that hopefully I'll get around to, but right now, for a lot of reasons, I'm really digging this game.

It's based on colonization and sending a bunch of people to a barren planet to set up a base camp. They have different planet types that you can unlock once you reach a certain amount of successes on the previous planet type. You have a crew and starting resources, but you have to get to the survival stage and then self-sustaining fairly quickly or the crew starts having problems, you start running low on all kinds of things like spare parts and bots and sometimes even people. 

The opening mission is on a Mars type planet. You can pick anywhere on the planet to start your base and the idea is expansion for as far and long as you have resources, colonists and room to grow. It really is like a Sim game in a lot of ways. Until you get to the challenge section.

I started the first challenge Wednesday night. It was pretty simple:

Scenario:  Accumulate 100 ore

Given I have 5 people (2 biologists, 3 engineers)

And 9 robots (4 drilling, 1 construction, 4 carrier)

And a limited supplies 

And only trade ships available

Then I should be able to accumulate 100 ore

What you find out when you click into the challenge is that the game has removed abilities. The first limitation you are told when you enter the challenge, no more colonists than what you start off with. You lose someone or a bot, you are probably in for a rough ride.

This is from normal game play - but it's still a cool day shot.

Working Towards A Goal

As you can see from the gherkin above, I had to manage people, robots and resources. When you get into the challenge, you realize it's also removed any way to make building materials from the raw sources you produce. So you either have to trade/buy the materials or recycle them from something else. It also disabled any way for you to build more robots. If I wanted more, I was going to have to trade or buy them from the trading ships. 

One of the first things I did was recycle the construction bot and two carrier bots after the initial construction was done. More building resources! Yeah! 

With limited resource come limited ways to produce power to power everything, and store energy. My first problem was with the power grid. I had enough resources dedicated to it until I realized I was going to need a landing pad, and I couldn't recycle anything else. I had used the resources I pilfered from the bots to build out a bigger power grid and now, I was going to have to adjust that, and use what I had left to build the landing pad, or I wasn't going to have a way to get trading ships to my base. I recycled one of my solar panels to build a landing pad.

This is a great example of making initial decisions and the modifying them in the iterations that come later. When something looks acceptable, and then a customer or a tester detects an issue, this triggers (or it should trigger) a triage process by which resources and people can be moved and pointed at the problem. And then, solving one problem can lead to another.

Night shot of Ice Planet Colony (called it Hoth Rebel Base)

Because I took out part of my power grid, I was had to manage the power resources during the night cycle. I had one turbine that was there when there was any wind, which was rarely, but enough to keep producing energy. The real energy makers were the solar panels. I would shut off solar panels and even the landing pad to keep power for as long as possible. When I later added storage areas for the raw materials, I would shut off power to those as well. I also would shut down a mine if a bot wasn't working in it.

The power management problem, produced previously by the landing pad problem is pretty typical in project management. If you take resources or people away from a project which had a balanced, predictable cadence of production, you have to compensate in other ways, by reassigning people, moving other resources or limiting/restricting access to a resource so it isn't used up too quickly. This is project management basics. Mistakes aren't mistakes, they are really just resource problems. It only becomes a mistake if you can't compensate fast enough with another resource.

 Once the trading ships started showing up, I traded off any extra I thought I could safely trade away for building materials, semi-conductors or other needs. Eventually I was able to build out another storage unit, another solar panel, and other power collector and a second robot repair station. At this point, I was about 75 percent done with my goal. And my project was self-sustaining. I walked away for 15 minutes to do other things around the house and came back. All was well. I completed the challenge with 100 ore, all the people and the robots I didn't recycle, and had a few resources left over.

When projects hit this point, of self-sustaining, you basically watch for any serious issues, but it becomes a hands-off affair. Everybody knows the goal, knows what they are doing, and progress is reported on a regular basis. Progress can and should also be verified. In this game, it was seeing the storage rooms fill up. In the real world, it's demos, releases, defect reports and product sales/usage. This is the time when you start working towards your next goal, setting up for the next project. It's the quiet before the next storm. 

All of this is people and resource management. It happens every day in every business on every project imaginable. The trick is knowing who to put where and what to use to get the job done. If you are any good at these games, then you might have a career in project management. You just have to learn how to deal with real people instead of the meeple that run around in your sim. And that's a different blog post. 

#ChangeTheRatio - More Voices In STEM

"Remember Red, hope is a good thing, maybe the best of things, and no good thing ever dies."

- Andy Dufresne, Shawshank Redemption

Not so long ago, I jumped out of my comfort zone and into a group of lady developers, developers-to-be, and even a few testers, like me, in that group of women at a meetup, all hoping to make a difference in the day-to-day practices of software development. 

That group was Women Who Code. I also have to acknowledge that I wouldn't have thought to do that without the stalwart support Ministry of Testing, another group, run and promoted by a woman named Rosie Sherry. That group is constantly pushing forward creating a presence and acceptance of the testing profession as something valid in the software development world, and they are huge advocates of inclusion of women into the testing/development arena.

I'm on a Skype channel which has voices and new ideas from a wonderful group of ladies every day. They are from all walks of life, all over the planet; a 24/7 channel of ideas and support for women working in the testing profession and the tech industry. They advocate, discuss and disagree and have a large amount of hope for the future. I think most women do. 

From the young 20-something navigating a world, to the 40-year-old professional looking at reinventing herself, to the retired woman who did the work, got little recognition for it, and is still active in the community, we all want to change STEM for the better.  

Today, I applied for CodingHouse developer scholarship. It's a 14 week in-house program in which you live, eat and breath coding.

Testing is changing. And unfortunately, many of us are finding we aren't changing with it. Or as fast as we would hope. It's the classic problem of learning and working at the same time. The one that feeds you is going to get the priority over the one that extends what might feed you. 

It's not that I haven't been trying to learn, but I feel like the minute I focus on one thing, the next thing is hitting the shelves and then the next. I'm excited about these changes, and excited it's getting easier and easier to learn how to do all of these things. 

But what should I learn? Is Java more important than Ruby? Should I focus on back-end services or front end tech? Can I learn it all and still do a good job? Do I focus on this one thing, and learn it completely, or can I take concepts and move them from one thing to the next? 

I feel like I'm missing the Rosetta Stone here where coding languages are concerned. I feel like I'm being aged out of an industry I've loved for years. But I'm out here, pushing, trying and continuing because I can't stop - won't stop. I love this too much to stop. 

If you're out there, whether you're young or old and love this industry, tell your story. Get it out there, let other people, especially women, know they aren't alone. It may take time, but it's going to happen. Women are here to stay and they aren't giving up hope.

Are You Thinking About Attending a Conference?

"I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel." 

- Maya Angelou

I've been extremely lucky in the experiences I've had at conferences. The last two years have been wonderful in the quality of topics, an excellent environment of learning, and the peer relationships I have built with those who attended.

TestBash NYC was a one day conference put on by the Ministry of Testing. I had the opportunity to go via a contest, where I wrote an essay which won me a ticket. It was eight hours of topics presented by wonderful people, many of whom I still have contact with today. {Here is a link to the essay I wrote about the conference itself.}

I also met other people who are industry leaders, thought leaders and testers, and had great discussions about topics, all relating to testing. The overwhelming feeling of community stayed with me long after I went home. I still talk about that experience like it was yesterday.

So this time, I want to talk about several conferences, if you are planning to go to one, or want to go but aren't sure which ones are worth the money and time. Here are a few I would suggest you check out no matter where you are on the planet.

Test Bash  - any Test Bash, there are four of them now! Get to the one nearest you and have your very own mind nova! The Ministry of Testing organizes these and I can tell you this group of people are about developing the community in ways that will definitely shape the industry to come. Passionate people about their profession and the time they invest in content and community shows in this showcase of talks and talent. The next one is in Philadelphia, Pennsylvania and it's shaping up to be pretty epic!

European Testing Conference (ETC) - this was another one that had a good mix of people who have roots in Ministry of Testing. There are others involved with this conference that made three days in Romania some of the most mind opening and educational days I've spent in another country. The organizers are wonderful and understand what it takes to have an event succeed. They are also mindful of the cost to speakers and those that attend. I'm very glad I had this experience and I wouldn't hesitate to recommend this conference which will be in Finland in 2017.

Agile Testing Days - Seven days of testing and development heaven with some of the worlds best and brightest speaking and exchanging ideas. I have not personally attended one yet, but it's on my bucket list. This year it's in Berlin. Next year it will be in Boston, and I hope I can attend. There are smaller events around Europe and I recommend those as well. I've heard nothing but good things from people attending the smaller conferences. And a great number of good things from people who attend the week-long one as well.

If you are planning on attending Agile Testing Days in Germany and would like to receive a 10% discount, use the following code: MelTheTester_010 - full disclosure, for everybody that uses my discount code, I have the chance to get a conference ticket. So if you haven't purchased your ticket yet, here's a good discount!


Regardless of what conference(s) you choose, go with an open mind and get out of your comfort zone and meet some of your fellow testers. The experience will stay with you for years to come.

I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.
Read more at: http://www.brainyquote.com/quotes/quotes/m/mayaangelo392897.html?src=t_learning

I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at: http://www.brainyquote.com/quotes/quotes/m/mayaangelo392897.html?src=t_learning

I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at: http://www.brainyquote.com/quotes/topics/topic_learning.html

I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at: http://www.brainyquote.com/quotes/topics/topic_learning.html

I've learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel. Maya Angelou
Read more at: http://www.brainyquote.com/quotes/topics/topic_learning.html

Finding Allies in Testing

 

Hello World! Hello Friend!

   It can be a lot to take in when you first move into a new environment, with a new job, and new applications to learn. Some of the basics are the same, but the little things, the details that matter, that do trip up users, are the issues that you need to learn quickly to make headway on any project with longevity.

Maybe you aren't the best tester for that particular product, with a lack of knowledge, but you want to be. How do you get to that point? Reading documentation can get you part of the way, but that can be time consuming and often out-of-date.

How can you get the latest and greatest info, and understand some of the pain-points your app users are going through without necessarily doing an intensive week long training pouring over every inch of GUI and code available? Well, if you have other testers on your team, that could be as easy as doing some pair testing sessions with them to get up-to-speed. If you don't, where could you go then?

Customer Service Reps are an ally

For anyone with a team or even the lone tester, if you don't have deep knowledge of the application, the next stop for you should be your customer service department. Whatever the CS manager will let you sit in on or experience with their CSRs, do it. Plan to shadow calls or chats. Sit in on trainings they have. Talk with feature experts and get their first hand knowledge about the app and about the users.

Not only does this get you valuable information right from the start of any kind of job, this also develops a model of goodwill and trust with the customer service people. This alone is worth it's weight in gold. Having a good reputation with the CS team, means they will communicate with you trends that they see happening with the application, or customer complaints that could give you valuable information when looking at the next feature story or upgrades to an app. If your acceptance criteria could affect things with customer service, having a customer service viewpoint could be invaluable for that feature story. Working on defects becomes much easier having access to the person that wrote the defect and understanding the customer that reported it.

Go out of your way to understand this team and you have created the best ally you can have in the fight to raise the quality of any application.

Professional Trainers are the Front Line

If you are lucky enough to have a customer service team and professional trainers who routinely go into the field and demo your product, or perform the set up, definitely find a few friendly ones that are willing to share their experiences.

Professional trainers could be training users with different parts of the product. Especially areas that deal with billing or finances. They could be doing setup and initial on-boarding for a client that doesn't have the internal structure to train people to use the application they want to use. {Often this happens in the domains of education, health/medicine, logistics,  human resources, finance. There are probably others, but those are the ones I have experience with personally.} Going onsite with a professional trainer can be a wealth of information in observing users and understanding the questions users are asking. Those questions should serve as beacons for testers when looking at usability and accessibility for their users. You also gain first hand information about issues rather than waiting for the first draft of the story or the first draft of the feature code to land on your desk.

In return, fostering a relationship with a professional trainer can give them credibility when they talk about the product with first hand knowledge from the development team. Communicating in an informal way, letting them understand the process the development team is in can give a trainer ways to help work around current issues they might be having with the app. This can also foster a better client relationship for the professional trainer since they can say they know someone on the development team that is willing to listen to issues.

A Story: I once sat in on a professional training session for medical software. They were demonstrating the billing section. I had used the application for a year or so now, and I was one of the main people testing the billing section with the updated reports and transaction logs. I went to the training because it was offered to the company, not just the other trainers, and I thought it would be a good way to get more knowledge about what I was working on as well. During the session, the trainer presented the workflow and I was surprised. How I had been taught internally to use it, wasn't at all the workflow the users were using or the trainers were training. I showed the trainer the workflow I knew  and she indicated users literally couldn't use it that way because they needed to wait for a 3rd party process to happen before they could go to the next part of the workflow. Also, the order of the tabs were not it the process order customers were using, making the workflow even harder for users since they had to wait for this 3rd party acknowledgement to happen. Our internal tool, that mimicked the process of the 3rd party inadvertently caused us to change how we were using the billing section for testing. When I brought this information back, people on the development team were as shocked, if not more so, than I was to discover this issue. They wanted it to be easy to use, and thought it was, but we had made it harder without realizing it. Doing the professional training suddenly became a value add and more people were encouraged to go to the next one.

Product Management/ Product Development are Natural Advocates

 I haven't worked a job yet where the product management team, along with business analysts and product development folks, {or whatever flavor you have driving your development cycles} lacked a deep product knowledge and customer understanding. This knowledge is absolutely valuable and when you are on any project, and some of the best, most immediate answers to questions usually come from this team of people doing market research and study. They hope that decisions they are making will further the future of the product and be profitable. They often comb through defects, understand what usability problems plague users {and already have ideas to fix them}, while maintaining a high level knowledge of the tech stack and talent pool they are working with. I have personally worked as a business analyst for a week, writing up two stories, researching issues that might come up and then dealing with all the questions and acceptance demos that resulted once those stories made it to the pipeline.

Another Story: I will never, ever say product development or business analyst job is easy work. First of all, you have to be able to write effectively, communicate with developers and management on two different levels, and think about how to resolve problems that come up during the development cycle. And if your solution wasn't correct, you have to own that too. I once covered a BA's vacation. I created two stories, based on defects we had in the backlog. I wrote the acceptance criteria and even created some screen shots about how I thought the UI should change to fix those issues. I'd been doing QA for about four years now and thought about switching to the BA position because I can write pretty well and communicate well. And it seemed like a way to add another level to my ever growing skill set.  Writing the stories was the easy part, and that was still pretty complicated. They were reviewed and PDs asked questions about my requirements and acceptance criteria. Both stories went through several revisions. But once they were done, the real work started. It took about three weeks before they ended up in the development pipeline. I was responsible for seeing these two very small defect fixes through to deployment. I was asked questions on a regular basis for two weeks. I even attended the scrum meetings for the team the stories were assigned to. This was all while I was doing my own testing work and attending my own team meetings. I can say, without hesitation, that shit is hard. You have to be on point in meetings and you have to have answers in a reasonable amount of time. You have to have your team trust the answers you give them and you need to trust their feedback. It's a lot of freaking trust. A lot. Anyone that says otherwise is bullshitting or doesn't understand the amount of work needed to make sure one story, let alone a whole project, works and won't mess up other pieces of the puzzle. Additionally, if you are bad at product development, it shows, faster than any other job on the development team. It's a lot of pressure and I have a lot of respect for people that stay in that role for a long period of time.

I know for a certain that you can work with your product team to gather more information or understand usability problems. They should be a go-to source for any tester, any developer, really anyone on a team, for product knowledge. That might be stating the obvious, but sometimes that has to be done. People forget that they have access to someone that can help and you can certainly help them. Cultivate these relationships and keep them going even after you move onto another team or another company. You never know when someone might have knowledge which can help you solve a problem.

The Valued Customer

If you can have customer contacts, absolutely make them. Customers can be a wealth of information and knowledge about your system under test. They might not know all the in's and out's but they can tell you what they like and don't like about the product. Getting this information directly instead of via Customer Service puts a face on the users. When you ask the users questions and they can answer because they know the domain they are working in well, and they can see what you are trying to do with a product, you are getting insight into your user. Some companies advocate "Dog Fooding", and that's OK too. But the biggest problem with that is you know too much sometimes. You know more than a normal customer, so it's easy to dismiss minor issues because you might know what's causing them or that they might never be fixed. But those are the things you should go after and advocate fixing, even if it's only a minor annoyance. Those minor things can turn into major losses depending on the product and the customer.

The more contact you have with customers the more your work means to them as well. They might not understand what you do in software development, but they understand that you are trying to make the product work for them. They will tell you things they might not tell a customer service person or even their sales rep because you might listen more or be willing to bring an issue up in a product meeting when you can.

A Small Caveat

Be somewhat careful with cultivating these relationships to not accidentally circumvent a process or divulge information which shouldn't be used outside of the company or a department.The goal here is to be cooperative and open, but not so much that the relationship becomes an issue and the company takes steps to mitigate or manage contact between the departments or people and customers.



Allies are everywhere, if you understand what you are looking for and who might best help you with your questions, they can be easy to find. They are also some of the best unskilled testers available. They use the product just as much as you would, maybe even more, and understand things at different levels that could give you valuable insight. That insight alone can be your first line of defense in preventing defects and a poor user experience.