iConcept : Agile software development methodologies and how to apply them

Agile software development methodologies and how to apply them by 



This article is about basic introduction to Agile software development methodologies and how to apply them. It is about how to work together to achieve a common goal.  This is not only suitable for the Software Developers but also for Team Leaders, Project Managers, Product Managers,  Development Managers, Testers, QA Managers, QA Engineers, Technical Writers, UX Designers, anyone involves in the delivering of software.  This article focus on how technology team work together well  to plan, build and deliver software. It does not talk about code or not focus on specific technology  or not only about Microsoft tools. Hope this will improve your professional life and the effectiveness of your team.

The need for professional behave. Does our industry knows what it means to behave? The definition of a software developer, who sits in a room spend some time and code comes out. We get very confuse about deadlines, date, estimates and all of the things we are suppose to be doing, we do them badly. Now thats not unusual. Our industry is still young.


Winston Royce‘s Waterfall Model

“From the 1970 IEE paper “Managing the Development of Large Software Systems”

There are two essential steps common to all computer program developments, regardless of size or complexity. There is first an analysis step, followed second by a coding step. Then he introduced most five important steps:


Allocate processing, functions, design the data base, define data base processing, allocate execution time, define interfaces and processing modes with the operating system, describe input and output processing, and define preliminary operating procedures. Write an overview document that is understandable, informative and current.

Step2: Document the Design

The first rule of managing software development is ruthless enforcement of documentation requirements.

Step 3: Do It Twice

The second most important criterion for success revolves around whether the product is totally original. If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned.

Step 4: Plan, Control, and Monitor Testing

It is the phase of greatest risk in terms of dollars and schedule. It occurs at the latest point in the schedule when backup alternatives are least available, if at all.

Step 5: Involve the Customer

It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery.

A careful reading of Royce’s paper reveals:  

  • Each phase should pass iteratively to the next
  • The entire process should be exercised twice before release
  • Royce knew that a single pass will fail

Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.

What are all this stuff ?

The answer is :

Agile development is not a methodology in itself. It is an umbrella term that describes several agile methodologies. At the signing of the Agile Manifesto in 2001, these methodologies included Scrum, XP, Crystal, FDD, and DSDM. Since then, Lean practices have also emerged as a valuable agile methodology and so are included under the agile development umbrella in the illustration later.

To learn more read Agile Principles and Values, by Jeff Sutherland

Original Signatories

Ref: agilemanifesto.org

Manifesto for Agile Software Development

Ref: agilemanifesto.org

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Twelve Principles behind the Agile Manifesto

Ref: agilemanifesto.org

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development.The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity–the art of maximizing the amount of work not done–is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Please click here for further detail on Agile Manifesto .

Many developers have lived through the nightmare of a project with no practices to guide it. The lack of effective practices leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping schedules, growing budgets, and poor quality. Developers are disheartened by working ever-longer hours to produce ever-poorer software.


The DSDM (Dynamic Software Development Method) was developed to fill in some of the gaps in the RAD method by providing a framework which takes into account the entire development cycle. The main features of the DSDM method are as follows:

  1. User involvement
  2. Iterative and incremental development
  3. Increased delivery frequency
  4. Integrated tests at each phase
  5. The acceptance of delivered products depends directly on fulfilling requirements.


FDD is a wrapper methodology, in that it allows you to apply a method to manage projects at a very high level, but it still allows you to use other methodologies at a lower level. FDD’s focus is on being able to set estimates and schedules and to report on the status of a project as a whole, or at a very granular level, but it doesn’t prescribe a specific method to apply in order to create the schedule, leaving that up to you to decide. The idea is that you can look at your project and state with some certainty what the project status is, whether you are on time, slipping, early and so on.


Lean Thinking is a way of approaching system optimization focusing on reducing waste and improving overall flow of value through a system. Lean has a rich history in manufacturing and has gained popularity in software development circles in recent years.

