Blog

Manual Testing on Real Devices – Top Generic Use Cases

by admin | Sep 27, 2019 | Manual Testing, Fixed, Blog | 0 comments

In the realms of software and mobile app testing, a use case describes a pertinent ‘use’ of the system by the end user or a tester emulating a real world scenario. This is used extensively at a system or acceptance level while developing tests. Use cases essay a critical role in the several different stages of SDLC, and are based on user actions and the response of the system to such actions. The experts at Codoid, adept at mobile app testing services (and more), are meticulous when preparing the documentation (use cases), of the actions performed by the end user or their testers emulating a real world scenario. The documents specify the actions taken by a user, and hence must be user oriented.

All those involved in use cases contribute to the wealth of the content encased in this set of documents. The testing of use cases is a software testing technique identifying those test cases that provide coverage for the entire system. In the realm of real device testing, app development companies are now turning towards testing on cloud-based real devices since there are obvious challenges in acquiring, maintaining, and sustaining actual physical devices.

As a leading Software Testing Company we understand that automated testing in a number of ways is the best method of improving the efficacy of testing. However, we also understand that this form of testing is not practicable for some scenarios – the cost and time required for automated testing of a miniscule step would not be a sensible act. In such scenarios, manual testing comes to the fore and essays a noteworthy and effective role. If the scope of a project is small, with simple features manual testing on real devices is much more efficient, quicker, and cost effective method. There are top generic use cases where manual testing is better place to accurately simulate the user’s experience of the app/system.

With our years of experience in both manual and automated testing, we proffer some of the top generic use cases that would justify manual testing.

Heightened Ability to Attest Device Compatibility and PermissionsTesting manually will quickly bring to the fore the causes of any incompatibility of a device. Any compatibility issues can only be found by installing an app on a device, and this would enable testers to speedily remove the issues before they become a sore point with the end-users. Additionally, compatibility testing is not a frequently undertaken or repetitive task, and hence it would be feasible to conduct manual testing. Our QA testers also use manual testing to check device permissions, when the usage of these permissions would be low. Manual testing on a real device becomes the most effective method when the app would need users to run and maintain several levels of permissions.

Speedy Replication of Reported Bugs by a UserIt would be easier for developers to retrace the exact steps taken by a user that led to an issue. It would also help the developer to understand the exact place and reasons for the issue. Since the developer would need to set up a testing framework, input requirements, create scenarios, and run tests, manual testing would prove a lot more effective.

Standby Mode App ResponsesAs a standard for all mobile devices, the app must respond as expected in the standby mode – that is not run any tasks in the background. Our mobile app testing experts use manual testing for the standby mode to ensure that there is no unexpected activity in the app and that the app functions as intended.

Speedier Assessment of User Interface and ExperienceAs a leading QA company we understand that manual testing on real devices is the most efficient approach to undertaking UI testing. Through manual testing, we are also able to quickly ascertain whether the UX functionality of an app is working as intended. Manual testing is more effective since it enables the simulation of real user interactions with the app, and early identification of bugs (before the user encounters them)

Validate Connectivity of AppManual testing on real devices is the best method to ascertain the functioning of an app in the event of poor/low connectivity. This method will help developers and testers to understand the ‘behavior’ under varying network situations – for instance, if the user loses Wi-fi connectivity and the phone being used by the user moves to the data connection, the app should function the same way.

Ascertaining Navigation Issues with the AppThe best way to view the app from the user’s perspective is to manually test the accessibility and navigation of the app. Each user has her or his peculiar user issues, and it would not be possible to understand and rectify these without manual testing. Real people interacting in real-time with the app would be the best method to ascertain navigation issues.

Ascertain App Performance in the Presence of other Running AppsAny app would need to run and work seamlessly parallel with other apps. Through manual testing, it is possible to uncover any problems with the app when there are other apps running simultaneously.

In Conclusion:

