What's the difference between System testing and Acceptance testing?Acceptance testing checks the system against the "Requirements." It is similar to System testing in that the whole system is checked but the important difference is the change in focus:
System testing checks that the system that was specified has been delivered. Acceptance testing checks that the system will deliver what was requested. The customer should always do Acceptance testing and not the developer.The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgement. This testing is more about ensuring that the software is delivered as defined by the customer. It's like getting a green light from the customer that the software meets expectations and is ready to be used.
What kind of input do we need from the end user to begin proper testing?
The product has to be used by the user. He is the most important person as he has more interest than
anyone else in the project.
From the user we need the following data:
The first thing we need is the acceptance test plan from the end user. The acceptance test defines the
entire test which the product has to pass so that it can go into production.We also need the requirement document from the customer. In normal scenarios the customer never writes a formal document until he is really sure of his requirements. But at some point the customer should sign saying yes this is what he wants.
The customer should also define the risky sections of the project. For instance, in a normal accounting
project if a voucher entry screen does not work that will stop the accounting functionality completely.
But if reports are not derived the accounting department can use it for some time. The customer is the
right person to say which section will affect him the most. With this feedback the testers can prepare a
proper test plan for those areas and test it thoroughly.The customer should also provide proper data for testing. Feeding proper data during testing is very important. In many scenarios testers key in wrong data and expect results which are of no interest to the customer.
Can you explain the workbench concept?
In order to understand testing methodology we need to understand the workbench concept. A Workbench is a way of documenting how a specific activity has to be performed.
There are five tasks for every workbench:
Input: Every task needs some defined input and entrance criteria. So for every workbench we need defined
inputs. Input forms the first steps of the workbench.
Execute: This is the main task of the workbench which will transform the input into the expected output.
Check: Check steps assure that the output after execution meets the desired result.
Production output: If the check is right the production output forms the exit criteria of the workbench.
Rework: During the check step if the output is not as desired then we need to again start from the execute step.
Can you explain the concept of defect cascading?
Defect cascading is a defect which is caused by another defect. One defect triggers the other defect. For
instance, in the accounting application shown here there is a defect which leads to negative taxation. So
the negative taxation defect affects the ledger which in turn affects four other modules.
Can you explain cohabiting software?
When we install the application at the end client it is very possible that on the same PC other applications
also exist. It is also very possible that those applications share common DLLs, resources etc., with your application. There is a huge chance in such situations that your changes can affect the cohabiting software. So the best practice is after you install your application or after any changes, tell other application owners to run a test cycle on their application.
What is the difference between pilot and beta testing?
The difference between pilot and beta testing is that pilot testing is nothing but actually using the product
(limited to some users) and in beta testing we do not input real data, but it's installed at the end customer
to validate if the product can be used in production.
What are the different strategies for roll out to end users?
There are four major ways of rolling out any project:
Pilot: The actual production system is installed at a single or limited number of users.
Pilot basically means that the product is actually rolled out to limited users for real work.
Gradual Implementation: In this implementation we ship the entire product to the limited users
or all users at the customer end. Here, the developers get instant feedback from the recipients
which allow them to make changes before the product is available. But the downside is that developers
and testers maintain more than one version at one time.
Phased Implementation: In this implementation the product is rolled out to all users in incrementally.
That means each successive rollout has some added functionality. So as new functionality comes in, new
installations occur and the customer tests them progressively. The benefit of this kind of rollout is
that customers can start using the functionality and provide valuable feedback progressively. The only
issue here is that with each rollout and added functionality the integration becomes more complicated.
Parallel Implementation: In these types of rollouts the existing application is run side by side with
the new application. If there are any issues with the new application we again move back to the old a
pplication. One of the biggest problems with parallel implementation is we need extra hardware, software,
and resources.
What is the difference between latent and masked defects?
A latent defect is an existing defect that has not yet caused a failure because the sets of conditions
were never met.
A masked defect is an existing defect that hasn't yet caused a failure just because another defect has
prevented that part of the code from being executed.
Can you explain calibration?
It includes tracing the accuracy of the devices used in the production, development and testing. Devices
used must be maintained and calibrated to ensure that it is working in good order.
What's the difference between alpha and beta testing?
Alpha and beta testing has different meanings to different people. Alpha testing is the acceptance testing
done at the development site. Some organizations have a different visualization of alpha testing. They consider alpha testing as testing which is conducted on early, unstable versions of software.
On the contrary beta testing is acceptance testing conducted at the customer end.
How does testing affect risk?
A risk is a condition that can result in a loss. Risk can only be controlled in different scenarios but not
eliminated completely. A defect normally converts to a risk.
What is coverage and what are the different types of coverage techniques?
Coverage is a measurement used in software testing to describe the degree to which the source code is tested. There are three basic types of coverage techniques as
Statement coverage: This coverage ensures that each line of source code has been executed and tested.
Decision coverage: This coverage ensures that every decision (true/false) in the source code has been executed and tested.
Path coverage: In this coverage we ensure that every possible route through a given part of code is executed and tested.
A defect which could have been removed during the initial stage is removed in a later stage. How does this affect cost?
If a defect is known at the initial stage then it should be removed during that stage/phase itself rather than at
some later stage. It's a recorded fact that if a defect is delayed for later phases it proves more costly and design phase is the most cost effective, while a defect removed during maintenance is 20 times costlier than during the requirement and design phases.
For instance, if a defect is identified during requirement and design we only need to change the documentation, but if identified during the maintenance phase we not only need to fix the defect, but also change our test plans, do regression testing, and change all documentation. This is why a defect should be identified/removed in earlier phases and the testing department should be involved right from the requirement phase and not after the execution phase.
No comments:
Post a Comment