Is the best way to interact with your team in person, with your teammates right next to you? Not necessarily. By working online with remote programmers and testers, people tend to approach problems from some unique perspectives. Read on to learn how imagining an ocean between you and your teammates can actually improve your communication and process.
David Thach and Rick Rene share what they have learned are the most effective and readily adoptable agile processes, as well as a few techniques to integrate hybrid waterfall approaches. Companies adopt an agile software development framework to become more effective and more efficient, not to become a model of purist agile utopia—which, if attempted, ironically can be immensely costly and detrimental to progress, if not disastrous.
Thinking about interacting with the customer at the start of the project? Who would argue against that? Well, it depends on what you call it. It also depends on whether you then do it without the benefit of the rest of the project team. Here, Ulrika Park helps us see what an agile approach to thinking about the requirements might look like.
Most of the organizations in today's world have some legacy software or systems. With pressures coming from outsourcing and cost-cutting, new applications are constantly being added to existing IT frameworks. In most cases, it is risky to completely replace the existing systems. As a result, most places have complex applications and systems frameworks. In order to achieve a successful coexistence of several applications on different platforms and technology architecture, teams are faced with some major questions, such as "Should we interoperate or integrate?"
Divided information security and QA teams face three major problems, and ignoring the impact of these problems can lead to disaster. In this week's column, Ryan English discusses the problems and offers three easy steps any organization can take to merge key teams and processes. Improve your QA with this method and avoid finding yourself on the increasingly long list of companies that paid the price when they ignored easily preventable security defects.
As corporate budgets remain tight, most of us are tired of always having to justify additional spending. When security testing pops up on your QA radar, you probably realize that more people and money are needed to make it a reality. But what your boss really wants to see in your plan is a return on investment. In this week's column, Ryan English will help you set up the facts before you try to justify security testing in QA to your manager.
Organizations are feeling the heat regarding application security. Gone are the days when security breaches could be pushed aside or dealt with behind closed doors. Since the beginning of 2005, several security breaches have made front-page news. While it is unclear how many can be blamed on insecure technology, it is obvious that security is quickly becoming an area of great concern.
Many companies are under the impression that testing for Web application security simply involves a cursory check for easy-to-guess usernames and passwords. But Ryan English believes application security testing can and should involve more complex checks, such as testing for SQL injection and cross-site scripting. In this column, Ryan explains that management should avoid postponing this sort of review until the Web application is in production, when it is too late to stop a hacker or a malicious program from attacking and much more expensive to remediate the vulnerability. Instead, QA groups should enter the SDLC early to help mitigate risk.
As the number of Web application vulnerabilities continues to skyrocket, developers are beginning to take security more seriously. In this week's column, Jason Schmitt explains that most developers still are not equipped with the time, tools, or training needed to reliably develop secure Web applications. Yet Jason believes that utilizing hybrid analysis tools can help developers release more secure products.
As software development professionals, we're always learning—not just new technology, but the problem domain, the quirks of the users/clients, even the characteristics of the evolving system itself. That's a lot of learning—from many sources.