Ch. 6: Testing, Operation, and Evolution Flashcards
Software quality is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides …
… value.
What is the difference between software quality and software quality management?
Software quality is concerned with whether and how the system provides value by satisfying stakeholders’ needs. Software quality in the broadest sense denotes a property of software. The term quality management (QM) encompasses all organized measures and activities that serve to improve the quality of products, processes or services of any kind.
What are the main activities for quality management?
- Quality planning. This is the creation and documentation of the quality requirements together with the client.
- Quality control. This is monitoring, management, and control of activities for quality testing in the software development process.
- Quality assurance. This comes in the form of activities ensuring that defined quality requirements for products, processes, and services are met.
- Quality improvement. This is the evaluation of product and process data to improve the quality level.
What is the difference between constructive and analytical QM?
- In constructive quality management, all quality properties for products or processes are defined a priori (i.e., before creation) in order to avoid errors during software development and to guarantee or increase the quality of the artefacts created. The measures for constructive QM are technical, organizational and socio-psychological.
- In analytical quality management, measures are carried out ex post (i.e., after creation) to test and evaluate the current quality level of the test objects in order to systematically track down errors and determine their extent. It can be divided in static analysis (as part of a review or audit, the test item is analyzed, appraised, and examined. The information obtained is collated, if necessary, condensed into metrics or key figures, and evaluated) or dynamic analysis (the system under test (SUT) is executed with specific input values, and the result of the execution is evaluated.)
What is a test item?
All artifacts created in software engineering can be tested for compliance with quality requirements. This means that business requirements, technical specifications, architecture descriptions, and test cases can be tested in addition to the generated program code.
What are the typical test levels/stages in software development?
- Unit test
- Integration test
- System test
- Acceptance test
What is a unit test and what are some examples of it?
To enable the implementation of a software system by several software developers, the system is broken down into its logical components (units, modules, classes, and building blocks). Each component is implemented separately and incorporated into the system after completion (integrated). During, or after, the completion of a software component, it can be checked for compliance with specified requirements. The isolated testing of individual software components is called a unit test. Some examples of unit tests are as follows: premium calculation requires calculation of insurance premiums depending on the selected services, shopping cart requires calculation of the total of all items, address component requires the correct address for correspondence to be generated from the customer data
What is a (component) integration test? What is its relationship with drivers, stubs, SUT and dummies?
During, or after, the integration, the interaction of groups of components is tested in integration tests. The integration tests check whether the components work together as described in the specification.
Missing components are simulated by drivers and dummies so the test can be started. Software fragments that simulate the calling of other components are called drivers. Stubs, on the other hand, simulate components that are called by other components.
What is a system test?
After completion of the development work and the integration of all software components into a finished system, the system as a whole is tested with the system test. The aim of the system test is to check whether the system meets the specified requirements. In addition to the business requirements, the specified quality properties are also tested.
A major challenge in the system test is reproducing the customer’s productive environment as true to the original as possible. This includes the hardware and software environment in which the system is operated, the software systems with technical interfaces used by the system, realistic utilization, realistic user behavior, and real data records.
What is an acceptance test?
The last test level is the acceptance test, in which the finished system is handed over to the client, installed, and tested under the actual operating conditions. The acceptance test checks whether the system has the contractually agreed performance characteristics from the client’s point of view. The most important difference compared to the system test is that it is carried out by a different organization than the one that developed the system. A successful acceptance test is often the contractually agreed-upon requirement for invoicing.
What is the difference between traditional and Agile testing?
Traditional testing approaches perform the test levels one by one, based on a comprehensive project plan. Unfortunately, this is risky since it prevents early knowledge. In Agile approaches, knowledge is gained early in the software process through short feedback cycles. For this purpose, in contrast to traditional plan-driven approaches, only a small subset of the requirements are analyzed, specified, implemented, and tested by the development team from the start of the project.
What are the typical characteristics of Agile testing?
- Test as early as possible and as often as necessary.
- As many steps as possible are to be automated (except for exploratory tests by experts)
- Concentrate on testing the basic functionality and select other test types according to actual needs
- Working in an interdisciplinary manner means, depending on the type of test, also involving the developers.
What is a release plan during operation?
A release plan defines specific dates on which change requests and adjustments to software systems are implemented and put into operation. With the help of release planning, business departments, application development, and operations can internally plan and carry out the tasks required to import a new software version. This includes, in particular, quality assurance activities.
For large systems, between one and four release dates per year are common, and the specific dates are often based on industry-standard cycles or legal requirements.
What are the key issues with few major releases?
First, to accommodate all desired adjustments in a few releases, changes must be carried out at many points at the same time. However, large adjustments always involve a high risk of errors. Second, business departments are dissatisfied with the IT support, and important change requests are usually only implemented after weeks or months. But a slow IT response time can result in competitive disadvantages. Third, a long time to correct newly discovered security gaps or errors in the application leads to possible attack scenarios.
What is continuous integration during operation, delivery and DevOps?
Continuous integration is daily and weekly releases of software systems that can be created and automatically tested through automation and tool support. If all tests are completed positively, the adapted application can be deployed directly by setting up an automatic delivery.
The prerequisites for continuous integration and continuous delivery, however, are intensive cooperation between application development and operation. Such cooperative approaches are also called development operations (DevOps).
