The Latest
A Selection of "Our Take" Columns[article] "Our Take" is a regular column from the editors at Software Quality Engineering. It appears in the twice-monthly StickyLetter since its inception in September 2000 (originally "STQe-Letter"). From jazz music, to car troubles, to the Lewis and Clark expedition, Robert Rose-Coutré, former StickyMinds.com Editor, will use anything to make a point about building better software. The editors at Software Quality Engineering have compiled a collection of some of these pieces. Musings from StickyLetter's "Our Take" are presented here. |
||
Bug Counts vs. Test Coverage[article] Occasionally, we encounter projects where bug counts simply aren't as high as we expect. Perhaps the product under test is in its second or third release cycle, or maybe the development team invested an inordinate amount of time in unit testing. Whatever the reason, low bug counts can be a cause of concern because they can indicate that pieces of functionality (which potentially contain bugs) are being missed. When low bug counts are encountered, management may begin to wonder about the quality of testing. This article covers techniques for dealing with low bug counts, and methods for reassuring management that coverage is being achieved. |
Andrew Lance
March 21, 2002 |
|
Make Your Point—Without Pointing a Finger[article] When errors are not detected during testing, somewhere down the line someone has to take responsibility. In this column, Linda Hayes shows you when and how to do so—and you might even be able to turn the situation to your advantage. |
||
Build and Deployment Process for Web Applications[article] This paper describes practices that have led to a sound and reliable build and deployment process at Hewlett-Packard. Two teams of engineers, later joined by a third, responsible for developing e-service components to build a Web application, chose to use open source development tools/utilities in the "Evolutionary Software Development Lifecycle" environment. |
Bhushan Gupta
March 14, 2002 |
|
How to Preview User Satisfaction before Your Release[article] Why wait to discover how your users will react to your system when there are ways to measure such things during development? This column describes a simple tool to develop visibility into customer satisfaction. Learn how you can begin to manage expectations so that neither you nor the customer has an unpleasant surprise on release day. |
||
Giving the Human Touch to Software[article] Yogita works as a QA/testing professional with Mindfire Solutions, and has written a number of articles on QA and testing strategies. Yogita is currently exploring thoughts of beauty as an area of testing and its relation to usability. Her role at Mindfire has been to implement Quality processes throughout the organization and build a dedicated testing team. The team recently published a White Paper “Porting projects: Test techniques,” downloadable from www.mindfiresolutions.com. Yogita can be reached at [email protected]. |
||
Avoiding the Script Cemetery[article] It's frightening how many companies are on their second, third, or even greater attempt to automate their testing—each time junking months or years of effort and work product. Here, test automation advisor Linda Hayes shows the way to avoid having to bury your automation project. |
||
Wizardry and Requirements[article] Illusion and reality. Challenges and fear. These are just a few of the elements that go into requirements gathering and management. Being aware of what you know and what you don't know can ensure getting the right requirements. Read on as Harry Potter fan Becky Winant shares some insight and survival tips for requirements analysts. |
Becky Winant
January 9, 2002 |
|
Reflections on a Fable about Developer-Tester Relationships[article] Lee Copeland's fictional story about getting children to clean their rooms struck a chord with many of our readers, who compared it to getting developers to test their code. Here are Lee's responses to your feedback, along with a few insights about the dynamics behind developers examining their work. |
||
Can You Negotiate Quality?[article] XP teams have the right to do their best work. On the other hand, customers have the right to specify and pay for only the quality they need. How does one reconcile two potentially conflicting points of view? Is quality negotiable? If so, how do we go about negotiating it? This paper will explore the following questions: Is quality negotiable? How can we negotiate quality? What are internal and external quality, and are either or both negotiable? What's the XP tester's quality assurance role? How far should testers go in helping the customer define acceptance criteria? |
||
Managing for Value with Agile Software Development[article] Agile development increases business value for the customer, with the customer controlling the variables at each iteration. Ken Schwaber, co-creator of the Scrum agile approach, explains the basic notion behind agile development. A number of useful links appear at the end of the article. |
||
Did You Hear What I Said?[article] Software projects are complex endeavors that rely on clear communication for success. If communication methods are mismatched or leave too many gaps, your project could suffer, and you could be highly frustrated. In this column, Karl Wiegers details potential problems to be mindful of, and strategies to use, when communicating about a project. |
Karl E. Wiegers
November 27, 2001 |
|
The 11th Hour[article] Testers are often on the critical path for getting a software release out. They must plan carefully in order to minimize the critical path, while still doing a complete job of testing. This schedule pressure is taken to an extreme when a production server must be taken offline in order to deploy the software, and everyone is waiting for the final test results before the system can go live again. Karen Johnson describes her company's carefully planned and orchestrated method for doing a final check of an installed system. Her story is relevant to e-commerce companies as well as IT shops that are under pressure to keep systems updated while minimizing downtime. |
||
Let's Bury the Term Software Engineering[article] Softwareengineering is not an accurate way to describe what software designers anddevelopers do. We create software in an environment that is constantly changingto fulfill the expectations of businesspeople who aren't exactly sure what theywant. Does that sound like engineering? As I'll discuss in this article, physicalengineers deal with the universal laws of physics, but software designers and developersdeal with unrelenting change. By using the word engineering to describe our profession, we set ourselves up for staticprocesses and brittle team structures that tend to discourage change, ratherthan folding it into our everyday lives. Once we can shift our mindsets awayfrom engineering our software, people, and processes, we'll find that our teamsare more responsive, productive and change-readythan ever before.
|
||
What to Do When the Right Person Doesn't Come Along[article] You've written the job description. You know just what you want in this employee. You have one tiny problem-you just can't find that person. Now what? Sometimes you can continue to wait for the right person to come along. Sometimes you choose to hire someone with inadequate skills. In either case, you don't have to just hope for the best. You have other proactive choices: hiring from within, hiring a candidate with some skills and training the rest, changing the way you work, and changing the job description. |