Wednesday, December 3, 2014

Capability Maturity Model Integration (CMMI)



Capability Maturity Model Integration (CMMI) is a process improvement training and appraisal program and service administered and marketed by Carnegie Mellon Universityand required by many DOD and U.S. Government contracts, especially in software development. Carnegie Mellon University claims CMMI can be used to guide process improvement across a project, division, or an entire organization. Under the CMMI methodology, processes are rated according to their maturity levels, which are defined as: Initial, Managed, Defined, Quantitatively Managed, Optimizing. Currently supported is CMMI Version 1.3. CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

Overview



CMMI currently addresses three areas of interest:
  1. Product and service development — CMMI for Development (CMMI-DEV),
  2. Service establishment, management, — CMMI for Services (CMMI-SVC), and
  3. Product and service acquisition — CMMI for Acquisition (CMMI-ACQ).
CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.[1] By January of 2013, the entire CMMI product suite was transferred from the SEI to the CMMI Institute, a newly created organization at Carnegie Mellon.[2]
CMMI originated in software engineering but has been highly generalized over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM (CMM, see below).

History

CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by integrating many different models into one framework. The project consisted of members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI). The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association.
CMMI is the successor of the capability maturity model (CMM) or Software CMM. The CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released, Version 1.2 followed in August 2006, and CMMI Version 1.3 in November 2010. Some of the major changes in CMMI V1.3 [3] are the support of Agile Software Development,[4]improvements to high maturity practices [5] and alignment of the representation (staged and continuous).[6]
According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes."[7]

CMMI topics

CMMI representation

CMMI exists in two representations: continuous and staged.[1] The continuous representation is designed to allow the user to focus on the specific processes that are considered important for the organization's immediate business objectives, or those to which the organization assigns a high degree of risks. The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations. The staged representation also provides for an easy migration from the SW-CMM to CMMI.[1]

CMMI model framework

For more details on this topic, see Process area (CMMI).
Depending on the CMMI areas of interest (acquisition, services, development) used, the process areas it contains will vary.[8] Process areas are the areas that will be covered by the organization's processes. The table below lists the collection of sixteen CMMI core process areas that are present for all CMMI areas of interest in CMMI Version 1.3.

Capability Maturity Model Integration (CMMI) Core Process Areas
AbbreviationNameAreaMaturity Level
CARCausal Analysis and ResolutionSupport5
CMConfiguration ManagementSupport2
DARDecision Analysis and ResolutionSupport3
IPMIntegrated Project ManagementProject Management3
MAMeasurement and AnalysisSupport2
OPDOrganizational Process DefinitionProcess Management3
OPFOrganizational Process FocusProcess Management3
OPMOrganizational Performance ManagementProcess Management5
OPPOrganizational Process PerformanceProcess Management4
OTOrganizational TrainingProcess Management3
PMCProject Monitoring and ControlProject Management2
PPProject PlanningProject Management2
PPQAProcess and Product Quality AssuranceSupport2
QPMQuantitative Project ManagementProject Management4
REQMRequirements ManagementProject Management2
RSKMRisk ManagementProject Management3
SAMSupplier Agreement ManagementSupport2

Maturity levels in CMMI for development

There are five maturity levels. Maturity level ratings are awarded for levels 2 through 5. The process areas below and their maturity levels are listed for the CMMI for Development model:
Maturity Level 2 - Managed
  • CM - Configuration Management
  • MA - Measurement and Analysis
  • PMC - Project Monitoring and Control
  • PP - Project Planning
  • PPQA - Process and Product Quality Assurance
  • REQM - Requirements Management
  • SAM - Supplier Agreement Management
Maturity Level 3 - Defined
  • DAR - Decision Analysis and Resolution
  • IPM - Integrated Project Management
  • OPD - Organizational Process Definition
  • OPF - Organizational Process Focus
  • OT - Organizational Training
  • PI - Product Integration
  • RD - Requirements Development
  • RSKM - Risk Management
  • TS - Technical Solution
  • VAL - Validation
  • VER - Verification
