Quardev

One of Quardev's foundational core values is "Absolute Integrity, Absolutely." The theme of this issue of the Quardev Quarterly is trust and how it is developed with clients, advocates, co-workers and the general community. Holding ourselves to an absolute standard that integrity must be a part of all our interactions contributes significantly to the trust we've been able to build in these areas and has helped us maintain our 100% client return rate - a solid statement of trust.

Thank you for reading the Quardev Quarterly. We hope that some of the viewpoints we've been able to share in this issue will give you more insight to some of the ways we operate and may help you in your daily work life. And, of course, Happy New Year! We wish you all the best of health, happiness and success throughout the coming year.

Enjoy the newsletter with our compliments and please contact us with questions, comments, or article ideas.

All our best;

-The Quardev Crew!

Download the Quardev Quarterly - Q1 2008 PDF

Building Trust with Customers

By Jon Scherrer, Business Development Manager, Quardev, Inc.

There are quite a few books and articles written on trust. Some focus on what it is, others on how to build it, get it, or give it. So rather than spend the time defining it, I'll give you some insights in to how a veteran salesman views trust. For me, there are four elements of trust; history, commitment, authenticity, and norms.

Since trust is a forward emotion, it makes sense that the more we know of someone or something, the more accurate our prediction will be on their behaviors, desires, dislikes, etc. The ability to view a situation within the context of history helps us build confidence on a future outcome - basically it helps us trust. An example of how this might be applied would be the allocation of resources or time to a given project that is being proposed by managers X and Y. If manager X has provided six proposals in the past, and half of them have lost money, while manager Y has provided twice as many proposals and more than eighty percent of them have been home runs you would tend to trust manager Y's proposals over manager X's. Of course there are a lot of 'what ifs' and contextual questions that could come up, but I'm sure you get the idea. So the key for sales is to build a cachet of good experiences with a client and if the relationship is early in its formation, to offer up examples of other relevant good experiences - references basically.

Commitment sometimes gets confused with conviction. The difference is that commitment is a variable state; whereas, conviction is a constant, unwavering belief or state. In the world of business (and especially sales) you never have the luxury of a customer who is buying based on conviction. So how do you get commitment and how do you raise the level of commitment in relationships? It all starts with you. How much time, energy, and effort are you (and your organization) willing to spend understanding your customer? An interesting side note, the majority of people are most comfortable working with people that are like themselves. And here is where many salespeople lose it. They either want to control the relationship or they make a half-hearted attempt (usually in a vacuum) to match the right product or service to the right problem - basically forcing a square peg in to a round hole. True commitment means understanding and having empathy for the other person or organization. Ask questions such as: what are the things you fear the most, how can I help, where and how should I fit in the solution? And my favorite is spending time and effort to learn your customer's inside language, acronyms, and culture.

The efforts you spend on commitment can all be washed away without a solid level of authenticity. It's my belief that you can teach anyone the basic skills to business or sales, but if they misuse or abuse them then you won't build trust. I've always laughed at the phrase "he is such a great salesman that he could sell ice cubes to Eskimos". First of all, if he was such a great salesman he wouldn't try to sell what's not needed, secondly, the ability to get reoccurring revenue from such a model would make him the lowest paid "best salesman" around - I'd much rather spend my time in the Bahamas right next to the blender salesman. Authenticity is a cultural thing. If your company has it, there is a good chance that your people have it. If one or the other is missing it, you might have a lot of frustrated people on your hands.

Finally, norms are also an important element of building trust. They are the social contracts that we make with ourselves, our co-workers, our customers, and our colleagues. Norms can be formally stated or agreed upon at the beginning of a relationship; such as communication elements like status reports or weekly calls, or they can develop over time. In either case, norms are critical in establishing what is acceptable and what isn't. Since trust is a forward emotion, trying to eliminate the potential for miscommunication and confusion up front is important. I also like to build in a '911' norm such that, if stuff hits the fan, we agree to seek clarity on the situation and then build a solution together.

If you want to build trust you need to build history. In the absence of history, you need to build a framework that allows for a level of predictability. References or industry stories told by others (who are credible) about you or your company can help open the door. Once the door is open, you should take the first step towards committing yourself to the relationship - learn the culture, the pain points, the success criteria, the acronyms. And allow your customer or partner to understand you and your requirements and do this authentically. Finally (but not necessarily linearly) create and agree to a set of norms on how you will communicate and treat one another. And once it is working well, make sure to stay committed and fresh to the relationship, not convicted to it.

