Testing Throughout the Software Life Cycle Section 2

Testing Throughout the Software Life Cycle Section 2 ISTQB Foundation

Summary What you will learn in this second section • Software Testing Methodologies. Waterfall, V-Model and Iterative • What is unity or component system testing • What is integration, system and acceptance means • Differences between functional and non-functional testing • What is a structural testing • Change-related testing • Maintenance testing

Life Cycle Models Sequential Life Cycle Models Iterative-Incremental (Agile) Life Cycle Models In sequential models the entire system is built in a single sequence of activities that successively define, build test and implement the software. In iterative-incremental development models, systems are built in a series of short development cycles which deliver working systems in a number of separate increments that can later be integrated together. Examples are waterfall, Structured System Analysis and Design Method (SSADM), the V -model and the W-model. Agile development is a term for several methodologies including Scrum, Crystal Clear and many more. Each has its specific approach but all share the common vision and core values as continuous planning, testing, integration, for the project and software. Is adaptable and they all focus on empowering people to collaborate and make decisions together quickly and effectively.

Life Cycle Models Testing does not exist in isolation. Test activities are related to software development activities. Different development life cycle models, methodologies, need different approaches to testing. There are many system development life cycle models, which fall into two main categories: Sequential Iterative-Incremental (Agile) • • Waterfall V-Model Rapid Application Development (RAD) Rational Unified Process (PUP) Extreme Programming (XP) Scrum Dynamic Systems Development Method (DSDM) Atern

Waterfall Model Life cycle through which a project goes. Sequential or linear design process. Testing is carried out at the end. Initiation Analysis Design This is the traditional approach to systems development. Each stage is quite separate, carried out by specialists, and each must complete before the next begins. Each stage outputs a deliverable which is input to the next. All testing is done at the end, after the code is developed. Therefore this model does not allow for early testing, as recommended in the principles earlier. Build Test Deploy

V-model mi c Product Ready St c ati Mini cycles show the purpose of each test level, and show the importance of catching defects early. Requirements Dy na Although the similarities with the sequential method as in waterfall, the V-model includes a number of different test levels, each correspond to a development stage. This allows testing activities to be fully integrated with other tasks in the project life cycle. The V-model also shows how static testing can be carried out during the development stages, before the code is written. Documents are identified which can be reviewed to trap faults as early as possible. Coding

V-model There’s many variations of V-model, with slightly different number and description of levels. The ISTQB Foundation exam syllabus refers to a model with 4 test levels: - Component testing Integration testing System testing Acceptance testing Then goes on to describe two different integration test levels, so in this demonstration, I’ll describe a V-model with 5 levels of testing instead: - Component testing Component integration testing System integration testing Acceptance testing

V-model Acceptance Testing --------------------------- Interface Specifications System Integration Testing ---------------------- System Specifications ---------------- Component Specification Dy na c ati St Design Specification Component Integration Testing --------------Source Code System Testing mic Business Requirements Component Testing Object Code

Iterative-Incremental (Agile) Models A software design model where the stages are ongoing opposite to the waterfall method. Testing occurs as part of each sprint. Agile development is an umbrella term for several iterative and incremental software development methodologies. Most popular agile methodologies are: Scrum, Crystal Clear, XP (Extreme Programming), DSDM and FDD. Typically, development teams work closely together with fewer formal documents and more emphasis on face-to-face communication. This minimises overall risk and allows the project to adapt to changes quickly.

Iterative-Incremental (Agile) Models Reqts Test Code timebox ----------------------------------- Test Design Code timebox ---------------------------------------------------------------------- Reqts ----------------------------------- Increment 3 Increment 2 Increment 1

Unity or Component Testing Tests individual units or pieces of code for a system. The aim of component testing is to determine whether an individual function works properly in isolation before integrate with the system then combine it with other components. Component testing is different from all later test stages as it is not done by testers but by the developers of the code, in the developer’s environment using IDE, debugging tools and test frameworks incorporating stubs and drivers. As an example, in the V-model method Component Specification and Component Testing level unity is where is located at. Code Review Code Unit A Component Code Unit B Or Subsystem Code Unit C Component test

It should not test the functionality within the component (by this time it has already been done by component testing), only focusing how it communicate with each other. It is normally performed by developers in the development environment. V-model document: Design Specification and Component A Component B Integration Testing ion rat g eg Int estin T Performed to ensure that two modules operate together correctly. The aim is to test all major interfaces and interactions between the individual components, and to uncover communication failures between components. Int eg Te ratio stin n g Integration Testing Component C

