Question Answers

1.What is Software Testing? Ans- To validate the software against the requirement. 2. What is the Purpose of Testing? Ans- To check whether system is meeting requirement. 3. What types of testing do testers perform? Ans- Black Box 4. What is the Outcome of Testing? Ans- System which is bug free and meet the system requirements. 5. What kind of testing have you done? Ans- Black Box 6. What is the need for testing? Ans- To Make error Free Product and Reduce Development Cost. 7. What are the entry criteria for Functionality and Performance testing? Ans- Functional: should have stable functionality code Performance- After

system testing 8. What is test metrics? Ans- Contains how many test cases we have executed, which again

contain how many pass, fail and can not be executed. 9. Why do you go for White box testing, when Black box testing is

available? Ans- To check code, branches and loops in code 10. What are the entry criteria for Automation testing? Ans- Should have stable code. 11. When to start and Stop Testing? Ans-When system meets the requirement and there is no change in

functionality. 12. What is Quality? Ans- Consists of two QA and QC.Customer point of View Fit for use and

Meets User Requirement is Quality. 13. What is Baseline document, Can you say any two? Ans- Document which is standard like test plan format, checklist for

system testing . 13. What is Baseline document, Can you say any two? Ans- Document which is standard like test plan format, checklist for

system testing 14. What is verification?

Ans- To review the document. 15. What is validation? Ans- To validate the system against the requirements. 16. What is quality assurance? Ans – Bug presentation activity is called QA. 17. What is quality control? Ans- Bug dictation activity is called QC. 18. What is SDLC and TDLC? Ans- SDLC- Software Development Life Cycle and Testing is a part of it.

TDLC-Test Development Life Cycle. 19. What are the Qualities of a Tester? Ans- Should have ability of find out hidden bug as early as possible in

SDLC. 20. When to start and Stop Testing? Ans- Start- At the time of requirement gathering, When Meets

Requirements. 21. What are the various levels of testing? ans- Unit,Integration,System and Acceptance testing. 22. What are the types of testing you know and you experienced? Ans- Black Box, Functional Testing, system testing, gui testing etc 23. After completing testing, what would you deliver to the client? Ans- Testware 24. What is a Test Bed? Ans- Test Data is called test bad. 25. What is a Data Guidelines? Ans- Guidelines which are to be followed for the preparation of test data. 26. Why do you go for Test Bed? Ans- To validate the system against the required input. 27. What is Severity and Priority and who will decide what? Ans- Severity- how much severe is bug for application like critical Priority-

How much urgency of functionality in which bug occur. 28. Can Automation testing replace manual testing? If it so, how? Ans- Yes, if there are many modifications in functionality and it is near

impossible to update the automated scripts. 29. What is a test condition? Ans: logical input data against which we validate the system. 30. What is the test data? Ans- input data against which we validate the system.

31. What is an Inconsistent bug? Ans-Bug which are not reproducible 32. What is the difference between Re-testing and Regression testing? Ans- Regression- Check that change in code have not effected the

working functionality Retesting- Again testing the functionality of the application.

BUG LIFE CYCLE BUG: Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software. A bug is a specific concern about the quality of the Application under Test (AUT). Bug Life Cycle: In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle. The life cycle of the bug can be shown diagrammatically as follows:

The different states of a bug can be summarized as follows: 1. New 2. Open 3. Assign 4.

Test 5. Verified 6. Deferred 7. Reopened 8. Duplicate 9. Rejected 10. Closed

Description of Various Stages:

1. New: When the bug is posted for the first time, its state will be “NEW”. This means

that the bug is not yet approved.

2. Open: After a tester has posted a bug, the lead of the tester approves that the

bug is genuine and he changes the state as “OPEN”.

3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to

corresponding developer or developer team. The state of the bug now is changed to

“ASSIGN”.

4. Test: Once the developer fixes the bug, he has to assign the bug to the testing

team for next round of testing. Before he releases the software with bug fixed, he

changes the state of bug to “TEST”. It specifies that the bug has been fixed and is

released to testing team.

5. Deferred: The bug, changed to deferred state means the bug is expected to be

fixed in next releases. The reasons for changing the bug to this state have many

factors. Some of them are priority of the bug may be low, lack of time for the release

or the bug may not have major effect on the software.

6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug.

Then the state of the bug is changed to “REJECTED”.

