In this blog post, the author points out that "modeling" or "prototyping" are one of the more effective ways to test software.
http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-your-code/
Can someone describe these techniques and how they are used in practice?
[update]
I found another reference to the data: http://railspikes.com/2008/7/11/testing-is-overrated
It's from page 470 of Code Complete by Steve McConnell.
Code Complete by Steve McConnell is an excellent book and I recommend it to folks who want to understand more about software engineering in general. Since the chart lists modeling or prototypinig they seem to be equating these because they are both abstractions of the real thing.
WRT to the findings the bugs they are likely referring to here are functional bugs versus non-functional and behavioral issues. For example, the easiest and fastest way to find 99% of most boundary bugs could be via code inspections and/or unit testing. (Unfortunately many boundary bugs sneak by because of the inadequacy of peer code reviews (not formal inspections) and happy path unit tests, or unit tests that are focused on attaining some measure of code coverage rather than test coverage.)
The real take away is
More companies are putting more emphasis on TDD, unit tesitng, and even peer reviews. This is all good stuff. It doesn't mean that testers will ever be out of work. But with the emphasis to drive "quality" upstream and reducing the costs of finding certain types of bugs late in the cycle I suspect the role of testing will grow and testers will truly participate in ALL aspects of the SDLC.
If you get hold of a copy of the book 'how we test software at microsoft' there's a chapter there on Model-Based testing.
Review of that chapter by TESTHEAD can be found at http://mkl-testhead.blogspot.com/2010/12/testhead-book-club-how-we-test-software_15.html
I will not speculate about what the author meant by "modeling", because within the realm of software it can mean different things. Perhaps you could use the comment box at the bottom of the article to ask him what he meant.
In the context of his article, I believe "prototyping" means building a mocked-up version of some aspect of a product for purposes of illustrating and testing an idea. For example, a paper prototype of a user interface might be a set of hand-drawn pictures that illustrate the essential nature of the user interface. Advocates of paper prototyping assert that testing the paper prototype will yield insights into the "real" product's requirements and design.
Done properly, prototyping can be a valuable tool for getting early input on a concept before investing a significant effort building an actual product.
I think user246 gave a very good answer. However, I dare to speculate about the term modeling. We use the term to speak about creating a coded model of specifications you've got at hand before actually getting some code. So it's quite close to prototyping. There are also kind of very sophisticated tools for modeling as e.g. NModel (NModel homepage). In practice, I'd read through the specifications of a new feature (static method) and then, if the logic is very complicated to see through, I'd set up a little model program with NModel let it analyse my model for possible dead ends etc. (yes, it can do that). I personally don't use NModel often. Instead I write down a model of what the program is supposed to do, e.g. flowchart. This is also useful when there is already code which can then be used as spec, too. Looking at the diagram or maybe already while building it I normally get a good feeling about where things can go wrong and bugs are likely to be found.
If one considers the “act” of software development in its entirety, one would realise that we are simply striving to translate an idea conceived in the human mind, into something that can be executed on a computer, i.e. “a program”.
The problem arises because of the vast disparity between two. The human mind is a inconceivably powerful information processor, whereas our current CPUs are simpletons, only capable of churning zeros and ones (binary – i.e. 1GL) in a repetitive manner. To bridge this cap, we have extended the cognitive (i.e. understanding) abilities of our computers by first introducing the second generation languages (2GL e.g. Assembly Language), and then later our currently used third generation languages (3GL e.g. Java, C#, etc.).
However, a problem still exists in translating our sophisticated mental ideas and constructs, into simple constructs that cab be understood by third generation compliers. So we (i.e. the Software Engineering world) have introduced an intermediate cognitive step, and called it a MODEL, which is intended to provide an appropriate framework in which to think, prior to coding the actual system/solution. This is also a common practice in other disciplines such as architecture and engineering, where plans or blueprints are drawn up prior to the building of the actual structure.
Secondly, a prototype is simply a mock-up of the envisaged software system/solution – and should always be thrown away and never form the actual code base of the system being developed. It usually adds value by providing a means to clarify the requirements of the intended system with the users, prior to starting the actual coding of the system.