Building Client Trust

A Short Interview with Rob Sabourin by Jon Bach

The following is a short interview with prominent software engineer Rob Sabourin. In 2004, Rob called us [Quardev, Inc.] as a consultant needing a test lab to do a short project on short notice with high stakes for one of his customers. The success of that project led to several more projects and a long relationship between him and Quardev, to the degree that he is Quardev's main Partner Consultant. I asked him to talk with me about how he builds trust in his consulting business, Amibug.com.

Jon Bach: Do you go about building trust with your clients the same way? Is there a formula?

Rob Sabourin: I don't look at it like a formula. In the world of quantum mechanics, for example, you don't look at vectors and forces, you look at energy. You deal with things like how much energy a system has and how the energy moves between systems. You look at things in a different way than you do in Newtonian physics. I look at things in a way where I can learn if I am in sync with fundamental principles with my customer. I see how their goals are aligned, how they see their role in the community, and how they act as a community. I also see how they deal with people, how they deal with opportunities. If it's in alignment with how I deal with things, I will see a long, healthy relationship.

JB: What makes you come to trust people in business?

RS: That's hard to answer... but each has a story around it - a shared experience with each where we've built something together. For example, I trust Scott Barber because he and I ran a peer conference. Because of that collaboration, we learned about our core values. Even though we don't agree on everything, we built a relationship based on that. In the long run, if something comes up, you can get someone's advice or support, and work that you might not do, you can trust someone to do it.

JB: Sometimes we have to take a risk, though...

RS: Right. Sometimes you take a risk, take baby steps, collaborate on one thing to start. If that shows you have harmony and values, then you can move on. If not, you can step back and move a different way. In one case, I didn't like a contractor's style and approach, but I was forced to deal with them even though I was totally out of sync with them. They were basically approaching testing and bug-finding from a very different perspective - making up requirements and asking my customer to sign off when the customer wasn't knowledgeable or aware of what they were doing. It created an ethical dilemma for me that I wanted to resolve that before I did meaningful work for them. Now, I look for those things - "are those real requirements or are you hiding things you just got a customer to sign off on?" In the long term, good will is built by consistency. Inconsistency does the opposite, in my experience.

JB: What about in the short term? Like on that initial call?

RS:

I've learned that you can't. Some people have mastered skills of argumentation beyond belief, and can flim-flam you into all kinds of false notions. I would be careful. I'm not saying first impressions are good or bad, but I don't want to build trust on one or two conversations. The main thing is to be honest.

JB: Do you have an example?

RS: I was contacted by a customer about whether I could do training for software security testing. I immediately said, "I don't have any expertise there. I know a lot about software engineering and quantifying quality factors related to that, but it's far off from anything I would consider myself an expert in. But why don't we just talk?" We had a conference call, (the reseller, the customer and me) and I said "as a software engineering manager, when I was confronted with a similar problem, here's what I did..." They were impressed and I got two contracts based on this - not teaching them how to do security testing at all. I didn't pitch them something they didn't need.

JB: So you don't necessarily look at what the customer is asking, but what problem they are trying to solve.

RS: Listening is important. People create models of what they *think* the problem is, but when you get into a dialog about it, it makes them more comfortable. That word "comfort" is a key to building trust.

Trust Between Programmers and Testers

Jon Bach, Manager for Corporate Intellect, Quardev, Inc.

Seven years ago, I was interviewed for a sidebar to an article Bret Pettichord was writing titled "Testers and Developers Think Differently." The article focused on the different attitudes that testers and developers must have to complement each other on a project. I was happy to contribute, because I believed the mentalities of a developer and a tester were very different, and needed to be.

For example, even though I had only been in the testing business for a few years at the time, I knew I didn't need developers to think about how the thing might break - that was MY job. My job was to imagine, model, traverse, conjecture, discover, learn, explore, juxtapose, resource, configure, branch, combine, deconstruct, hypothesize, corroborate, refute, observe, infer, examine, record, and report.

But I had a problem. Testing was too much fun. When I found a bug, I celebrated right away, with the testers around me, too. When something even looked like a bug, I would happily say what I saw... "it IS this" or "THIS is the cause." I was paid to test, and finding bugs was what I was good at.

The problem was, I would usually be proven wrong in my logic. The bug I saw was not the bug that was. I hadn't known the difference between fault and failure, nor did I have a strong understanding of what equivalence classes were.

Yes, that's the reputation some of us had on the team. We'd compete with each other to find the best "something strange," and we'd celebrate and file our reports as fast as we could. Management encouraged it, and we rarely took the time to investigate further.