Maturity Level 4 - Quantitatively Managed
  • OPP - Organizational Process Performance
  • QPM - Quantitative Project Management
Maturity Level 5 - Optimizing
  • CAR - Causal Analysis and Resolution
  • OPM - Organizational Performance Management

Maturity levels in CMMI for services

The process areas below and their maturity levels are listed for the CMMI for Services model:
Maturity Level 2 - Managed
  • CM - Configuration Management
  • MA - Measurement and Analysis
  • PPQA - Process and Product Quality Assurance
  • REQM - Requirements Management
  • SAM - Supplier Agreement Management
  • SD - Service Delivery
  • WMC - Work Monitoring and Control
  • WP - Work Planning
Maturity Level 3 - Defined
  • CAM - Capacity and Availability Management
  • DAR - Decision Analysis and Resolution
  • IRP - Incident Resolution and Prevention
  • IWM - Integrated Work Managements
  • OPD - Organizational Process Definition
  • OPF - Organizational Process Focus
  • OT - Organizational Training
  • RSKM - Risk Management
  • SCON - Service Continuity
  • SSD - Service System Development
  • SST - Service System Transition
  • STSM - Strategic Service Management
Maturity Level 4 - Quantitatively Managed
  • OPP - Organizational Process Performance
  • QWM - Quantitative Work Management
Maturity Level 5 - Optimizing
  • CAR - Causal Analysis and Resolution
  • OPM - Organizational Performance Management

Maturity levels in CMMI for acquisition

The process areas below and their maturity levels are listed for the CMMI for Acquisition model:
Maturity Level 2 - Managed
  • AM - Agreement Management
  • ARD - Acquisition Requirements Development
  • CM - Configuration Management
  • MA - Measurement and Analysis
  • PMC - Project Monitoring and Control
  • PP - Project Planning
  • PPQA - Process and Product Quality Assurance
  • REQM - Requirements Management
  • SSAD - Solicitation and Supplier Agreement Development
Maturity Level 3 - Defined
  • ATM - Acquisition Technical Management
  • AVAL - Acquisition Validation
  • AVER - Acquisition Verification
  • DAR - Decision Analysis and Resolution
  • IPM - Integrated Project Management
  • OPD - Organizational Process Definition
  • OPF - Organizational Process Focus
  • OT - Organizational Training
  • RSKM - Risk Management
Maturity Level 4 - Quantitatively Managed
  • OPP - Organizational Process Performance
  • QPM - Quantitative Project Management
Maturity Level 5 - Optimizing
  • CAR - Causal Analysis and Resolution
  • OPM - Organizational Performance Management

CMMI models[edit]

CMMI best practices are published in documents called models, each of which addresses a different area of interest. The current release, CMMI Version 1.3, provides models for three areas of interest: development, acquisition, and services.
  • CMMI for Development (CMMI-DEV), v1.3 was released in November 2010. It addresses product and service development processes.
  • CMMI for Acquisition (CMMI-ACQ), v1.3 was released in November 2010. It addresses supply chain management, acquisition, and outsourcing processes in government and industry.
  • CMMI for Services (CMMI-SVC), v1.3 was released in November 2010. It addresses guidance for delivering services within an organization and to external customers.

Appraisal

An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a capability level achievement profile.
Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are typically conducted for one or more of the following reasons:
  1. To determine how well the organization’s processes compare to CMMI best practices, and to identify areas where improvement can be made
  2. To inform external customers and suppliers of how well the organization’s processes compare to CMMI best practices
  3. To meet the contractual requirements of one or more customers
