Manual Testing Interview Questions & Answers

Posted On:January 25, 2019, Posted By: Latest Interview Questions, Views: 4749, Rating :

Best Manual Testing Interview Questions and Answers

Dear Readers, Welcome to Manual Testing Interview Questions and Answers have been designed specially to get you acquainted with the nature of questions you may encounter during your Job interview for the subject of Manual Testing. These Manual Testing Questions are very important for campus placement test and job interviews. As per my experience good interviewers hardly plan to ask any particular questions during your Job interview and these model questions are asked in the online technical test and interview of many IT companies.

interview questions on manual testing

1. Explain the Manual testing process?

Manual Testing Process :
Process is a roadmap to develop the project is consists a number of sequential steps.
Software Testing Life Cycle:
• Test Plan
• Test Development
• Test Execution
• Analyse Results
• Defect Tracking
• Summarise Report
Test Plan :
It is a document which describes the testing environment, purpose, scope, objectives, test strategy, schedules, mile stones, testing tool, roles and responsibilities, risks, training, staffing and who is going to test the application, what type of tests should be performed and how it will track the defects.
Test Development :
• Preparing test cases
• Preparing test data
• Preparing test procedure
• Preparing test scenario
• Writing test script
Test Execution :
In this phase we execute the documents those are prepared in test development phase.
Analyse result :
Once executed documents will get results either pass or fail. we need to analyse the results during this phase.
Defect Tracking :
When ever we get defect on the application we need to prepare the bug report file and forwards to Test Team Lead and Dev Team. The Dev Team will fix the bug. Again we have to test the application. This cycle repeats till we get the software with our defects.
Summarise Reports :
• Test Reports
• Bug Reports
• Test Documentation
 

2 . What is diff. between CMMI and CMM levels?

CMM: - this is applicable only for software industry. KPAs -18
CMMI: - This is applicable for software, out sourcing and all other industries. KPA - 25
 

3. What is the scalability testing?

1. Scalabilty is nothing but how many users that the application should handle
2. Scalability is nothing but maximum no of users that the system can handle
3. Scalability testing is a subtype of performance test where performance requirements for response time, throughput, and/or utilization are tested as load on the SUT is increased over time.
4. As a part of scalability testing we test the expandability of the application. In scalability we test 1.Applicaation scalability, 2.Performance scalability
Application scalability: to test the possibility of implementing new features in the system or updating the existing features of the system. With the help of design doc we do this testing
Performance scalability: To test how the s/w perform when it is subjected to varying loads to measure and to evaluate the
Performance behavior and the ability for the s/w to continue to function properly under different workloads.
–> To check the comfort level of an application in terms of user load. And user experience and system tolerance levels
–> The point within an application that when subjected to increasing workload begin to degrade in terms of end user experience and system tolerance
–> Response time
Execution time
System resource utilization
Network delays
? stress testing
 

4. What is status of defect when you are performing regression testing?

A:-Fixed Status
 

5. What is the first test in software testing process?

A) Monkey testing
B) Unit Testing
c) Static analysis
d) None of the above
 Unit testing is the first test in testing process, though it is done by developers after the completion of coding it is correct one.
 

6. When will the testing starts? a) Once the requirements are Complete b) In requirement phase?

 Once the requirements are complete.
This is Static testing. Here, u r supposed to read the documents (requirements) and it is quite a common issue in S/w industry that many requirements contradict with other requirements. These are also can be reported as bugs. However, they will be reviewed before reporting them as bugs (defects).
 

7. What is the part of Qa and QC in refinement v model?

V model is a kind of SDLC. QC (Quality Control) team tests the developed product for quality. It deals only with product, both in static and dynamic testing. QA (Quality Assurance) team works on the process and manages for better quality in the process. It deals with (reviews) everything right from collecting requirements to delivery.
 

8. What are the bugs we cannot find in black box?

 If there r any bugs in security settings of the pages or any other internal mistake made in coding cannot be found in black box testing.
 

9. What are Microsoft 6 rules?

 As far as my knowledge these rules are used at user Interface test.
These are also called Microsoft windows standards. They are
. GUI objects are aligned in windows
• All defined text is visible on a GUI object
• Labels on GUI objects are capitalized
• Each label includes an underlined letter (mnemonics)
• Each window includes an OK button, a Cancel button, and a System menu
 

10. What are the steps to test any software through automation tools?

 First, you need to segregate the test cases that can be automated. Then, prepare test data as per the requirements of those test cases. Write reusable functions which are used frequently in those test cases. Now, prepare the test scripts using those reusable functions and by applying loops and conditions where ever necessary. However, Automation framework that is followed in the organization
should strictly follow through out the process.
 

11. What is Defect removable efficiency?

The DRE is the percentage of defects that have been removed during an activity, computed with the equation below. The DRE can also be computed for each software development activity and plotted on a bar graph to show the relative defect removal efficiencies for each activity. Or, the DRE may be computed for a specific task or technique (e.g. design inspection, code walkthrough, unit test, 6 month operation, etc.) Number Defects Removed DRE = –—————————————————— * 100
Number Defects at Start of Process
DRE=A/A+B = 0.8
A = Testing Team (Defects by testing team)
B = customer ( ” ” customer )
If dre <=0.8 then good product otherwise not.
 

12. Example for bug not reproducible?

 Difference in environment.
 

13. Difference between adhoc testing and error guessing?

 Adhoc testing: without test data r any documents performing testing.
Error Guessing: This is a Test data selection technique. The selection criterion is to pick values that seem likely to cause errors.
 

14. Diff between test plan and test strategy?

 Test plan: After completion of SRS learning and business requirement gathering test management concentrate on test planning, this is done by Test lead, or Project lead.
Test Strategy: Depends on corresponding testing policy quality analyst finalizes test Responsibility Matrix. This is dont by QA. But both r Documents.
 

15. What is difference in between Operating System 2000 and OS XP?

Windows 2000 and Windows XP are essentially the same operating system (known internally as Windows NT 5.0 and Windows NT 5.1, respectively.) Here are some considerations if you’re trying to decide which version to use:
Windows 2000 benefits:
1) Windows 2000 has lower system requirements, and has a simpler interface (no “Styles” to mess with).
2) Windows 2000 is slightly less expensive, and has no product activation.
3) Windows 2000 has been out for a while, and most of the common problems and security holes have been uncovered and fixed.
4) Third-party software and hardware products that aren’t yet XP-compatible may be compatible with Windows 2000; check the manufacturers of your devices and applications for XP support before you upgrade.
Windows XP benefits:
1) Windows XP is somewhat faster than Windows 2000, assuming you have a fast processor and tons of memory (although it will run fine with a 300 MHz Pentium II and 128MB of RAM).
2) The new Windows XP interface is more cheerful and colorful than earlier versions, although the less- cartoon “Classic” interface can still be used if desired.
3 Windows XP has more bells and whistles, such as the Windows Movie Maker, built-in CD writer support, the Internet Connection Firewall, and Remote Desktop Connection.
4) Windows XP has better support for games and comes with more games than Windows 2000.
5) Manufacturers of existing hardware and software products are more likely to add Windows XP compatibility now than Windows 2000 compatibility.

 