For example, if I found that a certain object in the UI was not appearing where it should be, I used to file the bug as: "Record X is not appearing."

Even during the rare times I was proven right about a bug, the developer would show me an even betterbug I missed had I not stopped testing to celebrate my find.

I hated that feeling more than any other. Here, a developer was finding a bug I should have found!

So I started practicing safety language.

When I found something strange, I would say "it seems like...," "it could be that...," and "it appears as if..." when talking to the programmer. That way, when I was wrong, it wouldn't be a surprise to either of us and I'd wind up learning something without them feeling that they were having to school yet another one of those righteous, clueless testers.

After being open to schooling (and stern lectures at times) by programmers, I started to understand the importance of finding the underlying fault instead of just the surface failure.

After a lot of mistakes and a lot of practice balancing my humility with an earnest need to learn once and for all about why code behaved the way it did - I started to notice something. When I filed bugs, the developers started to believe me. They saw me not as someone they had to believe because I was paid to find bugs, but someone they wanted to believe.

When records didn't appear, I made sure to squash my celebration at finding the bug, take just a few calculated breaths, and try some deeper tests instead of rushing off to file what I knew. I'd open SQL Query Analyzer to find out if the record even existed in the database. If it did, I would check the log files to see where the record was last seen. From that, I could make sure I had the right build in case it was a compatibility problem. Could it be a corrupted managed-object-file at the outset - the thing that was supposed to instantiate the record in the first place? Could be a network protocol problem?

If I asked more questions of my test results, I found the developers would ask less questions of me, and soon I began to feel that a bug wasn't something to trigger a celebration in me, it was something that invited me to a bigger mystery that needed my help to solve.

I wanted to be of better service to developers, so I started asking better questions, and doing deeper investigations. To my surprise, management encouraged this, too, because although they knew speed-of-filing a bug was a good trade-off for depth-of-investigation, building trust with Development had its merits.

In return, I wanted to trust the developers. There were times they lost trust with me - checking in code they said that they tested, but that broke existing function. Or, checking in something they knew was broken only to have me file a bug and get the reply "Known issue," flagging bugs as fixed when they weren't.

So it is, years later, this trust "thing" between Dev and Test. I want to believe them when they tell me something is fixed, and I want them to believe me when I say that something here is a problem (or could be). Though complaints about walls between Dev and Test indicate sever pathologies in project communication, I don't need there to be NO walls between us. After all, we need to think differently. Let me reverse engineer, destruct, and find while you design, create, and fix. The right hemisphere of the brain and the left hemisphere have very different characteristics and assignments, but work together to make small even the smallest tasks possible.

Today I teach testers how to do deeper investigations once they find a bug. Celebration is still ok, just tempered with a healthy does of anticipating what the Developers may ask them about their bugs. "A failure is just an invitation to a deeper investigation to the fault," I say in class, "so to win more trust and autonomy, let's take a look at some failures and how they may all be connected to the same fault."

I've known Mike Kelly for about 5 years and I'd work with him on any project, any time. Why? I trust him for the very reasons he writes about in the following article, and I picked him to write a guest column because I suspected he would add value to this edition with anything he chose to say about building trust. Again, he did not disappoint. He has a knack for that, just as with everything he has contributed to the software testing community. -Jon Bach

Building Trust as a Consultant

Michael Kelly

As an independent consultant working in the Midwest, I've worked hard over the last few years to build a reputation as a trustworthy software testing specialist. Now, as a Software Development Manager for a Fortune 100 company, I have the challenge and opportunity of finding vendors and consultants that I trust for my projects. From both perspectives, building trust is not easy.

Delivering value

Delivery is the basic building block of trust for a consultant, whether it's showing up at the client site on time, delivering various completed project artifacts, or even something as simple as finishing a class on time. Consistent delivery of a high-quality product is where trust begins. As a consultant, you want all of your clients to associate your name with hassle-free high-quality work that's delivered on time. No one will give repeat business to someone they don't trust to deliver.

Helping build the bigger picture

If consistent delivery keeps the door open for continued work, helping the client see the bigger picture is what moves you from a trusted order-taker to a trusted partner. A partner helps find innovative solutions to problems. They help you understand the bigger problem, not just the symptoms. They help you deconstruct your most difficult problems. When your clients see you influence their strategies in positive ways, they will see you as a trusted partner they can count on to do the right thing.

Turning down work

