1 Three main stages in software development life cycle: 1. Requirement analysis done by system engineers or Analyst 2.

Development done by programmers 3. Different types of testing done by testers Testing:Testing is a process of executing a program, finding maximum number of defects with minimum amount of time and effort. Requirement analysis: Software engineers talk to end users of the software and first understand what the user is looking for and then write a detailed requirement document. Once the document is written, the systems engineer meets with programmers and testers. During this phase the entire team also determines what programming language, operating system will be used. Development: Once the requirement analysis is done and programmers ready to implement the system exactly the way stated in the document, programmers start coding, once the programming is done, the developers test their own codes to make sure that there are no silly errors.

1.

2.

Unit Testing: It is a module level testing Generally it can be done by developers not by testers Its require internal code design knowledge of module Testing: Once the development is done, testers take over and test the software thoroughly to make sure that the software is error free to the best of their knowledge and ability. Once the testing is done, the software is ready to go to the market. Usually 30% of the total time is spent for requirement analysis, 30% of the time is spent for coding or programming and the 40% of the time is spent for software testing. SOFTWARE TESTING is very important thats why so much time and money are spent.

3.

V Model:
SRS FRS HLD SDLC LLD Coding Acceptance (alpha and beta testing) System/ Functional Integration Unit STLC

2 V stands of Verification and Validation: This model defines mapping in between development stages and testing stages From the above V model organizations are maintaining multiple stages of development process along with multiple stages of testing. But organizations are interesting to maintain separate testing team only. Because the stage is bottle neck stage in software development. Verification:Verification involves reviews, meetings to evaluate documents, code, plans, requirements, Specification. It will do with Check List. Validation:Evaluation of the software at the end of the software development process to ensure whether it meets requirements Product Evaluation: Before buying any product, we will check its features, cost and how best it is useful to us. This process is called evaluation 1. Software Requirement Specification (SRS):-- Entry Criteria is contract proposal from client Analyst Gather information by conducting meeting, discussion and similar existing projects -- Exit Criteria is requirement document 2. Functional Requirement Specification (FRS):-- Entry Criteria is requirement document Identify all the requirements to implement application -- Exit Criteria is functional document 3. Higher Level Design (HLD):-- Entry Criteria is requirement and functional documents Identify modules and Data Flow Diagrams (This document specifies the overall architecture on system from root to leaves.) -- Exit Criteria is Design Documents DFD: A graphic that illustrates the movement of data between external entities and the process and data stores with in a system. 4. Lower Level Design (LLD):-- Entry Criteria is Design documents from HLD Pseudo code can be developed for each module (This document defines the internal logic of every module or functionality or features or services. ) LLD s are also known as internal logic diagrams or detailed design diagrams. -- Exit Criteria is final design specifications and Pseudo code (Algorithm) Pseudo Code : Pseudo Code is kind of structured English for describing algorithmic steps needed in a program, similar to flow chart as a planning tool for programming. 5. Coding:-

3 -- Entry Criteria is design documents and requirement documents Developed actual code for each module -- Exit Criteria is design documents and actual code for entire application 6. Testing:-- Entry Criteria is requirement documents, design documents, application, test plan document Finding defects in application --Exit Criteria is final complete bug free application What is a base lined requirement documents? Ans: Base lined requirement document is the final document that the programmers and testers will follow to do their development and testing. White box Testing:It requires knowledge of internal code design. Generally it covers statements, paths, conditions, branches and loops of the code The white box testing technique classified into 4 sub Tests such as 1) 2) 3) 4) Basis paths testing Control structure testing Program Technique testing Mutation testing

Basis paths testing: In this test the programmer is verifying every statement execution; due to this reason the programmer is running that programme more than one time. In this testing the programmer is calculating the Cyclomatic Complexity of a programme. The Cyclomatic complexity is software metric that provides a quantitative measure of the logical complexity of a program Cyclomatic Complexity 1-10 11-20 21-50 greater than 50 Risk Evaluation a simple program, without much risk more complex, moderate risk complex, high risk program untestable program (very high risk)

