Test Credit Card Numbers

Number

Card Type

3400 0000 0000 009

American Express

6011 0000 0000 0004

Discover

5500 0000 0000 0004

MasterCard

4111 1111 1111 1111

Visa

3000 0000 0000 04

Diner’s Club / Carte Blanche

2014 0000 0000 009

en Route

3088 0000 0000 0009

JCB

Why Developers should not perform Testing?

Of course, they can test, but they can’t be good testers. If the developers test their own work or the work of their peers,then the following problems crop up:

1. Misunderstandings of the requirements/specifications will go unnoticed.

2. Given the time, developers tend to allocate more time improving the code or documentation rather than testing the code.

3. They tend to be optimistic of producing defect free work and thus ‘under’ test the product.

4. Testing needs skill, occasional tester with no prior training in testing techniques is no match to a trained bug hunter whose sole activity is testing.

5. To catch a higher percentage of bugs, tester needs to be aggressive.Nobody will be aggressive, if they are testing their own product.Testers are rewarded if they hunt lots of bugs, developers are rewarded if the product they developed has less number of bugs and this balance can only be maintained if the separate teams exist for testing and development.

Mobile Application Testing CheckList

Functional Verify that all functional requirements have been tested as per the functional test cases of the mobile app All functionality should be tested as per the test cases
UI/Design Verify that design of the mobile app is as per the mockup Design of the the mobile app should be as per the design mockup
Performance & Stress Verify perfomance of the mobile app Performance of the mobile app should be acceptable as per the defined criteria

Verify mobile app behaves gracefully under heavy load Mobile app should behave gracefully under heavy load
Navigation Verify navigation of the application
Content Testing Verify content of mobile app Content of mobile app should be proper

Verify spelling mistakes There should not be any spelling mistakes
Messages Verify messages are context specific and proper Messages should be context specific and proper

Verify for missing messages There should not be any message missing if it is required
System Crash/Force Close Application must preserve sufficient state information to cope with forcible close by the system The Application must not lose any information that it implies would be preserved, nor become difficult to use subsequently, as a result of a forcible closure by the system
Installation Verify that application can be Installed Successfully Application should be able to install successfully

Verify that version number must match that specified during submission The version number must match that specified during submission

Verify that the application has successfully installed on the device by navigating to the area on the phone where new applications are installed Application must be seen in the installed applications list
Uninstallation Verify that application can be uninstalled successfully. User should be able to uninstall the application successfully.
Network Verify the behavior of application when there is Network problem and user is performing operations for data call User should get proper error message like “Network error. Please try after some time”

Verify that user is able to establish data call when Network is back in action User should be able to establish data call when Network is back in action
Voice Call Handling Verify that user can accept Voice call at the time when application is running and can resume back in application from the same point User should be able to accept Voice call at the time when application is running and can resume back in application from the same point.

Verify that user can reject the Voice call at the time when application is running and can resume back in application from the same point User should be able to reject the Voice call at the time when application is running and can resume back in application from the same point

Verify that user can establish a Voice call in case when application data call is running in background. User should be able to establish a Voice call in case when application data call is running in background.
SMS Handling Verify that user can get SMS alert when application is running User should be able to get SMS alert when application is running

Verify that user can resume back from the same point after reading the SMS User should be able to resume back from the same point after reading the SMS
Unmapped keys Verify that unmapped keys are not working on any screen of application Unmapped keys should not work on any screen of application
Application Logo Verify that application logo with Application Name is present in application manager and user can select it. Application logo with Application name should be present in application manager and user can select it.
Splash Verify that when user selects application logo in application manager splash is displayed. When user selects application logo in application manager splash should be displayed.

Note that Splash do not remain for fore than 3 seconds. Splash should not remain for fore than 3 seconds.
Low Memory Verify that application displays proper error message when device memory is low and exits gracefully from the situation. Application should display proper error message when device memory is low and exits gracefully from the situation.
Clear Key Verify that clear key should navigate the user to previous screen. Clear key should navigate the user to previous screen.
End Key Verify that End Key should navigate the user to native OEM screen End Key should navigate the user to native OEM screen.
Visual Feedback Verify that there is visual feedback when response to any action takes more than 3 seconds There should be visual feedback given when response time for any action is more than 3 second.
Continual Keypad Entry Verify that continual key pad entry do not cause any problem. Continual key pad entry should not cause any problem in application.
Exit Application Verify that user is able to exit from application with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point. User should be able to exit with every form of exit modes like Flap,Slider,End Key or Exit option in application and from any point.
Charger Effect Verify that when application is running then inserting and removing charger do not cause any problem and proper message is displayed when charger is inserted in device. When application is running then inserting and removing charger should not cause any problem and proper message should be displayed when charger is inserted in device.
Low Battery Verify that when application is running and battery is low then proper message is displayed to the user. When application is running and battery is low then proper message is displayed to the user telling user that battery is low.
Removal of Battery Verify that removal of battery at the time of application data call is going on do not cause interruption and data call is completed after battery is inserted back in the device. Removal of battery at the time of application data call is going on should not cause interruption and data call should be completed after battery is inserted back in the device.
Battery Consumption Verify that application does not consume battery excessively. The application should not consume battery excessively.
Application Start/ Restart 1. Find the application icon and select it 2. “Press a button” on the device to launch the app. 3.Observe the application launch In the timeline defined Application must not take more than 25s to start.