Lean comes from Lean Manufacturing and is a set of principles for achieving quality, speed & customer alignment. There are 7 Principles of Lean Software Development:

  1. Eliminate Waste
  2. Build Quality In
  3. Create Knowledge
  4. Defer Commitment
  5. Deliver Fast
  6. Respect People
  7. Optimize the Whole

Applying these principles to the work of delivering a software product is not an end goal. One is not said to “Do Lean”; rather one uses Lean principles to guide decision making and to choose techniques that will improve a system overall. For example, the practice of TDD (Test-Driven Development) builds integrity in to software by inspecting it at the point of creation, thus supporting the Lean principle of building integrity in during the creation process.


In Plan driven development a project is successful if it goes according to plan, so in software development it depends on requirements stability, on having clear and fixed requirements. As you probably know, that is a luxury most software projects don’t have.

The plan-driven methodologies, it is less costly to change requirements during the design stage and it is more expensive to adapt to changes when construction has already started. So,lot of energy is put into the planning phase.But software development is different.  There is no guarantee that a good design will make construction predictable.

"Walking on water and developing software from a specification are easy if both are frozen."– Edward V. Berard

The Agile approach is to break the dependency on requirements stability and come up with a process that takes into account changes. It does that by using Adaptive Planning and Evolutionary Design.

Adaptive planning implies going through the project cycle many times, re-planning and re-adapting often.

Evolutionary design can be achieved with the help of practices like Self Testing Code, Continuous Integration, Refactoring and Simple Design.

One is value-driven (agile) and another is plan-driven (traditional). This is not to say that plan-driven approaches have no values; it is to say that in agile, we make them explicit and discuss them often.

Both agile and plan-driven approaches have situation-dependent shortcomings that, if not addressed, can lead to project failure. The challenge is to balance the two approaches to take advantage of their strengths in a given situation while compensating for their weaknesses.

Plan vs. Agile

Fundamental difference between Plan driven development and Agile driven development lies between two  significant differences. First one in the Plan driven model the team will deploy one increment of software at the end of the project. But in Agile we will deploy very small change of the software or more frequently. The second one is sequential verses concurrent activity.  In Plan driven development one process starts after successful completion of another. But in Agile we plan all the time.

Plan your work, then work your Plan” by Martin Fowler and Neal Ford

  • Both provide processes, tools and techniques
  • Both require disciplined approach to software development
  • Each has strengths and weaknesses
  • Agile methodologies address many situations for which Plan-driven methodologies are not well suited
  • Agile is still a disciplined approach to software development but with an emphasis on different aspects of the process!
  • Plan driven emphasizes formal communications and control
  • Agile emphasizes continual communications and ability to changes and uncertainty
  • Highly iterative to achieve quality over Lots of gates to control quality
  • Inspect work as it is being done over Inspect product when it is complete
  • Start with a goal of filling a need over Start by predicting what will be delivered
Ability to changes

Customer satisfaction by rapid, continuous delivery of useful software.
People and interactions are emphasized rather than process and tools. Customers, developers and testers constantly interact with each other.
Working software is delivered frequently (weeks rather than months).
Face-to-face conversation is the best form of communication.
Close, daily cooperation between business people and developers.
Continuous attention to technical excellence and good design.
Regular adaptation to changing circumstances.
Even late changes in requirements are welcomed

Management teams that work well with Plan-driven approaches also tend to work well with Agile approaches  

However, management teams that lack the ability to work well with Plan-driven approaches may lack the focus required of Agile


The principles and values of agile software development were formed as a way to help teams to break the cycle of process inflation and mainly focus on simple techniques for achieving their goals. The GOAL ?? What is the the GOAL?

OK, the main goal of every software developer and every development team is to deliver the highest possible value to employers and customers. Yet our projects fail, or fail to deliver value.

The key is in the Agile technique compressing the five sequences of the conventional software development method – called the Waterfall method – to a one-week cycle. It manages to do this by developing a system through repeated cycles (iterative) and in smaller portions (incremental), allowing developers to test and review during development. Speed, lower cost and flexibility are key benefits.

“Adoption rates among IT departments are accelerating,” says Phil Murphy, vice president and research director at Forrester in a 2011 report.

