Monday, March 26, 2012

Flash Application - Automation Tools


List of Automation Tools.



 1
Autotestflash
http://osflash.org/autotestflash
2
TestSmith
http://agilethinking.net/qualityforge/testsmith/index.html
3
This site contains some tools list
http://blog.altom.ro/2009/03/flexflash-test-automation-tools.html
4
Ranorex (paid)
5
Flash Selenium (Free)
6
Falsh with Selenium RC
7
Pushtotest
http://www.pushtotest.com/flex-flash-automation-testing

8. 
Test Drive (paid)
http://www.origsoft.com/products/testdrive/
9
FunFx (FREE)
http://funfx.rubyforge.org/
10
FlexPilot (FREE)
http://www.flexpilot.org/
https://addons.mozilla.org/en-US/firefox/addon/flex-pilot-x/
11
RIATest (Paid)
http://www.riatest.com/

























Thursday, February 16, 2012

More about Rapid Release Methodology..............

The Rapid Release Model
The Internet enables software companies to adopt a new software development model, the Rapid Release Model. In this model, once a product is released, a new version is released on the Internet every 90 days. Each 90-day update includes both bug fixes and new features. The pace of development is no different than in the 18-month development cycle, but new features are released to customers as soon as they are ready. During an 18-month period the customer receives six updates that collectively equal or exceed what he traditionally would have received from a single, monolithic update.
Benefits to Customers
Customers benefit from the rapid release model in three ways:
(1) Higher quality
During a 90-day development cycle, new features are implemented during the first 60 days and are tested and debugged during the last 30 days. Any bugs found during testing are easier to fix because the code is still fresh in the developer's mind. During an 18-month cycle, the code in question could be more than a year old. Also, in the Rapid Release Model, the pressure to release features before they are ready is greatly reduced because the next release is already scheduled in 90 days.
The Rapid Release Model does not increase the pace of software development, but it does increase the pace of releases.
(2) Better service
Releasing an update every 90 days enables the software developer to be more responsive to the needs of its customers. For example, when an update to the operating system ships, customers know that an updated version of their software that supports the new OS will be shipping within 90 days. In addition, software companies can plan releases around major OS updates to further prevent customers from having to wait.
(3) Lower price
The Rapid Release Model is more cost effective for the software developer because it no longer maintains the old version of their product while working on a new version. In the Rapid Release Model, old versions are not maintained; they are replaced by an update that contains both bug fixes and new features. The lower cost of development is a benefit that some software companies will choose to pass on to their customers.
Benefits to Developers
Software developers also benefit from the Rapid Release Model in three ways:
(1) Enhanced competitiveness
Software companies that employ the Rapid Release Model can respond very quickly to changing market conditions, demonstrating greater market agility, the ability to be responsive to customer requirements. This makes companies on longer development cycles struggle to keep up.
(2) Reduced risk
Large, monolithic releases can be very risky because 18 months is an enormous period of time in the technology business. Market conditions today are nothing like they were two years ago. Release dates for large updates are often delayed because customer requirements change during the development cycle as new features must be added to an already complex development project. Releasing every 90 days minimizes risk by reducing the amount of time between planning a product and releasing it.
(3) More marketing opportunities
Before the Internet, marketing software required long-range planning around print advertising and magazine editorial calendars. Today, however, most software marketing takes place online, where software updates are covered on websites and in blogs where content is updated on a daily basis. In the Internet marketing game, each new release provides a fresh opportunity to grab a fleeting moment of coverage and online advertising can be focused on the benefits of each new release.
The Rapid Release Model provides more opportunities for a software product to be mentioned by the media as interesting new product releases are made available more frequently.
The Rapid Release Business Model
One challenge with the Rapid Release Model is finding the right way to sell frequent releases to customers. Clearly it would be problematic to ask a customer to purchase an update every three months. Customers would consider this onerous and corporate purchasing departments would be resistant to authorizing frequent update orders. In addition, determining the correct pricing for each small upgrade would be challenging. For these reasons, the most effective way to package and sell rapid updates is through a software maintenance model, where the customer purchases all of the updates released during a 12-month period. This enables the customer to conduct just one transaction per year while receiving an update every 90 days.
Customers do not want to purchase a software upgrade every 90 days.
The customer's concern with this model is whether the developer will stay on schedule and release an update every 90 days. The solution to this problem is to include six months of updates with every new purchase to demonstrate a commitment to the Rapid Release Model before asking the customer to purchase 12 months of updates.
By the time the six months of updates have ended the customer has received two "free" updates and is convinced of the software developer's ability to rapidly update its product.
Conclusion
The traditional 18-month development cycle is a vestige of pre-Internet sales models. Although some commercial software, such as games, require long development cycles with no updates, most software companies and their customers would benefit from a move towards shorter, faster development cycles.
Consumer benefits of this model include higher quality, better service and lower prices. Developer benefits include greater competitiveness, reduced risk and more marketing opportunities.
Developers who do remain on traditional 18-month schedules will appear slow and unresponsive when compared to their more agile competitors who adopt the Rapid Release Model.

