The drive to agile methodologies has held out the promise of software development teams without a dedicated quality-assurance specialist—or organizations without test/QA departments.

Sorry, that’s not going to happen. Sure, dev teams can and should focus on building quality into the product. Of course, code repositories can enforce standards for unit testing. Certainly, business stakeholders should regularly review the software to ensure that it meets their business requirements, just as architects should review against technical requirements.

All of those trends will improve software quality by identifying defects sooner so they can be fixed less expensively. All of those trends will shorten software release cycles and lower software costs.

However, no matter how you slice it, sophisticated software will require sophisticated testing that goes beyond what developers can do. The role of the dedicated test professional or QA team may be diminished, but it has not been eliminated.

That doesn’t mean that we should be satisfied with the speed of software testing, either within the development team or in a dedicated quality-assurance group. There is a business imperative to release software as early as possible and to drive costs out of the process. The QA function, which often comes at the end of the timeline, is both squeezed by coding delays, budget pressures and the CEO’s demand to “ship it faster, ship it now.” With no loss of quality, of course.

What’s a development team lead or software development executive to do? Some answers (as you’ll read in Marnie Hutcheson’s article, “Your tests need to go faster”), involve increasingly automated test suites. Some involve leveraging the latest in DevOps and Continuous Delivery products or services. Some involve sophisticated collaboration. And certainly with the latest in tools, and with careful policies, a team can squeeze a lot of time out of the process.

Not all of it, though. It’s our feeling that while the goal may be to eliminate the need for discrete, human-powered testing phases, we should never expect to totally meet that goal. Unless you plan to turn your customers or end users into beta testers (and we acknowledge that this is trending), someone, somewhere, needs to perform QA prior to release. All the automation in the world can’t eliminate the need for QA. Thank heavens.
An IDE in a browser
We have seen the future of the integrated development environment, and for development teams, that means an IDE delivered from the cloud into a browser. We’re already seeing this move to the cloud happen with business and office productivity software (Salesforce, Microsoft’s Office 365, Adobe Photoshop), and for many of the same reasons, IDEs will not be far behind.

To write software, a development team’s IDE needs libraries, configurations, links into the continuous integration and build system, ties into the testing environment, and whatever extra plug-ins and add-ons are needed by the organization to produce its acceptable standard of code.

Well, a cloud-based, browser-delivered IDE solves all of these issues. It’s something that’s been hinted at for some time. The Eclipse Foundation, for example, has been working on the Orion project, and on a headless Eclipse installation that acts as a server for client-side developers. Both projects have been designed specifically to increase IDE deployment velocity. And, on p. 16, we spotlight a Java-based IDE startup that’s attracted serious attention from investors.

That is what the move to the browser is all about: velocity. Rather than spending the first week with a new hire installing Eclipse and all the stuff that goes with it, you can clone and deploy a development environment, exactly as you would fork a project on GitHub, for example. Who wouldn’t want to be able to share a fully configured IDE with their team?

And for ISVs with hosts of APIs, the browser-based IDE model is a true administrative and productivity boost. Imagine that programmers don’t have to download anything to write software for your platform. They simply have to click on a link, enter security credentials, open a template, click a few buttons, associate a few variables, and then hit “deploy.” The browser as IDE: It is the future.