System Testing Tests the various parts of the applications work together within a system work. This test the behaviour of an end-to-end integrated system as defined by the scope of a development project. It is usually conducted by independent testers. The test environment should be as close to the production environment as possible in order to minimise the risk of environment-specific failures not System Testing Inputs Outcome System testing may include tests based on risks, requirements, business processes, use cases or high level text descriptions, models or system behaviour, interactions with the operating system and system resources. Requirements Events

System Integration Testing Most computer system will link with other systems, either internally to the organisation of externally. The purpose of system integration testing is to expose defects in the interfaces and interactions between systems and between hardware and software. It is normally carried out once system testing is complete by independent system testers in a near live environment. When testing links with external systems, testers may control only their own side of the interface, which might be considered as a risk, as their test system may be linked to an external production Other current systems system. System Under Test Internet Workflow implementation of business processes may involve a series of systems, where cross platform issues may be significant. External systems or databases Legacy systems Central database

Acceptance Testing To determine whether the product indeed satisfies its specifications and user story requirements. The purpose of acceptance testing is to establish confidence and main focus is ensuring is fit for purpose, not finding defects. Acceptance can be carried out by real business users or by independent testers representing users. Acceptance testing is normally the final stage of testing before deployment. V-model document: Business requirement and Acceptance testing. DEV QA UAT PROD Can also be called as UAT (User Acceptance Testing)

Functional Testing what the system does, based on analysis of specified requirements. Functional testing is concerned with WHAT the system must do to achieve its objectives, as defined in business requirements, functional specifications, use cases, business process models, etc. It considers the external behaviour of the software, hence is black-box testing. Functional testing is usually associated with data manipulation, such as input, validation, processing, storage and output. Black Box Testing Input Black box Output

Non-Functional Testing how well the system meets the required software characteristics such as performance and usability. It tests the attributes of a system that do not relate to functionality. It is concerned with how well a system works. It considers constraints on the functionality on how, how often, who or where a function can take place. Non-functional testing includes: Black Box Testing Input Black box Output • • Performance Load Stress Usability Accessibility Maintainability Reliability Portability

Structural Testing that takes into account the internal mechanism [structure] of a system or component. Types include branch testing, path testing, statement testing. Structural testing, it is sometimes called glass box, usually follows specification-based tests to ensure thoroughness of coverage. Full structured testing is very thorough but time-consuming, and is often mandated in safety-critical system such as life support machines. White Box Testing White box Input Output Coverage measurement applies at all levels, as any aspect of a system which can be represented in a structural diagram can be used as the basis for structural testing. • • • Program code design: coverage of statement, decisions, paths Component hierarchy diagram: coverage of component interfaces Web pages structure: coverage of page navigation

Change-related Testing a system following modifications or corrections; includes re-testing and regression testing. This is testing following a change or fix to the software or environment. This should involve two types of test: Re-testing or confirmation testing, that reruns test cases that previously failed in order to verify the success of corrective actions. Regression testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software as a result of the changes made. An estimated 20% to 50% of changes introduce new defects. It may be performed at all test levels and types, including functional, non-functional and structural testing. Regression should take place at all stages of testing after a functional improvement or repair. Regression Username Password Remember me Remember Password Sign In Retesting Automation testing, this is an advanced level for new be testers, make sure you follow my blog for other courses specifically on automation. Retesting and regression should be repeatable, so they can re-run every time there is a change or fix. Its essential to automate both re-testing and regression tests. Automation is not a full substitute to manual testing as not 100% automation testing can be achieved and it shouldn’t.

Maintenance Testing Once deployed, as software system is often in service for years or decades. During this time the operational system, its configuration data or its environment are often corrected, changed or extended. The testing of these changes is called maintenance testing, and is triggered by: Live System ? New Changes ? ? Assess impact of changes on rest of system Select key functionality • • • Planned enhancements or upgrades to business systems Corrective and emergency changes Changes to the operating environment such as system upgrades Upgrade of commercial-off-the-shelf software Migration of applications from one platform to another Retirement of legacy software systems Regression Test Pack

Review This is what you have learned so far. . . • Waterfall Model • Acceptance testing • V-Model • Functional testing • Iterative Model • Non-Functional testing • Unity or Component testing • Structural testing • Integration testing • Change-related Testing • System testing • Maintenance Testing

End of Section 2 Do the Quiz (attached) for Section 2 Testing Throughout the Software Life Cycle – Section 2 ISTQB Foundation Questions? Comments? Thumbs up and Share it if you like this. Thank You