7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept

of the bug, then one bug status is changed to “DUPLICATE”.

8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester

tests the bug. If the bug is not present in the software, he approves that the bug is

fixed and changes the status to “VERIFIED”.

9. Reopened: If the bug still exists even after the bug is fixed by the developer, the

tester changes the status to “REOPENED”. The bug traverses the life cycle once

again.

10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the

bug no longer exists in the software, he changes the status of the bug to “CLOSED”.

This state means that the bug is fixed, tested and approved

Guidelines on deciding the Severity of Bug: Indicate the impact each defect has on

testing efforts or users and administrators of the application under test. This information is

used by developers and management as the basis for assigning priority of work on defects.

A sample guideline for assignment of Priority Levels during the product test phase includes:

Critical / Show Stopper — An item that prevents further testing of the product or function

under test can be classified as Critical Bug. No workaround is possible for such bugs.

Examples of this include a missing menu option or security permission required to access a

function under test. Major / High — A defect that does not function as expected/designed

or cause other functionality to fail to meet requirements can be classified as Major Bug. The

workaround can be provided for such bugs. Examples of this include inaccurate

calculations; the wrong field being updated, etc. Average / Medium — The defects which

do not conform to standards and conventions can be classified as Medium Bugs. Easy

workarounds exists to achieve functionality objectives. Examples include matching visual

and text links which lead to different end points. Minor / Low — Cosmetic defects which

does not affect the functionality of the system can be classified as Minor Bugs.

What should be done after a bug is found? The bug needs to be communicated and

assigned to developers that can fix it. After the problem is resolved, fixes should be re-

tested, and determinations made regarding requirements for regression testing to check

that fixes didn't create problems elsewhere. If a problem-tracking system is in place, it

should encapsulate these processes. A variety of commercial

problem-tracking/management software tools are available. The following are items to

consider in the tracking process:

Web Application Testing Web Application Testing: Test a Web Based Application , in Web Testing We Consider Many Testing.Web Testing We Test Each and Every Aspect.http://testingsolution.blogspot.com/2006/12/web-testing-challenges.html

Short release cycle

Constantly Changing Technology

Possibility Of huge number of users

Inability to control user’s running environment

24hour availability of the website

Functionality Testing: It involves making sure that all the features that most affect the

user interactions works properly.

These features may include

Forms in the page .

Searches present in the page.

Pop-up windows (client side and server side) .

Any online transactions available.

Usability Testing:

Identify the websites purpose.

Identify the intended users.

Whether the user completes the task successfully.

How much time the user needs to complete the task.

Number of pages accessed to complete the task.

At which place in the application the user can .

possibly make mistakes.

How the user seeks assistance when lost.

Whether the online information provides enough help.

How possibly a user can react for the specific

download time of the page.

Point at which the user gets confused and even fail to complete a task.

Number of clicks between tasks, number of seconds between clicks as well as

number of clicks, as well as number of pages browsed.

Whether the user felt successful in using site.

Feedback on navigation and other features of the sites.

Whether the user would recommend this product to friends.

Whether the user understood the terminology.

Ideas for improvement

What the user liked or disliked about the website, and why.

Navigation Testing :

Ø Easy and quick access to the information.

Ø Logical hierarchy of the pages.

Ø Conformation of the page to tell the user about where they are at any point.

Ø Facility to return to previous state or the home page.

Ø Consistent look and lay out of every page.

Ø Moving to and from pages .

Ø Scrolling through the pages .

Ø Clicking on images and thumbnails to make sure they work.

Ø Testing all the links (both internal and external) .

Ø Ensuring no broken links exists.

Ø Proper lay out under different browsers.

Ø Measuring load time of every page.

Ø Compatibility and usage of buttons, key board shortcuts and mouse actions.

Form Testing:

Ø Using tab key the form traverses fields in the proper order, both forward and

backward.

Ø Testing boundary values for the data input.

Ø Checking that the form is capable of trapping invalid data correctly. (Specially date

and numeric formats)

Ø The form is capable of updating the information correctly.

Ø Tool tip text messages displayed for the form are proper and not misleading.

Ø Objects are aligned in the form properly, and the labels displayed are not

misleading.

Page Content Testing :

Ø All the images and the graphics are displayed correctly.

Ø All contents are present as per the requirements.

Ø Page structures are consistent across the browsers.

