Software Engineering - Essay Example

CHAT APPLICATION PROJECT AFTER TEST PROGRAM ERRORS Introduction IEEE Computer Society through its SWEBOK 2004 defined software engineering as The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”; and 2. “The study of approaches as in the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software”.

(SWEBOK, 2004 p. 1-1).Software engineering includes the following knowledge areas (KAs): 1. Software requirements, 2. Software design, 3.Software construction, 4. Software testing, 5. Software maintenance, 6. Software configuration and management, 7. Software engineering management, 8. Software engineering process, 9. Software engineering tools and methods, 10. Software quality, and 11. Knowledge areas of related disciplines (Computer Engineering, Computer Science, Management, Mathematics, Project Management, Quality Management, Software Ergonomics, and Systems Engineering) (SWEBOK, 2004 p. 1-2). Software engineers, therefore, must be proficient with the latter knowledge areas to handle every software engineering projects properly, successfully and efficiently.

The software engineering project being studied at hand is the Chat Application. According to the given case, the status of which is that there is an unexpected disappearing messages that caused the team one extra week to debug. Further, the Director for Software Services has the following comments, impressions and questions: 1. She is not pleased with the delay, 2. She comes to one of the status meetings to find out what happened, 3. She states, Your team has been testing this application for weeks and didnt find any problems, 4.

She asked, Why didnt you find the problem sooner?, and 5. She also asked, Is there any way we can kept this from happening again?As a member of the team, she wants you to discuss the following: 1. Your opinion on testing, 2. Whether an application that passes testing is free from errors, 3. Whether it is possible to design a test that will find all potential errors in the Chat Application, 4. What other techniques or strategies can developers use in conjunction with testing.However, the Director for Software Services requires you to name at least two techniques or strategies that developers can use in conjunction with testing.

Opinion on testing“Testing is an activity performed for evaluating product quality, and for improving it, by identifying defects and problems.Software testing consists of the dynamic verification of the behavior of a program on a finite set of test cases, suitably selected from the usually infinite executions domain, against the expected behavior.”(SWEBOK, 2004 p. 5-1)Based on the above authoritative definition of testing, it is so rigid that a possible normal program error may possibly slip out of this rigidity in the process of testing.

But, it offers neither an assurance nor a realistic avoidance or absence of after test errors. However, the another view on software testing is clearly elaborated below:“The view of software testing has evolved towards a more constructive one. Testing is no longer seen as an activity which starts only after the coding phase is complete, with the limited purpose of detecting failures. Software testing is now seen as an activity which should encompass the whole development and maintenance process, and is itself an important part of the actual product construction.

Indeed, planning for testing should start with the early stages of the requirement process, and test plans and procedures must be systematically and continuously developed, and possibly refined, as development proceeds. These test planning and designing activities themselves constitute useful input for designers in highlighting potential weaknesses (like design oversights or contradictions, and omissions or ambiguities in the documentation).”(SWEBOK, 2004 p. 5-1)An application that passes testing is free from errors?

Definitely and realistically the application that passes testing may not be completely free from errors. There are various reasons for this, simply because not all computer networks, hardwares, softwares, operating systems, users and computing environments are created equal or the same, as those in the Software Testing Laboratory where the chat application was tested. However, program errors that may be discovered after the release date may be fixed as part of the Software Maintenance Phase of the Software Development Life Cycle.

This is consistent with the pronouncements of the IEEE Computer Society through its SWEBOK 2004, which states:“It is currently considered that the right attitude towards quality is one of prevention: it is obviously much better to avoid problems than to correct them. Testing must be seen, then, primarily as a means for checking not only whether the prevention has been effective, but also for identifying faults in those cases where, for some reason, it has not been effective. It is perhaps obvious, but worth recognizing, that, even after successful completion of an extensive testing campaign, the software could still contain faults.

The remedy for software failures experienced after delivery is provided by corrective maintenance actions. Software maintenance topics are covered in the Software Maintenance KA.”(SWEBOK, 2004 p. 5-1)Is it possible to design a test that will find all potential errors in the Chat Application? No. While it is true that it is possible to design a test that will find or anticipate majority of the potential errors in the Chat Application, its definitely very difficult to find or anticipate all of the program errors, because of very diverse computing environments, networks, hardwares, softwares, operating systems, users, and other unforeseen considerations.

