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

CASSUG hosting the Modern Migration Tour, June 19

The Modern Migration Tour is coming to Albany!

End of support for SQL Server 2008 is almost here (ends in July!), which means it’s time to take flight on your migration strategy.

But, do you have a plan in place? What approach should you take to ensure a smooth transition?

To guide you through these questions, PASS, Microsoft, and Intel® have teamed up for a series of expert-led events, giving you all the tools you need to get to the final destination—a modern data platform.

For information about this event and to register, click here to view the EventBrite announcement. You must register on the EventBrite link to RSVP.

See you there on June 19!

Security: Close isn’t good enough!

I am reblogging an article written by my friend, Greg Moore. Hopefully, we all have our data locked down, but I felt that what he wrote was important enough that it was worth passing along.

greenmountainsoftware

I was going to write about something else and just happened to see a tweet from Grant Fritchey that prompted a change in topics.

I’ve written in the past about good and bad password and security polices. And yes, often bad security can be worse than no security, but generally no security is the worst option of all.

Grant’s comment reminded me of two incidents I’ve been involved with over the years that didn’t end well for others.

In the first case, during the first dot-com bubble, I was asked to partake in the due diligence of a company we were looking to acquire. I expected to spend a lot of time on the project, but literally spent about 30 minutes before I sent an email saying it wasn’t worth going further.

Like all dot-com companies, they had a website. That is after all, sort of a requirement to…

View original post 626 more words

Monthly CASSUG meeting — March 2019

Greetings, data enthusiasts!

This is a reminder that our March CASSUG meeting will take place on Monday, March 11, 5:30 pm, in the Datto (formerly Autotask) cafeteria!

Our guest speaker is George Walters! His talk is about security features from SQL 2005 through 2017!

For more information, and to RSVP, go to our Meetup link at http://meetu.ps/e/FWkSv/7fcp0/f

Thanks to our sponsors, Capital Tech Search, CommerceHub, and Datto/Autotask, for making this event possible!

Treat All Sensitive Data as Important

Reblogging another important article by Steve Jones.

Voice of the DBA

We know that not all the data in our company is important. We have databases that contain orders or inventory or schedules, often much of which isn’t easily or directly related to an individual. At least, it’s not if you have a normalized database. If you use SQL Server to emulate Excel spreadsheets, it’s possible that most of the rows of information in your system contain sensitive data.

In some systems, there is definitely some data that is sensitive and needs more care than other data. We know this, and with legislation like the GDPR, we must protect this data. We also need to ensure we know where this data is, and having a good data catalog is important. This is something that few of us have, though I expect this to be a more regular part of our job as data professionals. SQL Server is building data classification into…

View original post 235 more words

SQL Saturday #855 Albany announced!

The Capital Area SQL Server User Group (CASSUG) is pleased to announce that, for the sixth time, we will host SQL Saturday #855, Albany on July 20!

For additional information, to register for the event, or to submit a presentation, click the link above!

I’ve already submitted presentations, but I will be there, regardless of whether or not I’m picked to speak!

Hope to see you there!

Email changes and security

When was the last time you changed your phone number?  Let’s say you lived in a house for, say, fifteen years.  In that house, you had a landline phone (yes, young ‘uns, once upon a time, homes had their own phone numbers).  For whatever reason, you had to sell the house, move away to another city, and get a new phone number.  So, you went through the exercise of changing your phone number.

Changing that phone number was sometimes quite a task.  You needed to give your new number to your family and friends.  You needed to update your business contacts and associates.  You set up a forwarding number for people you missed.  And you gave your new number to all your important businesses — your bank, your doctor, your broker, your babysitter, your lawyer, your gym, the people in your book club…

Or did you?  Are you absolutely sure you remembered everyone?

That gives you an idea of something that I’m dealing with now.  I’ve had the same email address for a long time; I’m not exactly sure how long, but it at least dates back to when I was in grad school (which was in the mid to late ’90s).

I was determined to not change my email, but recent circumstances made this a necessity.  For one thing, the ISP behind it used old and clunky technology.  Trying to coordinate it with other devices and tasks (calendars, for example) was a major chore.  For a long time, it was not SSL-secure.  It was not easy to check it remotely; if I wanted to do so, I had to remember to shut off my mail client on my PC at home, or else they would all be downloaded from the server before I had a chance to read them.  The issues got worse more recently; the ISP did not provide an easy way to change my password.  I could either (1) send an email to technical support (in response to this, my exact words were, “no way in HELL am I sending password changes via email!!!”), or (2) call tech support to give them my password change.

The last straw came today.  I was looking for a certain email, but couldn’t find it.  Figuring that it was caught in my spam filter, I logged into it to look for the email.  I didn’t find it, but what I did see were spam messages that included in the subject line…  and I’m repeating this for emphasis: IN THE SUBJECT LINE…  my passwords, clear and exposed.

That did it.  I decided right then and there that I was changing my email, since I couldn’t trust the old one (or the ISP) anymore.  I’ve had a Gmail account for a few years, but I never really used it.  Today, that account became my primary email account.  I’ll still hold on to my old email long enough to make sure everything and everyone is switched over to my new email, at which point I’ll shut down my old account.

I suppose there are several lessons to gain from this exercise.  For one thing (as I’d once written), don’t get comfortable.  I’d gotten comfortable with my old email, and I was determined not to change it.  I paid for that with my peace of mind.  For another, don’t take your personal data security for granted.  Make sure you change your password often (and if your provider doesn’t offer an easy way to do that, then get a new provider).  For yet another, if something can no longer do the job (in this case, no password change mechanism, unable to interface with other applications, difficult to use, etc.), then it’s probably time to get a new one (whatever that “something” is).  And for still another, make sure you keep track of your contacts.

(And I’m sure there are a bunch of others that I can’t think of right now.)

Too many of us (myself included) become lackadaisical when it comes to email and data security.  Don’t take it for granted, or you might wake up one day with your bank account drained and your credit rating slashed.