Appraisals of organizations using a CMMI model[9] must conform to the requirements defined in the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals, A, B and C, which focus on identifying improvement opportunities and comparing the organization’s processes to CMMI best practices. Of these, class A appraisal is the most formal and is the only one that can result in a level rating. Appraisal teams use a CMMI model and ARC-conformant appraisal method to guide their evaluation of the organization and their reporting of conclusions. The appraisal results can then be used (e.g., by a process group) to plan improvements for the organization.
The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method that meets all of the ARC requirements.[10] Results of an SCAMPI appraisal may be published (if the appraised organization approves) on the CMMI Web site of the SEI: Published SCAMPI Appraisal Results. SCAMPI also supports the conduct ofISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability Determination), assessments etc.
This approach promotes that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches, that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM as well as CMMI.[11] These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. Since the release of the CMMI, the median times to move from Level 1 to Level 2 is 5 months, with median movement to Level 3 another 21 months. These statistics are updated and published every six months in a maturity profile.[citation needed]
The Software Engineering Institute’s (SEI) Team Software Process methodology and the use of CMMI models can be used to raise the maturity level. A new product called Accelerated Improvement Method[12] (AIM) combines the use of CMMI and the TSP.[13]

CMMI Security Guides[edit]

To address user security concerns, two unofficial security guides are available. Considering the Case for Security Content in CMMI for Services has one process area, Security Management.[14] Security by Design with CMMI for Development, Version 1.3 has the following process areas:
  • OPSD - Organizational Preparedness for Secure Development
  • SMP - Secure Management in Projects
  • SRTS - Security Requirements and Technical Solution
  • SVV - Security Verification and Validation
While they do not affect maturity or capability levels, these process areas can be reported in appraisal results.[15]

Applications

The SEI published that 60 organizations measured increases of performance in the categories of cost, schedule, productivity, quality and customer satisfaction.[16] The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. These results do not guarantee that applying CMMI will increase performance in every organization. A small company with few resources may be less likely to benefit from CMMI; this view is supported by the process maturity profile (page 10). Of the small organizations (<25 employees), 70.5% are assessed at level 2: Managed, while 52.8% of the organizations with 1001–2000 employees are rated at the highest level (5: Optimizing).
Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. Sutherland et al. (2007) assert that a combination of Scrum and CMMI brings more adaptability and predictability than either one alone. David J. Anderson (2005) gives hints on how to interpret CMMI in an agile manner.
CMMI Roadmaps,[17] which are a goal-driven approach to selecting and deploying relevant process areas from the CMMI-DEV model, can provide guidance and focus for effective CMMI adoption. There are several CMMI roadmaps for the continuous representation, each with a specific set of improvement goals. Examples are the CMMI Project Roadmap,[18] CMMI Product and Product Integration Roadmaps [19] and the CMMI Process and Measurements Roadmaps.[20] These roadmaps combine the strengths of both the staged and the continuous representations.
The combination of the project management technique earned value management (EVM) with CMMI has been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements management approach, which relies on oral communication, was evaluated as not compliant with CMMI.
CMMI can be appraised using two different approaches: staged and continuous. The staged approach yields appraisal results as one of five maturity levels. The continuous approach yields one of four capability levels. The differences in these approaches are felt only in the appraisal; the best practices are equivalent and result in equivalent process improvement results.

See also

Wednesday, November 26, 2014

GUI Testing on Smart Devices – Testing Guidelines

As “First impression is the last”, so GUI(Graphical User Interface) does matter and creates a lot of difference. Importance of decent and attractive GUI can be felt more significantly in smart devicesenvironment where screen size is much small.
GUI testing can be toughest part especially while testing on smart device. You should pay full attention to the GUI while testing on smart devices and surely it is an important task that deserves significant time and resource allocation.
Practical Tips for Testing GUI on Smart Devices:
For me, while testing GUI, all the controls are accused. I raise questions why they are there on the screen and I try to answer these questions. I argue in opposition and favor of the controls one by one and I do all this without discussing with someone else. It is the time when I’m wearing multiple hats, Controls are accused and I’m the Prosecutor , I’m the Defense Lawyer and I’m the Judge and during all this process a control must have valid and solid reasons in its favor to be there on screen and consume space. I suggest you to try it and it will help you to decide which controls to display on the screen.
There also come the situations where you are given an already built GUI to test. In such situations also think about the missing controls, the controls that will add value to the screen and compare their importance with the current ones. If you think you need to make a change go ahead.
Once you have decided which controls will be shown on the screen, think thoroughly about size, style and location of the controls on the screen and more important how user will interact with them?
3 important factors to be considered while testing GUI on Smart Devices:
GUI testing smart devices
Size:
There are too many variations in screen sizes and available resolutions. In smart devices especially, controls sizes are not static, they have relation to the available screen size.
While testing, make sure that controls size looks esthetically good and control is completely visible on the screen without any sc
rolling. Test the GUI on different devices with different screen sizes and resolutions.
Emulators are good for this purpose but nothing matches the real device. So make sure that you test on at least two or three real devices. Also don’t forget to test on landscape and portrait orientations if the device supports it.
Style:
Definitely your application has a specific design. And style of the controls should match with that design. You might have seen many applications where some controls e.g. panels have round edges and text boxes in them have sharp edges. Although this type of issues don’t affect the usability or functionality but still a consistent look of the application helps to build a friendly relation between the application and the user.
Relatively more important thing in style is font on the different pages. Most of the times, we focus the text that is visible in normal situations and ignore the text that appears in specific situations. Success and Failure messages are an example of such type of text.