The participants in an agile process are not afraid of change. They view changes to the requirements as good things, because those changes mean that the team has learned more about what it will take to satisfy the customer. Agile team members work together on all aspects of the project. Each member is allowed input into the whole. No single team member is solely responsible for the architecture or the requirements or the tests. The team shares those responsibilities, and each team member has influence over them.

There are many agile processes : SCRUM, Crystal, Behavior-Driven Development (BDD), Test-Driven Development (TDD), Feature-Driven Development (FDD), Adaptive Software Development (ADP), Extreme Programming (XP) and more… However, the vast majority of successful agile teams have drawn from all these processes to tune their own particular flavor of agility. These adaptations appear to be come together with the combination of SCRUM and XP, in which SCRUM practices are used to manage multiple teams that use XP.

Extreme Programming (XP)

As developers we need to remember that XP is not the only game in town.- Pete McBreen

Extreme Programming emphasizes teamwork. Managers, customers, and developers.It improves a software project in five essential ways; communication, simplicity, feedback, respect, and courage.

So according to Wiki definition “Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent “releases” in short development cycles, which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.”

Extreme Programming is a set of simple and concrete practices that combine into an agile development process. XP is a good general-purpose method for developing software. Many project teams will be able to adopt it as is. Many others will be able to adapt it by adding or modifying

  • The ancestor of most Agile methodologies
  • Kent Beck created quite a buzz in the late 1990s and early 2000s
  • Blends processes and practices
 Kent Beck’s basic idea
  • Take observed effective team practices
  • Push them to extreme level

What does that mean “Push them to extreme level“? Is that mean something like the following images ??



No, that doesn’t mean XP. Lets us see what does that mean.

XP is a set of practices that conform to the values and principles of Agile. XP is a discrete method, whereas Agile is a classification. There are many Agile methods, XP is just one of them.

Having said that, none of the other Agile methods are as well defined, or as broad in scope as XP. Scrum, for example, is roughly equivalent to XP’s Planning game practice, with elements of Whole Team. While there are differences in the details, it is fair to say that Scrum is a subset of XP. Indeed, many Scrum teams augment their process by adding in many of the XP practices such as Acceptance Testing, Pair Programming, Continuous Integration, and especially Test Driven Development.
Of all the Agile methods, XP is the only method that provides deep and profound disciplines for the way developers do their daily work. Of those disciplines, Test Driven Development is the most revolutionary. Following are some good XP practices. I will try to write detail on each next time.


Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development. Its focus is on “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal” as opposed to a “traditional, sequential approach“. Scrum asks why does it take so long, and so much effort to do stuff? And why do we are we so bad at figuring out how long and how much effort things will take? Scrum embraces uncertainty and creativity. Because that is how people work. It places a structure around the learning process, enabling teams to assess both what they’ve created, and just as importantly, how they created it.

  • Scrum was first defined as “a flexible, holistic product development strategy in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka.
  • In 1995, Sutherland and Schwaber jointly presented a paper describing the Scrum methodology. First public presentation.

Scrum Roles

There are three core roles for producing the product.

  1. Product Owner
  2. Development Team
  3. ScrumMaster
  4. Stakeholders
  5. Managers
Product Owner

  • The Product Owner represents the stakeholders and is the voice of the customer.
  • Accountable for ensuring value to the business.
  • Writes (or the team) customer-centric items (user stories), prioritizes them, and adds them to the product backlog.
  • Scrum teams should have one, may also be a member of the development team
  • Not be combined with that of the ScrumMaster.
Development Team
  • Responsible for delivering potentially shippable product increments at the end of each Sprint.
  • Made up of 3–9 people with cross-functional skills who do the actual work (analyze, design, develop, test, technical communication, document, etc.).
  • Self-organizing, even though they may interface with project management organizations (PMOs).
  • Accountable for removing impediments to the ability of the team to deliver the sprint goal/deliverables.
  • Is not the team leader, but acts as a buffer between the team and any distracting influences.
  • Ensures that the Scrum process is used as intended.
  • Enforcer of rules. Protector of the team and keep it focused on the tasks at hand.
  • Also been referred to as a servant-leader to reinforce these dual perspectives.
  • Differs from a Project Manager in that the latter may have people management responsibilities unrelated to the role of ScrumMaster.
  • Excludes any such additional people responsibilities.