Control structure testing: After completion of basis paths coverage the programmer is concentrating on Correctness and Completeness of that programme structure. Ex: If conditions, If else, for loops Program Technique testing: After completion of basis paths and control structure testing the programmer is concentrating on the Execution time of that programme. At the time he is checking for the logic.

4 Mutation testing: A method where by errors are purposely inserted into a program under test to verify that the test can detect the error, also known as error seeding How do you determine what to test?
The duties of the software Tester is to go through the requirements documents and functional specification and based on those documents one should focus on writing test cases, which covers all the functionality to be tested. The tester should carry out all these procedures at the time of application under development. Once the build is ready for testing, we know what to test and how to proceed for the testing. Make sure, main functionality is tested first, so that all other testers can be ready for testing their modules/functionality

Black box Testing:Black box testing is based on requirements and functionality. It doesnt require any knowledge of internal code design. Build Verification Test / Sanity/ Ad-hoc Testing:Done after each build to make sure that the build doesnt contain major errors. It is initial testing effort to determine whether the new software version is performing well? Usability testing: During this test the testing team is concentrating on user friendliness of software build. User interface testing: Ease of use (Easy to operate) Look and feel (Attractive screens) Speed in interface(Short navigation) Integration Testing:Testing is combined parts of application to determine if they function together correctly Regression Testing: Re-Testing after fixes or modifications of the software Win Runner automation is especially used for Regression Testing Performance Testing:Load and Stress Testing Load Testing:Testing the application under heavy loads and determine at what point system response degrades or fails. Load Testing tool Load Runner a) Reduces the time spent by the testers b) Reduces the resources spent (Hardware) c) Mostly used in web testing

5 Stress Testing:Applying heavy repetition of certain actions or inputs Large complex queries, large inputs used in stress testing Recovery Test:Testing a system's ability to recover from a hardware or software failure. Security Testing:How well the data protects against unauthorized users. During this test the testing team is concentrating on below coverages a) Authorization : Validity of users to connect to software b) Access Control: Permissions to valid users to use specific functionalities. c) Encryption/Decryption : The original value converts into ------- value to prevent third party accessing. The encryption / decryption procedure testing is only possible by special category people in testing team. Acceptance Testing:Final Testing based on specifications of end-user. Alpha Testing:Testing the application when development is nearing completion conducted at developer site Beta Testing:Generally conducted at customer site it will come after release Alpha testing is differentiated from Beta testing by The location where the tests are conducted Exploratory Testing: Due to the lack of documentation the test engineers are depending on past experience, browsing related websites, discussion with others and contact customer site people to collect required complete and correct information this style of testing is called exploratory testing. Manual Support testing: The testing team is Validating the completeness and correctness of help documents. This testing is also known as user manuals testing. Compatibility Testing (or) Portability Testing: During this test the testing team is validating that whether the application build is working on customer expected platforms. Platform means that operating system, compilers, browsers and other system softwares. Configuration Testing: It is also known as hardware compatibility testing. During this test the separate testing team is validating that whether the software build is supporting different technologies in hardware are not?

6 Parallel Testing : To estimate competitiveness of our software build, the testing team is comparing that software build with other competitor software builds in market or with previous versions of same software products. This testing is also known as competitive testing or comparative testing. Compliance Testing: Whether the project team is following the responsible standards or not ? It is called compliance testing or standards testing. Boundary Value Analysis: Boundary Value Analysis is a black box testing Greater number of errors tends to occur at the boundaries of the input domain Test the application at the boundaries of the input domain, if A, B are boundaries then test at A-1, A, A+1 to B-1, B, B+1 Retest: retesting means executing the test cases again on the same build Regression testing: means executing the same test cases on the different build. Bug is nothing but a defect in Software application. Error,Defect,Bug: P T A mistake in coding is called Error (Programmer side) This error is detected during testing then it is called Defect/Bug Most common cause of defects is 1) Ambiguous or incomplete requirements Defect Tracking is monitoring defects from the time of recording until satisfactory resolution has been determined

Bug Life Cycle:Tester

Open

Rejected Project Manager/Team Leader

Assigned Developer Resolved Tester Close Reopen Tester

