Search This Blog

v model to w model

The V-model promotes the idea that the dynamic test stages (on the right hand side of the model) use the documentation identified on the left hand side as baselines for testing. The V-Model further promotes the notion of early test preparation.

The V-Model of testing

Early test preparation finds faults in baselines and is an effective way of detecting faults early. This approach is fine in principle and the early test preparation approach is always effective. However, there are two problems with the V-Model as normally presented.

The V-Model with early test preparation

There is rarely a perfect, one-to-one relationship between the documents on the left hand side and the test activities on the right. For example, functional specifications don’t usually provide enough information for a system test. System tests must often take account of some aspects of the business requirements as well as physical design issues for example. System testing usually draws on several sources of requirements information to be thoroughly planned.

V-Model has little to say about static testing at all. The V-Model treats testing as a back-door activity on the right hand side of the model. There is no mention of the potentially greater value and effectiveness of static tests such as reviews, inspections, static code analysis and so on. This is a major omission and the V-Model does not support the broader view of testing as a constantly prominent activity throughout the development lifecycle.

W Model:

The W-Model of testing

Paul Herzlich introduced the W-Model approach in 1993. The W-Model attempts to address shortcomings in the V-Model. Rather than focus on specific dynamic test stages, as the V-Model does, the W-Model focuses on the development products themselves. Essentially, every development activity that produces a work product is shadowed by a test activity. The purpose of the test activity specifically is to determine whether the objectives of a development activity have been met and the deliverable meets its requirements. In its most generic form, the W-Model presents a standard development lifecycle with every development stage mirrored by a test activity. On the left hand side, typically, the deliverables of a development activity (for example, write requirements) is accompanied by a test activity test the requirements and so on. If your organization has a different set of development stages, then the W-Model is easily adjusted to your situation. The important thing is this: the W-Model of testing focuses specifically on the product risks of concern at the point where testing can be most effective.

The W-Model and static test techniques.

If we focus on the static test techniques, you can see that there is a wide range of techniques available for evaluating the products of the left hand side. Inspections, reviews, walkthroughs, static analysis, requirements animation as well as early test case preparation can all be used.

The W-Model and dynamic test techniques.

If we consider the dynamic test techniques you can see that there is also a wide range of techniques available for evaluating executable software and systems. The traditional unit, integration, system and acceptance tests can make use of the functional test design and measurement techniques as well as the non-functional test techniques that are all available for use to address specific test objectives.

The W-Model removes the rather artificial constraint of having the same number of dynamic test stages as development stages. If there are five development stages concerned with the definition, design and construction of code in your project, it might be sensible to have only three stages of dynamic testing only. Component, system and acceptance testing might fit your normal way of working. The test objectives for the whole project would be distributed across three stages, not five. There may be practical reasons for doing this and the decision is based on an evaluation of product risks and how best to address them. The W-Model does not enforce a project symmetry that does not (or cannot) exist in reality. The W-model does not impose any rule that later dynamic tests must be based on documents created in specific stages (although earlier documentation products are nearly always used as baselines for dynamic testing. In projects using these methods, requirements and designs might be documented in multiple models so system testing might be based on several of these models (spread over several documents).

We use the W-Model in test strategy as follows. Having identified the specific risks of concern, we specify the products that need to be tested; we then select test techniques (static reviews or dynamic test stages) to be used on those products to address the risks; we then schedule test activities as close as practicable to the development activity that generated the products to be tested.

Someone essentially lend a hand to make severely articles I'd state. This is the very first time I frequented your website page and up to now? I surprised with the research you made to create this actual put up extraordinary. Excellent job!

Hello! I understand this is somewhat off-topic however I had to ask.Does building a well-established blog such as yours require a massive amount work? I'm brand new to running a blog however I do write in my journal every day. I'd like to start a blog so I can easily share my own experience and feelings online. Please let me know if you have any recommendations or tips for brand new aspiring blog owners.Appreciate it!

I don't even understand how I ended up here, but I thought this submit was great. I don't recognize who you might be but certainly you are going to a famous blogger in the event you are not already. Cheers!

hi!,I really like your writing very a lot! share we keep in touch extra approximately your article on AOL? I require a specialist in this space to unravel my problem. May be that's you! Looking forward to peer you.

Excellent blog! Do you have any helpful hints for aspiring writers? I'm planning to start my own site soon but I'm a little lost on everything.Would you advise starting with a free platform like Wordpress or go for a paid option?There are so many options out there that I'm totally confused .. Any ideas? Thanks a lot!

Woah! I'm really enjoying the template/theme of this site. It's simple,yet effective. A lot of times it's difficult to get that "perfect balance" between superb usability and appearance. I must say you have done a very good job with this. Additionally, the blog loads super quick for me on Chrome. Superb Blog!

I do agree with all the concepts you have offered on your post. They're very convincing and can certainly work. Still, the posts are too brief for novices. May just you please prolong them a bit from subsequent time? Thanks for the post.

Popular posts from this blog

Today, for a few minutes Google suddenly started warning all of its indexed sites as Harmful to your computer! Perhaps it was a glitch in their algorithm, but we managed to make a snap of it for the record.

Test coverage matrix is a checklist which ensures that the functionality of the given screen(unit) is checked in all possible combinations (positive and negative) which have not been covered in test cases. Test coverage matrix is usually prepared for a screen having large number of controls (textboxes, dropdowns, buttons etc) usually, test coverage matrix is prepared in a spread sheet having all the controls (textboxes, dropdowns, buttons etc) in the columns and then all possible entries in those fields in the rows with an ''yes'' or ''no'' in the rows against the controls listed in the columns. For example, consider a ''login'' screen wherein we have ''username'' and ''password" textfields.

While preparing test coverage matrix, the first column will be ''s.no'' and the second will be ''username" and ''password" will be the third field followed by …

Cyclomatic complexity is a software metric (measurement). It was developed by Thomas McCabe and is used to measure the complexity of a program. It directly measures the number of linearly independent paths through a program's source code. It is computed using a graph that describes the control flow of the program. The nodes of the graph correspond to the commands of a program. A directed edge connects two nodes if the second command might be executed immediately after the first command.

Definition

M = E − N + 2P

where

M = cyclomatic complexity E = the number of edges of the graph N = the number of nodes of the graph P = the number of connected components.

"M" is alternatively defined to be one larger than the number of decision points (if/case-statements, while-statements, etc) in a module (function, procedure, chart node, etc.), or more generally a system.

Separate subroutines are treated as being independent, disconnected components of the program's control flow graph.