Using automated tools across the lifecycle to develop higher quality Flex applications

In the past, Flash was associated mostly with timeline-based movies and games developed by a handful of people. Today, enterprise-grade Rich Internet Applications (RIA) based on the Flex Framework are common. Systems implemented using Flash Builder and Flex are becoming increasingly sophisticated. On the client-side, these systems include a rich user interface (requiring design talent, tools, and asset management) and complex business logic. Client-side applications typically also include data services that must handle not only structured data but images, video, and documents. As these applications access Java EE back-end servers, enhanced content, and service-oriented components across multiple platforms, they require comprehensive validation, particularly in financial, insurance, and medical industries. As application scope and complexity increase, so do the project teams. To be effective, larger teams require solid infrastructure supporting collaborative and quality-centric efforts. Because Flex developers face raised expectations for quality, efficiency, and productivity (or concerns about lack thereof), they need to approach the lifecycle of Flex applications on the same terms as applications developed in languages such as Java, C#, and C++.

This article explores lifecycle automation tools for developing quality Flex applications, including solutions from SmartBear.

Software quality is not one dimensional. It involves not just how you work (processes), but how you think and plan (disciplines), and what tools you use. It is well understood that software development is really a multiphase process comprising requirements, design, implementation, optimization, bug fixes, engineering changes, and so on. Defects can be introduced in any of these phases; therefore, there is not a single quality oriented technique that can be applied to magically render the software bug-free.

The biggest impact of poor initial software quality is waste, which causes teams to work more than needed, the software releases to cost more, or both. Studies have found that, on average, more than 50% of software development time is spent on wasted effort that does not result in anything useful. Waste may take many forms: implementing the wrong requirements, creating an inappropriate design, coding mistakes (it still holds true that there is a bug per roughly every 50 initial lines of code), chasing down a memory leak, breaking working code when making changes, manually testing your UI time after time, and so on. While a certain amount of waste is probably unavoidable, there are plenty of reasons and very practical ways to reduce it.

There is nothing really earth shaking in making software of better quality. The two key ingredients of a solution are just common sense: continuously improving development skills and knowledge, and staying disciplined. Following that, since no one is really perfect, having someone or something (whether a computer or a human) else check your work (however rigorously is appropriate) is a best practice. Finally, measuring your results helps you make informed decisions about where to apply resources to make further improvements.

For individuals and more importantly across teams there are many repetitive steps in the software development cycle, including nightly builds and regression tests among others. Of course, creativity is required as well, but repetition ultimately causes boredom and kills creativity. The solution to fighting boredom is simple: automate repetitive steps with tools, and clear more time for creative work.

When considering software tools to deploy, it helps to have a complete picture of the system development process in mind. Among the simplest representations of the development process is the V model or V cycle (see Figure 1). Implementation proceeds from requirements to design to code along the left side, and the right side comprises testing, verification, and maintenance activities. Logically, whatever can be inexpensively automated along this V cycle would be the first to tackle. As you explore the options, keep in mind that sometimes good tools happen to be free, and sometimes they are not.

Requirements capture is critical for a project, it defines what developers are there to build and what testing is going to conduct validation and verification against. In the past, a Word document or a simple web document used to do the job, but now teams are using more formal approaches, and for a good reason. Specifically, the ability to plan and link requirements to downstream activities (design, and especially coding), as well as across the V to tests offers significantly more visibility into the production of software. With teams working across multiple locations and across time zones, web access is practically mandatory. This is an area where improving individual and team knowledge will pay off, investigating trends and techniques in AGILE (use cases and stories leads to better user-developer communication) and Test-Driven Development (TDD). Fortunately, there is no shortage of good web-based requirements (and defect management) tools. Some tools even offer bridges to Mylyn for Eclipse and some Agile automation, for those who use this development approach. Check out, for example, Atlassian JIRA, FogBugz, or SmartBear ALMComplete and its free versions, DevPlanner, and QAPlanner.

Code review is one of the conceptually simplest quality improvement tasks you can do during software development. It has also been proven to be most effective at finding defects, with an average of 60% and up to 90% defects found. In addition to direct code cleansing effects, it also has other benefits, such as improving teamwork and educating developers with less experience. The only problem is that, in its traditional form, code review is a manual process, making it somewhat tedious and effort intensive. In some cases it borders on a waste of time if it is not well managed. Not to mention that checking someone else's work may appear less than exciting to developers.

In reality, code review is a prime example of an inherently creative process–comprehending someone else's code and looking for defects in it–that can be assisted with an automation framework. With tens of thousands of active users around the world, CodeCollaborator from SmartBear (see Figure 2) is among the most popular automated code review tools. It's available as a plug-in to Eclipse, which means it will work seamlessly with Flash Builder, or as a purely browser-based system, which means direct development using the Flex SDK is also supported. CodeCollaborator removes the drudgery from code reviews by handling the boring tasks, including file preparation, notifications, setting up appropriate diff views, and keeping track of the process. It enables real collaboration in real time that is squarely aimed at making code better. The newest version supports integration with TaskTop's Mylyn, which presents code review tasks right in Eclipse.

When it comes to functional testing, you must ensure that once implemented, the code does what it was specified to do (this test happens once). After that, you must ensure the code continues to do what it was specified to do (this regression testing happens many times). Ideally, the test used for the first case (validation) is the same test that is used in the second case (regression testing). There are many reasons to reuse test cases, including reducing wasted effort. Depending on the nature of the implemented feature, a unit test, an API integration test, or a GUI-based functional test may be more appropriate.

Flex is typically used to implement the UI layer, so some form of regression testing of the Flex application's UI is a must. TestComplete from SmartBear supports Flex 4.5 as well as earlier 3.x and 4.x versions. It takes care of both key functional testing tasks. First, it helps with the single-pass validation of every step of a functional scenario by capturing screenshots and inserting checkpoints to compare the actual behavior to whatever was specified. Then it automatically runs the test in regression mode to verify that the behavior stays the same over time. One of the advantages of TestComplete is that it has the capability to test a Flex application as is without any additional libraries or code changes (although it does require Adobe Flash Player content debugger). This enables you to test the actual software that is going to go to your users. Checkout this webinar and article Functional Testing of Adobe Flex Applications: Four Benefits of Using TestComplete on the tool and how to test Flex apps

One of the compelling features of TestComplete is its ability to record tests frame by frame (corresponding to use case steps). It not only uses these frames to aid in verification, but also to extend tests using additional tweaks or adding checkpoints right from the selected frame, without rerecording the whole test (see Figure 3).

This article covered some of the key aspects of automating Flex system development using third-party tools. Whether you choose a tool from a commercial vendor, or a free or open source alternative, be sure to evaluate carefully. Once you deploy a tool, make a commitment to it, so you can put more of your mundane development tasks on autopilot and streamline your development life cycle.