Verfiy that application appears in task manager after starting the application Application should appear in task manager

Verfiy that application does not appear in task manager after closing the application Application should not appear in task manager

Verify application appears after restarting the application Application should appear in task manager

Verify that the Application notifies the user about a long launch time If the Application takes longer than 5 seconds to launch, a progress bar or a message must be displayed to tell the user what is happening.
Application Side Effects Make sure that your application is not causing other applications of device to hamper. Installed application should not cause other applications of device to hamper.
OTA install Verify that the Application must install via OTA.
File System – Memory during run Verify that the Application correctly handles out of memory exceptions during Application execution The Application should handle any out of memory exceptions correctly.Ensure that there is a warning to the user advising about lack of memory when file is trying to be stored
HTTP – Invalid Network Connection Verify that the Application can handle the network connection being invalid / unusable
Network connectivity – Airplane mode Verify that when the Application uses network capabilities, it must be able to handle the device being in Airplane mode The Application will give a meaningful error message to indicate that the device is in Airplane mode and the application cannot run successfully.
Timed Event – Expiry during Application run Verify that the Application behaves correctly on expiry of a timed event while the Application is running Ensure that Application reacts correctly once the designated time has expired.
Timed Event – Expiry during Application suspend Verify that the Application resumes correctly from a suspended state on expiry of a timed event Ensure that the application resumes correctly once the designated time has expired, and then ensure that the Application behaves correctly after being resumed.
Timed Event – Expiry during Application exit Verify that the Application starts correctly from an exited state on expiry of a timed event. Application starts, or user is presented with a start option once the designated time has expired.
Application behaves correctly when started.
Memory Card – Insertion Verify that the Application works correctly following a memory card insertion action when the Application is suspended and resumed. The Application continues to operate as designed based on the Application specification and is not affected by the memory card insertion or mounting/unmounting.
Memory Card – screen behaviour Verify that the Application with memory card functional screens works correctly with memory card inserted and removed. The Application should work correctly following memory card insertion.
The Application should work correctly following memory card removal
Readability Verify that the application content is readable. The application content should be readable
UI – Read time Verify Comfortable time for content reading Each screen must be visible for the time necessary to comfortably read all its information.
UI – Consistency UI consistency The Application UI should be consistent and understandable throughout, e.g. common series of actions, action sequences, terms, layouts, soft button definitions and sounds that are clear and understandable
UI – Differing screen sizes Where the application is designed to work on multiple devices it must be able to display correctly on differing screen sizes The Application should display correctly without obvious errors
UI – Multiple Format Input Handling Where the device and application can accept input in multiple formats (e.g. external touchscreen / external keypad / internal touchscreen / internal keypad / QWERTY layout / 12-key layout and others), the application must work correctly with all supported input methods The Application should accept input correctly in all supported formats
Language – Correct operation Verfiy that application appears in task manager after starting the application All text content is rendered in the correct/expected language.
Ensure Application detects correct language and renders content as appropriate (if applicable).
Language – Supported formats Ensure that the Application supports all date/time/numeric/currency features for supported languages All text content relating to date/time/numeric/currency fields are rendered in the correct/expected language format.
Lifecycle – Resource Sharing – Database Check that database resources are properly shared between Application and a competing Application. Application should continue from the previous state prior to being suspended.
Application should see the new entry and the deleted entry.
Key Press – Scrolling in menus Scrolling in menus Scrolling should work with keypad or navigation device
Key Press – Selection key Selection key selects menu items This MUST select the menu item with no adverse effects on the Application
Key Press – Text field scrolling Scrolling in text fields and About / Help screens This should scroll vertically and (if applicable) horizontally in the dialog
Key Press – Pause The Application must support a pause feature in areas of the Application where immediate user interaction is needed 1. The user can pause the Application and the pause feature must support an option to resume .
2. All time-specific features of the Application are disabled at the time of the pause.
3. There is a clear indication that the Application is in a paused state.
4. There is a clear indication how the user can return from the paused state.
Action – Device Close Ensure that the Application while launching handles closing of the device correctly
The Application returns to the same state before the interruption
Action – Device Open Ensure that the Application handles device opening correctly The Application returns to the same state before the interruption
Orientation Verify that application works as expected in supported orientation Verify that application works as expected in supported orientation

Exploratory Testing

Exploratory Testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. Cem Kaner, who coined the term in 1983.  now defines exploratory testing as “a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.