16. What is bug life cycle?

 New: when tester reports a defect
Open: when developer accepts that it is a bug or if the developer rejects the defect, then the status is turned into “Rejected”
Fixed: when developer make changes to the code to rectify the bug…
Closed/Reopen: when tester tests it again. If the expected result shown up, it is turned into “Closed” and if the problem resists again, it’s “Reopen
 

17. What is deferred status in defect life cycle?

 Deferred status means the developer accepted the bus, but it is scheduled to rectify in the next build

 

18. What is smoke test?

A; — Testing the application whether it’s performing its basic functionality properly or not, so that the test team can go ahead with the application

 

19. Do you use any automation tool for smoke testing?

 Definitely can use.
 

20. What is Verification and validation?

 Verification is static. No code is executed. Say, analysis of requirements etc. Validation is dynamic. Code is executed with scenarios present in test cases.
 

21. What is test plan and explain its contents?

 Test plan is a document which contains the scope for testing the application and what to be tested, when to be tested and who to test.
 

22. Advantages of automation over manual testing?

 Time, resource and Money
 

23. What is ADhoc testing?

 AdHoc means doing something which is not planned.

 

24. What is mean by release notes?

 It’s a document released along with the product which explains about the product. It also contains about the bugs that are in deferred status.
 

25. Scalability testing comes under in which tool?

 Scalability testing comes under performance testing. Load testing, scalability testing both r same.

 

26. What is the difference between Bug and Defect?

 Bug: Deviation from the expected result. Defect: Problem in algorithm leads to failure.
A Mistake in code is called Error.
Due to Error in coding, test engineers are getting mismatches in application is called defect.
If defect accepted by development team to solve is called Bug.

 

27. What is hot fix?

 A hot fix is a single, cumulative package that includes one or more files that are used to address a problem in a software product. Typically, hot fixes are made to address a specific customer situation and may not be distributed outside the customer organization.
Bug found at the customer place which has high priority.
 

28. What is the difference between functional test cases and compatability testcases?

 There are no Test Cases for Compatibility Testing; in Compatibility Testing we are Testing an application in different Hardware and software. If it is wrong plz let me know.
 

29. What is Acid Testing??

 ACID Means:
ACID testing is related to testing a transaction.
A-Atomicity
C-Consistent
I-Isolation
D-Durable
Mostly this will be done database testing.

 

30. What is the main use of preparing a traceability matrix?

 To Cross verify the prepared test cases and test scripts with user requirements.
To monitor the changes, enhance occurred during the development of the project.
Traceability matrix is prepared in order to cross check the test cases designed against each requirement, hence giving an opportunity to verify that all the requirements are covered in testing the application.
 

31. If we have no SRS, BRS but we have test cases does u execute the test cases blindly or do u follow any other process?

 Test case would have detail steps of what the application is supposed to do. SO
1) Functionality of application is known.
2) In addition you can refer to Backend, I mean look into the Database. To gain more knowledge of the application

 

32. How to execute test case?

 There are two ways:
1. Manual Runner Tool for manual execution and updating of test status.
2. Automated test case execution by specifying Host name and other automation pertaining details.
 

33. Difference between re testing and regression testing?

 Who will change the Bug Status as Differed?
 Bug will be in open status while developer is working on it Fixed after developer completes his work if it is not fixed properly the tester puts it in reopen After fixing the bug properly it is in closed state.
Developer
 

34. wht is smoke testing and user interface testing ?

 ST:
Smoke testing is non-exhaustive software testing, as pertaining that the most crucial functions of a program work, but not bothering with finer details. The term comes to software testing from a similarly basic type of hardware testing.
UIT:
I did a bit or R n D on this…. some says it’s nothing but Usability testing. Testing to determine the ease with which a user can learn to operate, input, and interpret outputs of a system or component.
Smoke testing is nothing but to check whether basic functionality of the build is stable or not?
I.e. if it possesses 70% of the functionality we say build is stable.
User interface testing: We check all the fields whether they are existing or not as per the format we check spelling graphic font sizes everything in the window present or not|
 

35. what is bug, deffect, issue, error?

 Bug: — Bug is identified by the tester.
Defect:– Whenever the project is received for the analysis phase ,may be some requirement miss to get or understand most of the time Defect itself come with the project (when it comes).
Issue: — Client site error most of the time.
Error: — When anything is happened wrong in the project from the development side i.e. called as the error, most of the time this knows by the developer.
Bug: a fault or defect in a system or machine
Defect: an imperfection in a device or machine;
Issue: An issue is a major problem that will impede the progress of the project and cannot be resolved by the project manager and project team without outside help
Error:
Error is the deviation of a measurement, observation, or calculation from the truth
 

36. What is the diff b/w functional testing and integration testing?

 functional testing is testing the whole functionality of the system or the application whether it is meeting the functional specifications
Integration testing means testing the functionality of integrated module when two individual modules are integrated for this we use top-down approach and bottom up approach
 

37. what type of testing u perform in organization while u do System Testing, give clearly?

 Functional testing
User interface testing
Usability testing
Compatibility testing
Model based testing
Error exit testing
User help testing
Security testing
Capacity testing
Performance testing
Sanity testing
Regression testing
Reliability testing
Recovery testing
Installation testing
Maintenance testing
Accessibility testing, including compliance with:
Americans with Disabilities Act of 1990
Section 508 Amendment to the Rehabilitation Act of 1973
Web Accessibility Initiative (WAI) of the World Wide Web
Consortium (W3C)
 

38. What is the main use of preparing Traceability matrix and explain the real time usage?

 A traceability matrix is created by associating requirements with the work products that satisfy them. Tests are associated with the requirements on which they are based and the product tested to meet the requirement.
A traceability matrix is a report from the requirements database or repository.

 

39. How can u do the following 1) Usability testing 2) scalability Testing

A:–
UT:
Testing the ease with which users can learn and use a product.
ST:
It’s a Web Testing defn.allows web site capability improvement.
PT:
Testing to determine whether the system/software meets the specified portability requirements.
 

39. What does u mean by Positive and Negative testing & what is the diff’s between them. Can anyone explain with an example?

 Positive Testing: Testing the application functionality with valid inputs and verifying that output is correct