The product backlog is an ordered list of “requirements” that is maintained for a product. It consists of features, bug fixes, non-functional requirements, etc. – whatever needs to be done in order to successfully deliver a working software system. In Scrum, it is not required to start a project with a lengthy, upfront effort to document all requirements. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers

The sprint backlog is the list of work the Development Team must address during the next sprint. The list is derived by selecting stories/features from the top of the product backlog until the Development Team feels it has enough work to fill the sprint. This is done by the Development Team asking “Can we also do this?” and adding stories/features to the sprint backlog.


Conceptually, the team starts at the top of the prioritized Scrum backlog and draws a line after the lowest of the high-priority items they feel they can complete. In practice, it is not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five.

Agile Development Survey

The survey was conducted between August 9th and November 1, 2012. Sponsored by VersionOne, The survey polled 4,048 individuals from various channels in the software development communities. The data was analyzed and prepared into a summary report by Analysis.Net Research, an independent survey consultancy.

Who Knows Agile ?

 Cause Of Agile Failure 

 Barriers to Further Agile Adoption 

 Greatest Concerns about adopting Agile 


A good agile team picks and chooses the management & technical practices that best work for them.When trying to adopt Agile practices, there will be a ton of excuses as why it won’t work. Those who understand the real benefits of the approach – and genuinely want to make the transition – will likely have success. Those who are searching for reasons why it will fail – well, they will likely find them and either abandon the effort entirely or end up practicing what Elisabeth Hendrickson calls “fake agile.”

In support of this conclusion, let me leave you with some words (Collected from Robert C. Martin):
In preparing for battle I have always found that plans are useless, but planning is indispensable.” – General Dwight David Eisenhower

It is better not to fixate on any given methodology, because the needs/conditions of the company and project are likely to change regularly, and you need to be flexible in how you approach managing projects if you want them to be successful. No single methodology is a silver bullet, so the trick is to determine which methods work for you and tune your methodology to suit your individual needs. This is what being “Agile is fundamentally about.

Not Agile. It’s important to remember that Scrum and Agile methodology are not a one-time look at a companies process, it’s an on-going philosophy based on continuous improvement.

Reference : HERE




Software Development Life Cycle, or Software Development Process, defines the steps/stages/phases in the building of software.

There are various kinds of software development models like:

Models are evolving with time and the development life cycle can vary significantly from one model to the other. It is beyond the scope of this particular article to discuss each model. However, each model comprises of all or some of the following phases/activities/tasks.


  • Project Planning
  • Requirements Development
  • Estimation
  • Scheduling
  • Design
  • Coding
  • Test Build/Deployment
  • Unit Testing
  • Integration Testing
  • User Documentation
  • System Testing
  • Acceptance Testing
  • Production Build/Deployment
  • Release
  • Maintenance


  • Project Planning
    • Prepare
    • Review
    • Rework
    • Baseline
    • Revise [if necessary] >> Review >> Rework >> Baseline
  • Requirements Development[Business Requirements and Software/Product Requirements]
    • Develop
    • Review
    • Rework
    • Baseline
    • Revise [if necessary] >> Review >> Rework >> Baseline
  • Estimation[Size / Effort / Cost]
    • <same as the activities/tasks mentioned for Project Planning>
  • Scheduling
    • <same as the activities/tasks mentioned for Project Planning>
  • Designing[ High Level Design and Detail Design]
    • <same as the activities/tasks mentioned for Requirements Development>
  • Coding
    • Code
    • Review
    • Rework
    • Commit
    • Recode [if necessary] >> Review >> Rework >> Commit
  • Test Builds Preparation/Deployment
    • Build/Deployment Plan
      • Prepare
      • Review
      • Rework
      • Baseline
      • Revise [if necessary] >> Review >> Rework >> Baseline
    • Build/Deploy
  • Unit Testing
    • Test Plan
      • Prepare
      • Review
      • Rework
      • Baseline
      • Revise [if necessary] >> Review >> Rework >> Baseline
    • Test Cases/Scripts
      • Prepare
      • Review
      • Rework
      • Baseline
      • Execute
      • Revise [if necessary] >> Review >> Rework >> Baseline >> Execute
  • Integration Testing
    • <same as the activities/tasks mentioned for unit testing>
  • User Documentation
    • Prepare
    • Review
    • Rework
    • Baseline
    • Revise [if necessary] >> Review >> Rework >> Baseline
  • System Testing
    • <same as the activities/tasks mentioned for Unit Testing>
  • Acceptance Testing[ Internal Acceptance Test and External Acceptance Test]
    • <same as the activities/tasks mentioned for Unit Testing>
  • Production Build/Deployment
    • <same as the activities/tasks mentioned for Test Build/Deployment>
  • Release
    • Prepare
    • Review
    • Rework
    • Release
  • Maintenance
    • Recode [Enhance software / Fix bugs]
    • Retest
    • Redeploy
    • Rerelease


  • The life cycle mentioned here is NOT set in stone and each phase does not necessarily have to be implemented in the order mentioned.
  • Though SDLC uses the term ‘Development’, it does not focus just on the coding tasks done by developers but incorporates the tasks of all stakeholders, including testers.

There may still be many other activities/ tasks which have not been specifically mentioned above, like Configuration Management. No matter what, it is essential that you clearly understand the software development life cycle your project is following. One issue that is widespread in many projects is that software testers are involved much later in the life cycle, due to which they lack visibility and authority (which ultimately compromises software quality).

Source :  Here

Thanks, Keep Coding 🙂

iTesting: Software Testing Life Cycle (STLC)

Software Testing Life Cycle (STLC) defines the steps/stages/phases in testing of software. However, there is no fixed standard of STLC in the world and it basically varies as per the following:

Nevertheless, Software Testing Life Cycle, in general, comprises of the following phases:

Software Testing Life Cycle

Phase Activity Deliverables Necessity
Requirements/Design Review You review the software requirements/design (Well, if they exist.)
  • Review Defect Reports
Test Planning Once you have gathered a general idea of what needs to be tested, you ‘plan’ for the tests. Farsightedness
Test Designing You design/detail your tests on the basis of detailed requirements/design of the software (sometimes, on the basis of your imagination). Creativity
Test Environment Setup You setup the test environment (server/client/network, etc) with the goal of replicating the end-users’ environment.
  • Test Environment
Rich company
Test Execution You execute your Test Cases/Scripts in the Test Environment to see whether they pass. Patience
Test Reporting You prepare various reports for various stakeholders.
  • Test Results (Final)
  • Test/Defect Metrics
  • Test Closure Report
  • Who Worked Till Late & on Weekends Report

Interestingly, no matter how well-defined a Software Testing Life Cycle you have in your project or organization, there are chances that you will invariably witness the following widely-popular cycle:

  • Testing
  • Cursing

In this type of STLC, you skip phases like requirement/design review, test planning, and test designing –in the high hope that the skipping will save you some time and/or cost.

Also, note that the Software Testing Life Cycle phases mentioned above do not necessarily have to be in the order listed; some phases can sometimes run in parallel (For instance, Test Designing and Test Execution). And, in extreme cases, the phases might also be reversed (For instance, when there is Cursing prior to Testing).

Source : Read Here

Thanks , Keep Coding 🙂

iTesting : Best practices for iOS mobile application testing


iOS changed the mobility game, no doubt about it. It paved the way for the ‘mobile era’ by offering amazing functionality with a simple user experience.  However when it comes to testing and monitoring, working with the iPhone/iPad mobile application can be anything but simple…