1) Open Stage :- A defect originated by tester 2) Assign :- Raised defect assigned to developer 3) Resolved :- Developer provides the code fix for the bug and make it resolved 4) Closed stage:- Tester re tests the bug and closes it, if its working otherwise he will reopen the defect and it go back to stage 1

Latentbug: If a bug/defect is repeatedly occurring (same bug) in every regression test while testing an application we call it as 'Latentbug'

How would you define a "bug?" Deviated Actual result from the Expected result
Severity defines the importance of defect with respective to functional point of view... Priority defines the importance of defect with respective to customer point of view

Severity is a technical issue where as priority is a business issue.

Types of defects:
1) User interface bugs (Low Severity)

a) Spelling mistake (High Priority) b) Typical meaning in object names (Medium Priority) c) Improper right alignment (Low Priority) 2) Error handling defects (Medium Severity)

a) There is no error message when you perform wrong operation (High Priority) b) Error message with wrong meaning (Medium Priority) c) Error message but complex understanding (Low Priority)

3) Load Condition bugs

(High Severity)

a) Does not allow multiple users (High Priority) b) Does not allow customer expected load (Medium Priority) c) Response time is more than bench mark (Low Priority)

Defect Resolution Types:

8 After receiving defect report from Test Engineer the development team is sending a reply to testing team, called resolution type. 1) Enhancement : Reported defect rejected due to future requirements relation. 2) Duplicate: Defect rejected due to previously accepted defect similarity. 3) Hardware Limitation: Defect rejected because that defect raised due to limitations of hardware devices. 4) Software Limitations: Defect rejected due to limitations of software technologies used in that project development. 5) Not applicable: Defect rejected due to improper meaning or wrong meaning 6) Functions as Designed: Defect rejected due to coding is correct with respect to design document. 7) Need more information: The defect is not accepted not rejected but developers required more information to understand that defect. 8) No plan to fix it: This defect is not accepted and not rejected but developer required some extra time to fix later. 9) Open : The defect accepted and developers are ready to resolve. Development team will release modified build and release note after resolving that defect. 10) Differed : Defect is accepted but resolution postponed, due to low severity and low priority. What is statement & program & module & software: A set of commands and expression is called statement; a set of executable statements is called a programme. A set of programs is called module. A set of module is called software. S.Q.A. (Software Quality Assurance): The monitoring and measuring the strength of development process is called software quality assurance. Mainly oriented towards defect prevention (Verification) S.Q.C. (Software Quality Control): The validation of a software in terms of requirements and expectations is called software Software Quality Control. Mainly oriented towards defect detection (Validation) What is considered a successful test? Making the application Bug Free, Executing maximum test cases successfully

Testing in Maintenance:

9 After completion of user acceptance testing and their modifications, project management is establishing Release team along with few programmers, few testers and few hardware engineers. This release team will go to customer site and conducts port testing. During this test the release team is observing the below factors in customer site. Complete installation Overall functionality Handling input, output, secondary devises Operating system error handling Co-Existence with other s/w applications

After completion of above observations the release team is providing training sessions to customer site employees (End Users) During utilization of that s/w the customer site people are requiring changes. There are two types of changes such as 1) Enhancement and 2) Solving missed defects 1) Enhancement : When an organization receive enhancement from customer site, the responsible team is conducting impact analysis, perform changes in coding and test that software changes completeness and correctness. 2) Solving Missed Defects : When an organization receive missed defect from customer site, the responsible team is conducting impact analysis, performing changes and improve that the capability of testing team. The responsible team is involving in above two situations, and it also known as CCB (Change Control Board) .In this team the project manager, few developers and few testers are involved. Test Cases need to be written for Valid and expected conditions Invalid and unexpected conditions Test Scenario A set of test cases that ensure that the business process flows are tested from end to end. They may be independent tests or a series of tests that follow each other, each dependent on the output of the previous one. The terms "test scenario" and "test case" are often used synonymously. Test Suite A collection of test scenarios and/or test cases that are related or that may cooperate with each other. Test Scope: Test scope is a part of Test Plan It will define what will and will not be covered in the test. Test Incident report is a document describing any event during the testing process that requires investigation

