Testing something? What’s the test plan?

Imagine if you will that you’ve been asked to test a product. The product could be anything — software, a car, a kitchen appliance, a piece of sports equipment, whatever. For the purposes of this article, we’ll say you’re working at some company, and you’ve been asked to test a piece of software.

You’re told to go into an application, and you’re given this instruction.

“Okay, test it and see if it works.”

That’s it.

How would you feel? Vague? Confused? Frustrated? Abandoned? All of the above? Something else?

Well, I, myself, have been put into this situation more times than I care to admit. It’s one of the most frustrating job situations I’ve ever been thrust into.

What, exactly, constitutes “see if it works”? I could simply start the application, see if it starts, and say, “okay, it works.” I suspect that that’s not what the people who make the request are looking for. Yet time and again, I get a request from a developer or a designer to test something, and that’s the only instruction I’m given.

And it’s frustrating like you wouldn’t believe.

What’s even more frustrating is when (not if) the application comes back with some kind of problem, and the people who asked you to test come back with, “you said you tested this! Why is this broken?”

Want to know why there’s so much friction between developers and QA personnel? This is a likely reason. This is something that definitely falls under my list of documentation pet peeves.

The fact is, if you develop a product, and you need to test it for functionality, you need to specify what it is you’re looking to test. You need to define — and spell out — what constitutes a “working product” from one that’s “defective.” Just because a car starts doesn’t mean it’s working. You still need to put it in gear, drive it, steer it, and make sure that it can stop.

If you are creating a product, you need to describe what parameters are required for it to pass testing. If you’re asking someone in quality control to test your product, provide the tester with guidelines as to what should be checked to ensure the product is functional. Better, provide him or her with a checklist to determine whether or not your product can be released. If you discover additional items that need to be tested, then update the checklist.

(If you want to know more about checklists, I highly recommend The Checklist Manifesto by Atul Gawande. It’s actually a surprisingly excellent read.)

So any time you release a product for testing, tell the testers what it is that constitutes a “good” product. Don’t just send it off with vague instructions to “make sure it works” and expect it to be tested. More often that not, that will result in a failed product — and defeat the entire purpose of why you’re looking to test it in the first place.

Advertisements

SQL Saturday #835, Philadelphia — 5/4/19 (a week from this Saturday)

I just received an email from the organizers of SQL Saturday #835, saying that I should ‘blog about the upcoming event. Okay, I will oblige!

This is the fourth consecutive year that I am speaking at Philadelphia SQL Saturday, and they’ve all been fun experiences! (Last year, I even wrote an article in which I documented my trip!)

This year, I will be doing my presentation on tech writing and documentation.

Image result for chewbacca
Chewie says, “May the 4th be with you at SQL Saturday!”

And… because this year’s Philadelphia SQL Saturday falls on May 4, attendees are encouraged to wear their favorite Star Wars garb. Yes, I intend to participate. No, I’m not saying how. You’ll just have to wait until May 4 to find out!

So if you’re interested in databases, data science, technology, professional development, or just want to hang out with a bunch of computer geeks, and you’re in southeastern Pennsylvania or southern New Jersey a week from Saturday, go register on their site, and we’ll see you there. May the fourth be with you!

The symbiotic relationship between documentation and application development

One of my current projects involves documenting processes for an application that are still under development. As such, much of what I write may change, depending on how processes are changed during the course of development.

At one point, I tested one of the processes so I could determine functionality and document it. In doing so, the process came back with an error message that I wasn’t expecting and didn’t have any user-friendly information, other than a cryptic error code. I contacted one of the developers working on the application and told him what I found. I gave him the error codes I experienced and steps I took to get them. He told me, “you’re coming across bugs that we didn’t even know we had.”

It occurred to me that I was doing more than just documenting the application. I was also acting as a beta tester.

One aspect about writing technical documentation is learning about what you’re writing. In order to write about a process, you need to understand how it works. If you’re documenting an application, the best thing you can do is run the application in a safe environment (such as development or a sandbox), learn how it works, and use it to document steps and capture screens. In doing so, you come across application bugs and even come up with ideas to make the application even better.

I’ve long argued as to the criticality of documentation. It records important information and serves as a reference. However, until this point, it didn’t occur to me that the document development process could have a symbiotic relationship with application development. To me, this adds further fuel to the argument that documentation is critical and required.