Another hallmark of a consultant you can trust is one who turns down work or leaves money on the table. I turn down work for two reasons: availability and lack of experience in what I'm being asked to do. If I am taking a stretch assignment, I let the client know up front. If I finish something early, I deliver it early - even if I have approval to bill for more hours under the current contract. The consulting companies I've worked with who do the same are the companies I recommend to my clients when I have no availability. Turning down business that's not right for you is an important way to build trust because the client can see that you will choose doing the right thing over closing more business.

Talking the right language

In a recent blog post I shared some experiences talking with vendors of consulting services. I didn't get the feeling they were speaking to me. I got the feeling they were speaking to someone else. Their message was tailored to my boss or my boss's boss, someone who didn't know the details of software testing, and someone who only had a passing knowledge of what it takes to actually deliver. Someone you trust will talk to you. They will talk about your problems, your goals, and in your language - not "marketing speak." Sometimes this means you have to learn the "local dialect," the way your client talks about their systems and project. Expending the effort to do so will increase trust because it demonstrates, once again, that they are more important than a quick buck.

Building up those around you

I think the final fundamental element of building trust with my clients is helping them build their own ability to deliver. For a client to trust I have their best interests at heart, I focus on making sure they understand that I'm not trying to carve out a niche for myself in their company. The best vendors I've worked with engage me upfront around the topic of how what they put in place will be sustained when they leave.

Being trustworthy is ultimately about being trustable. It's not enough to appear to be trustworthy - you actually have to be worth trusting. Clients will eventually see through pretenses of trustworthiness that aren't supported by a fundamental desire to leave your client better than you found them. If you want to have a reputation for trustworthiness, first start by cultivating your desire to do what is best for your client.

About the author

Mike Kelly is a Software Development Manager for a Fortune 100 company. Mike also writes and speaks about topics in software testing. He is currently the President for the Association for Software Testing and is a co-founder of the Indianapolis Workshops on Software Testing, a series of ongoing meetings on topics in software testing, and a co-host of the Workshop on Open Certification for Software Testers. You can find most of his articles and blog on his website www.MichaelDKelly.com

User Acceptance Testing and Trust

Fred Hagan, Managing Test Lead, Quardev, Inc.

The natural dichotomy in UAT

What do User Acceptance Testing (UAT) and Rodney Dangerfield have in common? That's right. They both get no respect. Well, maybe that's not always the case with UAT, but if you're a Product Manager interacting with an IT team (or even if you're not) then you probably know that it's the case too often. Ask most any IT Team that's entering a UAT testing phase how they really feel about it, and they'll likely tell you that UAT "just ain't sexy." That's because, they'll say, it involves working closely with all those non-technical Business User types (a.k.a. Subject Matter Experts or SME's). Then go and ask the Business SME's who are part of that same UAT phase, and they'll likely express some vague misgivings or even resistance to participation. Go ahead, ask.

See? As you've no doubt gleaned from their replies, there's definitely a certain tension between the IT group and the Business group. That's the case in many, perhaps even most, organizations. (This tension is not necessarily always a bad thing, but that's a topic for a different discussion.) Unfortunately, this natural tension normally leads to a few raised eyebrows, as it grows out of a general feeling of dubious trust, especially on the part or the Business Users. That's bad because, naturally, the success of the UAT effort depends on them. After all, the Business Users/SME's are the testers in the UAT phase, and they're also, even more importantly, the customers for whom the IT folks built the product in the first place. During UAT, the Business Users are wearing two hats: the Business hat that they wear for their day-to-day job, and a (possibly less comfortable) Tester hat, which gives them a temporary place in the IT world.

But wait, let's back up for a minute

For the information of any UAT neophytes out there, the UAT phase boils down to this: The product is code complete, has been through internal QA testing (done by the professional testers), and is basically almost finished. It's like the prototype model but without the paint job. All the really serious bugs (those involving crashes and data loss and such) have already been found and fixed before the UAT phase begins. The IT folks say, in effect, to the Business User folks, "Well, here it is - a full, working version of the product you said you wanted. So, how do you like it?" And then the Business Users use it -- generally by executing scripted tests based on "use cases" and real-world scenarios created from the Business Requirements -- and tell the IT folks whether it does in fact meet their needs, comes nowhere near it, or comes close but still misses the mark. In the process, the UAT testers/Business Users log "issues" to be addressed by IT as either bug fixes or desired enhancements before implementation and release.