10 SEI/CMM is an application of process management and quality improvement concepts to software development and maintenance Major component of Risk Analysis are the probability that the negative event will occur. The potential loss or impact associated with that event.

What is Risk analysis? a. Evaluating risks b. Evaluating Controls c. Evaluating vulnerabilities Internal Control Officer will assess vulnerability in the system These are the main attributes of test automation a) b) c) d) Time saving Correctness Less Manpower More reliable

Features to be concentrated while testing World Wide Web sites is Interaction between html pages Performance on the client side Security aspects The application has functionality that wasn't in the requirements But as a tester you are treating it is bug But the developer is not accepting the bug what will you do Update the Project Manager with the details and the risk involved

Development Manager is essentially responsible for the quality of a product. 3 costs that make up the Cost of Quality Prevention, Appraisal, Failure Expected production costs Labor, materials, and equipment

11

Appraisal costs are Costs associated with detection of errors Example of a Failure Cost is Rework

Defect Density is calculated by Total no. of Defects/ Effort Effort Variation is calculated by (Actual Planned) / Planned Percentage Rework is calculated by Rework Effort / Actual Effort expended The categories of Error Oriented Techniques are Statistical assessment, Error-based testing and Fault based testing. The following factors should be considered for the Test Tool selection Test Phase Test Objective Test Technique Test Deliverable Equivalence partitioning consists of various activities: a). Ensure that test cases test each input and output equivalence class at least once b). Identify all inputs and all outputs c). Identify equivalence classes for each input
Test by progressive Stages Module test: Static tests : Lint and inspections Dynamic tests: To check boundaries, branches and paths. The difference between static and dynamic tests 1.Static Testing: It is the process of verifying Physical Components of system is called Static Testing Ex:Physical Documents:Testplans,Test Cases or any Project Oriented Documents.In Testing Term it is called as "Verification"

12 2.Dynamic Testing:It is the process of verifying Logical Components of system is called Dynamic Testing Ex:Executable Components of System(Builds).In Testing Term it is called as "Validation" Component Test: This is the black-box test of modules or group of modules which represent certain functionality. There are no rules about what can be called a component. It is just what the tester defined to be a component; Components can be step by step integrated to bigger components and tested as such. Integration Test: The software is step by step completed and tested by tests covering a collaboration of modules or classes. The integration depends on the kind of system. System Test: This is a black-box test of the complete software in the target system. The environmental conditions have to be realistic (complete original hardware in the destination environment).

Which Test finds which Error? Possible error Syntax errors Data errors Algorithm and logical errors Interface errors Integration errors Example Missing semicolons, Values defined but not initialized or used. Overflow of variables at calculation, values not initialized, and lifetime of pointers. Wrong program flow, use of wrong formulas and calculations. Overlapping ranges, range violation (min. and max.), wrong sequence of input parameters. Resource problems (runtime, stack, registers, memory, etc.)

13

System errors

Wrong system behaviors, specification errors

RE: What is the difference between product and project... Project : 1. Specifications will be given by Client 2. Client views/ requirements will be considered 3. End user is one Product : 1. Company designs product 2. Company with own views (based on market) develops product 3.End users are more than one

Some other differences between Web based Application and Client/Server Application 1) Client server applications do not require any browsers as media to access the application. But web based applications must required browser or media to access the application. 2) Lot of security is required for web based applications than client server applications. 3) Lot of scalability, reliability, performance is required to web based applications than client server applications, since those are generally multi users around the world. What is traceability metrics? The traceability metrics showing the relationship between test requirements and test cases. Test engineers doing all functionality covering or not? ThroughTraciblity metrics...mapping the requirement to test cases... Test strategy is a document and it specifies approach to be followed by the Testing team.It is a also called as "Test Commencement." scope & objective, Business Issues, Test Approach, Roles & responsibilities,

14 Test deliverables, Communication & Status reporting, Test Automation & Testing tools, Defect reporting & tracking, Risks & mitigations, Change & configuration Management, Testing measurement & Metrics, Training Plan