unit 6

• Although a software system can only be tested holistically for compliance with the necessary requirements after completion, the risk of waiting until the end of implementation to perform quality assurance activities is too high. Therefore, quality assurance measures in software engineering are carried out alongside all other activities.
• After installation, acceptance, and provisioning of the software system, the application operation ensures that the system is available to users and that it is protected against failure and threat scenarios.
• The application operation itself has no explicit constructive or quality assurance function in the development of a software system. However, when the software is handed over, it must be guaranteed that it can be executed in accordance with the company's specifications and guidelines.
• The software must also be able to be taken over into operation by the department responsible for information technology (IT) operations after development and testing.
• After the first release of a software system, adjustments and changes must be made to the system over the entire period of use. If the system is to be expanded by technical functions, or if technical functions are changed, these are activities of software evolution.
• This unit will introduce the core concepts within software testing, including software quality and quality management.
• Software quality


  The degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value
• Decisions about the quality of software can only be made on the basis of the specification ("stated needs").
• In practice, the perceived quality of software is primarily determined by whether the customer determines that the software meets their actual requirements ("implied needs").
• Since many requirements are often only recognized during software development, with a view to customer satisfaction, it must be continuously ensured that the set of specified requirements also includes the set of actual requirements.
• In addition to determining the quality of a software system as a whole, the quality can also be determined for the artifacts (software models, requirements, architectures, documents, software components) generated in the course of software development.
• Quality management (QM)


  All organized measures that serve to improve the quality of products, processes, or services of any kind
• Since it is too risky in software engineering to wait to determine the software quality until implementation is complete, the quality of software fragments that have already been created is determined during the development process.
• The implementation is directly dependent on the specifications and decisions made in the requirements engineering, specification and architecture activities, so errors in the specification, and the architectural definition spread to the implementation. Therefore, these artifacts must also be included in quality management in software engineering.
• Typical activities in quality management

  • Quality planning
  • Quality control
  • Quality assurance
  • Quality improvement
• 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 artifacts created
• 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
• Measures for constructive quality management

  • Technical (e.g., use of modeling languages, tools, development environments)
  • Organizational (e.g., guidelines, standards, templates, checklists)
  • Socio-psychological (e.g., training, working atmosphere, team building activities)
• 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.
• Dynamic analysis


  The system under test (SUT) is executed with specific input values, and the result of the execution is evaluated.
• In principle, all artifacts created in software engineering can be tested for compliance with quality requirements.
• Test levels


  • Unit test
  • Component integration test
  • System test
  • Acceptance test
• Unit test


  The isolated testing of individual software components
• Component integration test


  The interaction of groups of components is tested
• Drivers


  Software fragments that simulate the calling of other components
• Stubs


  Components that simulate components that are called by other components
• System test


  The system as a whole is tested to check whether it meets the specified requirements
• Acceptance test


  The finished system is handed over to the client, installed, and tested under the actual operating conditions
• Early knowledge, which is valuable for Agile approaches in general, is gained 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.
• Scrum teams can, for example, derive test cases directly from the sprint backlog in order to test the planned partial result (called "increment" in Scrum).
• Because Agile teams are typically composed in an interdisciplinary manner, they can cover this range of tests well.
• Acceptance test


  Contractually agreed upon requirement for invoicing
• Agile Testing


  • Early knowledge gained through short feedback cycles
  • Only a small subset of requirements analysed, specified, implemented, and tested from start
  • Test cases derived directly from sprint backlog
  • Abstraction level of test cases based on requirement abstraction level
  • Interdisciplinary team covers range of tests
• Agile testing


  1. Test as early as possible and as often as necessary

  2. Automate as many steps as possible

  3. Concentrate on testing basic functionality first

  4. Involve developers depending on test type
• Agile testing


  • Relocation of test effort (less manual, more automated unit tests)
  • Shifting test tasks to developers
  • Tester having disciplined work organization
  • Well thought-out test data management
  • Integration of development and operation
  • Integration of user in tests
• Enterprise information systems


  • Business-critical operating and production resources
  • Changes must be planned and implemented with utmost care
  • Technical and process-related dependencies on other systems
• Release planning


  1. Specific dates for change requests and software system adjustments

  2. Quality assurance activities included
• Release plan


  Defines dates for implementing change requests and software adjustments
• For large systems, 1-4 release dates per year are common, based on industry-standard cycles or legal requirements
• Challenges of clear release plan with 4 releases per year: Accommodate all changes in few releases, high risk of errors, less time for installations, slow IT response time, long time to correct security gaps or bugs