Another factor, important in style is relation between the font color and the situation in which text is displayed. For example Red color is used for Error messages, Green for success, Yellow for warnings and Blue (now a day occasionally) for hyperlinks.
Location:
Location and position are the two words that are used alternatively and it is interesting that they are further used to convey two different concepts that are explained below.
1. Sometimes it is the area on the screen where a control appears. For example Header is located on Top of the page, Labels are Left Aligned, and Text boxes are Right Aligned etc. Here text in bold are relative positions of the controls
2. Sometimes it is the order of a control among the other controls. For example while getting personal info, First Name is followed by the last name or format of controls to ask for a US address should be in order ZIP, City, State.
For both these situations, make sure that everything is logical and shows a good aesthetic sense.
Forgot something even more important. There are situations where one or more controls appear on more than one screen, in this situation make sure that they appear on same location and in the same order on all the pages.

Mobile Application Testing

Introduction to Mobile Application Testing:
Gone are the days when the telephone used to be an appliance that sat in a corner and had to ring to get our attention or a computer was a machine only few people used – they are now an extension of our being- a window to the world and virtual servants that do as they are told. Computers were a rage and changed how we humans thought, behaved, learnt and existed.

Types of Mobile Testing

There are broadly 2 kinds of testing that take place on mobile devices:
#1. Hardware testing:
The device including the internal processors, internal hardware, screen sizes, resolution, space or memory, camera, radio, Bluetooth, WIFI etc. This is sometimes referred to as, simple “Mobile Testing”.
#2. Software or Application testing:
The applications that work on mobile devices and their functionality is tested. It is called the “Mobile Application Testing” to differentiate it from the earlier method. Even in the mobile applications, there are few basic differences that are important to understand:
a) Native apps: A native application is created for use on a platform like mobile and tablets.
b) Mobile web apps are server-side apps to access website/s on mobile using different browsers like chrome, Firefox by connecting to a mobile network or wireless network like WIFI.
c) Hybrid apps are combinations of native app and web app. They run on devices or offline and are written using web technologies like HTML5 and CSS.
There are few basic differences that set these apart:
  • Native apps have single platform affinity while mobile web apps have cross platform affinity.
  • Native apps are written in platforms like SDKs while Mobile web apps are written with web technologies like html, css, asp.net, java, php.
  • For a native app, installation is required but for mobile web apps, no installation is required.
  • Native app can be updated from play store or app store while mobile web apps are centralized updates.
  • Many native app don’t require Internet connection but for mobile web apps it’s a must.
  • Native app works faster when compared to mobile web apps.
  • Native apps are installed from app stores like Google play store or app store where mobile web are websites and are only accessible through Internet.
The rest of the article is going to be about Mobile Application Testing.

Significance of Mobile Application Testing

