Common Mechanisms of UML

Testing vs Debugging

• Many people consider both as same, but
• Testing start with known conditions, uses predefined procedures and has predictable outcomes
• Debugging starts from possibly unknown initial conditions and the end can not be predicted(except statically)
• The purpose of testing is to find the error or misconception that led to the programs failure, and to design and implement the program changes that correct the error
• Testing is performed to find the location of a defect, and debugging is performed to fix these defects
• Testing is performed by the testing team and debugging is performed by the development team
• Intention behind testing is to find as many defects as possible in the defined environment, but the intention behind debugging is to fix as many defects as possible keeping the requirements in view.

• Debugging usually follows testing, but they differ as to goals, methods and most importantly, psychology. The below table shows few important differences testing and debugging.

Testing	Debugging
Testing starts with known conditions, uses predefined procedures and has predictable outcomes	Debugging starts from possibly unknown initial conditions and the end can not be predicted except statistically
Testing can and should be planned, designed and scheduled	Procedure and duration of debugging cannot be so constrained
Testing is a demonstration of error or apparent correctness	Debugging is deductive process
Testing proves a programmers failure	Debugging is the programmers  vindication(Justification)
Testing, as executes, should strive to be predictable, dull, constrained, rigid and inhuman	Debugging demands intuitive leaps, experimentation and freedom
Much testing can be done without design knowledge	Debugging is impossible without detailed design knowledge
Testing can often be done by an outsider	Debugging must be done by an insider
Much of test execution and design can be automated	Automated debugging is still a dream.

Function vs Structure

Function	Structure
It takes the user point of view-bother about functionality and features and not the programs implementation	It looks at the implementation details
In functional testing, the program or system is treated as a black box            It is subjected to inputs and its outputs are verified for conformance to specified behaviour	Things such as programming style, control method, source language, database design, and coding details dominate structural testing

• Both structural and functional tests are useful, both have limitations, and both target different kinds of bugs
• Functional tests can detect all bugs but would take massive time to do so
• Structural tests are inherently finite, but cannot detect all errors, even if completely executed

Designer vs Tester

• Test designer is the person who designs the test, whereas the tester is the one who actually tests the code
• During functional testing, the designer and tester are probably different persons. During unit testing, the tester and the programmer merge into one person
• Tests that are designed and executed by software designers are more likely inclined to structural considerations
• Structural testing restricts these tests to convey its meaning correctly in a simple lucid (easy) manner

Modularity vs Efficiency

• A module is a discrete, well-defined, small component of a system
• If modules are small, then they are difficult to integrate
• If modules are large, then they are difficult to understand
• Both tests and systems can be modular
• Testing should be organized into modular components
• small, independent test cases can be designed to test independent modules
• So has to have efficient testing in modular programming approach, components belonging to a particular module shall be organized and the other in which they are to be tested shall be streamlined using a test procedure
• Test cases related to components shall be grouped and presented
• Components and related dependency information shall be maintained
• If the system is modular, the tests can also be modular which results in the efficiency of the system as well as in the efficiency of testing process
• Proper care should be taken to minimize the effort needed for test design, debugging and test execution with out compromising the efficiency

Small vs Large

• Programming in the large, means constructing programs that consists of many components written by many different programmers
• Example for programming in the large- The software is developed by several people with a few thousands of statements for more than 5 years
• Programming in the small, is what we do for ourselves in the privacy of our own offices
• Example for programming in the small- Home work exercises for college students, personal scripts to manage our data etc.
• Qualitative and Quantitative changes occur with size and so must testing methods and quality criteria

Builder vs Buyer

• Most of the software's are written and used by the same organizations
• Unfortunately, this situation id dishonest, because it clouds accountability
• If there is no separation between builder and buyer, there can be no accountability

The different roles/users in a system include
Builder: who designs the system and is accountable to the buyer
Buyer: who pays for the system in the hope of profits from providing services
User: Ultimate beneficiary or victim of the system, The users interests are also guarded by
Tester: Who is dedicated to the builders destruction