Negative testing: Testing the application functionality with invalid inputs and verifying the output.
Difference is nothing but how the application behaves when we enter some invalid inputs suppose if it accepts invalid input the application
Functionality is wrong
Positive test: testing aimed to show that s/w work i.e. with valid inputs. This is also called as “test to pass’
Negative testing: testing aimed at showing s/w doesn’t work. Which is also know as ‘test to fail” BVA is the best example of -ve testing.
 

40. What is change request, how u use it?

 Change Request is a attribute or part of Defect Life Cycle.
Now when u as a tester finds a defect n report to ur DL…he in turn informs the Development Team.
The DT says it’s not a defect it’s an extra implementation or says not part of req’ment. Its newscast has to pay.
Here the status in ur defect report would be Change Request
I think change request controlled by change request control board (CCB). If any changes required by client after we start the project, it has to come thru that CCB and they have to approve it. CCB got full rights to accept or reject based on the project schedule and cost.
 

41. What is risk analysis, what type of risk analysis u did in u r project?

 Risk Analysis:
A systematic use of available information to determine how often specified events and unspecified events may occur and the magnitude of their likely consequences
OR
procedure to identify threats & vulnerabilities, analyze them to ascertain the exposures, and highlight how the impact can be eliminated or reduced
Types :
1.QUANTITATIVE RISK ANALYSIS
2.QUALITATIVE RISK ANALYSIS
 

42. What is API ?

A:– Application program interface
 

43. What isHigh severity, low priority bug?

 A page is rarely accessed, or some activity is performed rarely but that thing outputs some important Data incorrectly, or corrupts the data, this will be a bug of H severity L priority
 

44. If project wants to release in 3months what type of Risk analysis u do in Test plan?

A:– Use risk analysis to determine where testing should be focused. Since it’s rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgment skills, common sense, and experience. (If warranted, formal methods are also available.) Considerations can include:
• Which functionality is most important to the project’s intended purpose?
• Which functionality is most visible to the user?
• Which functionality has the largest safety impact?
• Which functionality has the largest financial impact on users?
• Which aspects of the application are most important to the customer?
• Which aspects of the application can be tested early in the development cycle?
• Which parts of the code are most complex, and thus most subject to errors?
• Which parts of the application were developed in rush or panic mode?
• Which aspects of similar/related previous projects caused problems?
• Which aspects of similar/related previous projects had large maintenance expenses?
• Which parts of the requirements and design are unclear or poorly thought out?
• What do the developers think are the highest-risk aspects of the application?
• What kinds of problems would cause the worst publicity?
• What kinds of problems would cause the most customer service complaints?
• What kinds of tests could easily cover multiple functionalities?
• Which tests will have the best high-risk-coverage to time-required ratio
 

45. Test cases for IE 6.0 ?

A:– Test cases for IE 6.0 i.e Internet Explorer 6.0:—
1)First I go for the Installation side, means that –
+ is it working with all versions of Windows ,Netscape or other softwares in other words we can say that IE must check with all hardware and software parts.
2) Secondly go for the Text Part means that all the Text part appears in frequent and smooth manner.
3) Thirdly go for the Images Part means that all the Images appears in frequent and smooth manner.
4) URL must run in a better way.
5) Suppose Some other language used on it then URL take the Other Characters, Other than Normal Characters.
6)Is it working with Cookies frequently or not.
7) Is it Concerning with different script like JScript and VBScript.
  HTML Code work on that or not.
9) Troubleshooting works or not.
10) All the Tool bars are work with it or not.
11) If Page has Some Links, than how much is the Max and Min Limit for that.
12) Test for Installing Internet Explorer 6 with Norton Protected Recycle Bin enabled .
13) Is it working with the Uninstallation Process.
14) Last but not the least test for the Security System for the IE 6.0
 

46. Where you involve in testing life cycle ,what type of test you perform ?

A:– Generally test engineers involved from entire test life cycle i.e, test plan, test case preparation, execution, reporting. Generally system testing, regression testing, adhoc testing
etc.

 

47. what is Testing environment in your company ,means hwo testing process start ?

A:– testing process is going as follows
quality assurance unit
quality assurance manager
testlead
test engineer
 

48. who prepares the use cases?

A:– In Any company except the small company Business analyst prepares the use cases
But in small company Business analyst prepares along with team lead
 

49. What methodologies have you used to develop test cases?

A:– generally test engineers uses 4 types of methodologies
1. Boundary value analysis
2.Equivalence partition
3.Error guessing
4.cause effect graphing
 

50. Why we call it as a regression test nor retest?

A:– If we test whether defect is closed or not i.e Retesting But here we are checking the impact also regression means repeated times
 

51. Is automated testing better than manual testing. If so, why?

A:– Automated testing and manual testing have advantages as well as disadvantages
Advantages: It increase the efficiency of testing process speed in process
reliable
Flexible
disadvantage’s
Tools should have compatibility with our development or deployment tools needs lot of time initially If the requirements are changing continuously Automation is not suitable
Manual: If the requirements are changing continuously Manual is suitable Once the build is stable with manual testing then only we go 4 automation
Disadvantages:
It needs lot of time
We can not do some type of testing manually
E.g Performances
 

52. what is the exact difference between a product and a project.give an example ?

A:– Project Developed for particular client requirements are defined by client Product developed for market Requirements are defined by company itself by conducting market survey
Example
Project: the shirt which we are interested stitching with tailor as per our specifications is project
Product: Example is “Ready made Shirt” where the particular company will imagine particular measurements they made the product
Mainframes is a product
Product has many mo of versions
but project has fewer versions i.e depends upon change request and enhancements
 

53. Define Brain Stromming and Cause Effect Graphing? With Eg?

A:– BS:
A learning technique involving open group discussion intended to expand the range of available ideas
OR
A meeting to generate creative ideas. At PEPSI Advertising, daily, weekly and bi-monthly brainstorming sessions are held by various work groups within the firm. Our monthly I-
Power brainstorming meeting is attended by the entire agency staff.
OR
Brainstorming is a highly structured process to help generate ideas. It is based on the principle that you cannot generate and evaluate ideas at the same time. To use brainstorming, you must first gain agreement from the group to try brainstorming for a fixed interval (eg six minutes).
CEG :
A testing technique that aids in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications.
 

54. Actually by using severity u should know which one u need to solve so what is the need of priority?

A:– I guess severity reflects the seriousness of the bug where as priority refers to which bug should rectify first. of course if the severity is high the same case is with priority in normal.
severity decided by the tester where as priority decided by developers. which one need to solve first knows through priority not with severity. how serious of the bug knows through
severity.
severity is nothing impact of that bug on the application. Priority is nothing but importance to resolve the bug yeah of course by looking severity we can judge but sometimes high severity bug doesn’t have high priority At the same time High priority bug don’t have high severity
So we need both severity and priority
 

55. What do u do if the bug that u found is not accepted by the developer and he is saying its not reproducible. Note:The developer is in the on site location ?

A:– once again we will check that condition with all reasons. then we will attach screen shots with strong reasons. then we will explain to the project manager and also explain to the client when they contact us
Sometimes bug is not reproducible it is because of different environment suppose development team using other environment and you are using different environment at this situation there is chance of bug not reproducing. At this situation please check the environment in the base line documents that is functional documents if the environment which we r using is correct we will raise it as defect We will take screen shots and sends them with test procedure also
 

56. What is the difference between three tier and two tier application?

A:– Client server is a 2-tier application. In this, front end or client is connected to
‘Data base server’ through ‘Data Source Name’,front end is the monitoring level.
Web based architecture is a 3-tier application. In this, browser is connected to web server through TCP/IP and web server is connected to Data base server,browser is the monitoring level. In general, Black box testers are concentrating on monitoring level of any type of application.
All the client server applications are 2 tier architectures.
Here in these architecture, all the “Business Logic” is stored in clients and “Data” is stored in Servers. So if user request anything, business logic will b performed at client, and the data is retrieved from Server(DB Server). Here the problem is, if any business logic changes, then we
need to change the logic at each any every client. The best ex: is take a super market, i have branches in the city. At each branch i have clients, so business logic is stored in clients, but the actual data is store in servers.If assume i want to give some discount on some items, so i
need to change the business logic. For this i need to goto each branch and need to change the business logic at each client. This the disadvantage of Client/Server architecture.
So 3-tier architecture came into picture:
Here Business Logic is stored in one Server, and all the clients are dumb terminals. If user requests anything the request first sent to server, the server will bring the data from DB Sever and send it to clients. This is the flow for 3-tier architecture.
Assume for the above. Ex. if i want to give some discount, all my business logic is there in Server. So i need to change at one place, not at each client. This is the main advantage of 3-tier architecture.
 

57. What is Impact analysis? How to do impact analysis in yr project?

 Impact analysis means when we r doing regressing testing at that time we r checking that the bug fixes r working properly, and by fixing these bug other components are working as per their requirements r they got disturbed.
 

58. HOW TO TEST A WEBSITE BY MANUAL TESTING?

 Web Testing
During testing the websites the following scenarios should be considered.
Functionality
Performance
Usability
Server side interface
Client side compatibility
Security
Functionality:
In testing the functionality of the web sites the following should be tested.
Links
Internal links
External links
Mail links
Broken links
Forms
Field validation
Functional chart
Error message for wrong input
Optional and mandatory fields
Database
Testing will be done on the database integrity.
Cookies
Testing will be done on the client system side, on the temporary internet files.
Performance:
Performance testing can be applied to understand the web site’s scalability, or to benchmark the performance in the environment of third party products such as servers and middle ware for potential purchase.
Connection speed:
Tested over various Networks like Dial up, ISDN etc
Load
What is the no. of users per time?
Check for peak loads & how system behaves.
Large amount of data accessed by user.
Stress
Continuous load
Performance of memory, cpu, file handling etc.
Usability :
Usability testing is the process by which the human-computer interaction characteristics of a system are measured, and weaknesses are identified for correction. Usability can be defined as the degree to which a given piece of software assists the person sitting at the keyboard to accomplish a task, as opposed to becoming an additional impediment to such accomplishment. The broad goal of usable systems is often assessed using several
Criteria:
Ease of learning
Navigation
Subjective user satisfaction
General appearance
Server side interface:
In web testing the server side interface should be tested.
This is done by Verify that communication is done properly.
Compatibility of server with software, hardware, network and database should be tested.
The client side compatibility is also tested in various platforms, using various browsers etc.
Security:
The primary reason for testing the security of an web is to identify potential vulnerabilities and subsequently repair them.
The following types of testing are described in this section:
Network Scanning
Vulnerability Scanning
Password Cracking
Log Review
Integrity Checkers
Virus Detection
Performance Testing
Performance testing is a rigorous usability evaluation of a working system under realistic conditions to identify usability problems and to compare measures such as success
rate, task time and user satisfaction with requirements. The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing.
To conduct performance testing is to engage in a carefully controlled process of measurement and analysis. Ideally, the software under test is already stable enough so that this process can proceed smoothly. A clearly defined set of expectations is essential for meaningful performance testing.
For example, for a Web application, you need to know at least two things:
expected load in terms of concurrent users or HTTP connections
acceptable response time
Load testing:
Load testing is usually defined as the process of exercising the system under test by feeding it the largest tasks it can operate with. Load testing is sometimes called volume testing, or longevity/endurance testing
Examples of volume testing:
testing a word processor by editing a very large document
testing a printer by sending it a very large job
testing a mail server with thousands of users mailboxes
Examples of longevity/endurance testing:
testing a client-server application by running the client in a loop against the server over an extended period of time
Goals of load testing:
Expose bugs that do not surface in cursory testing, such as memory management bugs, memory leaks, buffer overflows, etc. Ensure that the application meets the performance baseline established during Performance testing. This is done by running regression tests against the application at a specified maximum load.
Although performance testing and load testing can seen similar, their goals are different. On one hand, performance testing uses load testing techniques and tools for measurement and benchmarking purposes and uses various load levels whereas load testing operates at a predefined load level, the highest load that the system can accept while still functioning properly.
Stress testing:
Stress testing is a form of testing that is used to determine the stability of a given system or entity. This is designed to test the software with abnormal situations. Stress testing attempts to find the limits at which the system will fail through abnormal quantity or frequency of inputs.
Stress testing tries to break the system under test by overwhelming its resources or by taking resources away from it (in which case it is sometimes called negative testing).
The main purpose behind this madness is to make sure that the system fails and recovers gracefully — this quality is known as recoverability.
Stress testing does not break the system but instead it allows observing how the system reacts to failure. Stress testing observes for the following.
Does it save its state or does it crash suddenly?
Does it just hang and freeze or does it fail gracefully?
Is it able to recover from the last good state on restart?
Etc.
Compatability Testing
A Testing to ensure compatibility of an application or Web site with different browsers, OS and hardware platforms. Different versions, configurations, display resolutions, and Internet connect speeds all can impact the behavior of the product and introduce costly and embarrassing bugs. We test for compatibility using real test environments. That is testing how will the system performs in the particular software, hardware or network environment. Compatibility testing can be performed manually or can be driven by an automated functional or reg The purpose of compatibility testing is to reveal issues related to the product& interaction session test suite.with other software as well as hardware. The product compatibility is evaluated by first identifying the hardware/software/browser components that the product is designed to support. Then a hardware/software/browser matrix is designed that indicates the configurations on which the product will be tested. Then, with input from the client, a testing script is designed that will be sufficient to evaluate compatibility between the product and the hardware/software/browser matrix. Finally, the script is executed against the matrix,and any anomalies are investigated to determine exactly where the incompatibility lies.
Some typical compatibility tests include testing your application:
On various client hardware configurations
Using different memory sizes and hard drive space
On various Operating Systems
In different network environments
With different printers and peripherals (i.e. zip drives, USBs, etc.)

 

