Aspect-oriented requirements engineering (AORE) is a new methodology that can help us improve the analysis, structure, and cost of development of software requirements. AORE does not replace but rather complements any of the existing requirements methodologies. This two-part paper explains to software practitioners the AORE concept, illustrates how it can be applied on software projects, and discusses the benefits of AORE. Part I focuses on the AORE analysis techniques.
Kanban,a Japanese word meaning “signal card,” introduces a new way to think about software development. Through signaling, a limit is set on work in progress resulting in a system that is never overloaded. Kanban signals do not need to be based on passing physical cards; any virtual signaling mechanism will do equally well.
Risk-based testing allows project teams to focus their limited test efforts on the areas of the product that really matter, based on the likelihood of bugs in those areas and the impact of bugs should they exist. By using risk priority to sequence test cases and allocate test effort, test teams can also increase their chances of finding bugs in priority order and allow for risk-based test triage if necessary.
Test-driven development is usually presented as a developer process. On the other hand, acceptance test-driven development (ATDD) is a communication process between the customer and the developer. In ATDD, the tests provide the terminology in customer-understandable terms. The customer's terminology suggests abstract data types that make code more readable.
Charles Darwin was certainly a great scientist, but his career and his discoveries were also strongly influenced by serendipity and luck. What could this great explorer and scientist teach us about testing?
It's a technique children and teenagers have mastered: asking "why" until they get to an acceptable response (or until we're too tired to continue answering). Find out how Michele Sliger uses a similar approach designed by Six Sigma to drill down into the underlying cause of any problem within software projects. She then continues the inquisition with a series of other questions in order to find out how these problems affect business value and technology. Read on to learn what these questions are and how you can start using them to find out why things aren't going as planned.
The testing profession isn't easily mastered, and isn't something that can be perfected by practice alone. Good testers study testing to improve their knowledge of the areas they know about, but great testers strive to find out about areas of software testing they don't yet realize they don't know about.
Few would think that the tactics employed by military and law-enforcement Special Forces to breach buildings under siege bears any relation to software project teams. After a number of weekends training with ex-military and ex-law-enforcement Special Forces—just for fun—Antony Marcano draws a surprising parallel between the dynamics of modern Special Forces "room-clearing" methods and the dynamics of modern software development teams.
The foundation of any successful assessment is interviewing a diverse cross section of the staff. But asking the right questions and asking those questions right makes all the difference in the quality of information you can elicit from your interviewees.
Fresh ideas can provoke us into discovering great insights: Six thinking hats did just that for Julian Harty, who then applied them to software testing with great success. He, and tens of others, has found the thinking hats easy to use, practical, and very productive. Read on to find out how you can apply them to your work.