Ø Critical pages contain same contents across browsers.

Ø All parts of the table or form are present in the right place and in the right order.

Ø Links to the relevant contents inside or out of the page are appropriate.

Ø Web pages are visually appealing.

Ø Checking the vital information’s present in the page are not changing across

different builds.

Configuration and Compatibility Testing:

ØIs the user behind firewall?

ØDoes the user connect to the application server through a load balance.

ØDoes the browser accepts cookies?

ØAre high security settings enabled?

ØWhat technologies are the developers of the WebPages using?

ØAre secure blocking tools being used?

Performance Testing:

ØHigh activity volume at launch.

ØTime of day .

ØActivity spikes due to marketing promotions .

ØBottleneck due to hundreds of users on a network.

ØDownload time .

ØUsage patterns .

ØThink time .

ØUser arrival rates .

ØClient platforms .

ØInternet access speed .

ØAbandonment rates .

Load Testing:

Strategy:

•Understand the load requirements

•Number of user hits per day/week/month

•Total concurrent users (worst-case scenario)

•Peak request rates (Number of pages served per second)

•Identify the tools and their limitations.

•Generate enough users and transactions to access capacity.

•Create a base line criterion.

•Check the system behavior in multiple sessions.

•Identify any other application probably running on the client

•system or server.

•Execute the test multiple times.

Security Testing:

ØWhat precautions exist to prevent or limit attacks from users?

ØAre the browser settings set to ensure maximum security protections?

ØHow does the website handle access rights?

ØDoes the application has a virus detection mechanism?

ØDoes the application handle transaction tempering?

ØDoes the e-commerce vendor provide a mechanism to prevent

Øcredit card frauds?

ØHow does the website encrypt data transfer mechanism?

ØHow does the web site authenticate users?

ØDoes viewing the source code disclose any vital information?

ØHow safe is the credit card or user information?

ØDoes the application allow for a file to be digitally signed?

Test Case

Test Case : Test case is a document that describes an input, action or event and an

expected response to determine if a feature of an application is working correctly

and meets the user requirements.A Good test case is the one that has high

probability of finding as yet undiscovered error.

The Test case document contains the following fields:

Test case id : This is an id given to every test case and it should be unique.

Test case decription : This field contains the brief description of what we are going

to test in that application.

Test input : This contains the input that we are going to give to test the application

or system.

Test Action : This field explains the action to be performed to execute the test case.

Expected results : This fielsd contains the description of what tester should see

after all test steps has been completed.

Actual results : This field contains a brief description of what the tester saw after

the test steps has been completed.

Result:This is often replaced with either pass or fail. If both the expected result and

actual result are same then the result is pass else the result is fail.

Testing Process The steps in the testing process are as follows.1. Requirement analysisTesting should begin in the requirements phase of the software life cycle (SDLC). The actual requirement should be understand clearly with the help of Requirement Specification documents, Functional Specification documents, Design Specification documents, Use case Documents etc.During the requirement analysis the following should be considered.-Are the definitions and descriptions of the required capabilities precise? -Is there clear delineation between the system and its environment?-Can the requirements be realized in practice?-Can the requirements be tested effectively?2. Test PlanningDuring this phase Test Strategy, Test Plan, Test Bed will be created.A test plan is a systematic approach in testing a system or software. The plan should identify:-Which aspects of the system should be tested?-Criteria for success.-The methods and techniques to be used.-Personnel responsible for the testing.-Different Test phase and Test Methodologies-Manual and Automation Testing-Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc-Evaluation & identification – Test, Defect tracking tools3. Test Environment SetupDuring this phase the required environment will be setup will be done. The following should also be taken in account.- Network connectivity’s-All the Software/ tools Installation and configuration-Coordination with Vendors and others4. Test DesignDuring this phase-Test Scenarios will be identified.-Test Cases will be prepared.-Test data and Test scripts prepared.-Test case reviews will be conducted.5. Test AutomationIn this phase the requirement for the automation will be identified. The tools that are to be used will be identified. Designing framework, scripting, script integration, Review and approval will be undertaken in this phase. 6. Test Execution and Defect Tracking Testers execute the software based on the plans and tests and report any errors found to the development team. In this phase-Test cases will be executed.-Test Scripts will be tested.-Test Results will be analyzed.-Raised the defects and tracking for its closure.7. Test Reports Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release.-Test summary reports will be prepared-Test Metrics and process Improvements made-Build release-Receiving acceptance

Software Development Life Cycle SDLC: The software development life cycle (SDLC) is the entire process of formal, logical steps taken to develop a software product. Software development is the process of developing software through successive phases in an orderly way. This process includes not only the actual writing of code but also the preparation of requirements and objectives,

the design of what is to be coded, and confirmation that what is developed has met objectives.The software development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. Typical phases of software development:

1) Requirement Analysis 2) Software design 3) Development or Coding 4) Testing 5) Maintenance

Requirement Analysis: The new system requirements are defined. The requirements of a desired software product are extracted. Based the business scenario the SRS (Software Requirement Specification) document is prepared in this phase. The purpose of this document is to specify the functional requirements of the software that will be produced by the SOS project group. The specifications are intended to guide the group through the development process. Design: Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues for the software. Design phase is concerned with making sure the software system will meet the requirements of the product. It should also ensure that the future requirements will also be addressed.. Development (or) Coding: Programs are developed by the developers with the help of the design. The design is reduced to code by the software engineers. Testing: Testing is evaluating the software to check for the user requirements. Here the software is evaluated with intent of finding defects. Maintenance: Once the new system is up and running for awhile, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.

Testing Techniques

Black Box Testing -Testing of a function without knowing internal structure of the

program.

White Box Testing -Testing of a function with knowing internal structure of the

program.

Regression Testing -To ensure that the code changes have not had an adverse

affect to the other modules or on existing functions.

Functional Testing:Study SRS , Identify Unit Functions For each unit function -

Take each input function - Identify Equivalence class - Form Test cases - Form Test

cases for boundary values - From Test cases for Error Guessing Form Unit function

v/s Test cases, Cross Reference Matrix and Find the coverage.

Unit Testing:

The most 'micro' scale of testing to test particular functions or code modules.

Typically done by the programmer and not by testers .

Unit - smallest testable piece of software.

A unit can be compiled/ assembled/ linked/ loaded; and put under a test harness.

Unit testing done to show that the unit does not satisfy the functional specification

and/ or its implemented structure does not match the intended design structure.

Integration Testing: Integration is a systematic approach to build the complete

software structure specified in the design from unit-tested modules. There are two

ways integration performed. It is called Pre-test and Pro-test.

Pre-test: the testing performed in Module development area is called Pre-test. The

Pre-test is required only if the development is done in module development area.

System Testing: *

A system is the big component.

System testing is aimed at revealing bugs that cannot be attributed to a component

as such, to inconsistencies between components or planned interactions between

components.

Concern: issues, behaviors that can only be exposed by testing the entire integrated

system (e.g., performance, security, recovery)

Volume Testing: The purpose of Volume Testing is to find weaknesses in the

system with respect to its handling of large amounts of data during short time

periods. For example, this kind of testing ensures that the system will process data

across physical and logical boundaries such as across servers and across disk

partitions on one server.

Stress testing: This refers to testing system functionality while the system is under

unusually heavy or peak load; it's similar to the validation testing mentioned

previously but is carried out in a "high-stress" environment. This requires that you

make some predictions about expected load levels of your Web site.

Usability testing: Usability means that systems are easy and fast to learn, efficient

to use, easy to remember, cause no operating errors and offer a high degree of

satisfaction for the user. Usability means bringing the usage perspective into focus,

the side towards the user.

Security testing: If your site requires firewalls, encryption, user authentication,

financial transactions, or access to databases with sensitive data, you may need to

test these and also test your site's overall protection against unauthorized internal or

external access.

Alpha testing: Testing of an application when development is nearing completion

minor design changes may still be made as a result of such testing. Typically done

by end-users or others, not by programmers or testers.

Beta testing: Testing when development and testing are essentially completed and

final bugs and problems need to be found before final release. Typically done by

end-users or others, not by programmers.

Why Testing?

To unearth and correct defects.

To detect defects early and to reduce cost of defect fixing.

To ensure that product works as user expected it to.

To avoid user detecting problems

What is Testing?

An examination of the behavior of a program by executing on sample data sets.

Testing comprises of set of activities to detect defects in a produced material.

To unearth & correct defects.

To detect defects early & to reduce cost of defect fixing.

To avoid user detecting problems.

To ensure that product works as users expected it to.