Interaction and System Testing Concepts

• The chapter introduces software testing and software testing processes.
• After reading, it is expected to understand testing stages from development to acceptance testing by system customers,
• Have been introduced to techniques that help choose test cases for discovering program defects.
• Will understand test-first development, where tests are designed before writing code and run automatically.
• Will know about three distinct testing types: component, system, and release testing.
• Will understand distinctions between development testing and user testing.

Software testing

• Confirms a program functions as intended and identifies defects before deployment.
• Executes programs with artificial data to detect errors, anomalies, and gather insights on non-functional attributes.

Objectives

• Demonstrate software aligns with requirements for developers and customers via concrete tests.
• Reveals inputs or sequences causing incorrect, undesirable, or non-conforming software behavior attributable to defects ("bugs").
• Employs validation testing to confirm proper system performance using expected usage test cases.
• Uses defect testing to proactively identify defects, with test cases designed to expose vulnerabilities, not necessarily reflecting typical use.

Validation

• Involves testing to check whether a program will inevitably meet its intended requirements
• Are we building the right product?.

Verification

• Concerns checking that software meets specifications and delivers expected functionality, starting early.
• Are we building the product right?

Verification and Validation

• Aim to build confidence, ensuring a system is "fit for purpose," with appropriate reliability.
• Required confidence is tied with the system’s intent, the expectations by the users, plus the market trends

Testing Considerations

• Critical software demands high confidence levels
• Lower confidence may be expected due to prior experiences with buggy previous software
• The business environment must account for competing the price for the customer.

Software testing: advantages over testing

• May involve inspections and reviews, analyzing requirements, designs, code, and tests.
• Static V&V as the review doesn't require for the software to be executed

First Advantage

• Errors can "hide" others during testing, obscuring root causes. Inspections avoid execution interferences.
• Consequence, a inspection can discover system errors

Second Advantage

• Incomplete systems can be inspected without added costs, unlike custom test harnesses.
• This is in contrast to the expensive addition to developing the systems

Third Advantage

• Additionally, it is an inspection to consider broader quality attributes of a program, this also includes compliance with set standards
• Inflexibilities, poor algo's and programming which may be difficult for the program to update

Program Inspections Effectiveness

• Program inspections are shown to be effective, and more defect are discovered over testing the program
• Fagan (Fagan) reports over 60% of are picked using program inspections

Software testing

• Code analysis and testing are irreplaceable as inspections fail to replace testing
• Are ineffective when discovering defects for the interaction between different program aspects
• The testing and developing team usually cannot be put as a separate inspection team as possible team members may also be developers of te software

Software Testing abstract model

• Test data can be generated but test cases cannot
• Test execution with predicted restuls

Common test stages in commercial software

• Development Testing
• Release Testing
• User Testing

Test Planning

• Schedules and ressources all the activities in a testing phase
• Involves what is to be tested, the schedule which will be taken
• May also include systems tests to be run on software

Development testing

• System is tested during development in order to reveal bugs and defects
• Development process involves designers, and programmers

Release testing

• Different testing team is used to to test a version of the system before it is released to user with the sole purpose of checking that it has met all requirements

User testing

• This is where systems are being checked in their own environment
• Acceptance testing is where the customer takes it's their testing is whether the system meets the system requirements.
• Automated and manual processes

Manual testing

• Tester compares results and reports discrempancies to program developments

Automated testing

• Faster than manual testing specially relating to regression testing
• Check changes to the program

In automated testing, make use of automation framework such as JUnit

• Provides test classes to create all test cases
• They implement and report, often from a GUI (Graphical User Interface)

Development testing

• Incorporates all the activities carried out by the team which are developing the system including the testers
• Testers mainly consist of programmers who were developing the software

Debugging

• Debuggers use use they/theirs knowledge of the languages to locate and repair program errors
• They use programming, and test the code
• Interactive tools are implemented for program execution

Stages of development

• Unit Testing, where program units and object classes are tests, focussing on functionality
• Component Testing, where individual units are integrated

Important Info when tests design Test Cases

• Unit cases to show the component to be doing as it may be supposed to do - if there any defects these should be revealed by the cases
• There for 2 test cases these should reflect the component works - to showcase that the record exsists.

Strategies to choosing test cases

• Partiition Testing, where you identify groups of inputs
• Guideline testing, where you use previous errors made

Path testing

• Aims to excecise paths that can be expressed in a software program as to excecise everything that the source code can provide
• Independent paths are excecuted
• Whittaker's book includes general examples of test

Testing General Guidelines include

• inputs - to force the system to generate messages
• Design - for systems to overflow Repeat input of series of inputs numerous times Force invalid output to be generated force computation results to be small

Interface Errors Includes

• parameter - data is passed from 1 component to another - (methods in objects with interfaces) Shared memory interfaces for embedded where sensors create the processed Prodecduarl Interfaces Message interfaces

Interface errors can include

• Misuse - When calling comopentes which result to input of the wrong information
• MIsunderstanding - where input values may lead to issues. Timing errors in real time

General Guidelines Interface Includes

• examine - External components and provide a set of values to an interface
• Where pointers - a pass should always be completed along side a null process to counter issues
• Use Stress testing - for message systems in order to counter issues
• Where components - Interact by varying the order.

Systems testing

• Involves testing to integrate components to create systems with checks that they work together.
• Reusable and off shelf are the components and different team members

Features

