EEE 243B Applied Computer Programming Software engineering Life cycle and when to test

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Review What is the difference between white box and black box testing? What does coverage give you?

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Outline Software engineering (what is it?) Basic software lifecycle Verification and validation Testing revisited

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Software engineering Software engineering came of age as the demand on software products increased The first few software programs were written by one person for his/her own purpose These programs were small and were produced and used by experts The flexibility afforded by software created a high demand and the number of projects and the size of the projects grew exponentially

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Software engineering Software production was no longer an individual affair but became a team approach As the teams grew bigger and the complexity of the software projects increased a requirement grew to better manage these projects Some costly project delays, dropping quality of products and utter project failures in the late 1960s created what was called the software crisis

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Software engineering Software engineering: Is a label that is normally applied to a set of current (best) practices for software development Shaw and Garland 1996 Software engineering was first coined as an expression during a NATO conference in 1968 The conference was created to address the problems brought on by the software crisis

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Software engineering Engineering disciplines share five common traits: Creating cost effective solutions – economical aspect Solving practical problems – solutions that matter to the population (customer) Apply scientific knowledge – science, math, analysis and design Build things – tangible results Work in the service of mankind – Not just a customer

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Basic software lifecycle The quality of your software depends on all production activities: Analysis – Will your program meet the needs of the user (client)? Design – Is my design effective? Did I do a good decomposition and create a “readable” hierarchy of modules (high level) and functions (low level)? Did you chose the right design Implementation – Is the code solid, efficient, well documented, complete? Testing – Are my tests sufficient? Maintenance – Did I introduce side effects during changes

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Basic software lifecycle The 5 phases that we saw are often represented graphically as a waterfall; hence the waterfall model: Analysis Design Implementation Testing Maintenance

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Verification and Validation There are parts of the testing that has nothing to do with the code!! …Really there is. When you have elicited requirements as part of your analysis of the problem, you must test the requirements with your end user This test is called Validation Validation can occur at more than one stage of the software lifecycle

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Verification and Validation When you finish your design, you must ensure that you took into account all the requirements from analysis. So you test between these two phases This extends to the entire lifecycle: Every time you go from one phase to the next, you have to make sure you did not overlook anything, and that each phase is complete and agrees with the results of the previous phase This phase transition testing is called Verification

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Verification and Validation Verification and validation (V&V) ensure that you catch potentials errors before you get to the code and testing of the code. The reason for performing V&V at all stages of a project is to reduce the impact of changes later in the lifecycle Correcting a mistake at the end of the project may require you to start back at the analysis stage!

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Verification and Validation Verification ensures that each subsequent phase does not deviate from the requirement of the project If a deviation from the project must occur for the product to work, then the verification process must identify and track this deviation Verification ensures that the product is built to the right requirement - building the product right

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Verification and Validation The first thing you try to do is to ensure that you have the requirement right So validation has to do with building the right product You may sometimes have to build a prototype or scaffolding in a software project to validate with the customer and get feedback

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Testing revisited The scaffolding that you build as a prototype can also be used for testing purposes In structured programming, we use a top- down approach to decompose our problems during the design phase When we implement our design, we have two choices: Bottom-up implementation Top-down implementation

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Testing revisited In bottom-up implementation, it may sometimes be necessary to provide input to or get output from a module or a function In this case a driver can be used to simulate the input and get the output, as if the function under test was already part of a bigger system Drivers in a scaffolding may only be a few lines of code, but they provide all the necessary environment needed by lower functions

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Testing revisited In top-down implementation, it may be necessary for the upper modules or functions to obtain some results from lower functions In this case, we can provide a stub in the scaffolding to generate the necessary data needed by the upper function

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Testing revisited Many projects use both the top-down and the bottom-up approaches simultaneously. In these cases the scaffolding may include both drivers and stubs Stubs and drivers are small functions that form a scaffolding until the system is ready for integration Integration testing may use scaffolding, to perform incremental testing as we integrate functions one at a time

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Testing revisited Acceptance testing is the last phase of validation and is normally conducted in presence of the customer Most large software producers also have a Quality Assurance department that can represent and assist the customer For commercial software the QA department is the “customer”

Winter 2005Maj JGA Beaulieu & Capt MWP LeSauvage Quiz Time What are the five phases of the software lifecycle? What is the difference between verification and validation? What is the difference between a driver and a stub?