While the software is being tested, the tester learns things that together with experience and creativity generates new good tests to run. Exploratory testing is often thought of as a black box testing technique. Instead, those who have studied it consider it a test approach that can be applied to any test technique, at any stage in the development process. The key is not the test technique nor the item being tested or reviewed; the key is the cognitive engagement of the tester, and the tester’s responsibility for managing his or her time. Exploratory testing has always been performed by skilled testers.

According to me Exploratory Testing is done to explore the application and is done to get the knowledge of the application. In this user tries to understand the application as well as  functionalities of application.

Exploratory testing is testing where testers are not much aware of requirements and application. So he explore the application by using it in different concern.

Types of Mobile Apps Testing

  •  User Interface Testing :-  (Color scheme, Menu styles, Consistency of UI over various Devices)
  •  Functional Testing:-  (Testing core functionality of Mobile App as per specification)
  •  Performance & Stress Testing:-  [Behavior of Mobile Application in Low resources (Memory/Space), Behavior of mobile website when many mobile user simultaneously access
    mobile website)]
  • Usability Testing:-  (Testing of usability aspects of Mobile Apps)
  • Interruption Testing:-   (Voice Calls, SMS, Charger, Low memory Notification) while application is running.
  • Low Network / No Network Case Testing:- Application behavior when there is no network coverage or Low network strength.
  • Monkey Testing:-  Continual key pad entries via tools to test application stability with various key press events.
  • Testing for Compatibility:- Testing the compatibility of your application with native device features (i.e. To make sure your application is not hampering native device functionality)
  • Certification Compliance Testing:-For downloadable mobile applications, there are various Third party Mobile Quality Certification program for various platforms. True Brew Testing(for BREW Apps), Java Verified program (for J2ME apps), Symbian Signed Test Criteria (for Symbian Apps) are some examples. Apart from regular functional testing, you may need to test your application against the test cases/Testing criteria provided by these certification processes. However, it depends on your client, whether they want to certify their application or not.
  • Submission Guidelines Compliance Testing: – The application needs to adhere to the specified submission guidelines  to publish it in any mobile application store. Failure to meet these guidelines may result in rejection of your app on mobile application stores. For example failure to comply with application Submission guidelines for Apple App Store may result in rejection of your app in Apple app store.

W3C Testing Tools

The MarkUp Validator – Also known as the HTML validator, it helps check Web documents in formats like HTML and XHTML, SVG or MathML.

 The Link Checker – Checks anchors (hyperlinks) in a HTML/XHTML document. Useful to find broken links, etc.

 The CSS Validator – validates CSS stylesheets or documents using CSS stylesheets.

New Look of Gmail Preview

A preview of Gmail’s new look

See the Below Screen short

 

STEP For New Look :-
———————-
Goto Mail Setting –> Select Themes –> Select Preview –> Get New Preview

Test Cases for White Board

1. Verify the Length & Width of the Board
2. Verify the Surface of the Board
3. Check whether you can able to write on the board
4. Check written words are visible
5. Try to erase the words written & write a new words

Soft skills for a Successful QA Engineer

Soft skills or how you interact with your fellow team members or managers is a very important aspect to be a successful tester and also a future manager. While it is important to be technically sound, you should also be able to take people working around you along with you to work as one team.

As most of us experience, personality clashes or ego clashes are quite common in a workplace. If you are just started in a job, you’ll see what I mean. You are probably better of reading this now than most of us understood the hard way.

I have listed a few DOs and DON’Ts here. This may not vary to a great extent from organization to organization.

* Be informed to convince – Typically testers are looked upon as someone who’s out there to draw the blood of the developer and are looked with skepticism. Don’t worry about it. Just be aware that you are there to do a job and do not take any passing comments to heart. Never get emotional and fight with a developer. Your arguments should be logical and backed by information. Typical fights would be whether a bug is a bug or not.

* When you are at fault, admit your mistake and do not argue to prove you are right when you know you are not. Admitting your mistake will enhance your reputation. But make sure you back it up with an action suggestion as to what you would do in order that mistake is not repeated.

* Maintain good personal rapport with developers especially with members who are more or less of the same age group. They would feel free to discuss problems with you more openly than their managers. This holds good for test managers too. Engage with grass root developers and do not give an impression that you are approachable only by their manager.

* Maintain good documentation as testers are questioned about their contribution more than the developers. Have your test plans, test execution history and results well organized and handy. Use a good tool if necessary.

* Estimate your work completion cautiously. Leave enough room for late delivery of code by development. In your test plan make this point very clear about what can be tested and what cannot be tested depending on the punctuality of the code delivery by engineering

Difference Between QA & QC

QA is preventive process.
QC is corrective process.

Quality Assurance is Process oriented.
Quality Control is Product oriented.

Quality Assurance makes sure you are doing the right things, the right way.
Quality Control makes sure the results of what you’ve got are what you expected.

QA focuses on building in quality….and hence preventing defects.
QC focuses on testing for quality…and hence detecting defects.

Quality Assurance is a focus on processes like defining,deploying,continuous improving with the goal of defect prevention.
Quality Control is a focus on products defect/bug detection with the goal of defect detection.

%d bloggers like this: