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!

Upcoming speaking engagements (as of 4/4/19)

I figured I was about due for an update of my speaking schedule. As of today, here are events where I am confirmed as speaking.

I’ve also applied to speak at the following events, but none of them are confirmed; there’s no guarantee that I will be speaking at any of these events. Stay tuned.

(Unfortunately, as much as I want to go, I am not applying to SQL Saturday #877, Boston, as I have a conflict with September 14.)

Additionally, these events are not yet live, but they are listed as “save the date.” I intend to apply to them once they do go live.

  • October 5: SQL Saturday, Pittsburgh

SQL Saturday events are held all across the country and around the world. I hope to be attending one near 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.

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!

SQL Saturday Boston BI — this Saturday, March 30

This coming Saturday, March 30, I will be speaking at SQL Saturday #813, Buston (BI Edition)! This is my first SQL Saturday for 2019, and it will be the third time since last September that I will be speaking in the Microsoft facility in Burlington, MA!

I will be doing my presentation on how to talk to non-techies, called “Whacha just say? Talking technology to non-technical people.”

SQL Saturday is always a great time! It’s a great opportunity for free training, and it’s also a great networking event — you have an opportunity to meet a number of SQL Server and other data industry experts, as well as a chance to meet other peers within your profession!

Hope to see you in Burlington this Saturday!