More about Extreme Testing or Test Driven Methodology

Extreme Programming

In Extreme Programming, rather than designing whole of the system at the start of the project, the preliminary design work is reduced to solving the simple tasks that have already been identified.
The developers communicate directly with customers and other developers to understand the initial requirements. They start with a very simple task and then get feedback by testing their software as soon as it is developed. The system is delivered to the customers as soon as possible, and the requirements are refined or added based on customer feedback. In this way, requirements evolve over a period of time, and developers are able to respond quickly to changes.
The real design effort occurs when the developers write the code to fulfill the specific engineering task. The engineering task is a part of a greater user story (which is similar to a use case). The user story concerns itself with how the overall system solves a particular problem. It represents a part of the functionality of the overall system. A group of user stories is capable of describing the system as a whole. The developers refactor the previous code iteration to establish the design needed to implement the functionality.
During the Extreme Programming development life cycle, developers usually work in pairs. One developer writes the code for a particular feature, and the second developer reviews the code to ensure that it uses simple solutions and adheres to best design principles and coding practices.
Discussion of the core practices of Extreme Programming is beyond the scope of this chapter. For more information, see the links referred to in "More Information" later in this section.
Test-driven development, which is one of the core practices in Extreme Programming, is discussed in greater detail later in this chapter.

When to Use Extreme Programming

Extreme Programming is useful in the following situations:
  • When the customer does not have a clear understanding of the details of the new system. The developers interact continuously with the customer, delivering small pieces of the application to the customer for feedback, and taking corrective action as necessary.
  • When the technology used to develop the system is new compared to other technologies. Frequent test cycles in Extreme Programming mitigate the risk of incompatibility with other existing systems.
  • When you can afford to create automated unit and functional tests. In some situations, you may need to change the system design so that each module can be tested in isolation using automated unit tests.
  • When the team size is not very large (usually 2 to 12 people). Extreme Programming is successful in part because it requires close team interaction and working in pairs. A large team would have difficulty in communicating efficiently at a fast pace. However, large teams have used Extreme Programming successfully.

More Information

For more information about the core practices in Extreme Programming, see the following resources:

More about Agile Methodology


Agile Methodology

Most software development life cycle methodologies are either iterative or follow a sequential model (as the waterfall model does). As software development becomes more complex, these models cannot efficiently adapt to the continuous and numerous changes that occur. Agile methodology was developed to respond to changes quickly and smoothly. Although the iterative methodologies tend to remove the disadvantage of sequential models, they still are based on the traditional waterfall approach. Agile methodology is a collection of values, principles, and practices that incorporates iterative development, test, and feedback into a new style of development. For an overview of agile methodology, see the Agile Modeling site at http://www.agilemodeling.com/.
The key differences between agile and traditional methodologies are as follows:
  • Development is incremental rather than sequential. Software is developed in incremental, rapid cycles. This results in small, incremental releases, with each release building on previous functionality. Each release is thoroughly tested, which ensures that all issues are addressed in the next iteration.
  • People and interactions are emphasized, rather than processes and tools. Customers, developers, and testers constantly interact with each other. This interaction ensures that the tester is aware of the requirements for the features being developed during a particular iteration and can easily identify any discrepancy between the system and the requirements.
  • Working software is the priority rather than detailed documentation. Agile methodologies rely on face-to-face communication and collaboration, with people working in pairs. Because of the extensive communication with customers and among team members, the project does not need a comprehensive requirements document.
  • Customer collaboration is used, rather than contract negotiation. All agile projects include customers as a part of the team. When developers have questions about a requirement, they immediately get clarification from customers.
  • Responding to change is emphasized, rather than extensive planning. Extreme Programming does not preclude planning your project. However, it suggests changing the plan to accommodate any changes in assumptions for the plan, rather than stubbornly trying to follow the original plan.
Agile methodology has various derivate approaches, such as Extreme Programming, Dynamic Systems Development Method (DSDM), and SCRUM. Extreme Programming is one of the most widely used approaches.