ISTQB – CTFL Certified Tester Foundation Level – Testing Throughout The Software Life Cycle

1. Software Development Models : The Waterfall Model [CC]

Hi, welcome back. There are many ways software activities are organized to create the software. Each one of them is called software development model. Software models vary according to its objective, discipline, interest, time to market, documentation and many other factors. A most appropriate software development model must be selected and applied for each software brochure. In the previous section we learned what is testing, why is testing and who is doing the testing.

In this section we will talk about how the testing is incorporated as part of the software development activities in different software development models. We will also discuss the different levels and types of testing. And finally we will discuss maintenance testing. Before we go on, we will explain quickly the oldest and one of the very well known development models known as the waterfall. The waterfall model is not part of the Ihttb curriculum, but understanding it will help in understanding many other concepts.

As seen in the graph, the waterfall model is a sequential model where every stage must be completely finished before moving to the following stage. Any software project starts with an idea or needs to be fulfilled by the software. The requirement is collected from the user in what we call the requirement phase. An analyst will analyze the user requirement and put it in a form of the requirement from the computer or system point of view, or in other words, defining the functions required to be carried out by the software to meet user needs.

For example, screens, dialogue or user scenarios, and so on. The analyst will store this in a document called the System Requirements or System Notification or Functional Specification. For example, the user requirements may be something like we need an annual report showing the employees names and salaries. The system requirement will state that the report has to be printed in a four paper. The logo is in the upper left at position 210, with which 120. The font is times, the font size is 14, the table header is bold, and so on.

Then comes the design phase, which is done in two stages by itself global Design and Detail Design. Global Design is concerned with mapping the system requirements to computer modules and how those modules interact with each other. Those modules can reside on a single computer or multicomputers or even different networks. This step is usually done by a designer, an architect and or developers. Global design is also called architecture design or high level design. Detailed design is about detailing what each module should do individually. It’s also called Low Level Design and is done by designers and developers. The following stage is coding.

This is where developers convert the detailed design of each module into a piece of software by using one of the many computer programming languages. Finally, testing is carried out once the code has been fully completed to make sure it’s ready to ship. Testing happens towards the end of the project. Lifecycle sound effects are detected close to the finished date of the project. With this model, it’s difficult to get feedback passed backwards. Up the waterfall.

In a waterfall, you can easily get down, but it’s very hard to go. Against the waterfall. That was the waterfall model. I have seen many, many companies claim that they use the waterfall model. But after explaining the model to them, they realized that what they are doing is not waterfall at all.

Actually, I haven’t seen any company using this model anymore the key point in Waterfall is that you need to have a very detailed system requirement before you start the design do you have a very detailed system requirement? Do you agree with the client on the size of the font before coding? Do you finish the whole coding before moving to the testing stage? If not, then for sure you are not using the waterfall model now is waterfall a good model? Well, it has its benefits it might be a good model for very very specific circumstances but generally speaking it has many drawbacks.

2. Software Development Models : Guidelines [CC]

Looking at the second column from the table on the screen we see that defects have originated from every phase in the software life cycle. We also notice from the second column and we have mentioned this in the second principle of software testing that the area of the testing begins the chief of the cost of fixing those defects.

This leads us to the conclusions that any software model should fulfill the following guidelines from the testing point of view at every stage a check should be made that the work product of that stage meets its objective. A worker product is the out of that stage. Worker product evaluation should take place when the product has been declared complete. If the worker product passes its evaluation we can broke this to the next stage in confidence. Fixing any problems at the point of creation is achievable than fixing them at a later stage. To achieve those goals we need to do what we call verification and validation.

3. Software Development Models : Verification and Validation [CC]

The definitions of verification and validation are very important as I haven’t seen any software testing job interview without asking about verification and validation. So what are those? Verification is doing the thing right. Validation is doing the right thing. So by doing both, both verification and validation we want to do the right thing in the right way.

Can we do the right thing in the wrong way? Yes, we can develop the software required by the customer, but the code is not meant or readable at all. It’s what we call a spaghetti code and God knows how many spaghetti codes are there in the world. Can we do the wrong thing in the right way? Yes, we can develop a very mental, readable reliable software following all the latest best practices. But it’s not what the customer asked for. So we should do both verification and validation. And again, because I have been asked this question many times who is responsible for verification and validation? And the answer again is everyone. Everyone is responsible for verification and validation depending on the county stage of the software lifecycle.