In brief, user Acceptance Testing is a different animal from other phases of the software development lifecycle. Although bugs may be discovered during the UAT phase, its goal is not to discover errors in the code, nor is it intended to assess usability. Rather, its purpose is to verify that the product does in fact meet the business requirements and needs of the end users, or customers, for whom it was developed. The system or product may have been built very well and have nearly error-free code, but is it the system or product that the end users expected (and paid for)? In other words, did the developers do an outstanding job of building the wrong product?

So back we go to this "trust" thing

The plain fact is that the Business SME's and the IT folks need each other if the final product is to be successful. It is paramount that these two mutually alien cultures and languages somehow work together, trusting that both desire the same end result: to release a high-quality and genuinely useful product for the ultimate end user, not merely a package of relatively "bug-free" code.

What's needed, of course, is a bridge for the natural communication gap between the SME's and the IT team, engendering and nurturing mutual trust and cooperation. That bridge (with any luck at all) is embodied in the UAT lead role.

The UAT lead

The UAT lead will inspire trust, in part, with the following traits.

1. Communication Skills: The ability to communicate effectively to both camps (Business and IT) is imperative. This person has to speak both languages fluently, and be at home in both cultures.
2. Personal Leadership Skills: The "bi-lingual" communication will facilitate the leadership skills that are necessary for the role because both camps will more readily trust and respect a person who speaks their language.
3. Grasp of "Usability" Concepts: While UAT is NOT the same thing as "usability" testing, the UAT lead should have a good understanding of the "usability" and "human factors" issues to bring to bear while overseeing the testing activities of the SME's. If issues of product usability do become apparent, the lead should recognize them and be able to address them.
4. Project Management Skills: We can't forget that another group the UAT lead must interface with is Management. To do this, the lead needs to be adept at gathering and organizing the results and progress data that management will expect to see all during the UAT process. The SME's and IT folks have to trust each other, but management has to trust everybody.
5. Formal QA Test Skills: It should go without saying, the UAT lead should know formal testing methodology and techniques inside and out. He or she will be responsible for creating the test plan and test cases and scripts that will be used by the SME's, and must be able quickly to identify holes in test coverage of the product. Also, the lead must coach the SME testers in describing bugs or needed enhancements for the product so that the IT folks can understand clearly what is to be done.

The importance of Business User involvement

Okay, so the above characteristics are great for the UAT lead, but what about the Business Users? In most projects, the Business Users are involved only at the very beginning and the very end of the development process. They are consulted by the Business Analysts to gather the requirements for the product (i.e. what does the customer want and need the product to do for them). They may review the Requirements document written by the Business Analyst to verify that the requirements were understood and documented accurately. But then they are cut out of the picture until the product is virtually complete and a "beta" build is ready to be unveiled to them.

Too often this produces bad results, as some requirements may have seemed so obvious to the SME's that they were never stated explicitly in the requirements documents or functional specifications that were handed off to the developers. So, the developers end up writing code that does not consider these "implied" requirements which, to them, were not obvious at all. At UAT time, tons of time and budget have been spent in development before the SME's see it for the first time - after code complete. Their last involvement was with the requirements document sign off, before any code had been written. They see the first UAT build, and only then does anyone know that it lacks features or elements that are essential to the end users. In these cases, UAT winds up testing the developers' mind reading skills. (It's getting easier to understand that mutual "dubious trust" thing, isn't it?)

It stands to reason that the Business Users/SME's will feel more of a sense of ownership in the outcome of their product, and will feel more a part of the overall "team effort," if they are included at regular intervals throughout the development process, not just during requirements gathering and UAT. A healthier rapport will develop between the two groups through more regular and frequent communication, and both groups will be more empowered to succeed as they better enable each other to create the right product the first time around. Ah, trust and respect at last. (And the launch party will be a lot more fun for everybody.)

Calendar of Events - Quarter 1 2008

January QA Sig - January 9, 2008

The Strange World of Problem Solving

The Strange World of Problem Solving with Dr. John Medina, a developmental molecular biologist focused on the genes involved in human brain development and the genetics of psychiatric disorders.

In this session we'll be exploring how we think, process, and test.

See more information on the QA Workgroup Web site: http://www.QASIG.org or visit http://www.Quardev.com for regular event updates.

Quardev is looking for Great People

We are always looking for great people to join our team.

At Quardev you will work hard, you will enjoy a great working environment and benefits, and you will be building a solid, interesting, and flexible career where you can learn and grow.

If a career with Quardev sounds interesting, or sounds like it may be a fit for someone you know, check out our Careers page or contact us today at Careers@Quardev.com.

We'd love to meet you!