Techniques or strategies that developers can use in conjunction with testing The techniques or strategies that developers can use in conjunction with software testing was thoroughly enumerated and elaborated in the IEEE Computer Society through its SWEBOK 2004, which states: “3. Test TechniquesOne of the aims of testing is to reveal as much potential for failure as possible, and many techniques have been developed to do this, which attempt to “break” the program, by running one or more tests drawn from identified classes of executions deemed equivalent.

The leading principle underlying such techniques is to be as systematic as possible in identifying a representative set of program behaviors; for instance, considering subclasses of the input domain, scenarios, states, and dataflow.It is difficult to find a homogeneous basis for classifying all techniques, and the one used here must be seen as a compromise. The classification is based on how tests are generated from the software engineer’s intuition and experience, the specifications, the code structure, the (real or artificial) faults to be discovered, the field usage, or, finally, the nature of the application.

Sometimes these techniques are classified as white-box, also called glassbox, if the tests rely on information about how the software has been designed or coded, or as black-box if the test cases rely only on the input/output behavior. One last category deals with combined use of two or more techniques. Obviously, these techniques are not used equally often by all practitioners. Included in the list are those that a software engineer should know.3.1. Based on the software engineer’s intuition and experience3.1.1.

Ad hoc testing [Kan99:c1]Perhaps the most widely practiced technique remains ad hoc testing: tests are derived relying on the software engineer’s skill, intuition, and experience with similar programs. Ad hoc testing might be useful for identifying special tests, those not easily captured by formalized techniques.3.1.2. Exploratory testingExploratory testing is defined as simultaneous learning, test design, and test execution; that is, the tests are not defined in advance in an established test plan, but are dynamically designed, executed, and modified.

The effectiveness of exploratory testing relies on the software engineer’s knowledge, which can be derived from various sources: observed product behavior during testing, familiarity with the application, the platform, the failure process, the type of possible faults and failures, the risk associated with a particular product, and so on. [Kan01:c3]3.2. Specification-based techniques3.2.1. Equivalence partitioning [Jor02:c7; Kan99:c7]The input domain is subdivided into a collection of subsets, or equivalent classes, which are deemed equivalent according to a specified relation, and a representative set of tests (sometimes only one) is taken from each class.3.2.2. Boundary-value analysis [Jor02:c6; Kan99:c7]Test cases are chosen on and near the boundaries of the input domain of variables, with the underlying rationale that many faults tend to concentrate near the extreme values of inputs.

An extension of this technique is robustness testing, wherein test cases are also chosen outside the input domain of variables, to test program robustness to unexpected or erroneous inputs.3.2.3. Decision table [Bei90:c10s3] (Jor02)Decision tables represent logical relationships between conditions (roughly, inputs) and actions (roughly, outputs). Test cases are systematically derived by considering every possible combination of conditions and actions. A related techniques is cause-effect graphing.

[Pfl01:c9]3.2.4. Finite-state machine-based [Bei90:c11; Jor02:c8]By modeling a program as a finite state machine, tests can be selected in order to cover states and transitions on it.3.2.5. Testing from formal specifications [Zhu97:s2.2] (Ber91; Dic93; Hor95)Giving the specifications in a formal language allows for automatic derivation of functional test cases, and, at the same time, provides a reference output, an oracle, for checking test results. Methods exist for deriving test cases from model-based (Dic93, Hor95) or from algebraic specifications. (Ber91)3.2.6. Random testing [Bei90:c13; Kan99:c7]Tests are generated purely at random, not to be confused with statistical testing from the operational profile as described in sub-topic 3.5.1 Operational profile.

This form of testing falls under the heading of the specification-based entry, since at least the input domain must be known, to be able to pick random points within it.3.3. Code-based techniques3.3.1. Control flow-based criteria [Bei90:c3; Jor02:c10] (Zhu97)Control flow-based coverage criteria is aimed at covering all the statements or blocks of statements in a program, or specified combinations of them. Several coverage criteria have been proposed, like decision/condition coverage. The strongest of the control flow-based criteria is path testing, which aims to execute all entry-to-exit control flow paths in the flowgraph.

