3. Verification and Validation
Before we go on with other sequential models, we need to hear what those of us who use the waterfall model think of it and what they thought would be good practices to overcome its drawbacks. On the screen you can see results from a typical software project. Looking at the second column of the table, we see their defects are originated from every phase in the software lifecycle. We also notice from the second column and as we have mentioned in the third principle of software testing, that the area the testing begins that she builds the cost of fixing those defects.
This lead us to the conclusion that any software model should fulfill with the following guidelines from the testing point of view at every stage a check should be made that the local product for that stage meets its objectives. A local product is the output of that stage. Local product evaluation should take place once the product has been declared complete.
Also, if the local product passes its evaluation, we can progress to the next stage in confidence. And last, fixing any problems at the point of creation is cheaper than fixing them at a later stage. To achieve those goals, we would need to do what we call verification and validation. The definitions of verification and validation are important. Also, I haven’t seen a software testing job interview without asking about verification and validation. Verification is doing the thing right. Validation is doing the right thing. So by doing 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 maintainable or readable. It’s what we call spacy code and God only knows how many spacy codes are out there. Can we do the wrong thing in the right way? Yes, we can develop a readable reliable software using all the latest best practices. But it’s not what the customer asked it 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?
The answer 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 requirements, meaning it’s written in a nice, understandable way, not ambiguous and complete and so on. Also, analysts should also validate the requirement document with the customer to make sure it’s actually what he asked it for. To make it easy for you to differentiate between validation and verification. Always think of the customer when talking about validation. The customer is the only one who can confirm that we are building the right thing. Testing is done by testers who test anything related to the software. But again and again who are the testers? They could be anyone the developers themselves, or the customer or the system testing team.
4. The V-Model
We are still talking about sequential models and in this video we will be talking about the V model. The Vmodel is an extension of the waterfall model. Its main objective is that 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 emphasizes that testing is not only concerned with executing test cases, but instead there are other testing activities that should be carried out like planning, analysis and design and so on. As we have mentioned in the testing process earlier, the V model integrates the test process throughout the development process where testing activities are carried out in parallel with development activities. Testing will take place as soon as any worker product is created. This is unlike the waterfall model where we had to wait until all the development activities are completed before we can 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 the waterfall stages. We can guess 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 test execution is carried out. Although variants of the V model exist, a common type of Vowel uses only four test levels.
The four test levels used, each with their own objectives are component testing searches for defects in implemented components integration testing tests interfaces and interaction between different components system testing concerned with testing the behavior of the whole system acceptance testing validation testing with respect to user needs, requirements and business processes conducted to determine whether or not to accept the system. We will talk more about test levels in later lectures. But what distinguishes the remodel is that we utilize having some worker products created early at each stage to help the testing team do a better job. For example, we know that the user requirements 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? Some might say not really. It will really help us understand the user requirements document much better by asking all the questions that might arise as early as possible. Any misunderstanding in the user requirements will lead to a disaster if we create the wrong software after all. Also, we use the system requirements document as a basis to perform the system testing. Same thing. We use the global design document to perform the integration testing and 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 V model is to have testers involved with even earlier during the review of the draft test debates. Worker Products in this model, the execution of tests associated with each test level proceeds sequentially, but in some cases, overlapping might occur. Talking about review will take place in a separate section of this course. So the V model, in a nutshell, is concerned with early testing by planning and designing test cases. As soon as each stage work, products or documents are drafts or ready.
5. Incremental – Iterative Development Models
Let’s talk now about a different category or categories of software development models. Iterative incremental development. Iterative incremental development models is not a single category of software development models, but rather there are software models that can be categorized under incremental category alone. And there are many software models that can be categorized under Iterative category alone. And there are software models that can be categorized under both incremental and Intuitive category. Incremental development involves establishing requirements, designing, building and testing a system in pieces, which means that the software features grow incrementally a fully functional first increment, then the second increment, which integrates seamlessly with the first increment, and a third increment, which also integrates with the various two increments and so on till we finish the whole software.
In incremental development, we deploy each increment at the customer site. The size of this feature increments values with some methods having larger pieces and some smaller pieces. The feature increments can be as small as a single change to a user interface screen or new query option. Iterative development, on the other hand, occurs when groups of features are specified, designed, built and tested together in a series of cycles, often over fixed duration. Iterations may involve the changes to features developed in earlier iterations, along with the changes in project scope. Each iteration delivers working software, which is a growing subset of the overall set of features until the final software is delivered or development is stopped. In Iterative development, we might only know high level requirements, but not the details. So we develop the first iteration with the information we currently have, then provide the result of this iteration to the customer for testing and evaluation. Then we build the second iteration or bond the feedback from the customer. The customer might add, remove or change anything in Iterative development.
We might need to deploy the result of the iteration to the customer. So in incremental Iterative or incremental Iterative 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 requirements, design, coding and testing, and maybe deployment. Customers are heavily involved with in incremental Iterative models during the whole duration of the software project. This is unlike the waterfall model, for example, where the customer is only involved during the early requirement and the late deployment phases. On my early days, very early days, I had a waterfall 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. We were working, yes, I told him, but he didn’t like this.
So unlike the waterfall model, a key feature of Iterative development is the involvement of user representatives in the testing. A user representatives are encouraged to request the changes to the software to meet their business needs. In contrast to sequential models, Iterative and incremental models may deliver usable software in weeks or even days, but may only delivers a complete set of requirements products over a period of months or even years.
Examples of Iterative incremental models include rational unified process where each iteration tends to be relatively long, for example, two to three months and the feature increments are correspondingly large, such as two or three groups of related features. Spiral or prototyping involves creating experimental increments, some of which may be heavily reworked or even abandoned in subsequent development work scrum. Each iteration tends to be relatively short for example, hours, days or few weeks and the feature increments are correspondingly small, such as a few enhancement and or two or three new features canben implemented with or without fixed lens iterations which can deliver either a single enhancement or feature upon completion or can glue features together to release at once. Both scrum and canben are examples of the Agile methodology.
I will talk more about scrum in a future video as there are various scrum terminologies used in this syllabus and I want you to be aware of those terminologies. You don’t need to learn the details of any of those models. All you need to know is how should we test our software if our project is using any of those models. From the testing point of view, components or systems developed using these methods often involve overlapping and Iterating test levels throughout development. Ideally, each feature is tested at several test levels as it moves towards delivery. In addition, Iterative methods form a growing system which may be released to end users on a feature by feature basis or an iteration by iteration basis or in a more traditional measure releases fashion.
Regardless of whether software increments are released to end user, regression testing is increasingly important as the system goes, so this is a very important point to notice. Regression testing is increasingly important in Iterative incremental models. Another important point related to testing in Iterative incremental models is that we should put into consideration that we might need to test the same feature many times due to changes in a short period. So we need to test a lot and we need to test very quickly. That’s why we might need to automate the tests to make it as fast as possible. In automated testing, they assembly run the scripts and the power of the computers these days will do the job for you. No need to manually click and type to test anymore. But of course testers are required to do know some programming knowledge to help them create those scripts. In some cases, teams use continuous delivery or continuous deployment, both of which involve significant automation of testing as part of their delivery pipelines.
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 a lot. Many development efforts using these methods also include the concept of self organizing teams which can change the way testing work is organized as well as the relationship between testers and developers. That’s all. What we need to know about Iterative incremental Models in summary, please remember the following characteristics of good testing in any Lifecycle model for every development activity there is a corresponding testing activity. If we are doing the requirements then there should be some sort of testing to the requirements.
If we are doing the coding then there should be some sort of testing to the code. Even if we are doing the project plan then there should be some sort of testing to the project plan itself. The second point each test level has test objectives specific to that level. We will talk more about test levels in the coming video, but you need to remember that each test level has its own test objectives. The third point the analysis and design of tests for any test level should begin during the corresponding development activity.
Aole testing similar to what we have seen in the V model. Last point testers should participate in discussions to define and refine requirements and design. Testers should be involved in reviewing documents or work of products, for example, requirements, design, user stories and so on. As soon as drafts are available in the software development, lifecycle directs mean before the documents are finalized. If the documents are finalized then what’s the boil in reviewing the documents and finding defects in the finalized documents?