59. which comes first test strategy or test plan?

A:– Test strategy comes first ans this is the high level document…. and approach for the testing starts from test strategy and then based on this the test lead prepares the
test plan….
 

60. what is the difference between web based application and client server application as a testers point of view?

A:– According to Tester’s Point of view——
1) Web Base Application (WBA)is a 3 tier application ;Browser,Back end and Server.
Client server Application(CSA) is a 2 tier Application ;Front End ,Back end .
2) In the WBA tester test for the Script error like java script error VB script error etc, that shown at the page. In the CSA tester does not test for any script error.
3) Because in the WBA once changes perform reflect at every machine so tester has less work for test. Whereas in the CSA every time application need to be instal hence ,it maybe possible that some machine has some problem for that Hardware testing as well as software testing is needed.
 

61. What is the significance of doing Regression testing?

A:– To check for the bug fixes. And this fix should not disturb other functionality
To Ensure the newly added functionality or existing modified functionality or developer fixed bug arises any new bug or affecting any other side effect. this is called regression test and ensure already PASSED TEST CASES would not arise any new bug.
 

62. What are the diff ways to check a date field in a website?

A:– There are different ways like :–
1) you can check the field width for minimum and maximum.
2) If that field only take the Numeric Value then check it’ll only take Numeric no other type.
3) If it takes the date or time then check for other.
4) Same way like Numeric you can check it for the Character,Alpha Numeric aand all.
5) And the most Important if you click and hit the enter key then some time pag e may give the error of javascript, that is the big fault on the page .
6) Check the field for the Null value ..
ETC…………………
The date field we can check in different ways Possitive testing: first we enter the date in given format
Negative Testing: We enter the date in invalid format suppose if we enter date like 30/02/2006 it should display some error message and also we use to check the numeric or text

 

63. What kind of testing to be done in client server application and web application? Explain

Web Testing
During testing the websites the following scenarios should be considered.
Functionality
Performance
Usability
Server side interface
Client side compatibility
Security
Functionality:
In testing the functionality of the web sites the following should be tested.
Links
Internal links
External links
Mail links
Broken links
Forms
Field validation
Functional chart
Error message for wrong input
Optional and mandatory [...]
 

64. After insert the record in front-end, How will u check the back end by manually? Please explain?

Back end Checking is what we call DATABASE TESTING have to know the queries very well. With out queries we will not able to test data base testing. But as a tester we will responsible for test and [...]
 

65. Do write a separate test case for Regression Testing? If it is Yes, Explain How to write the Test case?

Well we are not going to right separate test cases for regression testing. We execute the same test cases on newly modified build which ever failed in previous.
OR
We are not going to write new test cases. We will select the some of the test cases from test case document, and execute the test cases to check for the bug fixes. Here we selecting the test cases such way that, all the basic functionality test cases, and affected bug test cases.

 

66. How to do the performance testing manually? Does u have a test case for that?

We can test it manually but we don’t get accurate result. We don’t have separate test cases exactly we will do it with tool i.e. Load runner, Act, Web load.

 

67. What is the difference between Functional testing and Functionality testing?

Functional Testing:
The portion of security testing in which the advertised features of a system are tested for correct operation.
OR
Quality assurance that a web site performs properly. All aspects of the user interface, navigation between pages and off-site, multilingual navigation, etc. are tested. Testing is required in all the current browsers and on the major operating systems and platforms.
OR
Functional testing is nothing but whether the given function is working or not as per the specifications
Ex: field validation, Navigation etc.
Functionality Testing is nothing but to check whether our application is equal to customer requirements or not
Here we will do lot more tests
Ex: Inter system Testing
Error handling testing
 

68. What is Middleware? Can anybody explain me?

In the computer industry, middleware is a general term for any programming that serves to “glue together” or mediate between two separate and often already existing programs. A common application of middleware is to allow programs written for access to a particular database to access other databases. The systematic tying together of disparate applications, often through the use of middleware, is known as enterprise application integration.
Or
Software that mediates between an applications program and a network. It manages the interaction between disparate applications across the heterogeneous computing platforms. The Object Request Broker (ORB), software that manages communication between objects, is an example of a
middleware program

 

69. Suppose u and your team member is there.your team member (friend) has raised one bug..u don’t no about application as well as that functionality of that application.your TL give the task u have to give the Severity & Priority..how can u give the Severity & Priority?

I am using Adhoc testing for this type of bugs depends upon past experience i am try to execute the testcase and write the severity and priority of that big.

 

70.  What is the difference between Integration Testing and System Testing?

Integration testing will do the completion of unit or module level Testing.
System testing is nothing but the application meets the Required specifications or not
Or
In integration testing individual components are combined with other components to make sure the necessary communications, links and data sharing occur properly.
It is not system testing because the components are not implemented in the operating environment.
System testing begins one the modules are integrated enough to perform tests in whole system environment.System testing can occur in parallel with integration test, especially with the top-down method.
 

71. How Could u Present Test Strategy for the Product Testing?

Test strategy means that it is a document prepared by quality analyst/project manager. it specifies how to approach to testing team depends upon requirement gatherings, risks involved in our company and customer requirements
 

72. You may undergone many projects. Do all the projects match up with customer’s expectations?

Any project never matches with 100% requirements. We consider only when it reaches to certain extent
 

73. On what basis you are fixing up the time for project completion?

Test strategy; Based on the test strategy and testing Approach

 

74. How u r breaking down the project among team members?

It can be depend on these following cases—-
1) Number of modules
2) Number of team members
3) Complexity of the Project
4) Time Duration of the project
5) Team member’s experience
etc……
 

75. Usually customers won’t give all the requirements. How will u manage & collect all the necessary information?

Sometimes customer may not produce all the requirements. At this situation Business analyst and project manager will use their experience which they handles this type of projects otherwise we will go through some reference sites where we will observe the functionality and they will prepare use cases and requirements.
or
I am agree with the above answer.
If we really face such a problem then it is better to get information from development team so that we can know the exact info Or else use Ad-hoc testing for the required job.
 

76. what are the Qualities needed by a software tester?

