As I write this, I’m thinking of last night’s midsummer classic—the 2007 All-Star Game—in which the National League was an extra base-hit away from a dramatic ninth-inning, come-from-behind win. But alas, the American League will again have home-field advantage in the World Series.
I think that giving the All-Star Game some meaning beyond bragging rights is a good thing. Plenty of sports-savvy folks disagree, saying that many of the All-Star players come from teams with no chance of making it to the Fall Classic, and therefore have no impetus to make it exciting.
To me, that’s like saying that because I have no personal data on my company’s Web site, I have no interest in keeping it secure.
Nonsense.
That argument assumes that players from one league or the other have no pride in—or loyalty to—their own league, and that just because their own team didn’t make it to the World Series, they won’t then root for another team from their league. For example, if my favorite team—the New York Mets—doesn’t make it, I don’t automatically root for the Yankees; I root for the National League team opposing them (unless it’s the Atlanta Braves).
And I believe that in addition to the drive simply to win the game, players have loyalties similar to those we all should have about our company’s applications, Web sites, corporate data, fellow employees and other resources.
The phrase “If you build it, they will come” from the fine 1989 film “Field of Dreams” is often quoted. But if “it” refers to your Web site, “they” surely means hackers. Is your site up to the task?
And for enterprise applications—particularly those with sensitive data such as ERP, CRM and payroll—comers could include the malicious as well as the innocent. As a tester, it’s up to you to determine the roles the applications are intended to accommodate, and to make sure they allow and disallow access as appropriate.
In this month’s Security Zone special section, software testing veteran Linda Hayes addresses this critical role-based security issue. Cross-functional capabilities and tight integration require enterprise applications to provide security to specific components and data elements. This time-consuming role-based testing lends itself well to automation. This article provides a guideline to organizing, defining and automating your role-based security testing.
Exercise Your Unit Testing
The remaining three articles this month are all about unit testing. The first is the second and concluding installment on continuous integration from Jeffrey Fredrick, lead committer of the CruiseControl project. In it, Fredrick presents a model of change that explains why adopting unit testing is problematic, shows how understanding the model can suggest solutions, and offers steps that can be implemented to help a team successfully adopt unit testing. In short, how to train your old team some new tricks.
Also notable is “A Tale of Two Test Teams” from agile development guru Jeff Nielsen. On the surface, the two teams appear alike. They have similar projects, similar tools and almost identical levels of automation. But spend a day with each team and you’ll begin to notice some big differences.
About the Author
Edward J Correia