Jobs That Beat The Caring Out Of You

“The beatings will continue until morale improves.”

Unknown

Before I get into this article, let me say that this appears to be a thread going around today (on April Fool’s Day, no less). I decided to add to the chorus.

But before I do, here are the other articles (all with the same title) that inspired me to write this. I especially list Jen first, since she appears to be the one who started this thread.

Feel free to read their stories. Go ahead. I’ll wait.

Okay, now I’ll add on with my own story. This involves the company where I worked before I latched on with my current one. For reasons that I think are obvious, I will not name the company (I’ll simply refer to it as “The Company” — and I think capitalizing even that is giving it too much credit), nor will I describe who they are or what they do, other than that they’re a software company. I will leave it at that. Those of you who know me well will likely know the organization to which I refer. Everyone else… well, you’ll just have to play along.

So here’s the scoop. Essentially, I was fired from The Company.

I suppose a little background story is in order.

I’ll start at the beginning. I was hired at The Company as an application developer. I was hired because I have experience with classic ASP — an old technology that isn’t widely used anymore. It seemed like a good place, and I was looking forward to getting started with The Company. Indeed, the people were friendly, and I am still friends with many of them to this day.

Nevertheless, there were warning signs from Day One, and I didn’t pay heed. Only now through hindsight do I recognize those signs.

The first sign: my very first day on the job, I was poking around the application. My very first question: “where is the documentation for this?”

And people looked at me as though I had two heads.

There was absolutely no code documentation anywhere. It simply did not exist. It barely even existed as code comments, and even those were rare. I was expected to understand how the code worked just by looking at it and remembering how it all worked as I went through it — without writing anything down. I’ll say it again for emphasis: I was expected to be able to do this.

That should have been a major red flag there. But there’s more.

There appeared to be a lot of employee turnover at The Company. People seemed to come and go on a regular basis. As I would tell people years later, “this place didn’t just have high turnover, they had a revolving door.” This was another major red flag.

It seemed like a fun place to work. Once a year, they closed the office for a day for a company picnic. It included a golf outing, food and games. Every year around the holidays, they would have a holiday party where they would give out large prizes (including cash bonuses and TVs), and The Company even sprung for a hotel for the night. They would do it again in late winter or early spring, and refer to it as a “blow off steam” party. They regularly had a massage therapist come to the office once in a while to give free massages. I even remember one day where The Company achieved a major success (it was either a successful release or gained a major client — I don’t remember which), and to celebrate, they had girls walking up and down the aisles with trays of hors d’oeuvres. I didn’t even need to eat lunch that day. Indeed, it seemed like a party atmosphere, and they made it out to be a fun workplace.

(I’m guessing that, at this point, those of you who know me know who “The Company” is.)

However, looks can be deceiving. And a “fun party” workplace doesn’t do much for one’s career.

To say that I struggled as a developer is an understatement. I couldn’t grasp a lot of what The Company was doing in their applications. I did my best to keep up, but the lack of documentation was a major stumbling block. I started to doubt my own coding skills — and a lot of that doubt still continues to this day. It’s one of the major reasons why I’ve been moving away from my technical skill sets. I do enjoy writing code, but that experience made me question whether or not I was really cut out to be a developer. At one point in my career, I was hoping to do more as a developer, but my harrowing experience with The Company has since dashed those aspirations.

Let me go back to the part about lack of documentation. I made it clear to management that I had a Master’s degree in technical communication and professional experience as a technical writer. I let them know that I was willing to take on documentation duties, and offered my services as such. They had a company Wiki that was underused, and only a few people had access to it. I asked for, and got, access, and documented what I could, which wasn’t much.

There were clients asking for a system administration guide. I saw what they were sending out. My opinion of the document — the only good place where it could’ve been used was the bathroom. The document was absolutely horrific. It had absolutely no structure whatsoever, and it was impossible to read. It basically looked like a bunch of scratch notes just thrown together into a Word doc that was given to clients — which was pretty much what it was. The excuse I got was, “these people are techies just like us. They don’t need formal or good documentation.”

I offered to rewrite the system admin guide, and I did what I could. I threw out the old guide and rewrote the entire thing. It wasn’t perfect, but it was an infinite improvement over what they had before.

