ISTQB Foundation Level Exam Crash Course Part-4
This is Part 4 of 35 containing 5 Questions (Q. 16 to 20) with detailed explanation as expected in ISTQB Foundation Level Exam Latest Syllabus updated in 2011
Deep study of these 175 questions shall be of great help in getting success in ISTQB Foundation Level Exam
Q. 16: What is Acceptance Testing?
The step after the system testing is usually acceptance testing. The purpose of acceptance testing is to provide the end users with confidence that the system will function according to their expectations. Referring once more to the V-model, acceptance testing will be carried out using the requirement specification as a basis for test.
The requirement specification is typically the first document to be written, after initial capture of the user requirement. An example of a requirement could be to create a website that enables users to buy
airline tickets online.The subsequent documentation (functional, technical and program specifications) will expand on this in increasing levels of detail, in order to facilitate development of the system, as seen earlier. Thus, it is paramount that these requirements are fully documented and correct before further development activity is carried out. Again, this is the V-model approach. We know that having such an ideal set of requirements is a rare thing. This does not mean, however, that the need for correctness and completeness should be ignored.
As for system testing, no reference is made to the code from which the system is constructed.
The test bases for acceptance testing can include:
1) User requirements
2) System requirements
3) Use cases
4) Business processes
5) Risk analysis reports
The test objects for system testing can include:
1) The fully integrated system
2) Forms and reports produced by the system.
Unlike system testing, however, the testing conducted here should be independent of any other testing carried out. Its key purpose is to demonstrate system conformance to, for example, the customer requirements and operational and maintenance processes. For instance, acceptance testing may assess the system’s readiness for deployment and use.
Acceptance testing is often the responsibility of the customers or users of a system, although other project team members may be involved as well.
<<<<<< =================== >>>>>>
Q. 17: What are the different forms of Acceptance Testing?
Typical forms of acceptance testing include the following:
1) User acceptance testing: Testing by user representatives to check that the system meets their business needs. This can include factory acceptance testing, where the system is tested by the users before moving it to their own site. Site acceptance testing could then be performed by the users at their own site.
2) Operational acceptance testing: Often called operational readiness testing. This involves checking that the processes and procedures are in place to allow the system to be used and maintained. This can include checking:
# Back Facilities # Procedure for disaster recovery # Training for end users # Maintenance procedures # Data load and migration tasks # Security procedures
3) Contract and Regulation Acceptance Testing: Operational acceptance testing: Often
# Contract acceptance testing: Sometimes the criteria for accepting a system are documented in a contract. Testing is then conducted to check that these criteria have been met, before the system is accepted.
# Regulation acceptance testing: in some industries, systems must meet governmental, legal or safety standards. Examples of these are the defence, banking and pharmaceutical industries.
4) Alpha and Beta Testing:
# Alpha testing takes place at the developer’s site – the operational system is tested whilst still at the developer’s site by internal staff, before release to external customers. Note that testing here is still independent of the development team.
# Beta testing takes place at the customer’s site – the operational system is tested by a group of customers, who use the product at their own locations and provide feedback, before the system is released. This is often called �field testing�.
<<<<<< =================== >>>>>>
Q. 18: What are the different types or categories of Testing?
Types of testing fall into the following categories:
1) Functional Testing: The functional testing looks at the specific functionality of a system, such as searching for flights on a website, or perhaps calculating employee pay correctly using a payroll system. Note that security testing is a functional test type. Another type of functional testing is interoperability testing – this evaluates the capability of the system to interact with other specified components.
Functional testing is also called specification-based testing: testing against a specification.
2) Non-Functional Testing: This is where the behavioral aspects of the system are tested. As for functional testing, these requirements are usually documented in a functional specification. Thus, mainly black-box testing techniques are used for this type of testing.
These tests can be referenced against a quality model, such as the one defined in ISO 9126 Software Engineering – Software Product Quality. Note that a detailed understanding of this standard is not required for the exam.
3) Structural Testing: This type of testing is used to measure how much testing has been carried out. In functional testing, this could be the number of functional requirements tested against the total number of requirements.
In structural testing, we change our measure to focus on the structural aspects of the system. This could be the code itself, or an architectural definition of the system. We want to do this to check the thoroughness of the testing carried out on the system that has actually been built. A common measure is to look at how much of the actual code that has been written has been tested.
The structural testing can be carried out at any test level.
<<<<<< =================== >>>>>>
Q. 19: Describe different type of testing related to changes
We carry out testing at the different stages in the development life cycle. At any level of testing, it can be expected that defects will be discovered. When these are found and fixed, the quality of the system being delivered can be improved.
After a defect is detected and fixed the changed software should be retested to confirm that the problem has been successfully removed. This is called retesting or confirmation testing. Note that when the developer removes the defect, this activity is called debugging, which is not a testing activity. Testing finds a defect, debugging fixes it.
The unchanged software should also be retested to ensure that no additional defects have been introduced as a result of changes to the software. This is called regression testing. Regression testing should also be carried out if the environment has changed.
Regression testing involves the creation of a set of tests, which serve to demonstrate that the system works as expected. These would be run again many times over a testing project, when changes are made, as discussed above. This repetition of tests makes regression testing suitable for automation in many cases.
<<<<<< =================== >>>>>>
Q. 20: Describe Maintenance Testing
For many projects the system is eventually released into the live environment. Hopefully, once deployed, it will be in service as long as intended, perhaps for years or decades.
During this deployment, it may become necessary to change the system. Changes may be due to the following reasons:
1) Additional features being required.
2) The system being migrated to a new operating platform.
3) The system being retired – data may need to be migrated or archived.
4) Planned upgrade to COTS -based systems.
5) New faults being found requiring fixing (these can be �hot fixes�).
Once changes have been made to the system, they will need to be tested (retesting), and it also will be necessary to conduct regression testing to ensure that the rest of the system has not been adversely affected by the changes. Testing that takes place on a system which is in operation in the live environment is called maintenance testing.
When changes are made to migrate from one platform to another, the system should also be tested in its new environment. When migration includes data being transferred in from another application, then conversion testing also becomes necessary.
All changes must be tested, and, ideally, all of the system should be subject to regression testing. In practice, this may not be feasible or cost-effective. An understanding of the parts of the system that could be affected by the changes could reduce the amount of regression testing required. Working this out is termed impact analysis, i.e. analyzing the impact of the changes on the system.
Impact analysis can be difficult for a system that has already been released. This is because the specifications may be out of date (or non-existent), and/or the original development team may have moved on to other projects, or left the organization altogether.
Part – 5 of the Crash Course – ISTQB Foundation Exam
Access The Full Database of Crash Course Questions for ISTQB Foundation Level Certification
An expert on R&D, Online Training and Publishing. He is M.Tech. (Honours) and is a part of the STG team since inception.