Data Structure
Networking
RDBMS
Operating System
Java
MS Excel
iOS
HTML
CSS
Android
Python
C Programming
C++
C#
MongoDB
MySQL
Javascript
PHP
Physics
Chemistry
Biology
Mathematics
English
Economics
Psychology
Social Studies
Fashion Studies
Legal Studies
- Selected Reading
- UPSC IAS Exams Notes
- Developer's Best Practices
- Questions and Answers
- Effective Resume Writing
- HR Interview Questions
- Computer Glossary
- Who is Who
Learn V-Model in Software Testing
The V-Model is a highly rigorous SDLC model in which each development phase is followed by a testing phase. The V model is a variation of the waterfall model, in which testing is carried out in tandem with development at each stage
Software Engineering Terminology
Software Development Life Cycle (SDLC) − SDLC stands for Software Development Life Cycle. Developers do a series of tasks in order to create and construct high-quality software.
The Software Testing Life Cycle (STLC) − is an acronym for Software Testing Life Cycle. It is a set of tasks carried out methodically by testers to test your software product.
Waterfall Model − A waterfall paradigm is a sequential model that divides software development activities into several phases. Each stage is intended to be used for a certain activity. In a waterfall paradigm, the testing process begins only after the system has been implemented.
To understand the V-Model, let's take an example.
Assume you've been tasked with creating custom software for a customer. Try to make an educated prediction regarding the sequence of actions you'll take to complete the work, regardless of your technical experience.
This is the right order.
| Various stages of the Software Development Cycle | Activities carried out in each step |
|---|---|
| Requirement Stage of gathering | Obtain as much information as possible from the customer regarding the specifics and specs of the necessary program. This is the stage where the requirements are gathered. |
| Stage 1: Design | Plan the programming language (Java, PHP,.net), as well as the database (Oracle, MySQL, etc.). Which would be appropriate for the project, as well as certain high-level architecture and functionality. |
| Build Stage | After the design stage, the construction step begins, which is nothing more than the actual coding of the software. |
| Stage of testing | After that, you test the software to ensure that it is built according to the client's specifications. |
| Stage of deployment | Install the program in the appropriate environment. |
| Maintenance Stage | You may need to alter the code once your system is ready to use if a client requests it. |
The waterfall technique of software development is made up of all of these tiers.
Drawbacks of the Waterfall Model
As you can see, the model's testing begins only when the implementation is complete.
However, if you're working on a huge project with complicated systems, it's easy to overlook important aspects during the requirements phase. In such cases, the client will receive an entirely incorrect product, and you may have to restart the project. Alternatively, if you correctly note the requirements but make serious errors in the design and architecture of your software, you will have to redesign the entire software to correct the error.
Problems introduced during requirements and design account for about half of all defects, according to assessments of hundreds of projects.
Additionally, as the development lifecycle progresses, the cost of repairing a fault rises. The sooner in the life cycle, a flaw is discovered, the less expensive it is to correct it. "A stitch in time saves nine," as the saying goes.
The V Model is the answer.
To address this issue, the V-model of testing was created, which includes a Testing phase for each phase of the development life cycle.
The Validation Phase of the V-model is divided into many phases
Unit Testing − Unit Test Plans (UTPs) are created during the module design process in the V-Model. These UTPs are used to find and fix issues at the code or unit level. A unit is the smallest thing that may exist on its own, such as a program module. When separated from the rest of the codes/units, unit testing confirms that the smallest object can perform appropriately.
Component Testing − These tests ensure that the program's tiniest components work properly. A component can be a module, a unit, or a class, depending on the programming language. The tests will be referred to as module tests, unit tests, or class tests as a result of this. Component tests examine the component's output after supplying input in accordance with the component specification. These are feature files for BDD's test-driven methodology. Component tests are distinguished by the fact that single components are evaluated in isolation, without communicating with other components. Because there are no additional components involved, finding problems is significantly easier.
Typically, a test framework is used to implement the test, such as JUnit, CPPUnit, or PyUnit, to mention a few prominent unit test frameworks. Code coverage may be monitored and examined with our code coverage analysis tool Coco to ensure that the tests cover as much of the component's source code as feasible.
Component tests can cover non-functional factors such as efficiency (e.g., storage consumption, memory consumption, program timing, and others) and maintainability in addition to functional testing (e.g. code complexity, proper documentation). Coco's code complexity analysis and function profiler can also assist with these tasks.
Integration Testing − Integration tests ensure that the components, which have been designed and tested separately, can be combined and interact as planned. A software system's tests might cover simply two individual components, groups of components, or even separate subsystems. After the components have been evaluated at the lower component testing level, integration testing is usually finished. The functional definition, system architecture, use cases, and process descriptions may all be used to create integration tests. Integration testing focuses on component interfaces (or subsystem interfaces) and reveals flaws that are caused by their interaction but would not be triggered if the components were tested separately.
Integration tests might also focus on other software or hardware components that interact with the application environment. In contrast to component integration testing, this is commonly referred to as system integration testing.
The test driver might also be a unit test framework, depending on the type of program. Our Squish GUI Tester can run the test for GUI apps. Along with the application under test, Squish may automate subsystems or external systems, such as configuration tools.
System Testing − The system test step examines the whole software system. System tests are built with the user's point of view in mind and focus on the functional and non-functional application requirements, whereas integration tests are largely focused on technical specifications. Performance, load, and stress testing are examples of the latter.
Despite the fact that the components and their integration have been evaluated, system tests are required to ensure that the functional software requirements are met. Without executing the entire software system, certain functions cannot be evaluated at all. Additional papers, such as user manuals or risk analysis documents, are frequently included in system testing.
System testing should be performed in an environment that is as near to the production environment as practicable. If feasible, utilize the same hardware, operating systems, drivers, network infrastructure, or external systems as the production system, and avoid using placeholders as much as possible. The production environment, on the other hand, should not be utilized as a test environment since any problems discovered during the system test might affect the production system.
To prevent time-consuming manual testing, system tests should be automated. Squish can now automate any GUI program and trigger and feed non-GUI processes thanks to image recognition and Optical Character Recognition. Squish may access internal application data present in both GUI and non-GUI objects, in addition to verifying application output through the GUI. Testing multiple applications in a single automated test, even if they use different GUI toolkits; embedded device testing; access to external systems such as database systems; and semi-automated testing, which includes manual verifications and validations, cover the majority of system testing requirements.
Acceptance Testing − Internal acceptance testing, for example, for a version of the software that has not yet been released, is possible. Internal acceptance tests are frequently performed by people who aren't engaged in the development or testing processes, such as product management, sales, or customer service.
Acceptance tests, on the other hand, might be external testing performed by the firm that requested the development or by the software's end users.
It may also be the client's job, partially or entirely, to decide if the final release of the program fits the high-level criteria during customer acceptance testing. Reports are written to keep track of test findings and to facilitate communication between the developing entity and the customer.
User acceptability testing (UAT), in contrast to customer acceptance testing, may be the penultimate phase before a final software release. It's a user-centric test to ensure that a product really supports the workflows that need to be completed. These tests might include factors like usability and the overall user experience.
Depending on the type of software, the amount of time and effort spent on acceptance testing may differ. Extensive testing and reporting may be done on a bespoke development that was created for a specific customer. In the case of off-the-shelf software, less effort is placed into this stage of testing, and acceptance tests may consist of little more than confirming the installation and a few procedures.
Acceptance tests are generally manual tests, with only a tiny percentage of them being automated, especially as they may only be run once at the conclusion of the development process. Acceptance testing, on the other hand, focuses on processes and user interaction, hence we advocate automating acceptance tests with Squish. All stakeholders can utilize BDD as a single language and specification. Consider the time and effort spent on acceptance testing for many versions of software throughout the course of the software lifecycle, or the several iterations in Agile projects. Test automation will save you a lot of time in the medium and long run.
Aside from the V model, there are iterative development methods, in which software is developed in phases, with each phase adding a new feature.
Each phase consists of its own set of development and testing tasks.
Rapid Application Development and Agile Development are two good instances of iterative development lifecycles.
When should you utilize V-Model?
When there is a clear and unambiguous demand.
The V-shaped model should be utilized for small to medium-sized projects with well-defined and fixed requirements.
When sample technical resources with needed technical skills are available, the V-shaped model should be used.
V-Model Benefits (Pros)
Simple to comprehend.
Testing methods like planning and test design take place prior to coding.
This helps you save a lot of time. As a result, it has a better likelihood of succeeding than the waterfall model.
Prevents flaws from flowing downhill.
This method works well for tiny plans with simple criteria.
V-Model disadvantages (cons)
Extremely hard and inflexible.
This isn't ideal for a large-scale project.
There are no early prototypes of software since it is developed during the implementation stage.
If there are any modifications in the middle, the test documents, as well as the needed papers, must be updated.
Conclusion
There are a variety of development life cycle models to choose from. The development model used for a project is determined by the project's objectives and goals.
Testing is not a stand-alone activity, and it must be tailored to the project's development process.
Testing should be carried out at all levels in any model, from requirements through maintenance.
645 Views
