Most people don't fully understand the complexities and scope of a software performance test. Too often performance testing is assessed in the same manner as functional testing and, as a result, fails miserably. In this four-part series we will examine what it takes to properly plan, analyze, design, and implement a basic performance test. This is not a discussion of advanced performance techniques or analytical methods; these are the basic problems that must be addressed in software performance testing.
Reloadable test data takes more time up front (as compared to on-the-fly data creation), but saves blood, sweat, and tears in the long term. It also virtually eliminates "works on my machine" bugs, creates a more intricate and realistic environment, and is the first step on the road to test automation.
A focused approach toward testing a product is important, but sometimes we discover information that we didn't anticipate at all. One of the key skills in testing is dynamically managing our focus; sharpening it sometimes and widening it at other times. If we vary our approaches, we might find something surprising and broaden our coverage.
In these times, many of us are being told to "do more with less." A more useful approach is "invest our organization's scarce resources where the return is the greatest." To do so, we must define the financial benefits sought when developing a system in addition to its requirements.
Aspect-oriented requirements engineering (AORE) is a new methodology that can help us to further improve the analysis, structure, and cost of development of software requirements. The second part of this two-part series focuses on the AORE specification techniques.
Improving your software development process is only valuable if it fills the highest priority needs for your business clients with speed and quality. Lean principles provide guidance on how to create a structure that lets business priorities drive the selection of the right products for creation and enhancement.
The benefits of Web services are becoming widely demonstrated and accepted. However, these benefits are not without their own challenges. How can you enter data and verify the response of a system without a GUI? Are you ready to tame this headless beast?
Fed up with good-ol'-boy salesmen, a manufacturing mindset, and just-get-it-out-the-door directions? A little assertiveness, a few ounces of patience, a dash of charm, a lot of leadership, and some attitude adjustment by everyone might help. Read how one manager made the world a better place to work one small victory at a time.
Revisiting your old code can be an enlightening experience. Pete Goodliffe encourages us to look back at our old code to see how our technique has improved, how our programming skills have progressed, and what we can learn from it.
Some schedule games—Split Focus and Pants on Fire—are the result of your management not making certain decisions about the project portfolio. Without those decisions, your project has problems. In this column, Johanna Rothman explains what you can do when the problems on your project are caused by your management’s lack of decision making.