Since path testing is generally not feasible because of loops, other, less stringent criteria tend to be used in practice, such as statement testing, branch testing, and condition/decision testing. The adequacy of such tests is measured in percentages; for example, when all branches have been executed at least once by the tests, 100% branchcoverage is said to have been achieved.3.3.2. Data flow-based criteria [Bei90:c5] (Jor02; Zhu97)In data flow-based testing, the control flowgraph is annotated with information about how the programvariables are defined, used, and killed (undefined).

The strongest criterion, all definition-use paths, requires that, for each variable, every control flow path segment from a definition of that variable to a use of that definition is executed. In order to reduce the number of paths required, weaker strategies such as all-definitions and all-uses are employed.3.3.3. Reference models for code-based testing (flowgraph, call graph) [Bei90:c3; Jor02:c5].Although not a technique in itself, the control structure of a program is graphically represented using a flowgraph in code-based testing techniques.

A flowgraph is a directed graph the nodes and arcs of which correspond to program elements. For instance, nodes may represent statements or uninterrupted sequences of statements, and arcs the transfer of control between nodes.3.4. Fault-based techniques (Mor90)With different degrees of formalization, fault-based testing techniques devise test cases specifically aimed at revealing categories of likely or pre-defined faults.3.4.1. Error guessing [Kan99:c7]In error guessing, test cases are specifically designed by software engineers trying to figure out the most plausible faults in a given program.

A good source of information is the history of faults discovered in earlier projects, as well as the software engineer’s expertise.3.4.2. Mutation testing [Per95:c17; Zhu97:s3.2-s3.3]A mutant is a slightly modified version of the program under test, differing from it by a small, syntactic change. Every test case exercises both the original and all generated mutants: if a test case is successful in identifying the difference between the program and a mutant, the latter is said to be “killed”.

Originally conceived as a technique to evaluate a test set (see 4.2), mutation testing is also a testing criterion in itself: either tests are randomly generated until enough mutants have been killed, or tests are specifically designed to kill surviving mutants. In the latter case, mutation testing can also be categorized as a code-based technique. The underlying assumption of mutation testing, the coupling effect, is that, by looking for simple syntactic faults, more complex faults, but real ones, will be found.

For the technique to be effective, a large number of mutants must be automatically derived in a systematic way. 3.5. Usage-based techniques3.5.1. Operational profile [Jor02:c15; Lyu96:c5; Pfl01:c9]In testing for reliability evaluation, the test environment must reproduce the operational environment of the software as closely as possible. The idea is to infer, from the observed test results, the future reliability of the software when in actual use. To do this, inputs are assigned a probability distribution, or profile, according to their occurrence in actual operation.3.5.2. Software Reliability Engineered Testing [Lyu96:c6]Software Reliability Engineered Testing (SRET) is a testing method encompassing the whole development process, whereby testing is “designed and guided by reliability objectives and expected relative usage and criticality of different functions in the field.”3.6.

Techniques based on the nature of the applicationThe above techniques apply to all types of software. However, for some kinds of applications, some additional know-how is required for test derivation. A list of a few specialized testing fields is provided here, based on the nature of the application under test:Object-oriented testing [Jor02:c17; Pfl01:c8s7.5] (Bin00)Component-based testingWeb-based testingGUI testing [Jor20]Testing of concurrent programs (Car91)Protocol conformance testing (Pos96; Boc94)Testing of real-time systems (Sch94)Testing of safety-critical systems (IEEE1228-94)3.7. Selecting and combining techniques3.7.1.

Functional and structural [Bei90:c1s.2.2; Jor02:c2,c9,c12; Per95:c17] (Pos96)Specification-based and code-based test techniques are often contrasted as functional vs. structural testing. These two approaches to test selection are not to be seen as alternative, but rather as complementary; in fact, they use different sources of information, and have proved to highlight different kinds of problems. They could be used in combination, depending on budgetary considerations.3.7.2. Deterministic vs.

random (Ham92; Lyu96:p541-547)Test cases can be selected in a deterministic way, according to one of the various techniques listed, or randomly drawn from some distribution of inputs, such as is usually done in reliability testing. Several analytical and empirical comparisons have been conducted to analyze the conditions that make one approach more effective than the other.”(SWEBOK, 2004 p. 5-5 to 5-7)WORKS CITEDAbran, Alain and Moore, James W., eds. (2004). Guide to the Software Engineering Body of Knowledge(SWEBOK), Version 2004.

Los Alamitos,California: IEEE Computer Society.