As a leading software testing company, Codoid understands the value of manual testing on real devices and views it as an indispensable method to assess the quality of mobile apps and speedy User Interfaces. Connect with us to leverage our experience with manual testing of physical and cloud devices, and ensure the best UI and UX for your app users.

Black Box Testing Techniques an Overview

by admin | Sep 25, 2019 | Manual Testing, Fixed, Blog | 0 comments

Black box testing implies an infinitesimally large source of software testing techniques which would help achieve excellent test coverage and saves time. Read the blog thoroughly to have a better understanding of what black box testing is all about and the underlying techniques one must use to impact your subsequent cycle of test.

Black Box Testing can be defined as a type of Software testing that the internal working structure (the source code) is unknown. The testers tend to validate all the functional aspects of the requirements without reviewing the source code. Presume that the code as being hidden inside a black box. For all sets of inputs, the tester compares the corresponding expected outputs with the actual outputs. Here, testers won’t review the internal code structure and don’t necessarily have to have knowledge of its structure or internal paths. Instead, they rely on the in depth knowledge of the software requirements to draw up test cases.

Black Box versus White Box Testing If you consider Black box testing as a type of software testing that denotes “unknown” internal software, then think of white box testing as “known” and transparent.White box testing mandates the tester to have expert level knowledge of the programming language and the corresponding system structure being used. Unlike black box testing, whose dependency is majorly on the end users’ perspective, white box testing on the contrary includes techniques that an end user need not have to simulate because software testers role is limited in only reviewing the code in finding issues pertaining to security, information flow and speed of execution.

Black Box Testing Techniques The following black box testing techniques aims to cover strategically the product while reducing the total count of test cases:

Equivalence partitioningThis black box testing intents to reduce loads of rework. Here test conditions are grouped together in each group, as a result of that only one test condition requires testing. If that condition is found to be true or if it works fine, then all of that group’s conditions must work too. Take for instance, with an uploader, this technique is used efficiently to test file types and sizes without having to overlap each and every test conditions and combination.

Boundary value analysis is a concept where you test the boundaries of what range of values are permitted. For instance, if you need the system to accept a number between 1 and 100, you may have to test those boundaries, as well as just over and just under ie (0 and 101) by effectively employing this method you save lot of time by not testing the numbers in between.

Decision table testing This method is employed for complex combinations, where varied inputs lead to different decisions (unlike the earlier two types equivalence partitioning and boundary value analysis). Popularly known as cause and effect tables, decision tables will help us clarify expected outputs and make sure that no combinations are missed while formulating test cases

State transition testing A system which gives different outputs for the same combination of inputs depending on external conditions requires state transition testing. For example: an ATM machine which dispenses the tester 80 USD initially and then later doesn’t give the tester 80 USD (Reason: account has dipped down below the set amount); or a traffic light which turns to green when the sensor is triggered, but later gives a different result (because someone else was there first and is allowed to turn left before you go straight). These examples clearly illustrate the fact that for the same set of inputs there is different outputs, because the system has “transitioned” to a new state.

Exploratory testing In this type of Software testing, the tester simulates user behaviour and subsequently ensuring system to maximize test coverage. This is almost on par with a black box technique because here no knowledge of the internal code is required. Instead, testers are aware of the software requirements and its expected behaviour. From there, they can behave like users—but always retain their testers mindset.

Error guessing The term error guessing is self-explanatory. A tester “guesses” wildly where errors are most likely to occur. The testers’ own experience, knowledge of the software application, results from earlier test cycles, customer issue tickets, previous release issue, and risk reports are taken in to due consideration. When we try to choose which module of the application will receive the most thorough testing, error guessing is a must.

Conclusion:

We at Codoid follow a holistic approach towards the entire gamut of Software testing services ranging from Unit, Integration, System, Acceptance to Regression, Smoke, Sanity, White box , Black box testing etc. Connect with us to work with the experts in the testing arena.