Category Archives: Quality Practices

Mob Programming

I’ve know Woody for a few years. He invited me to a free (yes, I said free, as in I don’t pay a dime) workshop to learn  Mob Programming.  After a couple of tries, I was able to attend what might be the last free workshop on February 25, 2017. It was free because Hunter Industries paid for Woody’s time, let us use their facility & equipment, provided our lunch, and volunteered their time to coordinate all the activities. Nice people.

This is my blog entry on my experience at the workshop.

Continue reading

Advertisements

Watir Podcast Episode 59

The Watir Podcast is publishing podcasts again. In this week’s episode, Neil Manvar from SauceLabs tells us about the advantages of use SauceLabs, how to get started, and what mistakes can lead to trouble.

Please listen and give feedback on this podcast on SoundCloud (https://soundcloud.com/the-watir-podcast/episode-59-saucelabs), as well as what you would like to hear about on future Watir Podcasts.

You can subscribe to The Watir Podcast feed (http://feeds.soundcloud.com/users/soundcloud:users:248873479/sounds.rss).

Badges? We don’t need no stinking badges!

In the Beginning

I am not a programmer. Well, I am but I never considered myself to be good at it. Most of the places that I worked, I was the only person creating test frameworks. I never received benefit from getting a code review of anything I wrote. I did not pair with anybody on writing any scripts, methods, or page objects. In fact, the first time I showed professionals in test automation my code, they looked embarrassed for me. When they got over the shock, they started giving suggestions that were obvious to them, but I had never learned. Hey, my code worked! Isn’t that what counted?

Learning

Well, since then I got over the big balls of mud that I was creating. I started paying more attention to the grace and simplicity of the code I saw from others. And I learned… some.

Maybe i can use more than one file for my code? Oh, I can let errors throw back to the calling function? Very interesting, I can create tests for my test tools. I can self-document these? I was learning, but I wanted more.

The Next Big Step

Within the past couple years, I have discovered a few things to help me with my programming. First, I found Rubocop (thanks Željko) which helped me to start up the style of my code. I started using standard indention, line lengths, variable names, limit the size of methods, and complexity.

Then I stumbled upon Travis-CI. I can’t remember for sure, but I think that I saw a badge on somebody’s github page. “Hey, I can use that too!” So I added that. I learned that I could run my test suite on several versions of ruby, even on JRuby. I felt that was important because I had written a tool that still used my rest client. I could add my own badge that lets everybody know my library is still good. I want people to feel confident that my builds are good so I added the badge.

Build Status

Then I saw coveralls where I learned that I my tests were missing parts of my code. It was only 10%. But it was coverable, so why not cover it? I improved my coverage to 100%. It did not drop down until… I tried to add support for JRuby9. That’s when I discovered that JRuby9 does not support coveralls yet when my coverage when down. I decided it was too early to support JRuby9. I wanted people to know that the library is tested so I added the badge.

Coverage Status

Then I hit the motherload. I was looking into a library that supported money formatting and discovered RubyMoney. Wow, they had badges for everything.

Quintuple Wow! Most of these tools are free for open-source projects, which is the only status that I would consider. Anybody can add them.

The Benefits

Adding the badges was fun, at least in the beginning. I discovered Reek this week, which is another linter for ruby. It played well with Rubocop so I added it to my project. There were different types of problems that I had to address. To support those changes, I expanded my automated tests too. When I checked in the branch, I could see how it was doing in CI. When I got negative feedback, I reworked the code. When the feedback was good, I knew I could merge the code to the master.

When I check in code changes, whether for refactoring, adding test cases, or increasing the versions of Ruby I support, I learn quickly whether my code was working still. When I learned reek didn’t support JRuby-1.7 because it’s base version of Ruby is 1.9, then I found a way to control that in both the Gemfile and Rakefile. When I tried to support JRuby9, I learned it’s not baked enough for me.

As my friend once stated, “you can never over-communicate.” Those tools are communicating to me, while the Badges are communication to anybody using my libraries.

Do We Need All Those Badges?

I also had to fool around with various configuration files to make sure the linters work working locally and cloudly (yes, I just made that up). Work is cost.

It seems like Gemnasium is going to start charging in 20 days to show my status. Money is cost.

Second thing I learned, while most of the work is in setting them up, maybe I can use some moderation in how many I use. So as long as it helps me, and as long as it’s free, I’ll use them. When I have to pay or they become more work than help, I will drop them.

Update on Book Review

When I was at ResMed, I was reviewing the book Black Box Testing in order to prepare for teaching a class to testers. Because I left ResMed in December, I will not complete the book review right now. Upon re-reading it after two decades, I find that I cherish the things I learned from it. I will continue reading it, but at a slower pace. As I do, I will submit reviews of each chapter at that time.

In the meantime, I will resume posts on investigations, experiments, and lessons that I learn in testing and testing technologies.

A Quick Way to Test Rest Web Services

Image

Photo “Seagulls on the American River” courtesy of Vince Mig.

Testing a Rest API

When I think of rest, it’s usually the type that requires a bed or comfortable couch. But these days I am spending more time verifying intermediate components of a larger system that take advantage of the synchronous behavior known as a restful web service than working on web GUI interfaces.

Continue reading

Developing Trust

Developing Trust

“What did they say?” “That it’s supposed to work that way.” “And?” “I wasn’t sure what else to say. What do you think?” “I think that you need to develop some trust. First, develop some trust in yourself. Then develop some trust from the dev to you.” It’s a common conversation I have with junior testers. As testers, our goal should be to build trust. Trust enables us to our jobs.

Trustphoto credit: mikebaird via photopin cc

What is trust?

The asset most required in our jobs as software testers is trust. That is because trust is knowledge of a person or group. The currency of that knowledge is the combination of competence, character, and commitment.

The first, competence, is how well we can do our jobs. People may think we have character, but we I say a feature has a problem, do people believe that I know what I am talking about. Competence varies for all of us depending on the domain. I can know much about restful web services (Rest) and not know much about User Experiences (UX). Or somebody may trust my knowledge in Rest but not UX. I could understand the technologies used but lack understanding of the business use.

The second measure of trust is character. I consider character to cross domains. I guess that somebody could have a character weakness, for instance if they are a covered alcoholic, but not relevant for this kind of trust. Do people know you give an honest answer? That would be integrity. Do they know you see things through to the end, or do you drop things when you get resistance? That would be courage. Other character traits of a tester include ability to communicate, and dealing with ambiguity.

And the third measure of trust is commitment to causes. A person could be honest and earnest, but wouldn’t lift a finger to save a spider if they don’t like spiders. Others will trust me or not if I am dedicated to those values that the team shares. This can vary from place to place. I have worked where the tester was ‘supposed to be the police’, as well as places where the tester was supposed to describe the quality level to management so they could make a proper decision. Popular commitments in agile include delivering value to the customer, continuous improvement, engineering for current (not potential needs), and always-working software.

Why do We Need Trust?

We do not hear many arguments against trust. But we do not always hear for a call to gain trust. Without trust, everything is more expensive in both money and time. For example, terrorist attacks in Mumbai and New York in the past decade created new, more expensive agencies to combat the potential for attacks. I have personally witnessed the cost in time every time I travel from an American airport. The example is extreme, but it scales down to our work. For instance, if I am not trusted to create tests then I will have additional review processes, sign-offs, etc.

Without building that trust, even when the competence, character, and commitment are present, you will pay the no-trust taxes. In a new relationship, the trust must be built. An assumed trust, one that is assumed upon meeting, can be duplicitous – other assumptions come with it.

How do We Build Trust?

How to build trust isn’t a simple question. That comes having competence, character, and commitment. When the currency is low then we will find building trust difficult. Those things can grow in time. If we study our craft, if we study our domain, we will gain the competence that convince our stakeholders that we ‘know what we are doing.’ As we mature, we build character from making the right decisions. As we question our beliefs and motives, we develop the commitment that other respect.

On the other hand, we build trust from others as we improve ourselves. We work in various domains – we have different levels of knowledge in those areas. We start at different trust levels in our relationships. We work with people who have different general tendencies for trust based on their experiences. Domain risk also plays into trust. I will be careful no matter who I am working with to build a pacemaker.

Lowest Trust – When we work with somebody that does not trust us, deserved or not, we can build a foundation of that trust by being polite, and simply helping them. Do not ask questions except for those that will help you do the task correctly.

Low Trust – Learn about them. Questions should be inquiring but not challenging. Your interest in them, and sharing some common experiences. Though you should focus more on them. What are their motives for what they are working on? What are their commitments?

Medium Trust – When you are at good level of trust, you can make suggestions to help them. THEN BACK OFF. Expect them to ignore your suggestion. In the occasion that they take your suggestion, be available to answer questions about details. Success isn’t necessary, but a big investment into a failure can lower the trust level.

High Trust – Once you have a high level of trust, you can act on their behalf if you tell them appropriately about what is done. Give them a report on what you will do, what you have done. For those working on Agile teams, this can sound like a ‘standup meeting’.

Highest Trust – When you are at the highest level of trust, you can just act on behalf of somebody. You know their interests and how they would decide themselves.

You can be at different levels of trust at different times of a relationship. It can go up or down for various reasons. If you haven’t interacted with somebody for a while, you might treat the trust level as if it atrophied. If you are a hired expert, you can probably skip the lowest trust level and start somewhere else.

Planning to Be Trusted

By evaluating the trust levels that your stakeholders have in you, you can begin planning on how to build a higher level of trust. The work you do when implementing a trust-building plan will actually make you better and more trustworthy. That trust is a cornerstone to becoming more effective as a software tester.

Trust me.