Manual Testing Questions & Answers (Compiled from UPSC, SSC ,PSC ,IBPS previous question papers)

Software Testing involves operation of a system or application under controlled conditions and evaluating the result. It is oriented to 'detection'.

Quality Assurance (QA) involves the entire software development PROCESS- monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

Inadequate requirements from the Client: if the requirements given by the client is not clear, unfinished and not testable, then problems may come.
Unrealistic schedules: Sometimes too much of work is being given to the developer and ask him to complete in a Short duration, then the problems are unavoidable.
Insufficient testing: The problems can arise when the developed software is not tested properly.
Given another work under the existing process: request from the higher management to work on another project or task will bring some problems when the project is being tested as a team.
Miscommunication: in some cases, the developer was not informed about the Clients requirement and expectations, so there can be deviations.

1.  Basic requirements- A clear, detailed, complete, achievable, testable requirement has to be developed. Use some prototypes to help pin down requirements. In nimble environments, continuous and close coordination with customers/end-users is needed.
2. Schedules should be realistic- enough time to plan, design, test, bug fix, re-test, change, and document in the given schedule. Adequate
3. testing- testing should be started early, it should be re-tested after the bug fixed or changed, enough time should be spend for testing and bug-fixing.
4. Proper study on initial requirements- be ready to look after more changes after the development has begun and be ready to explain the changes done to others. Work closely with the customers and end-users to manage expectations. This avoids excessive changes in the later stages.
5. Communication- conduct frequent inspections and walkthroughs in appropriate time period; ensure that the information and the documentation is available on up-to-date if possible electronic. More emphasize on promoting teamwork and cooperation inside the team; use prototypes and proper communication with the end-users to clarify their doubts and expectations.

Test scenario will be framed on basis of the requirement, which need to be checked. For that, we will frame set of test cases, in other terms, we can say all the conditions, which can be determined the testing coverage against business requirement.
Please see the below example, which is exactly matched to my explanation.
As we know all most all the application are having login screen, which contains login name and password. Here is the test scenario for login screen.
Scenario: USER’S LOGIN
Conditions to be checked to test the above scenario:
—————————————————-
1. Test login field and Password fields individually.
2. Try to login with valid login and valid password.
3. Try to login with invalid login and valid password. Etc

Write all the test cases under high level TC, which can be covered the main functionalities like
Creation, edition, deletion, etc….as per prescribed in the screen.
Write all the test cases under low level TC,which can be covered the screen, like input fields are displayed as per the requirements, buttons are enabled or disabled, and test case for low priority functionalities.
Example a screen contains two edit boxes login and password and a put buttons OK and Reset and check box for the label “Remember my password”. Now let us write high level TC
And low level test cases.

HIGH LEVEL TC
1. Verify that User is able to login with valid login and valid password.
2. Verify that User is not able to login with invalid login and valid password.
Etc…
..
3. Verify that Reset button clears the filled screen.
4. Verify that a pop up message is displayed for blank login.
Etc…
Etc.

LOW LEVEL TC
1. Verify that after launching the URL of the application below fields are displays in the screen.
1. Login Name 2.Password.3.OK BUTTON 4.RESET button etc.
5. Check box, provided for the label “remember my pwd” is unchecked.
2. Verify that OK button should be disabled before selecting login and password fields.
3. Verify that OK button should we enabled after selecting login and password.
4. Verify that User is able to check the check box, providedfor the label “remember my password”.
Etc.
In this way, we can categories all the test cases under HIGH LEVEL and LOW LEVEL.

Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them. 
Error Seeding is the process of adding known faults intentionally in a program for the reason of monitoring the rate of detection & removal and also to estimate the number of faults remaining in the program.

There are two documents, which should be prepared at particular phase.
1. Test Results document.
2. Test Report document.
Test Results doc will be prepared at the phase of each type of Testing like FULL FUNCTIONAL TEST PASS,REGRESSION TEST PASS,SANITY TEST PASS etc…Test case execution against
The application. Once you prepared this doc, we will send the doc to our TL and PM.By seeing the Test Results doc, TL will come to know the coverage part of the testcase.Here I am giving you the contents used in the Test Results doc?
1. Build No
2. Version Name
3. Client OS
4. Feature set
5. Main Feature
6. Defined Test cases on each feature.
7. QA engineer Name
8. Test e-cases executed. (Includes pass and fail)
9. Testcases on HOLD (Includes blocking test cases and deferred Test cases)
10. Covereage Report (Which includes the coverage ratings in %, like % of test cases covered, % of test cases failed)
Coming to Test report, generally we will prepare Test report, once we rolled out the product to our client. This document will be prepared by TL and delivered to the client.Mainly, this document describes the what we have done in the project, chievements we have reached, our
Learning’s in throughout the project etc…The other name for Test report is Project Closure Report and we will summarize the all the activities, which have taken place in through out the project. Here I am giving your the contents covered in the Test Report.
1. Test Environment (Should be covered the OS, Application or webservers, Mahchine names, Database, etc…)
2.Test Methods(Types of Tests, we have done in the project like Functional Testing, Platform Testing, regression Testing,etc..
3. Major areas Covered.
4. Bug Tracking Details. (Includes inflow and outflow of the bus in our delivered project)
5. Work schedule (When we start the testing and we finished)
6. Defect Analysis
6.1 Defects logged in different types of tests like Functional Test, regressiion Test as per area wised.
6.2 State of the Defects at end of the Test cycle.
6.3 Root cause analysis for the bugs marked as NOT A BUG.
7. QA observations or learning’s thought the life cycle.

1. Project
2. Subject
3. Description
4. Summary
5. Detected By (Name of the Tester)
6. Assigned To (Name of the Developer who is supposed to the Bug)
7. Test Lead (Name)
8. Detected in Version
9. Closed in Version
10. Date Detected
11. Expected Date of Closure
12. Actual Date of Closure
13. Priority (Medium, Low, High, Urgent)
14. Severity (Ranges from 1 to 5)
15. Status
16. Bug ID
17. Attachment
18. Test Case Failed (Test case that is failed for the Bug)

After preparation of test cases project manager will release software release note in that Document there will be URL path of the website link from that we will receive The build In case of web server projects, you will be provided with an URL or a 92.168. ***. *** (Web address) which will help you access the project using a browser from your system. In case of Client server, the build is placed in the VSS (Configuration tool) which will help you get the .exe downloaded to your computer.

Performance Testing:-testing the present working condition of the product
Regression Testing:-Regression Testing is checking for the newly added functionality causing any errors interims of functionality and the common functionality should be stable
In the latest and the previous versions

Boundary value testing is a technique to find whether the application is accepting the expected range of values and rejecting the values which falls out of range.

Example

A user ID text box has to accept alphabet characters ( a-z ) with length of 4 to 10 characters. BVA is done like this, max value: 10 pass; max-1: 9 pass; max+1=11 fail ;min=4 pass;min+1=5 pass;min-1=3 fail; Like wise we check the corner values and come out with a conclusion whether the application is accepting correct range of values.

Equivalence testing is normally used to check the type of the object.

Example

A user ID text box has to accept alphabet characters (a - z) with length of 4 to 10 characters. In +ve condition we have test the object by giving alphabets. i.e. a-z char only, after that we need to check whether the object accepts the value, it will pass. In -ve condition we have to test by giving other than alphabets (a-z) i.e. A-Z, 0-9, blank etc, it will fail.