Testing applications on mobile devices is more challenging than testing web apps on desktop due to
  • Different range of mobile devices with different screen sizes and hardware configurations like hard keypad, virtual keypad (touch screen) and trackball etc.
  • Wide varieties of mobile devices like HTC, Samsung, Apple and Nokia.
  • Different mobile operating systems like Android, Symbian, Windows, Blackberry and IOS.
  • Different versions of operation system like iOS 5.x, iOS 6.x, BB5.x, BB6.x etc.
  • Different mobile network operators like GSM and CDMA.
  •  Frequent updates – (like android- 4.2, 4.3, 4.4, iOS-5.x, 6.x) – with each update a new testing cycle is recommended to make sure no application functionality is impacted.
As with any application, Mobile application testing is also very important, as clientele is usually in millions for a certain product – and a product with bugs is never appreciated. It often results in monetary losses, legal issue and irreparable brand image damage.

Basic Difference Between Mobile and Desktop Application Testing:

Few obvious aspects that sets mobile app testing apart from the desktop testing
  • On desktop, the application is tested on a central processing unit. On a mobile device, the application is tested on handsets like Samsung, Nokia, Apple and HTC.
  • Mobile device screen size is smaller than desktop.
  • Mobile devices have less memory than desktop.
  • Mobiles use network connections like 2G, 3G, 4G or WIFI where desktop use broadband or dial up connections.
  • The automation tool used for desktop application testing might not work on mobile applications.

Types of Mobile App Testing:

To address all the above technical aspects, the following types of testing are performed on Mobile applications.
  • Usability testing- To make sure that the mobile app is easy to use and provides a satisfactory user experience to the customers
  • Compatibility testing- Testing of the application in different mobiles devices, browsers, screen sizes and OS versions according to the requirements.
  • Interface testing- Testing of menu options, buttons, bookmarks, history, settings, and navigation flow of the application.
  • Services testing- Testing the services of the application online and offline.
  • Low level resource testing: Testing of memory usage, auto deletion of temporary files, local database growing issues known as low level resource testing.
  • Performance testing- Testing the performance of the application by changing the connection from 2G, 3G to WIFI, sharing the documents, battery consumption, etc.
  • Operational testing- Testing of backups and recovery plan if battery goes down, or data loss while upgrading the application from store.
  • Installation tests- Validation of the application by installing /uninstalling it on the devices.
  • Security Testing- Testing an application to validate if the information system protects data or not.

Mobile Application Testing Strategy

The Test strategy should make sure that all the quality and performance guidelines are met. A few pointers in this area:
1) Selection of the devices - Analyze the market and choose the devices that are widely used. (This decision mostly relies on the clients. The client or the app builders consider the popularity factor of a certain devices as well as the marketing needs for the application to decide what handsets to use for testing.)
2) Emulators – The use of these is extremely useful in the initial stages of development, as they allow quick and efficient checking of the app. Emulator is a system that runs software from one environment to another environment without changing the software itself. It duplicates the features and work on real system.
Types of Mobile Emulators
  • Device Emulator- provided by device manufacturers
  • Browser Emulator- simulates mobile browser environments.
  • Operating systems Emulator- Apple provides emulators for iPhones, Microsoft for Windows phones and Google Android phones
List of few free and easy to use mobile device emulators
i. iPhone Tester – All you need to do with this is – enter the URL in search box and you can see the real time preview of how it appears on an iPhone.
mobile device emulator 1
ii. Mobile Phone Emulator – Used to test handsets like iPhone, blackberry, HTC, Samsung etc.
mobile device emulator 2
iii. MobiReady – With this, not only can we test the web app, we can also check the code.
mobile device emulator 3
iv. Responsivepx – It checks the responses of the web pages, appearances and functionality of the websites.
mobile device emulator 4
v. Screenfly – It is a customizable tool and used to test websites under different categories.
3) After a satisfactory level of development is complete for the mobile app, you could move to test on the physical devices for a more real life scenarios based testing.
4) Consider cloud computing based testing: Cloud computing is basically running devices on multiple systems or networks via Internet where applications can be tested, updated and managed. For testing purposes, it creates the web based mobile environment on a simulator to access the mobile app.
Pros:
  • Backup and recovery- Cloud computing automatically takes back up of your data from remote location making recovery and restoring of data easy. And also, the storage capacity is unlimited.
  • Clouds can be accessed from different devices and anywhere.
  • Cloud computing is cost efficient, easy to use, maintain and update.
  • Fast and quick deployment.
  • Web based interface.
  • Can run the same script on several devices in parallel.
