All code is not created equal. Learn from a master of the craft how to spot bad code and mold it into good. Mike wraps up his year-long column with tips for heading off code bankruptcy and leaves us with some final words of wisdom to help us continue to improve our coding craft.
All code is not created equal. Learn from a master of the craft how to spot bad code and mold it into good. This month, Mike Clark explains how moving code from one class to another to make it reusable can save you time in the long run.
Organizations saddled with legacy web applications often rewrite the applications from scratch. But what if an application could be rewritten a bit at a time by the same team that maintains it? Find out how one team "strangled" out legacy code with a new application—without having to start the rewrite from scratch.
More and more software testing is becoming a technical activity—and that means programming. In the future, simply having domain knowledge won't be enough. Good craftspeople need good tools, and some of the most powerful tools in the tester’s toolbox today are dynamic programming languages like Perl and Ruby. If you aren't familiar with these languages, this article will help you get up to speed and start scripting in no time.
Brian Marick is obsessed with faults of omission in software code, and he thinks you should be too. In this Bug Report, Marick describes coding omissions, design omissions, and requirements omissions, and offers some ways to prevent (or at least test) them.
Technical Editor Brian Marick introduces the first issue of STQE magazine. He says the magazine "is for people who get their hands dirty, whether by writing tests, cranking out code, managing others, or--perhaps the hardest task of all--being the internal QA consultant who has no direct authority but must somehow persuade ten projects with impossible deadlines to think strategically."
It doesn't matter when you deliver, if you build the wrong product. Development entails inferences and assumptions about the user, which are supposed to guide the build-process. However, even if development successfully matches the inferences and assumptions about the user, if those criteria don't match the Real User, the product fails. This article talks about how to incorporate the user into the requirements and design phase.
The theory underlying a measurement must take into account at least nine factors. This article defines these nine factors (e.g., the scope of the measurement, the scale of the instrument, and the variation of measurements made with the instrument) and applies them to a few examples.