The Company insisted on an addendum to the system admin guide. They insisted on sending out a document — which they insisted on writing in Excel (!!!!!!!!) — out to clients. They sent it out without review, and likewise, it was horribly written.

The Company wasn’t just disinterested in documentation. They were openly hostile to it.

The Company had absolutely no interest in developing their employees. The prevailing attitude was, you don’t need to develop your skills. You’re going to do what we need, you’re going to do it our way, and you’re going to do it well.

Now, I’ve practically made an entire career out of adjusting to my environment. When I realized that I wasn’t going to make the grade there as a developer, I offered my skill sets in other areas, especially in communication. I offered to write full-time. Eventually, they moved me to an area where I was responsible for client software releases. They were showing me that they had no interest in me and my development. They didn’t care about what I wanted. They just wanted something from me — something I could’ve offered, had I been in a decent, nurturing working environment — which this was definitely not.

I was called to HR and told that I was on probation. I had (I think it was) sixty days to shape up. So I worked harder. I worked on improving the quality of my work. I picked up the pace.

I should note that two things happened around this time.

First, I updated and actively (and discreetly) pushed my resume. I had gotten to the point that I was absolutely miserable working there, and wanted to leave as soon as I could. I wanted it to be on my terms, not The Company’s.

Second, I wrote this article. I could see the handwriting on the wall.

Several weeks later, I was called into HR again. I was told I was being let go. They noted the effort I was putting in, but said I was not improving my skill sets they way they wanted.

Not once during my probation period was I told that that was what they wanted me to improve. Not once.

I was cordial during my interview with HR. I asked questions like, “well, how will such-and-such be handled after I leave?” That was the face I gave them. In the back of my head, I was silently saying things to them that I cannot repeat in this article.

There is actually some more details to my story, but I don’t want to discuss them. By now, I think you have the gist.

I told myself then and there that I would never recommend The Company to anyone ever. I didn’t burn bridges with them; they burned them with me. The Company effectively discouraged me from pursuing positions as a developer. I could’ve been a lot more in my career than I am now, and The Company took that away from me.

I have since spoken with other people who experienced The Company, and every one, to a person, has said similar things. One of them went as far as to say, “I hope The Company goes out of business.”

So I suppose the moral of the story is to beware of bad places to work. If you’re not careful, they could adversely affect your career.

SQL Saturday Philadelphia — May 4

No sooner did I return from one SQL Saturday that I discovered that I will be speaking at another! This morning, I learned that I will be speaking at Philadelphia on May 4! This will be the fourth time that I’ve spoken at Philadelphia SQL Saturday, and each one has been a good time!

I will be doing my presentation on technical writing and documentation!

If you are in southeastern Pennsylvania on May 4, register for SQL Saturday and come check it out! Hope to see you there!

SQL Saturday Virginia Beach — I’m speaking June 8!

I just found out today that I will be speaking at SQL Saturday #839, Virginia Beach on June 8!

I will be doing my presentation about the role of documentation in disaster recovery!

I’ll post about this event again as we get closer to the date. See you there in early June!

Don’t forget to edit your system messages

One of my current work projects is a administrative guide for our application. After a recent status meeting, one of the developers sent me a list of validation error messages that might appear during data imports. I was asked to make sure the validation messages were included with the documentation.

While going through the validation messages, I noticed that they were filled with grammatical, capitalization, and spelling errors. I asked the developer if he wanted me to edit the messages, to which he responded, “yes, please!”

People don’t think about checking output messages for correctness during application development. It is often a part of applications that is overlooked. For what it’s worth, I, myself, didn’t even think about it until I was asked about these validations. Nevertheless, reviewing and editing output messages is probably a pretty good idea.

For one thing, and I’ve stated this before, good writing reflects upon your organization. Well-written documentation can be indicative that a company cares enough about their product and their reputation that they make the effort to produce quality documentation as well. Well-written system messages indicate that you care enough to address even the little things.

Well-written error messages can also ensure better application usage and UX. A good output message can direct an end user to properly use the application or make any needed adjustments. Messages that are confusing, misleading, badly-written, or ambiguous could potentially result in things like application misuse, corrupted data, accidental security breaches, and user frustration.

Ensure your application development review and testing also includes a review of your system messages. It may be a small thing, but it could potentially address a number of issues. As someone once said, it’s the little things that count.