Archive for the ‘QA’ Category
I’ve got some BlackBerry posts coming up, but first I’d like to say a few words about why I haven’t posted anything in six months. There are two reasons:
- I don’t like Windows OS. I’ll use it if I have to, but for my dev environment at home, I was just too tempted to clean the hard drive (once I’d finished my BlackBerry book), and replace the OS with Linux. Naturally, I told myself I’d set my BlackBerry dev environment back up on some other machine or in a virtual machine or something, and — since I love installing Windows so much — you can imagine that that task hasn’t come to the top of my “to do” list.
- I’m excited about my current job, and it’s something completely different: QA engineering for Dybuster.
Dybuster is a software suite that helps dyslexic kids learn to read. For the kids it’s a game. It works by giving the kids additional ways to learn words, using colors, tones, and 3D graphical representations:
Since I’ve been testing it, I can say that it has definitely improved my spelling in German. Of course I’m not Dyslexic. 😉
And, fortunately, there’s an English version available too (including a free downloadable demo version).
When doing a software QA project, you have to be ready to set up and design tests in a variety of different programming (and scripting) languages — to best integrate the automated tests with the rest of the project. I’ve worked in C/C++, but I’m far from being an expert on the subject. So I can end up wasting time on points that would be extremely simple for an engineer who works in C or C++ every day. And since I wasted my time on this, I’m posting my notes so that you won’t have to do the same.
I recently added some tests to the automated build of a C++ project that uses Qt, which has a built-in unit testing framework: QTestLib. QTestLib seems reasonably well-designed in terms of features. There were just a couple of points I felt were missing from the tutorial, so I’m posting a few remarks for the sake of Q.A. engineers who need to dive straight into the Qt unit test framework. (Apologies in advance to C/C++ developers who will undoubtedly find these points laughably trivial…)
Done? OK, let’s get started. My #1 problem with the tutorial is that it explains how to create a stand-alone application that runs a single QTest class, but doesn’t explain how to create an application that will use QExec to run a series of QTest test suites. Like so many things in software engineering, it’s very simple (once you know the trick). And today I’m going to tell you the trick! Continue reading
If you’ve spent any time studying best practices in software engineering, it can be jarring to discover how far the reality of software production often diverges from the ideal. It isn’t rare to see code in production — stuff that’s critical to a company’s business — that isn’t even under version control, much less documented with bug-fixes tracked to requirements, testing infrastructure in place, etc.
Personally, I like doing reverse-engineering (restoration of lost knowledge) — taking a bundle of mysterious old code and figuring out exactly how it works and what it’s doing, so that it can be upgraded or replaced. I’ve done it for more than one company. However (at the risk of cutting down on the need for this sort of work), I’ll tell you that it’s cheaper to fix “free-fall code” while you still have the engineers who designed it on hand, before a reverse-engineering effort becomes necessary. It’s a little like an old building with electrical wiring that’s not up to code: replacing all the wiring seems expensive for something that yields no visible results, yet it’s cheaper than leaving the old wiring in place to catch fire and burn the building down.
How does free-fall code get all the way to production? In my experience, there are a couple of main causes: Continue reading