Skip to main content

Manual Testing


  • Manual Testing is a type of Software Testing where Testers manually execute test cases without using any automation tools.
  • Manual Testing is the most primitive of all testing types and helps find bugs in the software system.
  • Any new application must be manually tested before its testing can be automated. Manual Testing requires more effort, but is necessary to check automation feasibility.
  • Manual Testing does not require knowledge of any testing tool.
  • Manual Testing is a process of finding out the defects or bugs in a software program. In this method the tester plays an important role of end user and verifies that all the features of the application are working correctly. The tester manually executes test cases without using any automation tools. The tester prepares a test plan document which describes the detailed and systematic approach to testing of software applications. Test cases are planned to cover almost 100% of the software application. As manual testing involves complete test cases it is a time consuming test.
 Goal of Manual Testing
  •  The key concept of manual testing is to ensure that the application is error free and it is working in conformance to the specified functional requirements.
  • Test Suites or cases ,are designed during the testing phase and should have 100% test coverage.
  •  It also makes sure that reported defects are fixed by developers and re-testing has been performed by testers on the fixed defects.
  • Basically, this testing checks the quality of the system and delivers bug-free product to the customer.

Procedure of Manual Testing

Given below are the details of each testing step that is carried out in each software quality and testing life cycle specified by IEEE and ISO standards:

1) SRS Review: Review of the software requirement specifications

2) Objectives are set for Major releases

3) Target Date planned for the Releases

4) Detailed Project Plan is built. This includes the decision on Design Specifications

5) Develop Test Plan based on Design Specifications

6) Test Plan: This includes objectives, the methodology adopted while testing, features to be tested
and not to be tested, risk criteria, testing schedule, multi-platform support and the resource allocation for testing.

7) Test Specifications:This document includes technical details (Software requirements) required prior to testing.

8) Writing of Test Cases
    Smoke (BVT) test cases
    Sanity Test cases
    Regression Test Cases
    Negative Test Cases
    Extended Test Cases

9) Development – Modules are developed one by one

10) Installers Binding: Installers are built around the individual product.

11) Build procedure :A build includes Installers of the available products – multiple platforms.

12) Testing Smoke Test (BVT): Basic application test to take decision on further testing
  •     Testing of new features
  •     Cross-browser and cross-platform testing
  •     Stress testing and memory leakage testing.

13) Test Summary Report Bug report and other reports are created

14) Code freezing No more new features are added at this point.

15) Testing Build and regression testing.

16) Decision to release the product

17) Post-release scenario for further objectives.


Comments

Post a Comment

Popular posts from this blog

Mobile Application Testing Checklist

1. DEVICE SPECIFIC CHECKS 1.1  Can the app be installed on the device? 1.2 Does the app behave as designed/desired if there is an incoming call? 1.3 Does the app behave as designed/desired if there is an incoming SMS? 1.4 Does the app behave as designed/desired if the charger is connected? 1.5 Does the app behave as designed/desired if the charger is disconnected? 1.6 Does the app behave as designed/desired if the device goes to sleeping mode 1.7 Does the app behave as designed/desired if the device resumes from sleeping mode 1.8  Does the app behave as designed/desired if the device resumes from lock screen? 1.9    Does the app behave as designed/desired if the device is tilted? 1.10  Does the app behave as designed/desired if the device is shaken? 1.11 Does the app behave as designed/desired if a local message is coming from another app (think   of: calendar reminders, to-do task etc.). 1.12 Does the app behave as designed/desired if a push message i...
Post a Comment
Read more

Test Scenarios for Excel Export Functionality

1. The file should get exported in the proper file extension. 2. The file name for the exported Excel file should be as per the standards e.g. if the file name is using the timestamp, it should get replaced properly with an actual timestamp at the time of exporting the file. 3. Check for date format if exported Excel file contains the date columns. 4. Check number formatting for numeric or currency values. Formatting should be the same as shown on the page. 5. The exported file should have columns with proper column names. 6. Default page sorting should be carried in the exported file as well. 7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages. 8. Check if the data displayed on a page and exported Excel file is the same. 9. Check export functionality when pagination is enabled. 10. Check if export button is showing proper icon according to the exported file type E.g . Excel file icon for xls files 11. ...
Post a Comment
Read more

Software Testing Tips

Here are some of the Best Testing Practices which I learned by Experience:  1) Learn to analyze your test results thoroughly. Do not ignore any test result. The final test result may be ‘pass’ or ‘fail’, but troubleshooting the root cause of ‘fail’ will give you the solution of the problem. Testers will be respected if they not only log the bugs but also provide solutions. 2) Learn to maximize the test coverage each time you test any application. 100% test coverage might not be possible but still, you can always try to reach near it. 3) In order to ensure maximum test coverage, break your application under test (AUT), into smaller functional modules. Write test cases on such individual unit modules. Also if possible break these modules into smaller parts. E.g : Lets assume that you have divided your website application in modules and ‘accepting user information’ is one of the modules. You can break this ‘User information’ screen into smaller parts for writing ...
Post a Comment
Read more