iTesting : SOFTWARE DEVELOPMENT LIFE CYCLE

SOFTWARE DEVELOPMENT LIFE CYCLE [SDLC] Information:

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.

SDLC IN SUMMARY

  • 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

SDLC IN DETAIL

  • 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

Notes:

  • 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 🙂

Advertisements

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
Curiosity
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
Diplomacy

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

Hi

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 🙂

iDiscussion: Does Your Enterprise Have a Central Strategic Mobile Resource?

Does Your Enterprise Have a Central Strategic Mobile Resource?

Mobile technologies are much more than a trend, and are no longer something that organizations and enterprises can overlook or pretend to ignore.

Mobile is already a significant market platform that generates substantial revenues, driven by the ever-growing use of smartphones and mobile applications. However, alongside these exciting business opportunities, mobile technologies and applications also introduce new types of risks that were not an issue in the desktop application world.

As mobile grows, the accompanying pains and risks require (even dictate) the adoption of a robust mobile strategy built upon a centralized organizational solution. Such a strategic solution should be based on an appropriate set of tools that can be used by management, development and testing teams wherever they may be located around the globe.

Mobile applications require enterprises to take into account several mobile-specific components that are not relevant to the desktop space:

  • Governance and availability of devices (smartphones and tablets). The extremely dynamic and fragmented mobile market requires continuous testing of mobile products. To ensure timely delivery to market, you must have access to an up-to-date set of mobile devices at all times.
  • Global solution which enables offshoring, testing and collaboration among diverse and distributed teams
  • Robust manual testing solution to handle user interface and other “look & feel” issues
  • Cross-device test automation solution in order to accelerate TTM and to enable QA to efficiently perform continuous regression testing while moving from one version of the product to the next
  • The ability to plug a dedicated, mobile-specific testing platform into your existing ALM tools, processes and organizational skill sets (i.e., seamlessly integrate with existing ALM quality suites)
  • Mobile Application Performance & Monitoring (APM) must be taken into account. Availability and response time for your mobile application are critical for business success. Studies show that mobile users are less tolerant than desktop users to performance and availability shortcomings.
Figure 1: World Quality Report 2012-2013, CapGemini

When formulating your mobile strategy, do not take the risk of overlooking these important aspects of mobile testing. In addition, the latest World Quality Report (as illustrated above) stresses the importance of using a cloud-based, centralized organisational resource to enhance agility, competitiveness and cost-effectiveness.

Using this blueprint, Perfecto Mobile has deployed mobile testing solutions for leading enterprises and mobile carriers worldwide.  Our experience shows that addressing these key pillars assures ongoing mobile quality while cost-effectively streamlining the entire mobile lifecycle for the various mobility groups (Development, Testing, Performance and Operations).

So here’s the takeaway:

Mobile is a serious business platform which is getting more complex and fragmented every day. New devices will continue to pop up and new mobile OS versions will be released with increasing frequency, making mobile testing that much more difficult.

To thrive in such an environment, enterprises ought to focus their time, energy and resources on developing high quality mobile products that serve their customers’ needs. Integrating the right mobile solution with your existing tools and processes will allow your team to focus on developing real mobile testing scenarios, automation, etc., rather than dealing with organisational issues. By supporting the pillars listed above, your mobile testing solution can serve as a central strategic resource across the enterprise IT environment.

Link : Read Here

Thanks 🙂

Keep Coding 🙂