As the iOS app market continues to produce record growth, challenges and complexities surrounding iOS application testing also continue to interfere with development. A key challenge of iOS testing is that, unlike the open-source Android OS, Apple iOS is a closed operating system. Added complexity during the development and testing stages arises with a closed system, since users can’t extract necessary data from low level objects, which are essential for test automation. So, what’s the best approach for getting the necessary level of access to the iOS device – rooting (jailbreaking) or compile-time source instrumentation? Should you base your testing on native objects or OCR-based screen analysis?

Let’s take a deeper look into some of these challenges and why a cloud-based hybrid approach is important to offer developers and testers the necessary coverage, capabilities and flexibility to deliver better iOS apps and deploy them with confidence.

Rooting (jailbreaking) vs. Source Instrumentation (compile-time)

There are two common methods used today in the mobile testing industry to address this challenge (i.e. access to the low level objects): rooting (jailbreaking) and source instrumentation (i.e. compile-time solution).

Jailbreaking refers to the process of removing the limitations placed by Apple on the iOS device in order to get low level (root) access to the operating system. This allows the tester to be able to recognize the objects within the application being tested.

Source Instrumentation is performed by compiling the application being tested with an additional piece of code that provides access (“back door”) to the low level OS for object recognition. This code enables the tester to execute the low level calls and get the Object ID’s from the operating systems (without the need to root/jailbreak the device).

The decision as what approach to adopt strongly depends on several considerations (below are just few):

1)    The used SDLC process

2)    Corporate policies

3)    Application under test

4)    Frequency of testing

Perfecto Mobile provides its end users with the freedom to choose what fits them best, while taking into consideration the advantages and disadvantages of each approach. When customers need to quickly test either a new iOS version or a new iOS device, the jailbreaking approach is less suitable. In such a case, the compile-time method is preferable – even though it complicates the SDLC by introducing additional code to the application being tested.

On the other hand, using a jailbroken device lets you test the application with the exact code by which it will be released (compile-time mandates that before store submission, you will remove the “back-door” or be exposed to serious security issues). This eliminates the need for compilation and intrusive operations which could potentially pose a risk to quality. Companies using a compile-time approach should also consider possible regulations (such as HIPAA) which enforce testing on the final binary (and not on debug version, test friendly version, etc.)

The combined (hybrid) approach lets you choose which type of tests to implement on which iOS device according to the nature of your application, project needs, and policy. When the test devices are deployed and securely managed in a “private cloud” (such as that offered by Perfecto Mobile), such a configuration guarantees that the jailbreak method does not introduce any risks or abuse of the platform for non-testing purposes. The jailbroken device is used only for testing purposes in a closed and secure testing environment. This is analogous to the use the way iOS devices used for development have a “developer signature,” as well as the way Android devices used for development have more levels of access than those required during the normal ALM cycle.

The Need for a Hybrid Approach to Object Recognition

Testing a mobile application requires strong object recognition capabilities. The use of visual analysis might not be sufficient, for example, the OCR technology can detect UI issues and glitches on the test devices, but cannot ensure 100% accuracy due to its heuristic nature. On the other hand, low level objects might “miss” the obvious qualification that a visual analysis can easily detect. That’s why a hybrid approach incorporating both visual and Native object analysis is imperative for covering all mobile business cases. Such an approach is supported by Perfecto Mobile.

Object level analysis vs. Visual analysis

This screenshot above shows the differences of using an object level analysis as opposed to visual analysis (object level analysis would not have detected the overlapping of the button on the text).

The Perfecto Mobile Approach: Go Cloud, Go Hybrid

Perfecto Mobile’s experience as a market leader has taught us that the best approach is to present each customer with all possible alternatives making them available inside the cloud.

Real devices + emulators (in the cloud),  OCR screen analysis + OS level native objects (in the cloud), rooted/jailbroken device + non-rooted/jailbroken devices (in the cloud)

With hundreds of thousands of automation hours running every month on our platform, we are well-positioned to suggest and guide, but not to “judge” what’s best for everyone…

Perfecto Mobile hybrid object support on a rooted android and a non-jailbroken iPhone

Source Here : Read Here

Thanks , Keep Coding 🙂