Analysts, for example, are responsible for verifying the requirement meaning it’s written in a nice, understandable way, not ambiguous and complete and so on. Also, analysts should validate the requirement document with the customer to make sure it’s actually what he asked for to make it easy for you to differentiate between validation and verification. Always think of the customer when talking about validation. Testing is done by testers who test the generated code. But again and again and again who are the testers? They could be anyone the developers, the customer or the system testing team. There are two types of development models that demonstrate the mentioned guidelines. The first is an extension to the waterfall model known as the V model. The second one is an Iterative model where the coding stage often begins once the initial user needs have been captured. Let’s talk about those two models in detail in the coming lectures. Thank you.

4. The V-Model [CC]

Hi. The Vmodel main objective is for testing needs to begin as early as possible in the life cycle, which as we have seen before, is one of the fundamental principles of testing. The Vmodel also emphasized that testing is not only concerned with executing test cases, but rather there are other testing activities that should be carried out like planning, analysis and design and so on. As we mentioned in the testing processes earlier, these testing activities are carried out in parallel with development activities. Testing will take place as soon as any work product is created. Unlike the waterfall model where we waited till the code is completed to start the testing, we see from the graph that the V model is very close to the waterfall model.

The activities on the left hand side of the Vmodel are similar to those of the waterfall stages. We can get that the development activities are carried out in the same sequence as that of the waterfall model. The right hand side of the graph represents the different test levels where testing execution is carried out. Although variants of the Vmodel exist, a common type of Vmodel uses four test levels. The four test levels used, each with their own objectives are component testing, which searches for defects in implemented components integration testing, which tests interfaces and interactions between different components system testing, concerned with testing the behavior of the whole system and lost acceptance testing where validation testing with respect to the user needs requirement and business processes conducted to determine whether or not to accept the system.

We will talk more about test levels in a later lectures. But for now, what distinguishes the V model is that we utilize having some work of products created early at each stage to help the testing team do a better job. For example, we know that the user requirement document will be the basis in performing the acceptance testing, right? Then why not plan and design the acceptance testing as soon as we create or receive the user requirement document too early? Not really. It will really help us understand the user requirements document better by asking all the questions that might arise as early as possible.

Any misunderstanding in the user requirement will lead to a disaster if we create the wrong software after all. Also, we use the system requirement document as a basis to perform the system testing. Same thing, we use the global design document to perform the integration testing and we use the detailed design document to perform the component testing.

So why not plan and design those testing activities as soon as the corresponding documents are created or even as drafts? One of the best practices in the Vmodel is to have testers involved very early in the software life cycle during the review of the draft testerbased documents. Talking about review will take place in a separate section of the course. So the Vmodel in a nutshell is concerned with early testing by planning and designing test cases. As soon as each stage welcome, products or documents are ready.

5. Incremental – Iterative Development Models [CC]

Let’s talk now about a different model for software development, which is Iterative incremental development. In incremental development, we developed a software in increments, a fully function first increment, then the second increment which works seamlessly with the first increment. And the third increment, which works with the two previous increments and so on. We finish the whole software. In incremental development, we deploy each increment at the customer site. In Iterative development, we might only know high level requirements, but not the details. So we develop the first iteration with the information we have. Then we provide the result of this iteration to the customer for testing and evaluating. Then we build the second iteration upon the feedback from the customer. The customer might add, remove or change anything. In Iterative development we might need to deploy the results of the iteration to the customer.

So in incremental development we deploy each increment at the customer for sure. But in Iterative development we might not deploy the increment to the customer. Some other models can be based on both the incremental and Iterative concepts. So it will be a mix between the two models. In either models, we go on a series of shorter cycles and get feedback from the customer before we continue to the next cycle. Each cycle involves everything a full software project might have from requirement design, coding, testing and maybe deployment.

For each cycle, a requirement is defined and a version of the code is produced which will allow testing by users. At the end of each iteration, a decision is made on which extra functionality needs to be created for the next iteration. This process is then repeated until a fully working system has been reduced. This is unlike the waterfall model where the customer is only involved during the early requirement and late deployment phases. On my early days as a software developer, I had a project where the customer totally forgot about the project and thought that my company went out of business because we haven’t talked to him for over six months.

