2018: Testing Throughout The Software Life Cycle

1. Software Development Models

In the previous section, we learned what's testing, why is testing, and who is doing the testing. In this section, we will talk about how testing is incorporated as part of 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. First, let's talk about software development lifecycle models. There are many ways software activities are organised to create the software and how activities relate to one another logically and chronologically. Each one of them is called a software development model. The objective, discipline, interest, time to market, documentation, type of activities performed at each stage, and other factors all influence software models. There are a number of different software development lifecycle models. The most appropriate software development model must be selected and applied for each software project. The testing approach of how we do testing varies according to the selected lifecycle model. It's an important part of a tester's role to be familiar with the common software development lifecycle models so that approval activities can take place. Software Development and Software Testing No matter which software development lifecycle model is chosen,this activity should start in the early stages of the life cycle. Adhering to the testing principle of early testing This service categorises common software development lifecycle models as follows Models of iterative and incremental development Sequential and iterative incremental development models can be considered as the two extremes. At the very end of one extreme is the waterfall model, and on the other end of the extreme is the agile model. Hundreds of models can be found in the spectrum between. The syllabus chose to talk about waterfall, the model, and various agile models. I will talk about each one of them in some detail. And if you need more information about various models,you can check my other course on software models, where you can find a cobalt for that course in the bonus lecture of this course. On one hand, sequential development models describe the software development process as a linear sequential flow of activities. This means that any phase in the development process should begin when the previous phase is completed. In theory, there is no overlap between phases, but in practise it's beneficial to have early feedback from the following phase. Sequential development models deliver software that contains the complete set of features but typically require months or years for delivery to stakeholders and users. We will talk about the waterfall and the V model related to the sequential development models in future videos. On the other hand, we have incremental and iterative models where the software development process moves in short cycles of activities where it can be visited multiple times. The duration of each cycle could be days, weeks, or as short as a few hours. We will talk more about agile models related to iterative incremental models, but let's start with the waterfall model in the coming videos.

2. The Waterfall Model

The oldest and one of the most well-known development models is known as the Waterfalls. Understanding the waterfall model will help in understanding many coming concepts. As seen in the graph, the waterfall model is a sequential model where every stage must be completely finished before moving to the next stage. Any software project starts with an idea or a need that needs to be fulfilled by the software. The requirements are collected from the user in what we call the User Requirements stage. An analyst will analyse the user requirements and put them in the form of a requirement from the computer or system point of view, or in other words, define the functions required to be carried outby the software to meet the user needs in the form of screens and dialogues and user scenarios. We will store this in a document called System Requirements,System Specification, or Functional Specifications. For example, the user requirement may be something like an annual report, showing the employees' names and sellers. The system requirement will state that the report has to be printed on a sheet of paper. The logo in the upper left corner is position 210, with which 120. The font is Times New Roman, the font size is 14, the table header is bold, and so on. Then comes the design phase, which is done in two stages: global design and Detailed Design.Global Design is concerned with mapping system requirements to computer modules and how these modules interact with each other. Those modules can reside on a single computer, multiple computers, or even different networks. This step is usually done by a designer or an architect and developers. Global design is also called architectural 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 started out.Once the code has been finally completed, make sure it's ready to ship. Testing happens towards the end of the bullet life cycle,so the effects are detected close to the bullet shape date. With this model, it's difficult to get feedback passed back up the waterfall. In a waterfall, you can quickly 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 realise that what they are doing is not a 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 very detailed system requirements before you start the design. Do you have very detailed system requirements? Do you agree with the client on the size of the font before coding? Do you complete all of the coding before proceeding to the testing stage? If not, then for sure you are not using the waterfall model. Is waterfall a good model or not? Well, it has its benefits It might be a good model for very specific circumstances, but generally speaking, it has many drawbacks.

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 we think would be good practises to overcome its drawbacks. On the screen, you can see the results from a typical software project. Looking at the second column of the table, we see that defects originate from every phase in the software lifecycle. We also noticed from the second column and as we mentioned in the third principle of software testing, that the earlier the testing begins, the lower the cost of fixing those defects. This leads us to the conclusion that any software model should be fulfilled with the following guidelines: From the testing point of view, at every stage a check should be made that the worker product for that stage meets its objectives. A worker product is the output of that stage. Worker product evaluation should take place once the product has been declared complete. Also, if the worker product passes its evaluation, we can progress to the next stage in confidence. 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 a spaciti code, and God only knows how many packetic codes are out there. Can we do the wrong thing in the right way? Yes, we can develop maintainable, readable, reliable software using all the latest best practises, but that's not what the customer asked for. So we should do both verification and validation. And again, because I have 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 requirements, meaning they're written in a nice, understandable way, not ambiguous, complete, and so on. The analyst should also 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. 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, 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 Vmodel. The Vmodel is an extension of the waterfall model. Its main objective is that testing needs to begin as early as possible in the lifecycle, which, as we have seen before, is one of the fundamental principles of testing. The Bmodel also emphasises 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 Vmodel integrates the testing 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 autofill model, where we have 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 model 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 Vmodel exist, the most common Vmodel uses only four test levels. The four test levels used, each with their own objectives, are component testing, search for defects in implemented components Acceptance testing, validation testing, with respect to user needs, requirements, and business processes, conducted to determine whether or not to accept the system. integration testing, testing interfaces and interaction between different components. system testing concerned with testing the behaviour of the entire system. We will talk more about test levels in later lectures. But what distinguishes the Vmodel is that we utilise some worker products created early at each stage to help the testing team do a better job. For example, we know that the requirements document will be the basis for 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 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 integration testing and use the detailed design document to perform 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 practises in the Vmodel is to have testers involved even earlier. During the review of the draught test base work above us, In this model, the execution of tests associated with each test level proceeds sequentially. But in some cases, overlapping might occur. Talking about reviews will take place in a separate section of this course. So the Vmodel, in a nutshell, is concerned with early testing. By planning and designing test cases as soon as each stage works, products or documents are drafted or pretty.

