Risk based device testing…. A new paradigm in the making
I have lost a count of the number of Android devices in the market today. iOSs are still a handful but it does not make my life any easier. With a zillion form factors and other attributes in this crowded street, you can get lost – just like me. Anyways…so you have just gone mobile and are looking to do the right kind of testing on the right kind of devices. You want to be able pick and choose those based on your business needs easily. Enter risk based device testing.
What is risk-based testing?
First, to give you a background, this tool is coming to you from a company which has established strong credibility in the mobile testing marketplace with structured approaches and guidelines. So from the guys who live and breathe testing daily, you are in good hands to listen to this. Risk based testing entails signing off on a project without performing complete testing on it. In your application, some features are used more than the others, and this information is used in the risk based testing schedule to determine what can be tested with the limited amount of resources.
Defining risk-based device testing?
Applying the same principles, it is a mechanism that allows users to define a testing schedule by choosing a set of devices from a large pool. The wizard allows users to make this selection from the device inventory. This methodology helps to establish a rapid response attitude – to work closely with the users to understand user needs and the technical risk to be addressed in testing. It means having a flexible testing process with different test cases that covers the most likely problems.
The need for risk based testing
Mobile applications is a fast moving market with millions of apps downloaded every second. There is pressure to deliver quickly. Project teams are continuously stampeding the testers. So there is a need to establish a requirement plan that delivers results quickly yet accurately. So testers need to be expert risk takers and understand the failure modes and translate it to the project teams.
Doing less testing means, it will help testers design effective test cases and clearly understand the risk of the release. It helps them to identify various dimensions of the software project risk and build a model that relates the risk dimensions to project performance. Also then there are budget constraints with a limited number of software resources. So there needs to be emphasis on the largest risk areas.