After the requirement phase, we were developing the software. I told him, but he didn’t like this. So unlike the Autofold model, a key feature of Iterative development is the involvement of users in the testing. The users are encouraged to request changes to the software to meet their business needs. The main point related to testing in Iterative models is that we need to test a lot and we need to test very quickly. That’s why you might need to automate the testing to make it as fast as possible. There are two types of automation testing. We can use any kind of them or both of them at the same time. One is where testers write their own test scripts to be run by testing automation tools. The second type of automation testing is where the developers, with the help of testers, write code to test their own code. So they are writing code to test their own code. So developers write code to test another code using what we call unit testing frameworks.

In either case, when testers or developers need to test the system, they assembly run the scripts and the power of the computer these days will do the job for them. No need to manually click and type to test anymore. But that of course requires that testers do need to know some kind of programming to help them create those scripts. Testers in Iterative incremental models need to have some sort of a change control system to keep a good eye on the software changes as they happen very often. Forms of Iterative development include prototyping rabbit application development and Agile software development for example Scrum and XP or Extreme Programming and also Rational unified process. In summary, in any Lifecycle model there are several characteristics of good testing.

For every development activity, there is a corresponding testing activity. Second, each test level has test objectives specific to that level. Three, the analysis and design of tests for any test level should begin during the corresponding development activity. As we have seen in the Vmodel, tisters should be involved in reviewing documents as soon as drafts are available in the software lifecycle. Thank you.

6. Test Levels : Unit Testing [CC]

In the Vmodel discussed the area, there were different test stages. They are often called test levels. Each test level has its own objectives, concerns and issues that we need to consider. The typical levels of testing are unit or component testing, integration testing, system testing and acceptance testing. To understand the whole idea better, think of building a curve. It has a lot of components, but before assembling the car, you need to make sure that each component is working perfectly well by itself. So you put some test on each component individually that’s component or unit testing. While assembling the curve, you will start adding the components one by one.

When you add a new component, you want to make sure that it works with the previous components quite well before moving along. So you want to make sure that the newly added component interacts well with other components. That’s integration testing. Now, the whole core is built and looks great, but you must do a test drive and try as many scenarios as possible. Like moving uphill, try it on a curvy road or bumpy road. That’s system testing.

So the car looks fine and looks great, but the buyer still must try it before purchasing it. That’s acceptance testing. Back to the software world. Each of these test levels will include tests designed to uncover problems specifically at that stage of development. These levels of testing can be applied to any development model and they may vary depending on the software model objective. The first test level is component or unit testing.

This is the lowest level in the V model. The units of software components are usually constructed in isolation. Those units are also called programs, modules or components, hence unit testing, component testing or program tests. Unit testing is intended to ensure that the code written for that unit meets its specification barrier to its integration with other units. Unit testing is usually done by the programmers as they are the best persons to know. The code and effects found during unit testing are often not recorded and developers can fix them instantaneously if we use the car assembly example. Again, some components of the car can be tested in isolation by itself, but some other components might need some sort of external tools, wires and maybe external bouts to help test this component. In software, we call those helpers stops and drivers.

Well, if a developer implemented this piece of code to calculate the salary of an employee, don’t worry, you don’t need to know any programming languages to understand this. In this unit, the developer needs to interact with another component called Calculate Bonus. But unfortunately, this unit is not ready yet. So what the developer should do? Well, he might try or create a fake piece of code and name it Calculate Bonus. It’s not the final version yet, but it’s there only to help the developer test his Calculate Salary unit. So what should he do in the Calculate Bonus? Code the bare minimum. We don’t want the new code to reduce bugs by itself.

So we might let the Calculate bonus code just return $1,000. So, while we test our calculate salary code, we will assume that all employees will receive a $1,000 bonus. In our example, the calculate bonus piece of code is called stub. So a stop is a dummy code used for testing in place of a cold component. Now, if we want to test Calculate Salary, we need to write code to run it. It cannot be executed by itself in many languages. The first start point of any software to run is a function called main. So in our case, we would write a main function to call our Calculate cellar. Now, this main function is written only for testing purposes and it’s called a driver. So a driver again is a dynamic code used for testing in place of a caller component. So a stop is a dynamic code used for testing in a place of a cold component and the driver is a dirty code used for testing in place of a cola component. Unit testing requires access to the code being tested. Thus test objects, which is what is under test, can be components programs, data conversion, migration programs, and database modules.

• Category: Uncategorized