5. Incremental - Iterative Development Models

Let's talk now about different categories of software development models. Iterative incremental development Iterative incremental development models are not a single category of software development models, but rather there are software models that can be categorised under the incremental category alone. And there are many software models that can be categorised under the iterative category alone. And there are software models that can be categorised under both the incremental and Intuitive category.Incremental development involves establishing requirements, designing, building, and testing assistance in pieces, which means that the software features grow incrementally from 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 previous 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 a 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 a fixed duration. Iterations may include changes to features developed in previous iterations as well as 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 the 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 on 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, innovative, or incremental iterative models,we go through a series of shorter cycles and get feedback from the customer before we continue to the next cycle. Each cycle involves every single software project that might have requirements, design, coding, testing, and maybe deployment. Customers are heavily involved in incremental iterative models during the whole duration of the software budget. This is unlike the waterfall model, for example,where the customer is only involved during the early requirements and the late deployment phases. In 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 hadn't talked to him for over six months. We were working, yes, I told him, but he didn't like this. So, unlike the Autofone model, a key feature of iterative development is the involvement of user representatives in the testing. 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 deliver a complete set of requirements brought up over a period of months or even years. Examples of iterative incremental models include rational unifiedprocess, 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 a few weeks, and the feature implementationsare correspondingly small, such as a few enhancements and or two or three new features can be implemented with or without fixed lens iterations, which can deliver either a single enhancement or feature upon completion, or can group features together to be released at once. Both scrum and can bend are examples of the Azure methodology. I will talk more about scrum in a future video as there are various scrum technologies used in this service and I want you to be aware of those technologies. You don't need to learn the details of any of those models. All you need to know is how to 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 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, an iteration-by-iteration basis, or in a more traditional measure release fashion. Regardless of whether software implementations are made available to end users, 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 incrementalmodels is that we should take 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 tests to make them as fast as possible. In automated testing, they run the scripts and the power of the computer 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 have 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 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 organised as well as the relationship between testers and developers. That's all. What we need to know about iterativeincremental models In summary, please remember the following characteristics of good testing in any life cycle 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 for the requirements. If we are doing the coding, then there should be some sort of testing for the code. Even if we are doing the project plan, then there should be some sort of testing for the project plan itself. The second point is that each test level has objectives specific to that level. We will talk more about test levels in the coming videos, but you need to remember that each test level has its own test objectives. The third point is that the analysis and design of tests for any test level should begin during the corresponding development activity. AOE testing in the same manner as seen in the V module At this point, testers should participate in discussions to define and refine requirements and design. Testers should be involved in reviewing documents or worker products, for example, requirements, design, user stories, and so on, as soon as draughts are available in the software development lifecycle. Drafts mean before the documents are finalized. If the documents are finalized, then what's involved in reviewing the documents and finding defects in the finalised documents?

ExamSnap's ISTQB CTFL-2018 Practice Test Questions and Exam Dumps, study guide, and video training course are complicated in premium bundle. The Exam Updated are monitored by Industry Leading IT Trainers with over 15 years of experience, ISTQB CTFL-2018 Exam Dumps and Practice Test Questions cover all the Exam Objectives to make sure you pass your exam easily.