A software tester must have intent of showing the product is not working as specified.
Software tester have the basic attitude of showing the presence of errors. He must have perspective of customers i.e he has to use the system as he is the client of the system. He has to strive for the quality.
Or
Software Tester must has these qualities—
1)He/she must observe the problem from both the side say user and programmer.
2)Must has good under standing with other team members .
3)Able to understand programmers view.
4)Once start testing, do not put it remain.
5)First test requirements of the user.
6)Before start testing first analysis the project like ;
technology using in project, all the flow etc……

 

77. Did you write test cases of design phase?

Yes We can write test cases at the design phase
At the time of designing we should be ready with test cases
 

78. In Testing 10 cases you found 20 bugs then how will you know which bug is for which test case?

Each Bug Will Have a Unique Bug-ID which would be related to that particular Test Case. We also make use of the Matrix to keep track of bugs and test cases.

 

79. what is the path for test director,where the test cases are stored ?

c:\TDcomdir\TD_projectname\tests\test no
Usually test cases are stored in Test Plan in Test director
 

80. what is mean by test suite?

Test suit is “set of test cases”
Group of test cases is nothing but functional(+ve & -ve) and GUI

 

81. What is the diff. b/w Baseline and Traceability matrix?

Baseline : The point at which some deliverable produced during the software engineering process is put under formal change control
Traceability : Is used to check if some of the test cases are left out or not in Manual and automated testing.
Baseline is nothing but a software specification or functionality that is reviewed or accepted for development. Once the functionality is baseline, we can start developing of the functionality.
Where as a Traceability Matrix lists all the functionality or features and the test cases for each feature. By using the traceability matrix we can measure, when to stop testing of the project or application.
Generally Traceability Matrix contains:
1. UseCaseID(Functionality/Feature).
2. Description of the Feature.
3. Priority for the Feature.
4. TestCaseIDs for this Feature. (Once if the mapped testcases for each Feature meets Success criteria, then we can stop testing of the project)
5. In which phase is the Feature (Unit,Component,Integration,System)
 

82. what methodologies you are following?

Methodologies are considered in 2 accounts.
1) There are a few methodologies like : v-model,spiral (most common), waterfall, hybrid, prototype, etc depends on the company.
2) Depends on the clients and the requirements.
No. 2 is def related to no 1
Methodology means the way we are following while writing test cases . there are different ways like…
1. Functional Test cases
2. Equivalence Partitioning Test cases
3. Boundary value analysis
4. Cause Effect Graphing and Decision table
 

83. What makes a good test engineer?

A good test engineer has a ‘test to break’ attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful. Previous software development experience can be helpful as it provides a deeper understanding of the software development process, gives the tester an appreciation for the developers’ point of view, and reduce the learning curve in automated test tool programming. Judgement skills are needed to assess high-risk areas of an application on which to focus testing efforts when time is limited.
 

84. What makes a good Software QA engineer?

The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see ‘what’s missing’ is important for inspections and reviews.
 

85. What makes a good QA or Test manager?

A good QA, test, or QA/Test(combined) manager should:
• be familiar with the software development process
• be able to maintain enthusiasm of their team and promote a positive atmosphere, despite
• what is a somewhat ‘negative’ process (e.g., looking for or preventing problems)
• be able to promote teamwork to increase productivity
• be able to promote cooperation between software, test, and QA engineers
• have the diplomatic skills needed to promote improvements in QA processes
• have the ability to withstand pressures and say ‘no’ to other managers when quality is insufficient or QA processes are not being adhered to
• have people judgement skills for hiring and keeping skilled personnel
• be able to communicate with technical and non-technical people, engineers, managers, and customers.
• be able to run meetings and keep them focused
 

86. What’s the role of documentation in QA?

