Manual Testing

1) Different kinds of software projects? 1. Development 2. Maintains projects 3. Testing projects 4. Enhancement projects 2) Project Requirement specification document 1. Preparation of SDLC follows Functional Design Specification documents 2. Requirements & Specification Document 3. STLC follows Functional Requirement Specification Documents 4. Testing Requirements specification documents 3) SDLC (Software Development Life Cycle ) 1. Requirements & Analysis 2. Design 3. Development/coding 4. Testing 5. Deployment 4) STLC(Software Testing Life Cycle ) 1. Requirement & Analysis 2. Test Design 3. Test Execution 4. Results Note: Software Test execution (from STLC) will be starts after the deployment completed (From SDLC).

1. How to start the Testing ?

1. Before going to release the build , client releases the requirements documents. 2. As per the given FRS document 3. Requirements : As per the FRS document 4. Analysis the requirements and meeting the development team to get the clarity of the requirements even though If we need any clarity we will get 5. The clarity from the on sight co-ordinator then 6. Preparing Query Sheet 7. Send query sheet documents to onsite lead to get the clarity of the 8. Queries which we have raised in query document 9. Prepare Test scenarios 10.Send test scenarios to the onsite lead for sign off 11.Preparing the Testcases 12.Execution of testcases 13.Preparing the bug report 14.Result analysis 2. Entry & Exit criteria of Testing
Entry Criteria :

1. Make me the application is deployed on the test environment 2. Test data is ready 3. Test cases are ready to execute
Exit Criteria :

1. All test cases are executed 2. S1 (Severity 1 bugs are closed )

How to decide 100 % testing is closed

Preparing the test metrix :

Test Metrix syntax: Requiements No 1.1 1.2 1.2.1 Descriptions Login Management Login Customers login Testsenerio TestCase Valid & invalide Testcases

3. What is Use Case? Explain ?

Executing Possitive flow of test cases Example : ATM system with all positive flows
1. Negitive flow of testcases Example : ATM system with all negative flows(we can have an exit option In ever y moment of ATM enquiry process)

4. What is different between priority & severity

Priority : In terms of time prioritize to fix the bugs . Severity : In terms of effect of bug on the application 5. What is test plan ? 1. Test plan is combination of test objectives ,test scope, resources, Training required , test approach What is test methodology 1. Test strategy 2. Test plan 3. Test execution 6. Test strategy : Test Strategy is the part of test plan Document fields of Test strategy

Test Module Name : Description: Prerequisites : 1. Application is on development 2. Test case is ready 3. approve the test cases Scope of the testing : 7. Retesting & Regression Testing Retesting :

Retesting is carried out to verify defect fix / fixes. Regression testing is done to check if the defect fix / fixes have not impacted other functionality of the application that was working fine before applying the code changes.
Regression Testing :

1. Test the enhanced features effect or not on the existing application. 2. Regression testing will conduct on existing test cases prepared by the client.
3. There are no new test cases prepared for the regression testing. 8. Alfa Testing & Beta Testing Alfa Testing : 1. In the presence of in-house development people and testers Beta Testing : 2. Beta testing is done totally on the presence of client or customer Side.

Santiy Smoke testing

Smoke Testing

Verfication & Validation

validation ensures that the product actually meets the user's needs, and that the specifications were correct in the first place, while verification is ensuring that the product has been built according to the requirements and design specifications. Validation ensures that you built the right thing.. Validation confirms that the product, as provided, will fulfill its intended use. System Testing : System testing is performed on the entire system in the context of a Functional Requirement Specification(s) (FRS) and/or a System Requirement Specification (SRS). System testing tests not only the design, but also the behaviour and expectations of the customer. It is also intended to test beyond the bounds defined in the software/hardware requirements specification(s).[citation needed]
Integration testing :

System application

Defect Severity determines the defect's effect on the application where as Defect Priority determines the defect urgency of repair. Severity is given by Testers and Priority by Developers

1. High Severity & Low Priority: For example an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. If there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.

2. High Severity & High Priority : In the above example if there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will block the functionality of the application immediately within a week. It should be fixed urgently.

3. Low Severity & High Priority : If there is a spelling mistake or content issue on the homepage of a website which has daily hits of lakhs. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.

4. Low Severity & Low Priority : If there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.

Smoke & Sanity Testing

Smoke Testing Sanity Testing Objective of Smoke Testing is to verify all the Objective of Sanity testing is to confirm that Critical and major functionality of an application the new build, environment and external services is working as expected before going ahead are stable enough to carry out any test i.e., even with full fledged testing i.e., Functional or before carrying out Smoke test. Regression testing. Smoke tests are broad and shallow. Smoke Tests Sanity tests are very narrow (usually, tests a are designed to catch any Critical or High single flow or two at the max) it is not designed severity defects across all the important to test all the important functionality of the functionalities. Smoke tests are designed to application. Sanity tests are intended to verify if catch Show stoppers (that was not tested and the application is available (up and running) and caught during sanity test) or blocker defects i.e., it is able to interact successfully with database, defects that indicate that a particular flow or external services and external devices if functionality cannot be tested. any.Sanity tests are designed to catch show stopper defects. Like, Unable to login to application OR application is not functioning due to JDBC connection failure etc., Smoke Testing is done by Testing team only as Sanity Testing is mostly done by Build the focus of this testing more on validating deployment/Operations Team after every new application functionality. build is deployed OR once the environment is brought up after a scheduled application / environment maintenance. Sanity testing is done by Build deployment team as immediate issues encountered post a new build deployment is more often towards configuration, database access and other setup issues. In some of the bigger projects, testing team may be asked to perform sanity testing. Smoke testing is usually done after Sanity Sanity Testing is done immediately after new Testing is completed. build deployment OR after application / environment scheduled maintenance.

Smoke Test cases are mostly documented. Sanity Test cases are usually not documented Smoke Test suite is built by picking Functional i.e., no written test cases. In most of the test cases that requires validating all the critical companies they follow a Sanity check list.e.g.:-a) and important functionalities of the Verify Loginb) Submit an Order and pay by cash application.e.g.:-a) Submit Orders and pay by different tender types (Cash, Credit, Debit, Gift c) Verify Oracle reports can be opened Card etc.,)b) Verify cancel order is working fine. As you can see, intent of Sanity testing is to find c) Verify return functionality is working fine issues that are show stoppers and that can make the system completely not testable. d) Verify sales data in Oracle daily sales report In the above example, tests are very narrow and And more test cases to test all the important does not test all the important functionality of the functionality of the application. application, instead it checks but the intent of the testing ==============UAT & ORT============== Below are the key differences between UAT (User Acceptance Testing) and ORT (Operational Readiness Testing). 1) UAT is conducted before ORT UAT is done before software deployment and ORT is done after software deployment. 2) UAT will be of longer duration compared to ORT UAT can last for a day to couple of months depending on the size of the requirements where as ORT would be only for few hours. 3) UAT is conducted by Business Users in Testing environment where as ORT is conducted by Business users (can involve testing team as well) in Production environment In some Cases, ORT may be done only by Testing team, however UAT will always be done by Business Team. 4) Objective of UAT is to validate application meets the requirements on which it was built ORT is conducted to verify application deployment was successful i.e., application and environment are working as expected. 5) UAT tests will be more exhaustive than the Tests done during ORT, as the objective of UAT is to find defects in the functionality itself and objective of ORT is to find an issues arising due to deployment before the production environment can be used by business users.