• All systems have emergent behavior, which means to put components together
• Design and focus on the interactions to check for working system parts.
• Interaction to find misundestandings

Approaches to system testing

• Focuses on interactions, use case to test the system
• Test to implement those interactions.

Testing a method should result in a thread of methods:

• Satcomm:request-WeatherStation::reportweater->Commslink:Get(Summary)
• WeatherData:summarize

Key Points

• Input of a request should have the data - and a report created ultimately from checking reports
• To know what the new data contains

System testing policies should have to be be based on

• A policy that progran executes at least 1 execution
• They may need to be used on set experiences of focus and experience for 1 example
• All functions should be testes through menus.

Test Driven Development

• An approach to a program, where you interleave testing and code
• The code is incrementally

You start by identifying the increment of funcitonality

• write a test
• run the test along with other tests.
• implement the function once it has completed go to the next portion of the coding

Test Case - Design

• To design a system code test design
• Followed as a form of system, tests make can it easier to undestadn a system

Other aspects of TDD

System that has actually been tested. TDD are checked to have introduced new bugs .

• Simplified - Should have a test that needs to be checked and modified.
• System documentation - Tests acts as documentation that show the system should execute

TDD Benefit includes

• reduces the amount of code to be written this reduces - Regression - tests to be passed after changes have happened to the system
• The changes havent introduced new bugs.

More effective - test will give new functions by the codes value

• To check the code again
• TDD is most valuable when developing software this results to writting systems for systems to perform effectively

TDD should result to system testing

• That to say the system as tested that the project system hold well

Release Testing

• Checks a particular release of a system outside of the development.
• Normally includes customers and system users

2 Distinctions of System Testing-

• Testing development team - shouldnt be responsible for release.
• System testing with team to the system which should focus on bugs testing.

In short a goal to determine good use

• That a particaular system works well in the world
• Is usually a black box testing type

Requirements base for design

• A general concept for good requirements is code is testable that they check requirements have been satisfied for requirements based testing
• Systematic design is based on requirements

Scenario Testing of code for better design

• Caner has suggested a test should be a narrative story that is credible and fairly complex.

Test should Motivate ShareHolders that Relates

• Authentication - Downloading - - Homs - Schedule - Modification - Maintenance
• a tester will observe how the system behavior relates to issues

Performance testing

• Designed to be the best in terms of performance when released
• Is concercened with system requirements

User Testing

• Stage where users provide feedback

User testing 3 Types includes

• Alpha Testing
• Beta Testing -Acceptance Testing

Alpha Testing

Where team works closely with the software and early release of the software

Beta testing

Releases the software to a large group

• and gives and allow a set of users an experiecned app

Acceptance testing

• Where custumers decide what the software has decided to do
• And then check to determine - if the software will act as to support

Testing involves

• The processes of both verification,validation and assurance of software

Software evolution

• Explain , descripe , why evolution is so important

Large softwares can be used

• Infrastructure, military for 30 pluses years
• This systems must change for them to remain useful. Business changes and users set new data.

Systems evolution

• To enasure to be of value
• This evolution can result in major cost to an expense
• The system is part of an overall system
• Can be in the form of brownfeild which may determine situation

Requirement of Insralled Software Includes

• New releases of interrated regularly

Software engineering (The spiral)

• Software engineering (The spiral) - May result or create 1 release
• This process may become obvious.

The Spiral

• • may take 2 to 3 years - A model may apply when system continues responsability for changes - the methods and proccesses are implemented

Evolution

• The system custumers may not have paid a company
• It may not be transferred and system documetion may have not been passed to another
• To see the differences in how to make improvements
• Evolvement and servicing is then to be determined as shown in figure 9.2 (258)

After software has been succesfully used many changes are then in line

• Degrades the structure
• Transition point less expensive / cost effective so is moved for servicing

Systems

• Includes no set of data from software
• Dependant of type maintained and development. process and skills
• All changes result for what can the system changes
• In the propasil one changes have to get and should update systems which are used for new systems

However, the system relates to issues with 3 reasons

• system failure detect
• System operatiomg

Systems can face that need means that it is not needed to do

• A way to make some system
• to adapt as testing guidelines
• to adapt to issues where systems are too slow
• Agile test driven are then more useful when used

Where the development has used an agile approach

What can that to have been used in the form of a test

Large companies are comutizing their opperations in the 60's

• Systems has evolved but are still in use

Layed systems include hardware, software, libraries , business processes and it's relationships (FIG 9.7 / 263)

the layers to see

• hardware - suppport - application - Application data - Business proccesses ,
• business policies

System hardware is expensive , no longer reliable

• Most common simply repplaces systems with equivalents, that is to expense + risky
• Mangers try to lower those risks and do not face uncertainty of new software

Some of the key requirements

-rarely been a complete spec

• There is rarely a way if knowing how that it will be implemented in certain ways
• Busnesses processes use that to ineteract
• Business is more than to depend on it
• The software system more than likey to be repplaced a new system

Legacy systems , are older systems

• No longer used with new system development which then degradated .
• Implemented as the time goes along with multiple peopple responsiible

4 Main Key Points of a Business Plan for Design

Identify that test may involve State it and go

Some software parts are then to make the main purpose of the system

• That said how to provide data , the best in the type with a change and have to been used
• But may not of been changed since had never been in system of agility

This content covers interaction testing, use case-based testing, and the role of sequence diagrams. It also discusses user involvement in alpha and beta testing phases. The goal is to validate system behavior and identify integration issues.