Q. 1: Why a software needs to be tested?
Every software product needs to be tested since, the development 'process' is unable to produce defect free software. Even if the development process is able to produce a defect free software, we will not be able to know unless & until we test it. Without testing it, we shall not be having enough confidence that it will work.
Testing not only identifies and reports defect but also measures the quality of the product, which helps to decide whether to release the product, or not.
<<<<<< =================== >>>>>>
Q. 2: What is the reason that Software have Bugs?
Following factors contribute to the presence of bugs in the software applications.
1) Software development tools like visual tools, class libraries, compilers, scripting tools, etc. usually introduce their own bugs in the system.
2) To err is human. Likewise programmers do make mistakes while programming.
3) In fast-changing business environments continuously modified requirements are becoming a fact of life. Such frequent changes requested by the customer leads to errors in the application already nearing completion. Last minute design changes leads to many chaos like redesign of the whole system, rescheduling of engineers, scrapping of the work already completed, fresh requirements of compatible hardware etc.
4) A quickly written but poorly documented code is bound to have bugs. It becomes difficult to maintain and modify such code that is badly written or poorly documented.
- it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read').
5) When project deadlines come too close & time pressures come, mistakes are bound to come.
<<<<<< =================== >>>>>>
Q. 3: What is the difference between QA and Testing?
QA stands for "Quality Assurance", and focuses on "Prevention" of defects in the product being developed. It is associated with the "Process" and activities related to the Process Improvement. Quality Assurance measures the quality of the processes employed to create a quality product.
Whereas "Testing" refers to "Quality Control", and focuses on Detection of Defect and removal thereafter. Or Quality Control measures the quality of a product.
<<<<<< =================== >>>>>>
Q. 4: What is the difference between Software Testing and Debugging?
Testing is the process of locating or identifying the errors or bugs in a software system.
Whereas Debugging is the process of Fixing the identified Bugs. It involves a process of analyzing and rectifying the syntax errors, logic errors and all other types of errors identified during the process of testing.
<<<<<< =================== >>>>>>
Q. 5: What is the difference between a Bug and a Defect?
"Bug" is a problem or an error in the software code, which is found in the application during Testing. Bug is responsible for failure of the application to comply with the desired specifications.
Whereas "Defect" is problem reported by the customer during usage of the software application.
<<<<<< =================== >>>>>>
Q. 6: What is the difference between a Bug and an Enhancement?
"Bug" is a problem or an error in the software code, which is found in the application during Testing. Bug is responsible for failure of the application to comply with the desired specifications.
Whereas "Enhancement" is the additional feature or functionality found and added to the application as desired by the end user / real word customer or tester during the testing process.
<<<<<< =================== >>>>>>
Q. 7: What is the difference between Requirements & Specifications?
"Requirements" are statements given by the customer as to what needs to be achieved by the software system. Later on these requirements are converted into specifications which are nothing but feasible or implementable requirements.
Whereas "Specifications" are feasible requirements derived from various statements given by the customer. These are the starting point for the product development team.
<<<<<< =================== >>>>>>
Q. 8: What is the sequence of succession in STLC - Software Testing Life Cycle?
1) Test Planning
2) Test Analysis
3) Test Design
4) Construction and verification
5) Testing Cycles
6) Final Testing and Implementation and Post Implementation.
<<<<<< =================== >>>>>>
Q. 9: What is the difference between Verification and Validation?
"Verification" involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications to confirm whether items, processes, services, or documents conform to specified requirements or not. This can be done with the help of checklists, issues lists, walkthroughs, and inspection meetings. The purpose of verification is to determine whether the products of a given phase of the software development cycle fulfill the requirements established during the previous phase or not.
Whereas "Validation" is the determination of the correctness of the final program or software product produced from a development project with respect to the user needs and requirements. This involves actual testing of the product and takes place after verifications are completed.
"Software Verification" raises the question, "Are we building the Product Right?"; that is, does the software conform to its specification.
"Software Validation" raises the question, "Are we building the Right Product?"; that is, is the software doing what the user really requires.
<<<<<< =================== >>>>>>
Q. 10: What is the difference between a Test Plan and a Use Case?
"Test Plan" is a document describing an introduction to the client company, intended scope, overview of the application, test strategy, schedule of testing activities, roles and responsibilities, deliverables and milestones. It describes test items, features to be tested, testing tasks, details of the personnel performing each task and any risks requiring contingency planning.
Whereas a "Use Case" describes the process as to how an end user uses a specific functionality in the application. It is a summary of user actions and system response to the user actions. It contains the flows like typical flow, alternate flow and exceptional flow. It also contains pre condition and post condition.
Q. 11: What is the difference between Bug Priority & Bug Severity?
"Bug Priority" is the need on how urgently bug is needed to be fixed. It describes the importance of the bug. Bug priority may change according to the schedule of testing.
Whereas "Bug Severity" is the quantum of danger as to how badly the bug can harm the system. It describes as to how bad the bug is. Severity is a feature of constant nature associated with the bug.
<<<<<< =================== >>>>>>
Q. 12: What is difference between Waterfall Model and V Model?
"Waterfall Model" Is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. To follow the waterfall model, we proceed from one phase to the next in a purely sequential manner. In traditional waterfall model, testing comes at the fag end of the development process.
Whereas "V Model" or "Life Cycle Testing" involves carrying out verification of consistency, completeness and correctness of software at every stage of the development life cycle. It aims at catching the defects as early as possible and thus reduces the cost of fixing them. It involves continuously testing the system during all stages of the development process rather than just limiting testing to the last stage.
<<<<<< =================== >>>>>>
Q. 13: What are Baseline Documents?
Baseline documents are the documents, which have been approved by the customer and will not have any more changes. Baseline Documents cover all the details of the project and have undergone "walkthrough" process. Once a document is Base-lined it cannot be changed unless there is a change request duly approved by the customer. Service Level Agreement (SLA) & Business Requirement Documents (BRD) are the examples of Baseline Documents.
<<<<<< =================== >>>>>>
Q. 14: What is Defect Density?
"Defect Density" Is a software metric defined as: Total number of defects per LOC (lines of code). Alternatively It can be: Total number of defects per Size of the Project. Here the measure of "Size of the Project" can be number of Function Points, Number of Feature Points, number of Use Cases or KLOC (Kilo Lines of Code) etc
<<<<<< =================== >>>>>>
Q. 15: What is Negative Testing?
"Negative Testing" involves testing the application for failure like conditions. It involves testing the tool with improper inputs. For example entering the special characters in place of a phone number.
<<<<<< =================== >>>>>>
Q. 16: What is Incremental Integration Testing?
"Incremental Integration Testing" Involves continuous testing of an application while new functionality is simultaneously added. It requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed. This testing is done either by programmers or by testers.
<<<<<< =================== >>>>>>
Q. 17: What is the difference between Unit Testing, Component Testing and Integration Testing?
"Unit Testing" involves testing of individual programs, modules, or components to demonstrate that the program executes as per the specification and it validates the design and technical quality of the application. In Unit Testing, the Called Components (or Communicating Components) are replaced with Stubs, Simulators, or Trusted Components. Testing Stubs or Drivers are used to simulate the behavior of interfacing modules.
"Component Testing" is like "Unit Testing" with the difference that all Stubs and Simulators are replaced with the real objects. Here a Unit is a component, and integration of one or more such components is also a Component.
Whereas "Integration Testing" is the test process which begins after two or more programs components have been successfully unit tested. It is conducted by the development team to validate the interaction or communication/flow of information between the individual components that will be integrated.
<<<<<< =================== >>>>>>
Q. 18: What is the difference between Statement Coverage, Branch Coverage and Path Coverage?
"Statement Coverage" is a type of "White-Box Testing" technique, involving execution of all statements at least once. Statement coverage is a simple metric to calculate & measure the number of statements in a method or class which have been executed. Its key benefit is its ability to identify which blocks of code have not been executed.
"Branch Coverage" is an outcome of a decision, and measures the number of decision outcomes or branches, which have been tested. This takes a more in-depth view of the source code rather than a simple "Statement Coverage". A branch is an outcome of a decision. For example Boolean decisions like an "If - Statement", has two outcomes or branches (i.e. True and False).
Whereas "Path Coverage" is a method of testing which satisfies the coverage criteria through which the program is tested across each logical path. Usually, paths through the program are grouped into a finite set of classes and one path out of every class is tested. In Path Coverage flow of execution takes place from the start of a method to its exit. Path Coverage ensures that we test all decision outcomes independently of one another.
<<<<<< =================== >>>>>>
Q. 19: What is the difference between Ad-hoc Testing, Monkey Testing and Exploratory Testing?
"Ad-hoc Testing" is performed without any planning of process and without any documentation like Test Case or Test Scenarios. It involves test design and simultaneous test execution. For Ad-hoc testing the testers possess significant understanding of the software before testing it.
"Monkey Testing" is done with no specific test in mind. Here the monkey is the producer of any input data (which can be either a file data or can be an input device data). It involves pressing some keys randomly and checking whether the software fails or not.
Whereas "Exploratory Testing" involves simultaneous learning, test design and test execution. It is a type of "Ad-hoc Testing", but only difference is that in this case, the tester does not have much idea about the application & he explores the system in an attempt to learn the application and simultaneously test it.
<<<<<< =================== >>>>>>
Q. 20: What is the difference between System Testing and End-to-End Testing or E2E Testing?
"System Testing" falls within the scope of Black-Box testing and the tester requires no knowledge of the inner design of the code or logic. It is conducted on a complete / combined part of a system to verify that all-functional, information, structural and quality requirements as per the specifications have been met.
"End-to-End Testing" or "E2E Testing" is also quite similar to "System Testing". It involves testing of the application in a environment that simulates the real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems.
Q. 21: What is the difference between Alpha Testing and Beta Testing?
Typically a software product passes through two stages of testing before it is considered to be Final. The first stage is known as "Alpha Testing". It is often performed by potential users / customers or an independent test team at the developers' site. It is usually done when the development of the software product is nearing completion; minor design changes may still be made as a result of Alpha testing.
The second stage coming after alpha testing is known as "Beta Testing". Versions of the software, known as beta versions, are released to a limited audience outside of the programming team so that further evaluation by the users can reveal more faults or bugs in the product. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximum number of future users.
<<<<<< =================== >>>>>>
Q. 22: What is the difference between Static Testing and Dynamic Testing?
"Static Testing" involves testing activities performed without actually running the software. It includes Document review, code inspections, walkthroughs and desk checks etc.
Whereas "Dynamic Testing" Is used to describe the testing of the dynamic behavior of the software code. It involves actual compilation & running of the software by giving input values and checking if the output is as expected. It is the validation portion of Verification and Validation.
<<<<<< =================== >>>>>>
Q. 23: What is the difference between Smoke Testing and Sanity Testing?
The general term of "Smoke Testing" has come from leakage testing of sewers & drain lines involving blowing smoke into various parts of the sewer and drain lines to detect sources of unwanted leaks and sources of sewer odors. In relation to software testing field, Smoke testing Is a non-exhaustive software testing, ascertaining that the most crucial functions of the program work well, without getting bothered about finer details of it.
Whereas "Sanity Testing" Is an initial testing effort to find out if the new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing the systems every 5 minutes, bogging down the systems to a crawl, or destroying the databases, then it can be concluded that the software may not be in a 'sane' enough condition to warrant further testing in its current state.
<<<<<< =================== >>>>>>
Q. 24: What is the difference between Stress Testing and Load Testing?
"Stress Testing" is subjecting a system to an unreasonable load while denying it the adequate resources as required to process that load. The resources can be RAM, disc space, mips & interrupts etc. etc. The idea is to stress a system to the breaking point in order to find bugs, which will make the break potentially harmful. The system is not expected to process the overload without adequate resources, but to fail in a decent manner (e.g., failure without corrupting or losing data). In stress testing the load (incoming transaction stream) is often deliberately distorted so as to force the system into resource depletion.
Whereas "Load Testing" is a test performed with an objective to determine the maximum sustainable load which the system can handle. Load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or causing excessive delay in transactions.
<<<<<< =================== >>>>>>
Q. 25: What is the difference between Black Box Testing & White Box Testing?
First of all Black-Box and White-Box both are Test Design Methods.
"Black-Box" test design treats the system as a "Black-Box" (Wherein the tester can't see as to what is there inside the box). Hence we design the test cases in such a way that we pour the input from one end of the box and expect a certain specific output from the other end of the box. To run these test cases, the tester need not know as to how the input gets transformed to output inside the box. Black-Box is also known as Behavioral-Box or Functional-Box or Opaque-Box or Gray-Box or Closed-Box.
Whereas "White-Box" test design treats the system as a Transparent Box, which allows anyone to see inside the "Box". In White-Box the tester is able to see the process of transformation of an "Input" into an "Output" inside the box. Hence we design the test cases with a view to test the internal Logic, Paths or Branches of the box. White-Box is also known as Structural-Box or Glass-Box or Clear-Box or Translucent-Box test design
<<<<<< =================== >>>>>>
Q. 26: What is Quality?
Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things.
Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization's management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free.
<<<<<< =================== >>>>>>
Q. 27: What is an Inspection?
An inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3-10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting is documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection.
<<<<<< =================== >>>>>>
Q. 28: What is Good Design?
Design could mean to many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented.
<<<<<< =================== >>>>>>
Q. 29: What is Six Sigma?
"Six Sigma" means Six Standard Deviations from the mean. It is a methodology aimed to reduce defect levels below 3.4 Defects Per one Million Opportunities. Six Sigma approach improves the process performance, decreases variation and maintains consistent quality of the process output. This leads to defect reduction and improvement in profits, product quality and customer satisfaction.
<<<<<< =================== >>>>>>
Q. 30: What is difference between CMM and CMMI?
"CMM" means "Capability Maturity Model" developed by the Software Engineering Institute (SEI). It is a process capability maturity model, which aids in the definition and understanding of an organization's processes. CMM is intended as a tool for objectively assessing the ability of government contractors' processes to perform a contracted software project.
Whereas "CMMI" means "Capability Maturity Model Integration" & it has superceded CMM. The old CMM has been renamed to Software Engineering CMM (SE-CMM).
Q. 31: What is Verification?
Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings.
<<<<<< =================== >>>>>>
Q. 32: What is Validation?
Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.
<<<<<< =================== >>>>>>
Q. 33: What is 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 nderstand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.
<<<<<< =================== >>>>>>
Q. 34: What is a Walkthrough?
A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. It's the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individual's or team's competency.
<<<<<< =================== >>>>>>
Q. 35: What is Software Life Cycle?
Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out.
<<<<<< =================== >>>>>>
Q. 36: What is the Difference between STLC & SDLC?
STLC means " Software Testing Life Cycle". It starts with activities like : 1) Preparation of Requirements Document 2) Preparation of Test Plan 3) Preparation of Test Cases 4) Execution of Test Cases 5) Analysis of Bugs 6) Reporting of Bugs 7) Tracking of Bugs till closure.
Whereas SDLC means " Software Development Life Cycle" is a software development process, used by a systems analyst to develop an information system. It starts with activities like :
1) Project Initiation
2) Requirement Gathering and Documenting
3) Designing
4) Coding and Unit Testing
5) Integration Testing
6) System Testing
7) Installation and Acceptance Testing
8) Support or Maintenance
<<<<<< =================== >>>>>>
Q. 37: What are the various components of STLC?
Various components of "Software Testing Life Cycle" are
1) Requirements Document
2) Preparation of Test Plan
3) Preparation of Test Cases
4) Execution of Test Cases
5) Analysis of Bugs
6) Reporting of Bugs
7) Tracking of Bugs till closure
<<<<<< =================== >>>>>>
Q. 38: What is the Difference between Project and Product Testing?
If any organization is developing the application according to the client specification then it is called as project. Accordingly its testing is known as "Project Testing"
Whereas If any organization is developing the application and marketing it is called as product. Hence its testing is known as "Product Testing"
<<<<<< =================== >>>>>>
Q. 39: What are the Testing Types & Techniques?
Black Box and White Box are the most popular types of software testing. These are not the stand-alone testing techniques.
Testing techniques falling under the Black-Box type are: 1) Equivalence Partitioning 2) Boundary Value Analysis 3) Cause-Effect Graphing 4) Error-Guessing etc.
Whereas testing techniques falling under the White-Box type are:
1) Statement coverage
2) Decision coverage
3) Condition coverage
4) Decision-condition coverage
5) Multiple condition coverage
6) Basis Path Testing
7) Loop testing
8) Data flow testing etc.
<<<<<< =================== >>>>>>
Q. 40: How do you introduce a new software QA process?
It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required.
Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable.
Q. 41: What are the common problems coming across Software Development Process?
Common problems in software development process are:
1) Poor Projection of Requirements - Generally the users are not very clear in regards to their exact needs. Most of the specifications given to Software Development Outsourcing vendors are rough and very sketchy. Problems arise if the requirements are unclear, incomplete, too general, and not testable etc.
2) Miscommunication - Becomes the main cause of problem when the developers remain ignorant of the exact needs or expectations of the customer.
3) Unrealistic Schedules - Cause problems if too much work is crammed in too little time.
4) Inadequate Testing - Problems arise when the application has not been adequately tested before giving it to the customer & the customer complains after using it or when there is a systems crash.
<<<<<< =================== >>>>>>
Q. 42: What is the role of documentation in QA?
Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining
of documents and determining what document will have a particular piece of information.
<<<<<< =================== >>>>>>
Q. 43: What is Phase Containment and Defect Prevention?
Phase Containment is incorporating QA into all the phases of SDLC. It results in Defect Prevention. If QA team performs Requirements Review, Design Review and Code Review, defects would be few when actual application is tested. That means we have prevented many defects by performing reviews at each stage of SDLC.
<<<<<< =================== >>>>>>
Q. 44: Why a Developer should not Test?
Of course, a developer can test, but he can't be a good tester. If developers do the testing of their own work or of the work of their peers, then the following problems crop up
1) Misunderstandings of the requirements or specifications may go unnoticed.
2) Under a given time frame, usual tendency of developers is to allocate more time in improving the code or documentation rather than doing the testing of the code.
3) Developers have a tendency of being optimistic of producing a defect free code hence 'under' test the product.
4) Testing needs great skill, while an occasional tester with no prior training in testing techniques is no match to a trained bug hunter whose sole activity is testing.
5) To uncover large number of bugs, tester needs to be aggressive. Whereas developer will not be aggressive, if he is testing his own product.
Testers are rewarded if they hunt lots of bugs, developers are rewarded if the product they developed has less number of bugs and this balance can only be maintained if the separate teams exist for testing and development.
<<<<<< =================== >>>>>>
Q. 45: Out of Tester & Developer, who is most appropriate to do Unit Testing & Integration Testing?
Of course Developers.
It is quite difficult for a tester to do unit testing and integration testing since it involves in-depth understanding of the code. Hence developers should do the unit testing and integration testing. While doing unit testing & integration testing, a few misinterpretation of requirements might escape from the notice of the developer, but its better to test with these issues rather than not testing at all.
For a better success, code developed by one developer, then his peer should do the unit test.
<<<<<< =================== >>>>>>
Q. 46: What are the important Check Points for Installation Testing?
Installation testing of a new software application should be able to check points like
1) To check previously installed versions of the software or its dependent software or patches like previously installed Service Packs. This is to ensure that older version of the software should not get installed over the newer version.
2) Installer should be able to define Default Installation Path like "C:\Program Files\."
3) Installer should be able to allow the user to install the new software at a location different from the Default Installation Path.
4) To check if the product can be installed "Over the Network"
5) Installation should start automatically when the CD is inserted in the CD drive.
6) Software Remove / Repair options should be available to the user while using the Installer.
7) While uninstalling the software, check that all the registry keys, files, Dll, shortcuts, active X components are removed from the system.
8) To check if the product can be installed without Administrative Privileges (login as guest).
9) To check if the product can be installed on different operating systems.
10) To check if the product can be installed on a system having non-compliant configuration like with less Memory / RAM / Hard Disc Capacity.
<<<<<< =================== >>>>>>
Q. 47: What is Installation Testing?
"Installation Testing" is performed to ensure that all the Installed features and options of the software are functioning properly. Its main objective is to verify that all necessary components of the application are actually installed or not without missing out any component.
<<<<<< =================== >>>>>>
Q. 48: Do automated testing tools make testing easier?
For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile. A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret. If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then retested by just playing back the recorded actions and compared to the logged results in order to check effects of the change.
<<<<<< =================== >>>>>>
Q. 49: What should be done after a bug is found?
When a bug is found, it needs to be communicated and assigned to developers that can fix it.
After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere.
If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea
of its severity, reproduce it and fix it.
<<<<<< =================== >>>>>>
Q. 50: What to do when software is full of bugs & it can't be tested at all?
In this situation the best solution is to have test engineers go through the process of reporting whatever bugs or 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, Insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.
Every software product needs to be tested since, the development 'process' is unable to produce defect free software. Even if the development process is able to produce a defect free software, we will not be able to know unless & until we test it. Without testing it, we shall not be having enough confidence that it will work.
Testing not only identifies and reports defect but also measures the quality of the product, which helps to decide whether to release the product, or not.
<<<<<< =================== >>>>>>
Q. 2: What is the reason that Software have Bugs?
Following factors contribute to the presence of bugs in the software applications.
1) Software development tools like visual tools, class libraries, compilers, scripting tools, etc. usually introduce their own bugs in the system.
2) To err is human. Likewise programmers do make mistakes while programming.
3) In fast-changing business environments continuously modified requirements are becoming a fact of life. Such frequent changes requested by the customer leads to errors in the application already nearing completion. Last minute design changes leads to many chaos like redesign of the whole system, rescheduling of engineers, scrapping of the work already completed, fresh requirements of compatible hardware etc.
4) A quickly written but poorly documented code is bound to have bugs. It becomes difficult to maintain and modify such code that is badly written or poorly documented.
- it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read').
5) When project deadlines come too close & time pressures come, mistakes are bound to come.
<<<<<< =================== >>>>>>
Q. 3: What is the difference between QA and Testing?
QA stands for "Quality Assurance", and focuses on "Prevention" of defects in the product being developed. It is associated with the "Process" and activities related to the Process Improvement. Quality Assurance measures the quality of the processes employed to create a quality product.
Whereas "Testing" refers to "Quality Control", and focuses on Detection of Defect and removal thereafter. Or Quality Control measures the quality of a product.
<<<<<< =================== >>>>>>
Q. 4: What is the difference between Software Testing and Debugging?
Testing is the process of locating or identifying the errors or bugs in a software system.
Whereas Debugging is the process of Fixing the identified Bugs. It involves a process of analyzing and rectifying the syntax errors, logic errors and all other types of errors identified during the process of testing.
<<<<<< =================== >>>>>>
Q. 5: What is the difference between a Bug and a Defect?
"Bug" is a problem or an error in the software code, which is found in the application during Testing. Bug is responsible for failure of the application to comply with the desired specifications.
Whereas "Defect" is problem reported by the customer during usage of the software application.
<<<<<< =================== >>>>>>
Q. 6: What is the difference between a Bug and an Enhancement?
"Bug" is a problem or an error in the software code, which is found in the application during Testing. Bug is responsible for failure of the application to comply with the desired specifications.
Whereas "Enhancement" is the additional feature or functionality found and added to the application as desired by the end user / real word customer or tester during the testing process.
<<<<<< =================== >>>>>>
Q. 7: What is the difference between Requirements & Specifications?
"Requirements" are statements given by the customer as to what needs to be achieved by the software system. Later on these requirements are converted into specifications which are nothing but feasible or implementable requirements.
Whereas "Specifications" are feasible requirements derived from various statements given by the customer. These are the starting point for the product development team.
<<<<<< =================== >>>>>>
Q. 8: What is the sequence of succession in STLC - Software Testing Life Cycle?
1) Test Planning
2) Test Analysis
3) Test Design
4) Construction and verification
5) Testing Cycles
6) Final Testing and Implementation and Post Implementation.
<<<<<< =================== >>>>>>
Q. 9: What is the difference between Verification and Validation?
"Verification" involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications to confirm whether items, processes, services, or documents conform to specified requirements or not. This can be done with the help of checklists, issues lists, walkthroughs, and inspection meetings. The purpose of verification is to determine whether the products of a given phase of the software development cycle fulfill the requirements established during the previous phase or not.
Whereas "Validation" is the determination of the correctness of the final program or software product produced from a development project with respect to the user needs and requirements. This involves actual testing of the product and takes place after verifications are completed.
"Software Verification" raises the question, "Are we building the Product Right?"; that is, does the software conform to its specification.
"Software Validation" raises the question, "Are we building the Right Product?"; that is, is the software doing what the user really requires.
<<<<<< =================== >>>>>>
Q. 10: What is the difference between a Test Plan and a Use Case?
"Test Plan" is a document describing an introduction to the client company, intended scope, overview of the application, test strategy, schedule of testing activities, roles and responsibilities, deliverables and milestones. It describes test items, features to be tested, testing tasks, details of the personnel performing each task and any risks requiring contingency planning.
Whereas a "Use Case" describes the process as to how an end user uses a specific functionality in the application. It is a summary of user actions and system response to the user actions. It contains the flows like typical flow, alternate flow and exceptional flow. It also contains pre condition and post condition.
Q. 11: What is the difference between Bug Priority & Bug Severity?
"Bug Priority" is the need on how urgently bug is needed to be fixed. It describes the importance of the bug. Bug priority may change according to the schedule of testing.
Whereas "Bug Severity" is the quantum of danger as to how badly the bug can harm the system. It describes as to how bad the bug is. Severity is a feature of constant nature associated with the bug.
<<<<<< =================== >>>>>>
Q. 12: What is difference between Waterfall Model and V Model?
"Waterfall Model" Is a sequential software development model (a process for the creation of software) in which development is seen as flowing steadily downwards (like a waterfall) through the phases of requirements analysis, design, implementation, testing (validation), integration, and maintenance. To follow the waterfall model, we proceed from one phase to the next in a purely sequential manner. In traditional waterfall model, testing comes at the fag end of the development process.
Whereas "V Model" or "Life Cycle Testing" involves carrying out verification of consistency, completeness and correctness of software at every stage of the development life cycle. It aims at catching the defects as early as possible and thus reduces the cost of fixing them. It involves continuously testing the system during all stages of the development process rather than just limiting testing to the last stage.
<<<<<< =================== >>>>>>
Q. 13: What are Baseline Documents?
Baseline documents are the documents, which have been approved by the customer and will not have any more changes. Baseline Documents cover all the details of the project and have undergone "walkthrough" process. Once a document is Base-lined it cannot be changed unless there is a change request duly approved by the customer. Service Level Agreement (SLA) & Business Requirement Documents (BRD) are the examples of Baseline Documents.
<<<<<< =================== >>>>>>
Q. 14: What is Defect Density?
"Defect Density" Is a software metric defined as: Total number of defects per LOC (lines of code). Alternatively It can be: Total number of defects per Size of the Project. Here the measure of "Size of the Project" can be number of Function Points, Number of Feature Points, number of Use Cases or KLOC (Kilo Lines of Code) etc
<<<<<< =================== >>>>>>
Q. 15: What is Negative Testing?
"Negative Testing" involves testing the application for failure like conditions. It involves testing the tool with improper inputs. For example entering the special characters in place of a phone number.
<<<<<< =================== >>>>>>
Q. 16: What is Incremental Integration Testing?
"Incremental Integration Testing" Involves continuous testing of an application while new functionality is simultaneously added. It requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed. This testing is done either by programmers or by testers.
<<<<<< =================== >>>>>>
Q. 17: What is the difference between Unit Testing, Component Testing and Integration Testing?
"Unit Testing" involves testing of individual programs, modules, or components to demonstrate that the program executes as per the specification and it validates the design and technical quality of the application. In Unit Testing, the Called Components (or Communicating Components) are replaced with Stubs, Simulators, or Trusted Components. Testing Stubs or Drivers are used to simulate the behavior of interfacing modules.
"Component Testing" is like "Unit Testing" with the difference that all Stubs and Simulators are replaced with the real objects. Here a Unit is a component, and integration of one or more such components is also a Component.
Whereas "Integration Testing" is the test process which begins after two or more programs components have been successfully unit tested. It is conducted by the development team to validate the interaction or communication/flow of information between the individual components that will be integrated.
<<<<<< =================== >>>>>>
Q. 18: What is the difference between Statement Coverage, Branch Coverage and Path Coverage?
"Statement Coverage" is a type of "White-Box Testing" technique, involving execution of all statements at least once. Statement coverage is a simple metric to calculate & measure the number of statements in a method or class which have been executed. Its key benefit is its ability to identify which blocks of code have not been executed.
"Branch Coverage" is an outcome of a decision, and measures the number of decision outcomes or branches, which have been tested. This takes a more in-depth view of the source code rather than a simple "Statement Coverage". A branch is an outcome of a decision. For example Boolean decisions like an "If - Statement", has two outcomes or branches (i.e. True and False).
Whereas "Path Coverage" is a method of testing which satisfies the coverage criteria through which the program is tested across each logical path. Usually, paths through the program are grouped into a finite set of classes and one path out of every class is tested. In Path Coverage flow of execution takes place from the start of a method to its exit. Path Coverage ensures that we test all decision outcomes independently of one another.
<<<<<< =================== >>>>>>
Q. 19: What is the difference between Ad-hoc Testing, Monkey Testing and Exploratory Testing?
"Ad-hoc Testing" is performed without any planning of process and without any documentation like Test Case or Test Scenarios. It involves test design and simultaneous test execution. For Ad-hoc testing the testers possess significant understanding of the software before testing it.
"Monkey Testing" is done with no specific test in mind. Here the monkey is the producer of any input data (which can be either a file data or can be an input device data). It involves pressing some keys randomly and checking whether the software fails or not.
Whereas "Exploratory Testing" involves simultaneous learning, test design and test execution. It is a type of "Ad-hoc Testing", but only difference is that in this case, the tester does not have much idea about the application & he explores the system in an attempt to learn the application and simultaneously test it.
<<<<<< =================== >>>>>>
Q. 20: What is the difference between System Testing and End-to-End Testing or E2E Testing?
"System Testing" falls within the scope of Black-Box testing and the tester requires no knowledge of the inner design of the code or logic. It is conducted on a complete / combined part of a system to verify that all-functional, information, structural and quality requirements as per the specifications have been met.
"End-to-End Testing" or "E2E Testing" is also quite similar to "System Testing". It involves testing of the application in a environment that simulates the real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems.
Q. 21: What is the difference between Alpha Testing and Beta Testing?
Typically a software product passes through two stages of testing before it is considered to be Final. The first stage is known as "Alpha Testing". It is often performed by potential users / customers or an independent test team at the developers' site. It is usually done when the development of the software product is nearing completion; minor design changes may still be made as a result of Alpha testing.
The second stage coming after alpha testing is known as "Beta Testing". Versions of the software, known as beta versions, are released to a limited audience outside of the programming team so that further evaluation by the users can reveal more faults or bugs in the product. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximum number of future users.
<<<<<< =================== >>>>>>
Q. 22: What is the difference between Static Testing and Dynamic Testing?
"Static Testing" involves testing activities performed without actually running the software. It includes Document review, code inspections, walkthroughs and desk checks etc.
Whereas "Dynamic Testing" Is used to describe the testing of the dynamic behavior of the software code. It involves actual compilation & running of the software by giving input values and checking if the output is as expected. It is the validation portion of Verification and Validation.
<<<<<< =================== >>>>>>
Q. 23: What is the difference between Smoke Testing and Sanity Testing?
The general term of "Smoke Testing" has come from leakage testing of sewers & drain lines involving blowing smoke into various parts of the sewer and drain lines to detect sources of unwanted leaks and sources of sewer odors. In relation to software testing field, Smoke testing Is a non-exhaustive software testing, ascertaining that the most crucial functions of the program work well, without getting bothered about finer details of it.
Whereas "Sanity Testing" Is an initial testing effort to find out if the new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing the systems every 5 minutes, bogging down the systems to a crawl, or destroying the databases, then it can be concluded that the software may not be in a 'sane' enough condition to warrant further testing in its current state.
<<<<<< =================== >>>>>>
Q. 24: What is the difference between Stress Testing and Load Testing?
"Stress Testing" is subjecting a system to an unreasonable load while denying it the adequate resources as required to process that load. The resources can be RAM, disc space, mips & interrupts etc. etc. The idea is to stress a system to the breaking point in order to find bugs, which will make the break potentially harmful. The system is not expected to process the overload without adequate resources, but to fail in a decent manner (e.g., failure without corrupting or losing data). In stress testing the load (incoming transaction stream) is often deliberately distorted so as to force the system into resource depletion.
Whereas "Load Testing" is a test performed with an objective to determine the maximum sustainable load which the system can handle. Load is varied from a minimum (zero) to the maximum level the system can sustain without running out of resources or causing excessive delay in transactions.
<<<<<< =================== >>>>>>
Q. 25: What is the difference between Black Box Testing & White Box Testing?
First of all Black-Box and White-Box both are Test Design Methods.
"Black-Box" test design treats the system as a "Black-Box" (Wherein the tester can't see as to what is there inside the box). Hence we design the test cases in such a way that we pour the input from one end of the box and expect a certain specific output from the other end of the box. To run these test cases, the tester need not know as to how the input gets transformed to output inside the box. Black-Box is also known as Behavioral-Box or Functional-Box or Opaque-Box or Gray-Box or Closed-Box.
Whereas "White-Box" test design treats the system as a Transparent Box, which allows anyone to see inside the "Box". In White-Box the tester is able to see the process of transformation of an "Input" into an "Output" inside the box. Hence we design the test cases with a view to test the internal Logic, Paths or Branches of the box. White-Box is also known as Structural-Box or Glass-Box or Clear-Box or Translucent-Box test design
<<<<<< =================== >>>>>>
Q. 26: What is Quality?
Quality software is software that is reasonably bug-free, delivered on time and within budget, meets requirements and expectations and is maintainable. However, quality is a subjective term. Quality depends on who the customer is and their overall influence in the scheme of things.
Customers of a software development project include end-users, customer acceptance test engineers, testers, customer contract officers, customer management, the development organization's management, test engineers, testers, salespeople, software engineers, stockholders and accountants. Each type of customer will have his or her own slant on quality. The accounting department might define quality in terms of profits, while an end-user might define quality as user friendly and bug free.
<<<<<< =================== >>>>>>
Q. 27: What is an Inspection?
An inspection is a formal meeting, more formalized than a walkthrough and typically consists of 3-10 people including a moderator, reader (the author of whatever is being reviewed) and a recorder (to make notes in the document). The subject of the inspection is typically a document, such as a requirements document or a test plan. The purpose of an inspection is to find problems and see what is missing, not to fix anything. The result of the meeting is documented in a written report. Attendees should prepare for this type of meeting by reading through the document, before the meeting starts; most problems are found during this preparation. Preparation for inspections is difficult, but is one of the most cost-effective methods of ensuring quality, since bug prevention is more cost effective than bug detection.
<<<<<< =================== >>>>>>
Q. 28: What is Good Design?
Design could mean to many things, but often refers to functional design or internal design. Good functional design is indicated by software functionality can be traced back to customer and end-user requirements. Good internal design is indicated by software code whose overall structure is clear, understandable, easily modifiable and maintainable; is robust with sufficient error handling and status logging capability; and works correctly when implemented.
<<<<<< =================== >>>>>>
Q. 29: What is Six Sigma?
"Six Sigma" means Six Standard Deviations from the mean. It is a methodology aimed to reduce defect levels below 3.4 Defects Per one Million Opportunities. Six Sigma approach improves the process performance, decreases variation and maintains consistent quality of the process output. This leads to defect reduction and improvement in profits, product quality and customer satisfaction.
<<<<<< =================== >>>>>>
Q. 30: What is difference between CMM and CMMI?
"CMM" means "Capability Maturity Model" developed by the Software Engineering Institute (SEI). It is a process capability maturity model, which aids in the definition and understanding of an organization's processes. CMM is intended as a tool for objectively assessing the ability of government contractors' processes to perform a contracted software project.
Whereas "CMMI" means "Capability Maturity Model Integration" & it has superceded CMM. The old CMM has been renamed to Software Engineering CMM (SE-CMM).
Q. 31: What is Verification?
Verification ensures the product is designed to deliver all functionality to the customer; it typically involves reviews and meetings to evaluate documents, plans, code, requirements and specifications; this can be done with checklists, issues lists, walkthroughs and inspection meetings.
<<<<<< =================== >>>>>>
Q. 32: What is Validation?
Validation ensures that functionality, as defined in requirements, is the intended behavior of the product; validation typically involves actual testing and takes place after verifications are completed.
<<<<<< =================== >>>>>>
Q. 33: What is 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 nderstand the why and how of product validation. It should be thorough enough to be useful, but not so thorough that none outside the test group will be able to read it.
<<<<<< =================== >>>>>>
Q. 34: What is a Walkthrough?
A walkthrough is an informal meeting for evaluation or informational purposes. A walkthrough is also a process at an abstract level. It's the process of inspecting software code by following paths through the code (as determined by input conditions and choices made along the way). The purpose of code walkthroughs is to ensure the code fits the purpose. Walkthroughs also offer opportunities to assess an individual's or team's competency.
<<<<<< =================== >>>>>>
Q. 35: What is Software Life Cycle?
Software life cycle begins when a software product is first conceived and ends when it is no longer in use. It includes phases like initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, re-testing and phase-out.
<<<<<< =================== >>>>>>
Q. 36: What is the Difference between STLC & SDLC?
STLC means " Software Testing Life Cycle". It starts with activities like : 1) Preparation of Requirements Document 2) Preparation of Test Plan 3) Preparation of Test Cases 4) Execution of Test Cases 5) Analysis of Bugs 6) Reporting of Bugs 7) Tracking of Bugs till closure.
Whereas SDLC means " Software Development Life Cycle" is a software development process, used by a systems analyst to develop an information system. It starts with activities like :
1) Project Initiation
2) Requirement Gathering and Documenting
3) Designing
4) Coding and Unit Testing
5) Integration Testing
6) System Testing
7) Installation and Acceptance Testing
8) Support or Maintenance
<<<<<< =================== >>>>>>
Q. 37: What are the various components of STLC?
Various components of "Software Testing Life Cycle" are
1) Requirements Document
2) Preparation of Test Plan
3) Preparation of Test Cases
4) Execution of Test Cases
5) Analysis of Bugs
6) Reporting of Bugs
7) Tracking of Bugs till closure
<<<<<< =================== >>>>>>
Q. 38: What is the Difference between Project and Product Testing?
If any organization is developing the application according to the client specification then it is called as project. Accordingly its testing is known as "Project Testing"
Whereas If any organization is developing the application and marketing it is called as product. Hence its testing is known as "Product Testing"
<<<<<< =================== >>>>>>
Q. 39: What are the Testing Types & Techniques?
Black Box and White Box are the most popular types of software testing. These are not the stand-alone testing techniques.
Testing techniques falling under the Black-Box type are: 1) Equivalence Partitioning 2) Boundary Value Analysis 3) Cause-Effect Graphing 4) Error-Guessing etc.
Whereas testing techniques falling under the White-Box type are:
1) Statement coverage
2) Decision coverage
3) Condition coverage
4) Decision-condition coverage
5) Multiple condition coverage
6) Basis Path Testing
7) Loop testing
8) Data flow testing etc.
<<<<<< =================== >>>>>>
Q. 40: How do you introduce a new software QA process?
It depends on the size of the organization and the risks involved. For large organizations with high-risk projects, a serious management buy-in is required and a formalized QA process is necessary. For medium size organizations with lower risk projects, management and organizational buy-in and a slower, step-by-step process is required.
Generally speaking, QA processes should be balanced with productivity, in order to keep any bureaucracy from getting out of hand. For smaller groups or projects, an ad-hoc process is more appropriate. A lot depends on team leads and managers, feedback to developers and good communication is essential among customers, managers, developers, test engineers and testers. Regardless the size of the company, the greatest value for effort is in managing requirement processes, where the goal is requirements that are clear, complete and testable.
Q. 41: What are the common problems coming across Software Development Process?
Common problems in software development process are:
1) Poor Projection of Requirements - Generally the users are not very clear in regards to their exact needs. Most of the specifications given to Software Development Outsourcing vendors are rough and very sketchy. Problems arise if the requirements are unclear, incomplete, too general, and not testable etc.
2) Miscommunication - Becomes the main cause of problem when the developers remain ignorant of the exact needs or expectations of the customer.
3) Unrealistic Schedules - Cause problems if too much work is crammed in too little time.
4) Inadequate Testing - Problems arise when the application has not been adequately tested before giving it to the customer & the customer complains after using it or when there is a systems crash.
<<<<<< =================== >>>>>>
Q. 42: What is the role of documentation in QA?
Documentation plays a critical role in QA. QA practices should be documented, so that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals should all be documented. Ideally, there should be a system for easily finding and obtaining
of documents and determining what document will have a particular piece of information.
<<<<<< =================== >>>>>>
Q. 43: What is Phase Containment and Defect Prevention?
Phase Containment is incorporating QA into all the phases of SDLC. It results in Defect Prevention. If QA team performs Requirements Review, Design Review and Code Review, defects would be few when actual application is tested. That means we have prevented many defects by performing reviews at each stage of SDLC.
<<<<<< =================== >>>>>>
Q. 44: Why a Developer should not Test?
Of course, a developer can test, but he can't be a good tester. If developers do the testing of their own work or of the work of their peers, then the following problems crop up
1) Misunderstandings of the requirements or specifications may go unnoticed.
2) Under a given time frame, usual tendency of developers is to allocate more time in improving the code or documentation rather than doing the testing of the code.
3) Developers have a tendency of being optimistic of producing a defect free code hence 'under' test the product.
4) Testing needs great skill, while an occasional tester with no prior training in testing techniques is no match to a trained bug hunter whose sole activity is testing.
5) To uncover large number of bugs, tester needs to be aggressive. Whereas developer will not be aggressive, if he is testing his own product.
Testers are rewarded if they hunt lots of bugs, developers are rewarded if the product they developed has less number of bugs and this balance can only be maintained if the separate teams exist for testing and development.
<<<<<< =================== >>>>>>
Q. 45: Out of Tester & Developer, who is most appropriate to do Unit Testing & Integration Testing?
Of course Developers.
It is quite difficult for a tester to do unit testing and integration testing since it involves in-depth understanding of the code. Hence developers should do the unit testing and integration testing. While doing unit testing & integration testing, a few misinterpretation of requirements might escape from the notice of the developer, but its better to test with these issues rather than not testing at all.
For a better success, code developed by one developer, then his peer should do the unit test.
<<<<<< =================== >>>>>>
Q. 46: What are the important Check Points for Installation Testing?
Installation testing of a new software application should be able to check points like
1) To check previously installed versions of the software or its dependent software or patches like previously installed Service Packs. This is to ensure that older version of the software should not get installed over the newer version.
2) Installer should be able to define Default Installation Path like "C:\Program Files\."
3) Installer should be able to allow the user to install the new software at a location different from the Default Installation Path.
4) To check if the product can be installed "Over the Network"
5) Installation should start automatically when the CD is inserted in the CD drive.
6) Software Remove / Repair options should be available to the user while using the Installer.
7) While uninstalling the software, check that all the registry keys, files, Dll, shortcuts, active X components are removed from the system.
8) To check if the product can be installed without Administrative Privileges (login as guest).
9) To check if the product can be installed on different operating systems.
10) To check if the product can be installed on a system having non-compliant configuration like with less Memory / RAM / Hard Disc Capacity.
<<<<<< =================== >>>>>>
Q. 47: What is Installation Testing?
"Installation Testing" is performed to ensure that all the Installed features and options of the software are functioning properly. Its main objective is to verify that all necessary components of the application are actually installed or not without missing out any component.
<<<<<< =================== >>>>>>
Q. 48: Do automated testing tools make testing easier?
For larger projects, or ongoing long-term projects, they can be valuable. But for small projects, the time needed to learn and implement them is usually not worthwhile. A common type of automated tool is the record/playback type. For example, a test engineer clicks through all combinations of menu choices, dialog box choices, buttons, etc. in a GUI and has an automated testing tool record and log the results. The recording is typically in the form of text, based on a scripting language that the testing tool can interpret. If a change is made (e.g. new buttons are added, or some underlying code in the application is changed), the application is then retested by just playing back the recorded actions and compared to the logged results in order to check effects of the change.
<<<<<< =================== >>>>>>
Q. 49: What should be done after a bug is found?
When a bug is found, it needs to be communicated and assigned to developers that can fix it.
After the problem is resolved, fixes should be re-tested. Additionally, determinations should be made regarding requirements, software, hardware, safety impact, etc., for regression testing to check the fixes didn't create other problems elsewhere.
If a problem-tracking system is in place, it should encapsulate these determinations. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, will give the team complete information so developers can understand the bug, get an idea
of its severity, reproduce it and fix it.
<<<<<< =================== >>>>>>
Q. 50: What to do when software is full of bugs & it can't be tested at all?
In this situation the best solution is to have test engineers go through the process of reporting whatever bugs or 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, Insufficient integration testing, poor design, improper build or release procedures, managers should be notified and provided with some documentation as evidence of the problem.
I just came here to know the details about software, Post in question and answer format helped me to get all answers what there were in my mind.
ReplyDeleteInterview Questions