In my last post, “Notes on Software Testing Habits,” I ran through a few thoughts about how to look at your software testing habits. Regulated or not, there are many commonalities.
In LinkedIn, I recently forwarded a post by Martin Lush entitled “Don’t Blame the Person – Fix the System!” One outcome for me from that is that it started a variety of side conversations with other people in the industry. One area of conversation that came up is that of testing, as a general topic and, today, I want to share my own thoughts on testing.
There are such a variety of users being served out there, people who need to get work done regardless of their computer skills, that it’s possible that those of us providing applications are expecting too much from them.
Many projects have a problem getting reports produced. In one sense, it seems expensive to hire a LIMS, ELN or LES expert who knows the data but who comes with a rather high rate. On the other hand, getting a cheap resource who knows the reporting tool isn’t an easy solution because it’s so incredibly difficult to teach them these massive databases and how they work. Today, I will tell you the solution to this problem.
Paul Drake was Perry Mason’s investigator. Last year, I had an opportunity to do what I suppose might be considered database investigatory work.
Just the other day, I had an interesting discussion with someone who is using remote resources on their project. We had a bit of a laugh over those people who constantly worry that remote resources might not be doing what they’re supposed to and, instead, goofing-off or, as we say in our industry jargon, “eating bon-bons.” Most projects are pretty savvy about this but what if your project is new to do this? How would you know, short of putting cameras on them?
There are always up-and-coming products out there but, these days, I seem to run into more and more new products. New LIMS seem to abound, for one. Not only are there new products coming up here in the USA, but there are always products coming from other countries that would like to get a foot-hold, here.
In my last post, I talked about failing projects in “Three Reasons Failing Projects Continue to Fail.” But what about the projects that are doing well or at least moping along at a decent pace? This post is about those projects.
There are a number of notorious projects in our industry that everyone has been asked to become involved in, everyone knows are failing, and seem to continue to drift off-course. Can these projects be saved? I say that it’s possible but unlikely. Here are three reasons why.
A few moments ago, a magazine I used to subscribe to announced to me that their digital newsletter was no longer going to be produced as the printed magazine is so popular that they’re no longer going to bother with creating the digital format. Another magazine I subscribe to gives free digital editions when you purchase the print edition (it actually does cost more to get both) and I find that I do sometimes use those digital editions when I want to print something out to mark it up, rather than putting Post-It Brand Notes all over the magazine, but the print edition remains popular because it’s the kind of thing where readers like to flip back-and-forth.