The Latest

This presentation explains the four "laws" of testability: test automation isn't possible without some level of testability; test automation is most successful when developers focus on providing testability; there is no clear distinction betw

This presentation addresses classifying, finding, and attacking software security vulnerabilities.

As Web services increase in complexity and connectivity, security is growing as a major concern. Many security breaches have been the result of poorly tested software that allows unexpected inputs to pass and weaken security measures. Such inputs can create conditions in which intruders can obtain access to parts of the system that would otherwise be secure. One effective way for development teams to prevent unexpected inputs is to perform thorough white-box testing at the unit level. Unlike specification testing (which tests that code behaves as it was intended), white-box testing checks for the conditions and inputs that are not expected, thereby enabling developers to more thoroughly test for what they cannot foresee. By performing such testing at the unit level, developers can quickly and easily identify and correct any weaknesses before security breaches have the opportunity to occur.

The testing environment of many corporations is all too often composed of young employees thrust into the technical world fresh out of college. They are eager and completely overwhelmed with their new environment. Managers are called upon to teach these employees the ways of their company testing. The result is predictable. Managers with limited skills wind up with a work group that reflects these limitations. Even skilled managers with seasoned workers are facing significant problems. It is estimated that over eighty-five percent of all IT projects are delayed or delivered without meeting the predefined specifications by those authorizing the work. In addition, managers do not typically receive training in newer management methodologies such as project management. One organization that faced just such a dilemma was Software Engineering Services, Worldwide Revenue Capture Systems, Information Technology Division within Federal Express Services. Over a period of eighteen months, this department went from not meeting project load dates to an organization that delivered software on-time with fewer software defects. It is the purpose of this paper to provide a blueprint for other organizations looking to reengineer their testing processes based on this experience.

Distributed development teams are becoming the norm for today's software projects. In lieu of close physical interaction, distributed teams are faced with the challenge of keeping software projects on track and keeping remote developers involved. This article provides some suggestions for keeping distributed software teams in touch and on target.

The results of the third annual STQE magazine/StickyMinds.com salary survey give the temperature of the testing industry. Thanks to our readers' continued participation, we now have three years' worth of data and the ability to start looking for trends.