Cons
  • Less control- Since the application runs on remote or third party environment, user has limited control and access over the functions.
  • Internet connectivity issues- the setup is on Internet. Network issues affect the availability and functioning
  • Security and privacy Issues- Cloud computing is an Internet computing and nothing on Internet is completing secure, so chances of data hacking are more.
  • If the application contains new functionality, test it manually.
  • If the application requires testing once or twice, do it manually.
  • Automate the scripts for regression test cases. If regression tests are repeated, automated testing is perfect for that.
  • Automate the scripts for complex scenarios which are time consuming if executed manually.
Two kinds of automation tools are available to test mobile apps:
Object based mobile testing tools- automation by mapping elements on the device screen into objects. This approach is independent of screen size and mainly used for Android devices.
  • Eg:- ranorex, jamo solution
Image based mobile testing tools- create automation scripts based on screen coordinates of elements.
  • Eg:- Sikuli, Egg Plant, RoutineBot
6) Network configuration is also necessary part of mobile testing. It’s important to validate the application on different networks like 2G, 3G, 4G or WIFI.

Test Cases for Testing a Mobile App

In addition to functionality based test cases, Mobile application testing requires special test cases which should cover following scenarios.
  • Battery usage- It’s important to keep a track of battery consumption while running application on the mobile devices.
  • Speed of the application- the response time on different devices, with different memory parameters, with different network types etc.
  • Data requirements – For installation as well as to verify if the user with limited data plan will able to download it.
  • Memory requirement- again, to download, install and run
  • Functionality of the application- make sure application is not crashing due to network failure or anything else.
Download Some Sample Test Cases for Testing Mobile Applications:

Typical activities and proceedings in Testing Mobile Application

The scope of the testing depends on the amount of requirements to be checked or the extent of changes made to the app. If the changes are few, a round of sanity testing will do. In case of major and/or complex changes, a full regression is recommended.
An example application testing project: ILL (International Learn Lab) is an application designed to help admin, publisher to create websites in collaboration. Using a web browser, instructors choose from a set of features to create a class that meets their requirements.
Mobile Testing process:
Step #1. Identify the types of testing: As ILL application is applicable for browsers, so it’s mandatory to test this application on all supported browsers using different mobile devices. We need to dousability, functional and compatibility testing on different browsers with the combinations of manual and automation test cases.
Step #2. Manual and Automated testing: The methodology followed for this project is Agile with the iteration of two weeks. Every two weeks dev. team releases a new build to testing team and testing team will run their test cases on QA environment. Automation team creates scripts for set of basic functionality and runs the scripts that help determine if the new build is stable enough to test. The Manual testing team will test the new functionality.
JIRA is used for writing of acceptance criteria; maintaining of test cases and logging /re-verification of defects. Once the iteration gets over, iteration planning meeting held where dev. Team, product owner, business analyst, and QA team discuss what went well andwhat needs to improve.
Step #3. Beta Testing: Once the regression testing is completed by the QA team, the build moves into UAT. User Acceptance Testing is done by the client. They re-verify all the bugs to make sure every bug was fixed and the application is working as expected on every approved browser.
Step #4. Performance test: Performance testing team tests the performance of the web app using JMeter scripts and with different the loads on the application.
Step #5. Browser testing: The web app gets tested across multiple browsers- both using different simulation tools as well as physically using real mobile devices.
Step #6. Launch plan: After every 4th week the testing moves into staging, where a final round of end to end testing on these devices is performed to make sure the product is ready for production. And then, it goes Live!

Conclusion

Designing the right test strategy, choosing the right mobile simulators, devices and mobile testing tools can make sure that we have 100% test coverage and help us include security, usability, performance, functionality and compatibility based tests into our test suites.
Well, this has been our effort to fulfill multiple requests from our readers on a mobile application testing guide.