Critical. (Note that documentation can be electronic, not necessarily paper.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented. There should ideally be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible.

 

87. What’s the big deal about ‘requirements’?

One of the most reliable methods of insuring problems, or failure, in a complex software project is to have poorly documented requirements specifications. Requirements are the details describing an application’s externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, ‘user-friendly’ (too subjective). A testable requirement would be something like ‘the user must enter their previously-assigned password to access the application’. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task. (See the Bookstore section’s ‘Software Requirements Engineering’ category for books on Software Requirements.)
Care should be taken to involve ALL of a project’s significant ‘customers’ in the requirements process. ‘Customers’ could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren’t met should be included if possible.
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as ‘The product shall…..’. ‘Design’ specifications should not be confused with ‘requirements’; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
‘Agile’ methods such as XP use methods requiring close interaction and cooperation between programmers and customers/end-users to iteratively develop requirements. The programmer uses ‘Test first’ development to first create automated unit testing code, which essentially embodies the requirements.
 

88. What steps are needed to develop and run software tests?

The following are some of the steps to consider:
• Obtain requirements, functional design, and internal design specifications and other necessary documents
• Obtain budget and schedule requirements
• Determine project-related personnel and their responsibilities, reporting requirements, required standards and processes (such as release processes, change processes, etc.)
• Identify application’s higher-risk aspects, set priorities, and determine scope and limitations of tests
• Determine test approaches and methods - unit, integration, functional, system, load, usability tests, etc.
• Determine test environment requirements (hardware, software, communications, etc.)
• Determine testware requirements (record/playback tools, coverage analyzers, test tracking, problem/bug tracking, etc.)
• Determine test input data requirements
• Identify tasks, those responsible for tasks, and labor requirements
• Set schedule estimates, timelines, milestones
• Determine input equivalence classes, boundary value analyses, error classes
• Prepare test plan document and have needed reviews/approvals
• Write test cases
• Have needed reviews/inspections/approvals of test cases
• Prepare test environment and testware, obtain needed user manuals/reference documents/configuration guides/installation guides, set up test tracking processes, set up logging and archiving processes, set up or obtain test input data
• Obtain and install software releases
• Perform tests
• Evaluate and report results
• Track problems/bugs and fixes
• Retest as needed
• Maintain and update test plans, test cases, test environment, and testware through life cycle
 

89. What’s a ‘test plan’?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the ‘why’ and ‘how’ of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:
• Title
• Identification of software including version/release numbers
• Revision history of document including authors, dates, approvals
• Table of Contents
• Purpose of document, intended audience
• Objective of testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans, etc.
• Relevant standards or legal requirements
• Traceability requirements
• Relevant naming conventions and identifier conventions
• Overall software project organization and personnel/contact-info/responsibilties
• Test organization and personnel/contact-info/responsibilities
• Assumptions and dependencies
• Project risk analysis
• Testing priorities and focus
• Scope and limitations of testing
• Test outline - a decomposition of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Outline of data input equivalence classes, boundary value analysis, error classes
• Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems
• Test environment validity analysis - differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes
• Test data setup requirements
• Database setup requirements
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation - justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution - tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs
• Test site/location
• Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security, and licensing issues.
• Open issues
• Appendix - glossary, acronyms, etc.
(See the Bookstore section’s ‘Software Testing’ and ‘Software QA’ categories for useful books with more information.)
 

90. What’s a ‘test case’?

• A 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. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.
• Note that the process of developing test cases can help find problems in the requirements or design of an application, since it requires completely thinking through the operation of the application. For this reason, it’s useful to prepare test cases early in the development cycle if possible.
 

91. 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 (see the ‘Tools’ section for web resources with listings of such tools). The following are items to consider in the tracking process:
• Complete information such that developers can understand the bug, get an idea of it’s severity, and reproduce it if necessary.
• Bug identifier (number, ID, etc.)
• Current bug status (e.g., ‘Released for Retest’, ‘New’, etc.)
• The application name or identifier and version
• The function, module, feature, object, screen, etc. where the bug occurred
• Environment specifics, system, platform, relevant hardware specifics
• Test case name/number/identifier
• One-line bug description
• Full bug description
• Description of steps needed to reproduce the bug if not covered by a test case or if the developer doesn’t have easy access to the test case/test script/test tool
• Names and/or descriptions of file/data/messages/etc. used in test
• File excerpts/error messages/log file excerpts/screen shots/test tool logs that would be helpful in finding the cause of the problem
• Severity estimate (a 5-level range such as 1-5 or ‘critical’-to-’low’ is common)
• Was the bug reproducible?
• Tester name
• Test date
• Bug reporting date
• Name of developer/group/organization the problem is assigned to
• Description of problem cause
• Description of fix
• Code section/file/module/class/method that was fixed
• Date of fix
• Application version that contains the fix
• Tester responsible for retest
• Retest date
• Retest results
• Regression testing requirements
• Tester responsible for regression tests
• Regression testing results
A reporting or tracking process should enable notification of appropriate personnel at various stages. For instance, testers need to know when retesting is needed, developers need to know when bugs are found and how to get the needed information, and reporting/summary capabilities are needed for managers.
 

92. What is ‘configuration management’?

Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes. (See the ‘Tools’ section for web resources with listings of configuration management tools. Also see the Bookstore section’s ‘Configuration Management’ category for useful books with more information.)
 

93. What if the software is so buggy it can’t really be tested at all?

The best bet in this situation is for the testers to go through the process of reporting whatever bugs or blocking-type problems initially show up, with the focus being on critical bugs. Since this type of problem can severely affect schedules, and indicates deeper problems in the software development process (such as insufficient unit testing or insufficient integration testing, poor design, improper build or release procedures, etc.) managers should be notified, and provided with some documentation as evidence of the problem.
 

94. How can it be known when to stop testing?

This can be difficult to determine. Many modern software applications are so complex, and run in such an interdependent environment, that complete testing can never be done. Common factors in deciding when to stop are:
• Deadlines (release deadlines, testing deadlines, etc.)
• Test cases completed with certain percentage passed
• Test budget depleted
• Coverage of code/functionality/requirements reaches a specified point
• Bug rate falls below a certain level
• Beta or alpha testing period ends
 

95. What if there isn’t enough time for thorough testing?

Use risk analysis to determine where testing should be focused.
Since it’s rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects. This requires judgement skills, common sense, and experience. (If warranted, formal methods are also available.)
Considerations can include:
• Which functionality is most important to the project’s intended purpose?
• Which functionality is most visible to the user?
• Which functionality has the largest safety impact?
• Which functionality has the largest financial impact on users?
• Which aspects of the application are most important to the customer?
• Which aspects of the application can be tested early in the development cycle?
• Which parts of the code are most complex, and thus most subject to errors?
• Which parts of the application were developed in rush or panic mode?
• Which aspects of similar/related previous projects caused problems?
• Which aspects of similar/related previous projects had large maintenance expenses?
• Which parts of the requirements and design are unclear or poorly thought out?
• What do the developers think are the highest-risk aspects of the application?
• What kinds of problems would cause the worst publicity?
• What kinds of problems would cause the most customer service complaints?
• What kinds of tests could easily cover multiple functionalities?
• Which tests will have the best high-risk-coverage to time-required ratio?
 

96. What if the project isn’t big enough to justify extensive testing?

Consider the impact of project errors, not the size of the project. However, if extensive testing is still not justified, risk analysis is again needed and the same considerations as described previously in ‘What if there isn’t enough time for thorough testing?’ apply. The tester might then do ad hoc testing, or write up a limited test plan based on the risk analysis.
 

97. What can be done if requirements are changing continuously?

A common problem and a major headache.
• Work with the project’s stakeholders early on to understand how requirements might change so that alternate test plans and strategies can be worked out in advance, if possible.
• It’s helpful if the application’s initial design allows for some adaptability so that later changes do not require redoing the application from scratch.
• If the code is well-commented and well-documented this makes changes easier for the developers.
• Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes.
• The project’s initial schedule should allow for some extra time commensurate with the possibility of changes.
• Try to move new requirements to a ‘Phase 2' version of an application, while using the original requirements for the ‘Phase 1' version.
• Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application.
• Be sure that customers and management understand the scheduling impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, that’s their job.
• Balance the effort put into setting up automated testing with the expected effort required to re-do them to deal with changes.
• Try to design some flexibility into automated test scripts.
• Focus initial automated testing on application aspects that are most likely to remain unchanged.
• Devote appropriate effort to risk analysis of changes to minimize regression testing needs.
• Design some flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans)
• Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this entails).
 

98. What if the application has functionality that wasn’t in the requirements?

It may take serious effort to determine if an application has significant unexpected or hidden functionality, and it would indicate deeper problems in the software development process. If the functionality isn’t necessary to the purpose of the application, it should be removed, as it may have unknown impacts or dependencies that were not taken into account by the designer or the customer. If not removed, design information will be needed to determine added testing needs or regression testing needs. Management should be made aware of any significant added risks as a result of the unexpected functionality. If the functionality only effects areas such as minor improvements in the user interface, for example, it may not be a significant risk.
 

99. How can Software QA processes be implemented without stifling productivity?

By implementing QA processes slowly over time, using consensus to reach agreement on processes, and adjusting and experimenting as an organization grows and matures, productivity will be improved instead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, minimize paperwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or bureacracy, and in the short run things may slow down a bit. A typical scenario would be that more days of planning and development will be needed, but less time will be required for late-night bug-fixing and calming of irate customers.
 

100. What if an organization is growing so fast that fixed QA processes are impossible?

