Sample of Mobile Test Cases

Untitled Document

TEST 1 — Installation
TEST STEPS
Before starting the test round, use a file manager to note the free user space available on the phone. You will need this information in test 8.
1	Install the application being tested.The application must install without error.
2	During installation note the version number presented to the user.The version number must match that specified during submission.
3	Verify that the application has successfully installed on the device by navigating to the area on the phone where new applications are installed.The application should present one or more icon(s) on the phone.
Notes
For any submissions which do not appear obviously once installed, the submitter must include details in the submission statement of how successful installation can be verified.If the content does not appear obviously on the device once installed, and specific instructions are lacking in the submission statement, then this test will be failed.

TEST 2 – Application start/stop behaviour
TEST STEPS
1	Start the application by selecting the icon or following the steps outlined in the submission statementNavigate to the Task Manager and check that the application appears there.
2	Close the application from the Task Manager.Exit the Task Manager, and re-launch the Task Manager. The application must no longer appear in the Task Manager.
3	Start the application as in Step 1.Go to the Task Manager to verify that the application is running. The application must appear in the task manager.
4	Close the application from within the application UI and then return to the Task Manager.The application must no longer be running and must no longer appear in the task manager.
5	Restart the application as in Step 1.Navigate to the Task Manager. The application must once again appear in the Task Manager.
Notes
An application which must run in the background does not need to appear in the Task Manager or present a UI so long as the developer justifies this behaviour during submission.All applications must have some way of verifying that they are running on the device, though, and the developer should provide this information.

Advertisement

 

Software Development Life Cycle

Software Development Life Cycle

Software development approach and has a value proposition that includes faster turnaround times, trained pool of engineers with decent exposure to processes and best practices followed for the entire SDLC.

We have exposure on the following SDLC models :

• Waterfall
• V-Shaped
• Structured Evolutionary Prototyping Model
• Incremental
• Spiral
• Agile

A brief description of the various models mentioned above is given below. Along with the description, we have mentioned the strengths and discussed when a particular model is suited to you:

 

Identifying sqa issues

Software Quality Assurance is a good practice that every large scale business should employ. IT related businesses have never hesitated to use SQA to ensure that the application they will release for their users or sell to their customers will live up to their expectations.

Sponsored Links

On the other hand, there are companies that has opted to forgo with the usage of SQA and relied on application testers just to make sure the application will never have internal errors. The SDLC on the other hand, will ensure the development of the application will work as planned.

Like other development plans, there are issues why developers and companies do not use SQA.

 

IEEE SOFTWARE TEST DOCUMENTATION Std 829-1998 – TEST PLAN

Purpose
To describe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

 

Software Testing Levels, Types, Terms and Definitions

Testing Levels and Types
There are basically three levels of testing i.e. Unit Testing, Integration Testing and System Testing. Various types of testing come under these levels.

Unit Testing:
To verify a single program or a section of a single program

Integration Testing:
To verify interaction between system components
Prerequisite: unit testing completed on all components that compose a system

System Testing:
To verify and validate behaviors of the entire system against the original system objectives
Software testing is a process that identifies the correctness, completeness, and quality of
software.

 

Most common software errors

Following are the most common software errors that aid you in software testing. This helps you
to identify errors systematically and increases the efficiency and productivity of software testing.
Types of errors with examples
• User Interface Errors: Missing/Wrong Functions, Doesn’t do what the user expects, Missing
information, Misleading, Confusing information, Wrong content in Help text, Inappropriate error
messages. Performance issues – Poor responsiveness, Can’t redirect output, Inappropriate use of
key board
• Error Handling: Inadequate – protection against corrupted data, tests of user input, version
control; Ignores – overflow, data comparison, Error recovery – aborting errors, recovery from
hardware problems.
• Boundary related errors: Boundaries in loop, space, time, memory, mishandling of cases
outside boundary.
• Calculation errors: Bad Logic, Bad Arithmetic, Outdated constants, Calculation errors,
Incorrect conversion from one data representation to another, Wrong formula, Incorrect
approximation.

 

Verification and Validation

 Verification and Validation.

• Testing is part of verification and validation.
• Verification: Are we building the product right?
• Validation Are we building the right product?
• V&V activities include a wide range of the SQA activities.

 

Some Important terminologies

Some Important terminologies

• Project :  If something is developed based on a particular user/users requirements, and is used exclusively by them, then it is known as project. The finance is arranged by the client to complete the project successfully.
• Product :  If something is developed based on company’s specification (after a general survey of the market requirements) and can be used by multiple set of masses, then it is known as a product. The company has to fund the entire development and usually expect to break even after a successful market launch.
• Defect v/s Defective: If the product is justifying partial requirements of a particular customer but is usable functionally, then we say that The product has a defect, But If the product is functionally non usable , then even if some requirements are satisfied, the product still will be tagged as Defective.
• Quality Assurance : Quality assurance is a process of monitoring and guiding each and every role in the organization in order to make them perform their tasks according to the company’s process guidelines.
  

 

Definitions of Black-box and White-box Testing

Black-box: This testing methodology looks at what are the

available inputs for an application and what the expected outputs are that should result from each input. It is not
concerned with the inner workings of the application, the process that the application undertakes to achieve a
particular output or any other internal aspect of the application that may be involved in the transformation of an
input into an output. Most black-box testing tools employ either coordinate based interaction with the applications graphical user interface (GUI) or image recognition. An example of a black-box system would be a search engine.You enter text that you want to search for in the search bar, press “Search” and results are returned to you. In such a case, you do not know or see the specific process that is being employed to obtain your search results, you simply see that you provide an input – a search term – and you receive an output – your search results.

 

Evaluating exit criteria and reporting

Evaluating exit criteria is the activity where test execution is assessed against the defined objectives. This should be done for each test level, as for each we need to know whether we have done enough testing. Based on our risk assessment, we’ll have set criteria against which we’ll measure ‘enough’. These criteria vary for each project and are known as exit criteria. They tell us whether we can declare a given testing activity or level complete. We may have a mix of coverage or completion criteria (which tell us about test cases that must be included, e.g. ‘the driving test must include an emergency stop’ or ‘the software test must include a response measurement’), acceptance criteria (which tell us how we know whether the software has passed or failed overall, e.g. ‘only pass the driver if they have completed the emergency stop correctly’ or ‘only pass the software for release if it meets the priority 1 requirements list’) and process exit criteria (which tell us whether we have completed all the tasks we need to do, e.g. ‘the examiner/tester has not finished until they have written and filed the end of test report’). Exit criteria should be set and evaluated for each test level. Evaluating exit criteria has the following major tasks: