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

Alpha Testing:

Alpha Testing is mostly like performing usability testing which is done by the in-house developers who developed the software or testers. Sometimes this Alpha Testing is done by the client or an outsider with the presence of developer and tester. The version release after alpha testing is called Alpha Release.

Beta Testing:

Beta Testing is done by limited number of end users before delivery, the change request would be fixed if the user gives feedback or reports defect. The version release after beta testing is called beta Release.

Gamma Testing:

Gamma Testing is done when the software is ready for release with specified requirements, this testing is done directly by skipping all the in-house testing activities.

Unit testing

Unit Testing is done to check whether the individual modules of the source code are working properly. i.e. testing each and every unit of the application separately by the developer in developer's environment.

Interface Testing

Interface Testing is done to check whether the individual modules are communicating properly one among other as per the specifications.
Interface testing is mostly used in testing the user interface of GUI application.

Integration testing

Integration Testing is done to check the connectivity by combining all the individual modules together and test the functionality.

The types of Integration Testing are

1. Big Bang Integration Testing

In Big Bang Integration Testing, the individual modules are not integrated until all the modules are ready. Then they will run to check whether it is performing well.

In this type of testing, some disadvantages might occur like,

Defects can be found at the later stage.It would be difficult to find out whether the defect arouse in Interface or in module.

    2.  Top Down Integration Testing

In Top Down Integration Testing, the high level modules are integrated and tested first. i.e Testing from main module to sub module. In this type of testing, Stubs are used as temporary module if a module is not ready for integration testing.

   3.  Bottom Up Integration Testing

In Bottom Up Integration Testing, the low level modules are integrated and tested first i.e Testing from sub module to main module. Same like Stubs, here drivers are used as a temporary module for integration testing.

The Business Analyst will pre pare the FRS.
Based on this we are going to prepare test cases.
It contains
1. Over view of the project
2. Page elements of the Application (Filed Names)
3. Prototype of the of the application
4. Business rules and Error States
5. Data Flow diagrams
6. Use cases contains Actor and Actions and System Responses

Web Application testing is done on a website to check its load, performance, Security, Functionality, Interface, compatibility and other usability related issues. In Web application testing, three phases of testing is done, they are,

Web Tier Testing

In Web tier testing, the browser compatibility of the application will be tested for IE, Fire Fox and other web browsers.

Middle Tier Testing

In Middle tier testing, the functionality and security issues were tested.

Database Tier Testing

In Database tier testing, the database integrity and the contents of the database were tested and verified.

Complex test cases 4-7 per day
Medium test cases 10-15 per day
Normal test cases 20-30 per day

Test plan is a high level document which explains the test strategy, time lines and available resources in detail. Typically a test plan contains:
-Objective
-Test strategy
-Resources
-Entry criteria
-Exit criteria
-Use cases/Test cases
-Tasks
-Features to be tested and not tested
-Risks/Assumptions.

The following are the types of functional testing:

• Compatibility
• Configuration
• Error handling
• Functionality
• Input domain
• Installation
• Inter-systems
• Recovery

In Two Tier Architecture or Client/Server Architecture two layers like Client and Server is involved. The Client sends request to Server and the Server responds to the request by fetching the data from it. The problem with the Two Tier Architecture is the server cannot respond to multiple requests at the same time which causes data integrity issues.
The Client/Server Testing involves testing the Two Tier Architecture of user interface in the front end and database as backend with dependencies on Client, Hardware and Servers.

In Three Tier Architecture or Multi Tier Architecture three layers like Client, Server and Database are involved. In this the Client sends a request to Server, where the Server sends the request to Database for data, based on that request the Database sends back the data to Server and from Server the data is forwarded to Client.

The Web Application Testing involves testing the Three Tier Architecture including the User interface, Functionality, Performance, Compatibility, Security and Database testing.

In Software Testing, Risk Analysis is the process of identifying risks in applications and prioritizing them to test.

In Software testing some unavoidable risk might takes place like

• Change in requirements or Incomplete requirements
• Time allocation for testing.
• Developers delaying to deliver the build for testing.
• Urgency from client for delivery.
• Defect Leakage due to application size or complexity.

To overcome these risks, the following activities can be done

• Conducting Risk Assessment review meeting with the development team.
• Profile for Risk coverage is created by mentioning the importance of each area.
• Using maximum resources to work on High Risk areas like allocating more testers for High risk areas and minimum resources for Medium and Low risk areas. Creation of Risk assessment 

To report the defect using excel sheet
Mention: The Future that been effected.
Mention: Test Case ID (Which fail you can even mention any other which are dependency on this bug)
Mention : Actual Behavior
Mention : Expected Behavior as mentioned in Test Case or EFS or EBS or SRS document with section
Mention : Your Test Setup used during Testing
Mention : Steps to Re-Produce the bug
Mention : Additional Info
Mention : Attach a Screen Shot if it is a GUI bug
Mention : Which other features it is blocking because of this bug that you are unable to
Execute the test cases.
Mention: How much time you took to execute that test case or follow that specific TC
Which leaded to bug?

Localization is the process of changing or modifying an application to a particular culture or locale. This includes change in user interface, graphical designs or even the initial settings according to their culture and requirements.

In terms of Localization Testing it verifies how correctly the application is changed or modified into that target culture and language.

In case of translation required of the application on that local language, testing should be done on each field to check the correct translation. Other formats like date conversion, hardware and software usage like operating system should also be considered in localization testing.

Examples for Localization Testing are

In Islamic Banking all the transactions and product features are based on Shariah Law, some important points to be noted in Islamic Banking are

1. In Islamic Banking, the bank shares the profit and loss with the customer.
2. In Islamic Banking, the bank cannot charge interest on the customer; instead they charge a nominal fee which is termed as "Profit
3. In Islamic Banking, the bank will not deal or invest in business like Gambling, Alcohol, Pork, etc.

In this case, we need to test whether these Islamic banking conditions were modified and applied in the application or product.

In Islamic Lending, they follow both the Gregorian calendar and Hijiri Calendar for calculating the loan repayment schedule. The Hijiri Calendar is commonly called as Islamic Calendar followed in all the Muslim countries according to the lunar cycle. The Hijiri Calendar has 12 months and 354 days which is 11 days shorter than Gregorian calendar. In this case, we need to test the repayment schedule by comparing both the Gregorian calendar and Hijiri Calendar.

1) Tester->
2) Open defect->
3) Send to developer
4) ->if accepted moves to step5 else sends the bug to tester gain
5) Fixed by developer ->
6) Regression testing->
7) No problem inbuilt and sign off
if problem in built reopen the issue send to step3

High level Test cases are those which cover major functionality in the application (i.e. retrieve, update display, cancel (functionality related test cases), database test cases).
Low level test cases are those related to User Interface (UI) in the application.

Branch Coverage or Decision Coverage metric is used to check the volume of testing done in all components. This process is used to ensure whether all the code is executed by verifying every branch or decision outcome (if and while statements) by executing atleast one time, so that no branches lead to the failure of the application.

To Calculate Branch Coverage,

Branch Coverage = Tested Decision Outcomes / Total Decision Outcomes.

Suppose in one banking application there is one module ATM Facility. In that ATM facility when ever we are depositing/withdrawing money it is not showing any conformation message but actually at the back end it is happening properly with out any mistake means only missing
Of message. In this case as it is happening properly so there is nothing wrong with the application but as end user is not getting any conformation message so he/she will be
Confuse for this. So we can consider this issue as HIGH Priority but LOW Severity defects…

Statement Coverage or Code Coverage or Line Coverage is a metric used in White Box Testing where we can identify the statements executed and where the code is not executed cause of blockage. In this process each and every line of the code needs to be checked and executed.

Some advantages of Statement Coverage / Code Coverage / Line Coverage are

• It verifies what the written code is expected to do and not to do.
• It measures the quality of code written.
• It checks the flow of different paths in the program also ensure whether those paths are tested or not.

To Calculate Statement Coverage,

Statement Coverage = Statements Tested / Total No. of Statements.

The bug is high severity only so we send the application to the client and find out the severity is priority or not. If its priority then we ask him to wait.
Here we found defects/bugs in the last minute of the delivery or release date
Then we have two options
1. Explain the situation to client and ask some more time to fix the bug.
2. If the client is not ready to give some time then analyze the impact of defect/bug and try to find workarounds for the defect and mention these issues in the release notes as known issues or known limitations or known bugs. Here the workaround means remedy process to be followed to overcome the defect effect.
3. Normally this known issues or known limitations (defects) will be fixed in next version or next release of the software