This is a common problem in the software industry, especially in new technology areas. There is no easy solution in this situation, other than:
• Hire good people
• Management should ‘ruthlessly prioritize’ quality issues and maintain focus on the customer
• Everyone in the organization should be clear on what ‘quality’ means to the customer
 

101. How does a client/server environment affect testing?

Client/server applications can be quite complex due to the multiple dependencies among clients, data communications, hardware, and servers. Thus testing requirements can be extensive. When time is limited (as it usually is) the focus should be on integration and system testing. Additionally, load/stress/performance testing may be useful in determining client/server application limitations and capabilities. There are commercial tools to assist with such testing. (See the ‘Tools’ section for web resources with listings that include these kinds of test tools.)
 

102.How can World Wide Web sites be tested?

Web sites are essentially client/server applications - with web servers and ‘browser’ clients. Consideration should be given to the interactions between html pages, TCP/IP communications, Internet connections, firewalls, applications that run in web pages (such as applets, javascript, plug-in applications), and applications that run on the server side (such as cgi scripts, database interfaces, logging applications, dynamic page generators, asp, etc.). Additionally, there are a wide variety of servers and browsers, various versions of each, small but sometimes significant differences between them, variations in connection speeds, rapidly changing technologies, and multiple standards and protocols. The end result is that testing for web sites can become a major ongoing effort. Other considerations might include:
• What are the expected loads on the server (e.g., number of hits per unit time?), and what kind of performance is required under such loads (such as web server response time, database query response times). What kinds of tools will be needed for performance testing (such as web load testing tools, other tools already in house that can be adapted, web robot downloading tools, etc.)?
• Who is the target audience? What kind of browsers will they be using? What kind of connection speeds will they by using? Are they intra- organization (thus with likely high connection speeds and similar browsers) or Internet-wide (thus with a wide variety of connection speeds and browser types)?
• What kind of performance is expected on the client side (e.g., how fast should pages appear, how fast should animations, applets, etc. load and run)?
• Will down time for server and content maintenance/upgrades be allowed? how much?
• What kinds of security (firewalls, encryptions, passwords, etc.) will be required and what is it expected to do? How can it be tested?
• How reliable are the site’s Internet connections required to be? And how does that affect backup system or redundant connection requirements and testing?
• What processes will be required to manage updates to the web site’s content, and what are the requirements for maintaining, tracking, and controlling page content, graphics, links, etc.?
• Which HTML specification will be adhered to? How strictly? What variations will be allowed for targeted browsers?
• Will there be any standards or requirements for page appearance and/or graphics throughout a site or parts of a site??
• How will internal and external links be validated and updated? how often?
• Can testing be done on the production system, or will a separate test system be required? How are browser caching, variations in browser option settings, dial-up connection variabilities, and real-world internet ‘traffic congestion’ problems to be accounted for in testing?
• How extensive or customized are the server logging and reporting requirements; are they considered an integral part of the system and do they require testing?
• How are cgi programs, applets, javascripts, ActiveX components, etc. to be maintained, tracked, controlled, and tested?
Some sources of site security information include the Usenet newsgroup ‘comp.security.announce’ and links concerning web site security in the ‘Other Resources’ section.
Some usability guidelines to consider - these are subjective and may or may not apply to a given situation (Note: more information on usability testing issues can be found in articles about web site usability in the ‘Other Resources’ section):
• Pages should be 3-5 screens max unless content is tightly focused on a single topic. If larger, provide internal links within the page.
• The page layouts and design elements should be consistent throughout a site, so that it’s clear to the user that they’re still within a site.
• Pages should be as browser-independent as possible, or pages should be provided or generated based on the browser-type.
• All pages should have links external to the page; there should be no dead-end pages.
• The page owner, revision date, and a link to a contact person or organization should be included on each page.
Many new web site test tools have appeared in the recent years and more than 280 of them are listed in the ‘Web Test Tools’ section.
 

103. Explain the components of a Test plan?

A software project test plan is a document that describes the objectives, scope, approach, and focus of a software testing effort. The process of preparing a test plan is a useful way to think through the efforts needed to validate the acceptability of a software product. The completed document will help people outside the test group understand the ‘why’ and ‘how’ of product validation. It should be thorough enough to be useful but not so thorough that no one outside the test group will read it.
A test plan states what the items to be tested are, at what level they will be tested, what sequence they are to be tested in, how the test strategy will be applied to the testing of each item, and describes the test environment.
A test plan should ideally be organisation wide, being applicable to all of organisations software developments.
The objective of each test plan is to provide a plan for verification, by testing the software, the software produced fulfils the functional or design statements of the appropriate software specification. In the case of acceptance testing and system testing, this generally means the Functional Specification.
The first consideration when preparing the Test Plan is who the intended audience is – i.e. the audience for a Unit Test Plan would be different, and thus the content would have to be adjusted accordingly.
You should begin the test plan as soon as possible. Generally it is desirable to begin the master test plan as the same time the Requirements documents and the Project Plan are being developed. Test planning can (and should) have an impact on the Project Plan. Even though plans that are written early will have to be changed during the course of the development and testing, but that is important, because it records the progress of the testing and helps planners become more proficient.
Qn. What to consider for the Test Plan:
1. Test Plan Identifier
2. References
3. Introduction
4. Test Items
5. Software Risk Issues
6. Features to be Tested
7. Features not to be Tested
8. Approach
9. Item Pass/Fail Criteria
10. Suspension Criteria and Resumption Requirements
11. Test Deliverables
12. Remaining Test Tasks
13. Environmental Needs
14. Staffing and Training Needs
15. Responsibilities
16. Schedule
17. Planning Risks and Contingencies
18. Approvals
19. Glossary
 

104. Which are the standards for Software test plans?

Several standards suggest what a test plan should contain, including the IEEE.
The standards are:
IEEE standards:
829-1983 IEEE Standard for Software Test Documentation
1008-1987 IEEE Standard for Software Unit Testing
1012-1986 IEEE Standard for Software Verification & Validation Plans
1059-1993 IEEE Guide for Software Verification & Validation Plans
The IEEE website is here:http://www.ieee.org
 

105. What’s the difference between load and stress testing?

1. Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts, etc.) needed to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). Bugs and failure modes discovered under stress testing may or may not be repaired depending on the application, the failure mode, consequences, etc. The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion.
2. Load testing is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads is in support of software reliability testing and in performance testing. The term “load testing” by itself is too vague and imprecise to warrant use. For example, do you mean representative load,” “overload,” “high load,” etc. In performance testing, load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or having, transactions suffer (application-specific) excessive delay.

 

106. During alpha testing why customer people are invited?

 becaz alpha testing related to acceptance testing, so, accepting testing is done in front of client or customer for there acceptance.