Unit Testing improves Software Quality Unit Testing and the Classification Tree Method

Size: px
Start display at page:

Download "Unit Testing improves Software Quality Unit Testing and the Classification Tree Method"

Transcription

1 Building a safe and secure embedded world Unit Testing improves Software Quality Unit Testing and the Classification Tree Method > White Paper Frank Büchner

2 Preface This White Paper is intended to give an overview on unit testing and the classification tree method. The documentation contains supplementary information, detailed notes, special examples, etc. For more information about current products and product versions or to access our update service, go to or The first part of this White Paper offers some general thoughts about unit testing. A simple example using the Tessy tool then shows how this might look in practice. The second part describes the classification tree method, which can be used to systematically identify test case specifications for unit testing. 2

3 Contents 1 Unit testing Introduction Module testing and unit testing in standards Modules vs. units What is Unit testing? When does unit testing make sense? Who should conduct unit testing? How is unit testing performed? Automatation is indispensible Example with Tessy The test unit The unit interface Initial test cases Conducting the test Troubleshooting and regression testing 10 2 The classification method Purpose Characteristics of the classification method Applying the classification method Identifying test-relevant aspects Classification Repeating to obtain a classification tree Specifying test cases in the combination table Example Tools to support the classification tree method 13 3 Summary 14 4 Literature 14 3

4 1 Unit testing 1.1 Introduction Module testing and unit testing in standards International standards for developing security-critical (embedded) software generally require module testing or unit testing (and software integration testing). Technical standards such as the cross-industry IEC call for module testing. Module testing is designed to show that modules provide the intended functionality and no unintended functionality. The newest edition of the standard (from 2010) recommends code coverage measures that must be measured independently of the Safety Integrity Level (SIL). The ISO standard (from 2011) requires unit testing. This standard also lists methods that should be used to identify test cases for unit testing and recommends identifying code coverage measures found in IEC The process-oriented standard Automotive SPICE uses the term software units and requires unit testing as part of their verification. In IEC 62304, which describes the software life cycle of medical device software, process step 5.5. calls for Software Unit Implementation and Verification. The industry-specific standard DIN EN (Railway applications) refers to the lowest software components as modules and requires them to be tested. ISO (Safety of machinery) also prescribes module testing in its V-model. RTCA/DO 178 (avionics) uses testing of low-level requirements and testing of software components that are verified using the requirements. Depending on the potential impact of errors in the software, DO-178 requires measurement of code coverage measures. All standards put a high value on test planning, test documentation and the option of repeating previous (successful) tests (regression testing). This also includes unit tests and module tests Modules vs. units A unit (as a test object in unit testing) is usually the smallest unit that can be sensibly tested in isolation from the rest of the application. This is consistent with ISO 26262, which defines a unit as an atomic level software component that can be subjected to stand-alone testing. For software written in C, a unit is therefore equivalent to a function as defined in C. IEC defines a software module as a construct that consists of procedures and/or data declarations. A module of this kind can also be understood as a function as defined in C, even when the definition would allow several functions in a module. Software components in DO-178 can be regarded as modules as defined in IEC 61508, which would mean that testing them is module testing. Thus, depending on the standard, the terms module and unit are used to refer to the test object. However, if you apply the definitions to a specific programming language, the end result is the same test object for the programming language C, namely a function as defined in C. To prevent a mix-up with the source modules in C, a function as defined in C is referred to as a unit in the following, not a module What is Unit testing? Unit testing tests a single function (as defined in C) in as comprehensive and isolated a way as possible. The unit is tested at its interface against its specification. We are therefore talking about a black box test in which the inner structure of the unit is not the decisive factor. The unit interface consists of the set of variables that the function reads (i.e. the input variables) and the set of variables that this unit writes (i.e. the output variables or result variables). The function s return value, if it has one, is part of the results. Of course, a variable can be an input variable and an output variable at the same time, such as when a variable is incremented by the unit. Functions that the test unit calls are also part of the interface in a broader sense. The unit s interface produces the structure of the test cases because a test case comprises 4

5 concrete values for input variables and the values for output variables that you expect when conducting a test with the available input values When does unit testing make sense? Unit tests reduce the complexity of testing. They enable us to focus on testing part of a functionality in an entire application and verify whether the unit correctly performs this functionality (although errorsensitive inputs are also checked, not just normal inputs). It can be very difficult or even impossible to define test cases for a unit that is very high in the call hierarchy so that called units that may be significantly lower in the call hierarchy are also adequately tested. Error handling of called units can be particularly difficult to test if the calling unit always uses the called unit correctly. This is why testing in isolation makes so much sense, because it avoids these problems. Since unit testing is supposed to ensure that a unit fulfills its intended function (and nothing more), security-critical units are especially predestined for unit testing. Since unit testing checks the relationship between the values of input and output variables, unit tests are particularly useful when converting input values to output values requires very complicated or extensive calculations. Examples of this are units that sort, analyze data, make complex decisions, etc. To identify units like these, you can use metrics such as McCabe s cyclomatic complexity metric. It is also good to test units that the application uses very frequently, since it is important that these units function correctly. However, there are many test questions that unit testing cannot answer by itself. One example is verifying time interactivity between units Who should conduct unit testing? It s a generally accepted fact that developers and software developers are not well-suited to testing their own code, especially when it comes to completeness of implementation or the treatment of unexpected inputs. After all, if a developer has failed to implement a functionality that the specification calls for, he or she is not likely to think about testing that missing functionality either. On the other hand, experience has shown that testers who conduct unit testing for code they did not create themselves spend most of their testing time getting to know the interface. They have to find out how interface variables convert test inputs (such as color information like green ) to concrete values, and they have to judge whether the values in the result variables are right or wrong. One way to resolve this dilemma could be for testers who did not write the code to define the required test cases based on the specification (including the expected results). They can use abstract data for this (test with color green ). They then hand the set of test cases over to the software developer to conduct. The developer now executes the test cases one by one, as long as it is simple enough for him or her to convert the abstract data provided ( green ) to concrete test data (such as an RGB value). If a test case does not provide the desired result, the developer can immediately investigate the problem and, if necessary, change the implementation. Executing the tests can thus be considered another step in processing the software, similar to a compiler checking the syntax. Many standards require an organizational separation of development and testing, and the method proposed here does not quite meet that requirement. In addition, developers are generally considered too valuable a resource to waste on testing. As a result, this type of distributed testing is rarely encountered in practice (for now) How is unit testing performed? There are different approaches you can take to test a unit. One option is to use the original application (original binary). Another is to use an application that has been created specifically for testing (test application). Original-binary testing The original-binary approach usually uses the entire application for testing, exactly as it will be in the finished product (fully translated, bundled and allocated). The process is similar to manual testing: A debugger is usually used as the execution environment for the application. A breakpoint is added at the 5

6 beginning of the unit to be tested. The next step is to start the application. After it reaches the breakpoint, the test input data for the unit is supplied and the test runs. The test result is produced at the end of the unit. Another test case can be executed as soon as the application has returned to the breakpoint at the beginning of the unit. Test-application testing The test-application approach attempts to only use the test unit from the original application. The other parts that are needed to have an executable application, known as the test drivers (for example, main() and the startup code), need to be supplied separately. The executable test application is produced from them along with the test unit. Every test unit requires its own special test application. Ideally, you should use placeholder functions (stubs) for functions that are called by the test unit. This ensures that the test unit can be tested in a reproducible way because it isolates the test unit from the behavior of the functions it calls. The special test applications may already contain the test data. That data is then transferred to the test system as soon as the test application is loaded. This can lead to problems in test systems with limited storage resources because the test application may not fit into storage when there is a large number of test cases. If test data is kept on the host, and only the test data that is needed for a specific test case is transferred to the target system, this problem does not normally occur, even if the number of test cases is very large. The drawback to this is slightly higher communication costs. Once the special test application is created, you can proceed as you would in the original-binary approach. Pros and cons The advantage of the original-binary approach is that it tests the test unit at its future address. This approach to unit testing does not require any additional effort for translation or linking because it uses the original application. It also allows you to conduct unit testing for applications that are already in a target system s ROM. In a case like that, you do not even need a compiler. (You still need a debugger though.) The original-binary approach also comes with some disadvantages. For instance, it can take a very long time for the normal application to call the test unit, which must happen for the test to take place. It is possible that the test unit will never be called under normal operation, and you will have to take special precautions to be able to execute the test, such as flipping a switch or triggering an interrupt. In an original-binary test, you cannot use placeholder functions for functions called by the test unit unless you take special steps. This is why all called units in the application are always used when the test unit is tested. As a result, test cases may show an error for a certain unit after an application has been republished, even though no changes were made to that unit. This is usually caused by a change at another point that led to an unexpected side effect. In addition, original-binary testing does not allow you to use any test input data you want. For example, if a unit receives its test data through a pointer, you can only supply as much test data as fits in the storage area that the application has provided Automatation is indispensible All standards require tests to be repeatable. The reason for this is obvious: You need to be able to repeat tests after making changes in the test object (or the development environment). Manual testing is too impractical for this purpose because it requires far too much time and effort. Instead, you need to automate at least the execution part of testing with appropriate tools. Tools can also complete other work, such as identifying the interface, managing test data, creating the test application, conducting the test, evaluating it, determining test coverage, and, last but not least, creating test documentation. 6

7 1.2 Example with Tessy The test unit As an example, let s look at a unit that solves the following problem. Say we have a number range that is specified by a start value and a length. We want to determine whether another value lies in this range (start <= value < (start + length)). We only want to look at whole numbers. This unit could be implemented in C as follows: Figure 1 Test unit This implementation has at least one obvious error. If (value == (start + length)) is true for the test value, the value will be mistakenly identified as being in the range, i.e. range_start == 5, range_len == 2 and v1 == 7 will yield yes instead of no The unit interface Tessy uses that unit s source code to automatically determine which variables in the unit are to be read or written. This identifies the unit interface. 7

8 Figure 2 The unit interface tells you the passing direction (IN / OUT) of variables The test unit has the number range (in the structure) and the test value as an input variable (IN). The result (the output) is the function s return value (OUT) Initial test cases The interface provides the structure of a test case. This lets you create ad-hoc test cases and fill them with data. But actually, test cases should be identified using the classification tree method. This is explained in part two. Figure 3 Entering test data for two ad-hoc test cases 8

9 We have created two ad-hoc test cases. The test cases or test data can be exported to Excel or another program and displayed there. (Test cases can also be imported from Excel.) Figure 4 Test cases displayed in Excel Conducting the test Generating the test application Tessy can generate the source code needed to create a special test application and translate and bind it with the source code from the test unit. It can do this with a cross-compiler for the desired target system or the Gnu C compiler. Loading the application Tessy loads the application to the target system for the test. This usually happens through a suitable debugger that Tessy controls. The debugger can control an instruction-set simulator, an in-circuit emulator with or without connected hardware, an OCDS / BDM / JTAG debugger or similar as a test target system. The tests can therefore be executed on real hardware if desired. Conducting all tests Tessy keeps the test data separate from the test application. For this reason, Tessy starts by transferring the test input data needed to conduct the first test case to the test target system. Tessy then conducts the test and determines the output data. It repeats this process for all remaining tests. Test evaluation and documentation Tessy uses a comparison of output data and expected results to specify the test result (passed or failed), which is displayed in green or red. You can have Tessy create test documentation as a PDF, Word or HTML file. There is also an XML option, which is intended for machines. Figure 5 Test results with details from the second test case Measuring code coverage Tessy can measure a test s Entry Point Coverage, Statement Coverage, Branch Coverage, Decision Coverage, Modified Condition / Decision Coverage (MC/DC), and Function Coverage. 9

10 1.2.5 Troubleshooting and regression testing Tessy enables a smooth transition from testing to debugging. A test case that yielded an unexpected result can be repeated in such a way that test-unit debugging begins immediately. Tessy achieves this by setting a breakpoint at the test unit. There are essentially two reasons why a test would yield an unexpected result: Either the expected result is incorrect or there is a flaw in the implementation of the unit. Once the (presumed) cause of the problem is identified and corrected, Tessy can be automated to repeat the test, and not just for the test case in question but for all the test cases that have been (successfully) conducted before it. This is particularly important if the software was modified to correct the error, because previous tests would then have been based on a different implementation of the unit, which would mean they are no longer valid. 2 The classification method 2.1 Purpose The classification tree method transforms a (functional) specification into a set of error-sensitive, lowredundancy test case specifications. This methodical process is intended to ensure that no important test cases are overlooked, i.e. the resulting set of test case specifications should contain all relevant test cases. Under this assumption, the method also provides a test completion criterion. 2.2 Characteristics of the classification method The classification tree method is generally applicable, i.e. it can be used for functional problems outside of software development as well. The classification tree method is not automatic; a person needs to apply it. This means, of course, that the result depends on the thinking and estimations of that human being. It is therefore advantageous for the user to be familiar with the problem and its environment. Different users are likely to identify different sets of test case specifications as a result for the same functional problem. Human error cannot be fully ruled out either. This contrasts with the systematic process that is expected of the user of this method and which leads him or her to specify test cases with a high probability of revealing an error. A key advantage of the classification tree method is that it presents test ideas visually, making them easy to understand in situations such as reviews. Reviews are an effective way of increasing the certainty that no test case specifications are missing. The classification tree method integrates several known approaches for deriving test cases, such as the equivalence partitioning method and the idea to test the boundaries of a range. 2.3 Applying the classification method Identifying test-relevant aspects The classification tree method starts with an analysis of the functional specification, or to put it another way, with a human user thinking about that specification. The goal here is to recognize what are called the test-relevant aspects of the problem. The variety of values that these aspects can take on guarantees a variety of different meaningful test cases. Example of a test-relevant aspects For a distance measuring device that measures distances with ultrasound, the temperature of the medium (air) is a test-relevant aspect because it influences the speed at which sound travels through the air. For this reason, it makes sense to conduct tests at different temperatures to check whether the temperature has been correctly incorporated into the distance calculation from the travel time. Air temperature does not play a role for a distance measuring device that uses radar instead of ultrasound (it even works without air). Thus, tests at different temperatures would not be meaningful and temperature is not a (meaningful) test-relevant aspect. This example also shows that it makes sense for the person using the method to have some familiarity with the problem environment. 10

11 2.3.2 Classification Once all test-relevant aspects are found, you need to look at the values that each aspect can accept. The next step is to divide the value range you found into classes, just like in the equivalence partitioning method. All values in the class should be considered to be equivalent for the test, i.e. the test result is not affected by which value from a class you use for the test Repeating to obtain a classification tree You can divide each class into sub-classes based on other aspects. Repeatedly forming sub-classifications by using the classes they belong to will ultimately produce a classification tree. The problem forms the root of the tree, which grows from the top down. Classifications are framed in boxes. Dividing the problem up into different aspects that can subsequently be refined separately, as described above, reduces the complexity of the original test problem significantly. Figure 6 Schematic for a classification tree with a combined table Specifying test cases in the combination table The leaves of the classification tree form the head of the combination table. A row in the combination table specifies a test case by marking the leaf classes of the tree from which a value is used for this test case. However, the method is not intended as a way to mechanically specify all possible combinations of leaf classes as test cases. Instead, the user should use a test case to cover multiple aspects in order to arrive at a minimal non-redundant set of test case specifications. Like when creating the tree, the number of test cases specified (and which ones) depends on the user s judgment. Clearly, a tree with many leaf classes requires more test cases than a tree with a small number of leaves. As a rule of thumb, the number of leaves should be the same as the number of test cases needed for reasonable coverage of a classification tree. 11

12 2.4 Example For the functional specification in part one ( Does a value lie in a range? ), you want to identify test cases using the classification tree method. The location of the range (given by a start value and length) and the position of the value that is to be identified as lying in the range or not can be considered test-relevant aspects, because in light of the length, for example, it makes sense to test using ranges of different lengths. A specification normally offers a basis for classifying test-relevant aspects. In the present specification, however, this is not the case for the start value of the range. As a result, all we can do is make a trivial division of the start values into negative and positive. (If the specification said something like, If the start value is even, the length doubles, it would be clear that we would need a class with even start values and a class with odd start values.) Zero gets its own class, but you could also assign zero to the class with positive (or negative) values; users should use their own best judgment here. For the length aspect, the same considerations apply as for the start value. The only difference is that it makes very good sense to create a separate class for the length of 0, because this ensures that there will be at least one test case in which the range has a length of 0. These considerations lead to a preliminary classification tree for the range s start and length aspects; the aspect for the position of the value is not part of the tree yet. Also preliminary is the specification in the combination table of two test cases (strictly speaking, they are ranges). This produces the following figure: Figure 7 Rudimentary classification tree for the range and two specifications The first specification combines a positive start value with a positive length. The range with a start value of 5 and a length of 2, which was used in the two ad-hoc test cases in part one, matches this specification. In that respect, this range specification is not extraordinary. The second test case is different. It combines a negative start value (such as 5) with a negative length (such as 2), which leads directly to the question of what values should be in a range like this. Should it contain 4 or 6 or is it better if it has no values at all? The problem specification should actually provide the answer to this question, but it does not. As a result, this question cannot and should not be decisively answered here. However, it is important to add that systematically applying the classification tree method can also reveal problems in the specification. If you extend the rudimentary classification tree to include the aspect of position, the two classes will obviously be inside or outside the range. It is equally obvious that the outside class will need to be further classified according to whether the value is below or above the range. Taking into consideration that preference should be given to tests on the borders of the range and that the largest positive number and smallest negative number could be interesting start values for the range gives rise to the following tree and a matching set of test case specifications. 12

13 Figure 8 Complete classification tree with test case specifications Test case specification 6 describes the combination of a negative start value and a negative length. A value should be chosen that is within the range, and, more specifically, on the border opposite the start value. This assumes that the problem specification has been extended to allow for this. Test case specifications 11 and 12 combine the largest possible positive start value with a positive length. Here, the start value is in the range, which test case specification 11 checks. Test case specification 12 makes sure that no other values, such as a very large negative value, are mistakenly identified as being in the range through wrap-around. In addition to the test case specifications given for the classification tree shown, there are other sets of test case specifications that make just as much sense. It is easy to imagine other classification trees too. However, it is important for users of the classification tree method to clarify what they hope to achieve through the test by carefully choosing the names of classes, classifications and test cases. 2.5 Tools to support the classification tree method There is a special tool you can use to apply the classification tree method the Classification Tree Editor (CTE). It offers a syntax-controlled graphical editor for creating classification trees. You can also manage large classification trees by moving refinements (sub-trees) to additional drawing areas. A navigator window makes it easier to orient yourself and move around in the trees. Descriptions and attributes can be added to elements in the tree. You can also use color in your tree. CTE helps compile test case specifications in the combination table by using the structure of the tree to automatically prevent invalid specifications (for instance, the start value cannot be positive and negative at the same time). The trees and test case specifications that you create can be documented and printed in different formats. Tessy includes CTE, and test cases specified in CTE can be transferred to Tessy. 13

14 3 Summary Unit testing is just one of many ways to ensure and improve software quality. Unit testing enables you to test small units that may be hidden in the overall system under extreme conditions, such as with invalid inputs, which would not otherwise be possible during system tests. Separately testing individual units reduces the overall complexity of testing. Errors can be directly assigned to a specific unit, and you do not need to search the entire application for them. The subsequent application is made up of separately tested individual components, which reduces the likelihood of errors during your system test. Once you have compiled an adequate set of test cases for testing a unit (the classification tree method is particularly well-suited for this purpose), you will have a good foundation for revising the unit. If, after revising the unit, all of the test cases still provide the expected result, it is safe to assume that the revision is okay. It is impractical to deploy unit testing without the help of certain tools, especially if you want to conduct regression tests. Tessy, CTE and the classification tree method come from the software technology lab of Daimler AG. They have been used in practice for a number of years, especially in the automotive industry. 4 Literature [1] [2] Grochtmann, M., Grimm, K.: Classification Trees For Partition testing, Software testing, Verification & Reliability, Volume 3, Number 2, June 1993, Wiley, pp [3] Wegener, J., Pitschinetz, R.: Tessy Another Overall Unit Testing Tool, Quality Week [4] Grimm, Klaus: Systematisches Testen von Software: Eine neue Methode und eine effektive Teststrategie. München, Wien, Oldenburg, GMD-Berichte Nr [5] Liggesmeyer, Peter: Software-Qualität: Testen, Analysieren und Verifizieren von Software. Heidelberg, Berlin, Spektrum Akademischer Verlag. [6] Broekman, B., Notenboom, E.: Testing Embedded Software. Addison-Wesly, About the Author: Frank Büchner, Principal Engineer Software Quality, Hitex GmbH Frank Büchner has a degree in IT and has been working in the Embedded Software Division at Hitex for over 25 years. He has been involved in a variety of tasks through the years, from embedded software development to his current position as Principal Engineer Software Quality. Frank has been dealing with the topic of testing and software quality for several years. He shares his knowledge through regular talks and specialist articles. 14

15 Building a safe and secure embedded world Hitex Head Office, Germany Hitex UK Hitex GmbH Greschbachstraße Karlsruhe Germany Phone: Fax: Hitex (UK) Ltd Millburn Hill Road University of Warwick Science Park Coventry CV4 7HS United Kingdom Phone: Fax: WP-UNITTEST-E Consulting Engineering Testing Training Tools Software Components Systems Manufacturing

Hitex Germany. White Paper. Unit Test of Embedded Software

Hitex Germany. White Paper. Unit Test of Embedded Software Hitex Germany Head Quarters Greschbachstr. 12 76229 Karlsruhe Germany +049-721-9628-0 Fax +049-721-9628-149 E-mail: Sales@hitex.de WEB: www.hitex.de Hitex UK Warwick University Science Park Coventry CV47EZ

More information

TESSY Automated dynamic module/unit and. CTE Classification Tree Editor. integration testing of embedded applications. for test case specifications

TESSY Automated dynamic module/unit and. CTE Classification Tree Editor. integration testing of embedded applications. for test case specifications TESSY Automated dynamic module/unit and integration testing of embedded applications CTE Classification Tree Editor for test case specifications Automated module/unit testing and debugging at its best

More information

Test Case Design Using Classification Trees and the Classification-Tree Editor CTE

Test Case Design Using Classification Trees and the Classification-Tree Editor CTE Quality Week 1995 Test Case Design Using Classification Trees and the Classification-Tree Editor CTE Matthias Grochtmann Joachim Wegener Klaus Grimm Daimler-Benz AG Research and Technology Alt-Moabit 96a

More information

Test Case Design Using Classification Trees

Test Case Design Using Classification Trees STAR 94, 8-12 May 1994, Washington, D.C. Test Case Design Using Classification Trees Matthias Grochtmann Daimler-Benz AG Forschung und Technik Alt-Moabit 91b D-10559 Berlin, Germany Tel: +49 30 39 982-229

More information

We drive Aurix to success Aurix Services for Automotive & Industrial

We drive Aurix to success Aurix Services for Automotive & Industrial Building a safe and secure embedded world We drive Aurix to success Aurix Services for Automotive & Industrial > Services HITEX: An Preferred Design House (PDH) Questions about? Ask us Aurix Services for

More information

TESSY -- An Overall Unit Testing Tool

TESSY -- An Overall Unit Testing Tool Quality Week 1995 TESSY -- An Overall Unit Testing Tool Joachim Wegener Roman Pitschinetz Daimler-Benz AG Research and Technology Alt-Moabit 96 a D-10559 Berlin, Germany Tel: +49 (0)30 39982-232 Fax: +49

More information

AURIX Preferred Design House. Hitex Development Tools GmbH Hitex (UK) Ltd.

AURIX Preferred Design House. Hitex Development Tools GmbH Hitex (UK) Ltd. AURIX Preferred Design House Hitex Development Tools GmbH Hitex (UK) Ltd. Company Profile Founded in 1976 38 years of experience in microcontroller technology Part of the Infineon Group since 2003 Leading

More information

Improved Software Testing Using McCabe IQ Coverage Analysis

Improved Software Testing Using McCabe IQ Coverage Analysis White Paper Table of Contents Introduction...1 What is Coverage Analysis?...2 The McCabe IQ Approach to Coverage Analysis...3 The Importance of Coverage Analysis...4 Where Coverage Analysis Fits into your

More information

Is 100% Code Coverage Enough? > TESSY White Paper Author: Frank Büchner. Nomenclature, measures and values of code coverage

Is 100% Code Coverage Enough? > TESSY White Paper Author: Frank Büchner. Nomenclature, measures and values of code coverage Building a safe and secure embedded world Is 100% Code Coverage Enough? Nomenclature, measures and values of code coverage > TESSY White Paper Author: Frank Büchner Preface In order to keep you up-to-date

More information

Hitex Germany. Application Note. ARM Debugging - Startup Behaviour after Reset

Hitex Germany. Application Note. ARM Debugging - Startup Behaviour after Reset Hitex Germany Head Quarters Greschbachstr. 12 76229 Karlsruhe Germany +049-721-9628-0 Fax +049-721-9628-149 E-mail: Sales@hitex.de WEB: www.hitex.de Hitex UK Warwick University Science Park Coventry CV47EZ

More information

Testing, Debugging, and Verification

Testing, Debugging, and Verification Testing, Debugging, and Verification Testing, Part II Moa Johansson 10 November 2014 TDV: Testing /GU 141110 1 / 42 Admin Make sure you are registered for the course. Otherwise your marks cannot be recorded.

More information

Test Case Design by Means of the CTE XL

Test Case Design by Means of the CTE XL Test Case Design by Means of the CTE XL Eckard Lehmann and Joachim Wegener DaimlerChrysler AG Research and Technology Alt-Moabit 96 a D-10559 Berlin Eckard.Lehmann@daimlerchrysler.com Joachim.Wegener@daimlerchrysler.com

More information

APPROACHES TO SOFTWARE TESTING PROGRAM VERIFICATION AND VALIDATION

APPROACHES TO SOFTWARE TESTING PROGRAM VERIFICATION AND VALIDATION 1 APPROACHES TO SOFTWARE TESTING PROGRAM VERIFICATION AND VALIDATION Validation: Are we building the right product? Does program meet expectations of user? Verification: Are we building the product right?

More information

Data Extraction Guide

Data Extraction Guide 1 Data Extraction Guide One of the big advantages of process mining is that it starts with the data that is already there, and usually it starts very simple. There is no need to first set up a data collection

More information

Advanced Testing Techniques

Advanced Testing Techniques 9 March, 2010 ISSN 1866-5705 www.testingexperience.com free digital version print version 8,00 printed in Germany Advanced Testing Techniques Conferences Special istockphoto.com/nwphotoguy istockphoto.com/esemelwe

More information

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT

SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT SOFTWARE DEVELOPMENT STANDARD FOR SPACECRAFT Mar 31, 2014 Japan Aerospace Exploration Agency This is an English translation of JERG-2-610. Whenever there is anything ambiguous in this document, the original

More information

Standard for Software Component Testing

Standard for Software Component Testing Standard for Software Component Testing Working Draft 3.4 Date: 27 April 2001 produced by the British Computer Society Specialist Interest Group in Software Testing (BCS SIGIST) Copyright Notice This document

More information

Software Testing Interview Questions

Software Testing Interview Questions Software Testing Interview Questions 1. What s the Software Testing? A set of activities conducted with the intent of finding errors in software. 2.What is Acceptance Testing? Testing conducted to enable

More information

Case studies: Outline. Requirement Engineering. Case Study: Automated Banking System. UML and Case Studies ITNP090 - Object Oriented Software Design

Case studies: Outline. Requirement Engineering. Case Study: Automated Banking System. UML and Case Studies ITNP090 - Object Oriented Software Design I. Automated Banking System Case studies: Outline Requirements Engineering: OO and incremental software development 1. case study: withdraw money a. use cases b. identifying class/object (class diagram)

More information

WebSphere Business Monitor

WebSphere Business Monitor WebSphere Business Monitor Debugger 2010 IBM Corporation This presentation provides an overview of the monitor model debugger in WebSphere Business Monitor. WBPM_Monitor_Debugger.ppt Page 1 of 23 Goals

More information

Software Security Analysis: Control Flow Security Analysis with McCabe IQ

Software Security Analysis: Control Flow Security Analysis with McCabe IQ Software Security Analysis: Control Flow Security Analysis with McCabe IQ Applying a Path-based Method to Vulnerability Assessment of the Microsoft SDL Banned Function Calls Introduction When considering

More information

Acceptance Criteria. Software Engineering Group 6. 0/3/2012: Acceptance Criteria, v2.0 March 2012 - Second Deliverable

Acceptance Criteria. Software Engineering Group 6. 0/3/2012: Acceptance Criteria, v2.0 March 2012 - Second Deliverable Acceptance Criteria Software Engineering Group 6 0/3/2012: Acceptance Criteria, v2.0 March 2012 - Second Deliverable 1 Contents: Page no: Introduction...3 Test Environment...4 Acceptance Tests...5 Types

More information

Testing A Tutorial. Alexander Klaus. Fraunhofer IESE. Dept. Information Systems Quality Assurance

Testing A Tutorial. Alexander Klaus. Fraunhofer IESE. Dept. Information Systems Quality Assurance Testing A Tutorial Alexander Klaus Fraunhofer IESE Dept. Information Systems Quality Assurance Alexander.Klaus@.iese.fraunhofer.de 0631-6800 2245 Room B3.20 Agenda Introduction Functional Testing Structural

More information

With Bosch Software Innovations ConnectedManufacturing Solutions.

With Bosch Software Innovations ConnectedManufacturing Solutions. Manufacturing Analytics tools & services Analyze production data, add value. www.bosch-si.com/manufacturing-analytics With Bosch Software Innovations ConnectedManufacturing Solutions. Software Innovations

More information

Test Specification. Introduction

Test Specification. Introduction Test Specification Introduction Goals and Objectives GameForge is a graphical tool used to aid in the design and creation of video games. A user with little or no experience with Microsoft DirectX and/or

More information

Advanced Software Test Design Techniques Decision Tables and Cause-Effect Graphs

Advanced Software Test Design Techniques Decision Tables and Cause-Effect Graphs Introduction Advanced Software Test Design Techniques Decision Tables and Cause-Effect Graphs The following is an excerpt from my recently-published book, Advanced Software Testing: Volume 1. This is a

More information

Chapter 3 Introduction to Predictive Modeling: Predictive Modeling Fundamentals and Decision Trees

Chapter 3 Introduction to Predictive Modeling: Predictive Modeling Fundamentals and Decision Trees Chapter 3 Introduction to Predictive Modeling: Predictive Modeling Fundamentals and Decision Trees 3.1 Creating Training and Validation Data... 3-2 3.2 Constructing a Decision Tree Predictive Model...

More information

Quality Assurance. Pragmatic Programmer Tip Think about Your Work

Quality Assurance. Pragmatic Programmer Tip Think about Your Work Quality Assurance Pragmatic Programmer Tip Think about Your Work Turn off the autopilot and take control. Constantly critique and appraise your work. Readings Required: Rapid Development, McConnell, Chapter

More information

Introduction to Automated Testing

Introduction to Automated Testing Introduction to Automated Testing What is Software testing? Examination of a software unit, several integrated software units or an entire software package by running it. execution based on test cases

More information

Software Testing. Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program.

Software Testing. Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program. Software Testing Definition: Testing is a process of executing a program with data, with the sole intention of finding errors in the program. Testing can only reveal the presence of errors and not the

More information

CHAPTER 3 Numbers and Numeral Systems

CHAPTER 3 Numbers and Numeral Systems CHAPTER 3 Numbers and Numeral Systems Numbers play an important role in almost all areas of mathematics, not least in calculus. Virtually all calculus books contain a thorough description of the natural,

More information

Muslah Systems Agile Development Process

Muslah Systems Agile Development Process Muslah Systems, Inc. Agile Development Process 1 Muslah Systems Agile Development Process Iterative Development Cycles Doug Lahti December 7, 2009 October 5, 2010 In consideration of controllable systems

More information

Software testing. Objectives

Software testing. Objectives Software testing cmsc435-1 Objectives To discuss the distinctions between validation testing and defect testing To describe the principles of system and component testing To describe strategies for generating

More information

Test Design Strategies

Test Design Strategies Test Design Strategies Louise Tamres, CSQE ASQ Software Division Webinar 18 July 2008 1 Objectives Translate requirements into test cases Improve communication by producing models Identify incomplete requirements

More information

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References

Outline. 1 Denitions. 2 Principles. 4 Implementation and Evaluation. 5 Debugging. 6 References Outline Computer Science 331 Introduction to Testing of Programs Mike Jacobson Department of Computer Science University of Calgary Lecture #3-4 1 Denitions 2 3 4 Implementation and Evaluation 5 Debugging

More information

Creating a Project with PSoC Designer

Creating a Project with PSoC Designer Creating a Project with PSoC Designer PSoC Designer is two tools in one. It combines a full featured integrated development environment (IDE) with a powerful visual programming interface. The two tools

More information

Building Mobile Applications With The.NET Compact Framework

Building Mobile Applications With The.NET Compact Framework .NET Mobile Application Development 1 Building Mobile Applications With The.NET Compact Framework Objectives The aim of this tutorial is to provide a practical introduction to the use of the.net Compact

More information

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com

Reduce Medical Device Compliance Costs with Best Practices. mark.pitchford@ldra.com Reduce Medical Device Compliance Costs with Best Practices mark.pitchford@ldra.com 1 Agenda Medical Software Certification How new is Critical Software Certification? What do we need to do? What Best Practises

More information

Functional Testing. in contrast to structural or white-box testing, where the program is the base.

Functional Testing. in contrast to structural or white-box testing, where the program is the base. From Pressman, Software Engineering a practitionerʼs approach, Chapter 14 and Pezze + Young, Software Testing and Analysis, Chapters 10-11 Testing Today, weʼll talk about testing how to test software.

More information

Global Access Quick Start Doc. Steps

Global Access Quick Start Doc. Steps Here is a link to the Getting Started webpage. Before We Begin: Global Access Quick Start Doc. Steps This guide is designed to take the new Global Access user step by step through the process of validating

More information

Desktop, Web and Mobile Testing Tutorials

Desktop, Web and Mobile Testing Tutorials Desktop, Web and Mobile Testing Tutorials * Windows and the Windows logo are trademarks of the Microsoft group of companies. 2 About the Tutorial With TestComplete, you can test applications of three major

More information

Microsoft Excel IF & AND Functions. By Stephen Groulx

Microsoft Excel IF & AND Functions. By Stephen Groulx Microsoft Excel IF & AND Functions By Stephen Groulx Excel IF & AND Functions Table of Contents Page Introduction... 3 IF Function, Simplified... 6 IF Function, Nested... 8 AND Function... 16 Assumptions

More information

White Papers: Unit Testing. www.dcmtech.com. Unit Testing

White Papers: Unit Testing. www.dcmtech.com. Unit Testing Unit Testing Table of Contents TESTING, VERIFICATION AND VALIDATION...1 UNIT TESTING PROCEDURES...3 C1 100% COVERAGE...3 QUERY GENERATION...4 TESTING, VERIFICATION and VALIDATION Black Box Testing White

More information

A binary search tree or BST is a binary tree that is either empty or in which the data element of each node has a key, and:

A binary search tree or BST is a binary tree that is either empty or in which the data element of each node has a key, and: Binary Search Trees 1 The general binary tree shown in the previous chapter is not terribly useful in practice. The chief use of binary trees is for providing rapid access to data (indexing, if you will)

More information

Smarter Balanced Assessment Consortium. Recommendation

Smarter Balanced Assessment Consortium. Recommendation Smarter Balanced Assessment Consortium Recommendation Smarter Balanced Quality Assurance Approach Recommendation for the Smarter Balanced Assessment Consortium 20 July 2012 Summary When this document was

More information

Best Practices for Verification, Validation, and Test in Model- Based Design

Best Practices for Verification, Validation, and Test in Model- Based Design 2008-01-1469 Best Practices for Verification, Validation, and in Model- Based Design Copyright 2008 The MathWorks, Inc. Brett Murphy, Amory Wakefield, and Jon Friedman The MathWorks, Inc. ABSTRACT Model-Based

More information

Comparing Automated Test Design Methods

Comparing Automated Test Design Methods A Conformiq White Paper Comparing Automated Test Design Methods How automatic is your automated test design process? There are three primary methods used in automated test design tools. They all deliver

More information

CHAPTER THREE. 3.1 Binary Addition. Binary Math and Signed Representations

CHAPTER THREE. 3.1 Binary Addition. Binary Math and Signed Representations CHAPTER THREE Binary Math and Signed Representations Representing numbers with bits is one thing. Doing something with them is an entirely different matter. This chapter discusses some of the basic mathematical

More information

Advanced Software Test Design Techniques Use Cases

Advanced Software Test Design Techniques Use Cases Advanced Software Test Design Techniques Use Cases Introduction The following is an excerpt from my recently-published book, Advanced Software Testing: Volume 1. This is a book for test analysts and test

More information

Automatic Test Data Generation for TTCN-3 using CTE

Automatic Test Data Generation for TTCN-3 using CTE Automatic Test Data Generation for TTCN-3 using CTE Zhen Ru Dai, Peter H. Deussen, Maik Busch, Laurette Pianta Lacmene, Titus Ngwangwen FraunhoferInstitute for Open Communication Systems (FOKUS) Kaiserin-Augusta-Allee

More information

Hypothesis Testing for Beginners

Hypothesis Testing for Beginners Hypothesis Testing for Beginners Michele Piffer LSE August, 2011 Michele Piffer (LSE) Hypothesis Testing for Beginners August, 2011 1 / 53 One year ago a friend asked me to put down some easy-to-read notes

More information

Compute Cluster Server Lab 3: Debugging the parallel MPI programs in Microsoft Visual Studio 2005

Compute Cluster Server Lab 3: Debugging the parallel MPI programs in Microsoft Visual Studio 2005 Compute Cluster Server Lab 3: Debugging the parallel MPI programs in Microsoft Visual Studio 2005 Compute Cluster Server Lab 3: Debugging the parallel MPI programs in Microsoft Visual Studio 2005... 1

More information

Team Development with Zend Studio for Eclipse

Team Development with Zend Studio for Eclipse White Paper: Team Development with Zend Studio for Eclipse Technologies January 2008 2008 Zend Technologies, Ltd. All rights reserved. Table of Contents Table of Contents... 2 Introduction... 3 Source

More information

CALCULATIONS & STATISTICS

CALCULATIONS & STATISTICS CALCULATIONS & STATISTICS CALCULATION OF SCORES Conversion of 1-5 scale to 0-100 scores When you look at your report, you will notice that the scores are reported on a 0-100 scale, even though respondents

More information

National University of Ireland, Maynooth MAYNOOTH, CO. KILDARE, IRELAND. Testing Guidelines for Student Projects

National University of Ireland, Maynooth MAYNOOTH, CO. KILDARE, IRELAND. Testing Guidelines for Student Projects National University of Ireland, Maynooth MAYNOOTH, CO. KILDARE, IRELAND. DEPARTMENT OF COMPUTER SCIENCE, TECHNICAL REPORT SERIES Testing Guidelines for Student Projects Stephen Brown and Rosemary Monahan

More information

University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities

University of Paderborn Software Engineering Group II-25. Dr. Holger Giese. University of Paderborn Software Engineering Group. External facilities II.2 Life Cycle and Safety Safety Life Cycle: The necessary activities involving safety-related systems, occurring during a period of time that starts at the concept phase of a project and finishes when

More information

A PRODUCT METRICS TOOL INTEGRATED INTO

A PRODUCT METRICS TOOL INTEGRATED INTO A PRODUCT METRICS TOOL INTEGRATED INTO A SOFTWARE DEVELOPMENT ENVIRONMENT Claus Lewerentz, Frank Simon Software and Systems Development Group Computer Science Department, Technical University of Cottbus

More information

EMBEDDED C PROGRAMMING MANUAL

EMBEDDED C PROGRAMMING MANUAL FUJITSU SEMICONDUCTOR CONTROLLER MANUAL CM71-00324-1E FR FAMILY 32-BIT MICROCONTROLLER EMBEDDED C PROGRAMMING MANUAL FOR fcc911 FR FAMILY 32-BIT MICROCONTROLLER EMBEDDED C PROGRAMMING MANUAL FOR fcc911

More information

Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP

Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP PROGRAMMING & SOFTWARE DEVELOPMENT AND INFORMATION SUPPORT & SERVICES PATHWAY SOFTWARE UNIT UNIT 5 Programming & and Support & s: (Unit 5) PAGE

More information

Computing Concepts with Java Essentials

Computing Concepts with Java Essentials 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Computing Concepts with Java Essentials 3rd Edition Cay Horstmann

More information

Global Journal of Enterprise Information System January 2009-June 2009

Global Journal of Enterprise Information System January 2009-June 2009 COMPARED TO MANUAL TESTING Page 126 1. Introduction Software testing is the process of executing a program with the intention of finding errors in the code. It is the process of exercising or evaluating

More information

7.0. What s New in. SOFTWARE QUALITY ASSURANCE TOOLS & TECHNOLOGY PROFESSIONAL SERVICES ACADEMY P a g e 1

7.0. What s New in.  SOFTWARE QUALITY ASSURANCE TOOLS & TECHNOLOGY PROFESSIONAL SERVICES ACADEMY P a g e 1 SOFTWARE QUALITY ASSURANCE TOOLS & TECHNOLOGY PROFESSIONAL SERVICES ACADEMY P a g e 1 What s New in 7.0 Cantata 7.0, available from February 2016, is a major new release of Cantata. This document outlines

More information

Appendix B Data Quality Dimensions

Appendix B Data Quality Dimensions Appendix B Data Quality Dimensions Purpose Dimensions of data quality are fundamental to understanding how to improve data. This appendix summarizes, in chronological order of publication, three foundational

More information

Software Test Automation Best Practices

Software Test Automation Best Practices Software Test Automation Best Practices 2 Test automation is a critical regression activity. Yet for many reasons, automation projects often fail. Follow these best practices to improve your chances of

More information

The Human Side of Test Automation

The Human Side of Test Automation White Paper Silk The Human Side of Test Automation Improving User Experience in an Increasingly Complex Environment White Paper The Human Side of Test Automation Introduction: Human Interaction We ve dreamed

More information

3 SOFTWARE AND PROGRAMMING LANGUAGES

3 SOFTWARE AND PROGRAMMING LANGUAGES 3 SOFTWARE AND PROGRAMMING LANGUAGES 3.1 INTRODUCTION In the previous lesson we discussed about the different parts and configurations of computer. It has been mentioned that programs or instructions have

More information

Introduction to Embedded Systems. Software Update Problem

Introduction to Embedded Systems. Software Update Problem Introduction to Embedded Systems CS/ECE 6780/5780 Al Davis logistics minor Today s topics: more software development issues 1 CS 5780 Software Update Problem Lab machines work let us know if they don t

More information

Industrial Engineering Prof. Inderdeep Singh Department of Mechanical and Industrial Engineering Indian Institute of Technology, Roorkee

Industrial Engineering Prof. Inderdeep Singh Department of Mechanical and Industrial Engineering Indian Institute of Technology, Roorkee Industrial Engineering Prof. Inderdeep Singh Department of Mechanical and Industrial Engineering Indian Institute of Technology, Roorkee Module - 04 Lecture - 03 Materials Requirement Planning A very warm

More information

EECS 211 Introduction to Compiling and Linking

EECS 211 Introduction to Compiling and Linking EECS 211 Introduction to Compiling and Linking The transformation of a set of C++ source and header files into an executable file requires many steps. This document provides a brief overview of those steps

More information

Quality control is performed after working with text and focuses on finding and removing any technical, linguistic and editorial errors.

Quality control is performed after working with text and focuses on finding and removing any technical, linguistic and editorial errors. TRANSLATION AS A PRODUCT TRANSLATION PROJECT MANAGEMENT IN A MODERN COMPANY Each translation project is coordinated by a Project Manager who is responsible for meeting the requirements for all aspects

More information

Chapter 8 Software Testing

Chapter 8 Software Testing Chapter 8 Software Testing Summary 1 Topics covered Development testing Test-driven development Release testing User testing 2 Program testing Testing is intended to show that a program does what it is

More information

Math 016. Materials With Exercises

Math 016. Materials With Exercises Math 06 Materials With Exercises June 00, nd version TABLE OF CONTENTS Lesson Natural numbers; Operations on natural numbers: Multiplication by powers of 0; Opposite operations; Commutative Property of

More information

Test Automation Architectures: Planning for Test Automation

Test Automation Architectures: Planning for Test Automation Test Automation Architectures: Planning for Test Automation Douglas Hoffman Software Quality Methods, LLC. 24646 Heather Heights Place Saratoga, California 95070-9710 Phone 408-741-4830 Fax 408-867-4550

More information

Formal Software Testing. Terri Grenda, CSTE IV&V Testing Solutions, LLC www.ivvts.com

Formal Software Testing. Terri Grenda, CSTE IV&V Testing Solutions, LLC www.ivvts.com Formal Software Testing Terri Grenda, CSTE IV&V Testing Solutions, LLC www.ivvts.com Scope of Testing Find defects early Remove defects prior to production Identify Risks Unbiased opinion When Should Testing

More information

Social Return on Investment

Social Return on Investment Social Return on Investment Valuing what you do Guidance on understanding and completing the Social Return on Investment toolkit for your organisation 60838 SROI v2.indd 1 07/03/2013 16:50 60838 SROI v2.indd

More information

Introduction to Computers and Programming. Testing

Introduction to Computers and Programming. Testing Introduction to Computers and Programming Prof. I. K. Lundqvist Lecture 13 April 16 2004 Testing Goals of Testing Classification Test Coverage Test Technique Blackbox vs Whitebox Real bugs and software

More information

Certification of a Scade 6 compiler

Certification of a Scade 6 compiler Certification of a Scade 6 compiler F-X Fornari Esterel Technologies 1 Introduction Topic : What does mean developping a certified software? In particular, using embedded sofware development rules! What

More information

Software Testing Strategies and Techniques

Software Testing Strategies and Techniques Software Testing Strategies and Techniques Sheetal Thakare 1, Savita Chavan 2, Prof. P. M. Chawan 3 1,2 MTech, Computer Engineering VJTI, Mumbai 3 Associate Professor, Computer Technology Department, VJTI,

More information

Example Software Development Process.

Example Software Development Process. Example Software Development Process. The example software development process is shown in Figure A. The boxes represent the software development process kernels. The Software Unit Testing, Software Component

More information

Part 1 Expressions, Equations, and Inequalities: Simplifying and Solving

Part 1 Expressions, Equations, and Inequalities: Simplifying and Solving Section 7 Algebraic Manipulations and Solving Part 1 Expressions, Equations, and Inequalities: Simplifying and Solving Before launching into the mathematics, let s take a moment to talk about the words

More information

Software Engineering. How does software fail? Terminology CS / COE 1530

Software Engineering. How does software fail? Terminology CS / COE 1530 Software Engineering CS / COE 1530 Testing How does software fail? Wrong requirement: not what the customer wants Missing requirement Requirement impossible to implement Faulty design Faulty code Improperly

More information

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali

Software development life cycle. Software Engineering - II ITNP92 - Object Oriented Software Design. Requirements. Requirements. Dr Andrea Bracciali Software development life cycle Software life cycle: Software Engineering - II ITNP92 - Object Oriented Software Design Dr Andrea Bracciali Module Co-ordinator 4B86 abb@cs.stir.ac.uk Spring 2014 (elicitation)

More information

Lab 2.1 Tracking Down the Bugs

Lab 2.1 Tracking Down the Bugs Lab 2.1 Tracking Down the Bugs Chapter 7 (To Err is Human ) discusses strategies for debugging finding and fixing problems with IT systems. In this lab, we focus on the early stages of debugging, where

More information

Database design basics

Database design basics Microsoft Office Access Database design basics Applies to: Microsoft Office Access 2007 A properly designed database provides you with access to up-to-date, accurate information. Because a correct design

More information

Memory Management Outline. Background Swapping Contiguous Memory Allocation Paging Segmentation Segmented Paging

Memory Management Outline. Background Swapping Contiguous Memory Allocation Paging Segmentation Segmented Paging Memory Management Outline Background Swapping Contiguous Memory Allocation Paging Segmentation Segmented Paging 1 Background Memory is a large array of bytes memory and registers are only storage CPU can

More information

Medical Device Software - Software Life Cycle Processes

Medical Device Software - Software Life Cycle Processes 1 Medical Device Software - Software Life Cycle Processes IEC 62304 2 Credits John F. Murray Software Compliance Expert U.S. Food and Drug Administration Marcie R. Williams Medical Device Fellow Ph.D.

More information

Chapter 4: Tools of Modern Systems Analysis

Chapter 4: Tools of Modern Systems Analysis Just Enough Structured Analysis Chapter 4: Tools of Modern Systems Analysis Nature has... some sort of arithmetical-geometrical coordinate system, because nature has all kinds of models. What we experience

More information

Requirements-Based Testing Process in Practice (Originally presented as Getting it right the first time )

Requirements-Based Testing Process in Practice (Originally presented as Getting it right the first time ) International Journal of Industrial Engineering and Management (), Vol.1 No 4, 2010, pp. 155-161 Available online at www.ftn.uns.ac.rs/ijiem ISSN 2217-2661 Requirements-Based Testing Process in Practice

More information

Test Case Design Techniques

Test Case Design Techniques Summary of Test Case Design Techniques Brian Nielsen, Arne Skou {bnielsen ask}@cs.auc.dk Development of Test Cases Complete testing is impossible Testing cannot guarantee the absence of faults How to select

More information

Microprocessors and Microcontrollers. Lab #0 Getting Started with MPLAB-X IDE

Microprocessors and Microcontrollers. Lab #0 Getting Started with MPLAB-X IDE EE 3954 Microprocessors and Microcontrollers Lab #0 Getting Started with MPLAB-X IDE Background: Some or all of the laboratory exercises performed throughout this course will involve writing assembly language

More information

Manage Software Development in LabVIEW with Professional Tools

Manage Software Development in LabVIEW with Professional Tools Manage Software Development in LabVIEW with Professional Tools Introduction For many years, National Instruments LabVIEW software has been known as an easy-to-use development tool for building data acquisition

More information

TRANSCRIPT: In this lecture, we will talk about both theoretical and applied concepts related to hypothesis testing.

TRANSCRIPT: In this lecture, we will talk about both theoretical and applied concepts related to hypothesis testing. This is Dr. Chumney. The focus of this lecture is hypothesis testing both what it is, how hypothesis tests are used, and how to conduct hypothesis tests. 1 In this lecture, we will talk about both theoretical

More information

1. Give the 16 bit signed (twos complement) representation of the following decimal numbers, and convert to hexadecimal:

1. Give the 16 bit signed (twos complement) representation of the following decimal numbers, and convert to hexadecimal: Exercises 1 - number representations Questions 1. Give the 16 bit signed (twos complement) representation of the following decimal numbers, and convert to hexadecimal: (a) 3012 (b) - 435 2. For each of

More information

IACBE Advancing Academic Quality in Business Education Worldwide

IACBE Advancing Academic Quality in Business Education Worldwide IACBE Advancing Academic Quality in Business Education Worldwide Bloom s Taxonomy of Educational Objectives and Writing Intended Learning Outcomes Statements International Assembly for Collegiate Business

More information

Introduction to Systems Analysis and Design

Introduction to Systems Analysis and Design Introduction to Systems Analysis and Design What is a System? A system is a set of interrelated components that function together to achieve a common goal. The components of a system are called subsystems.

More information

Can you design an algorithm that searches for the maximum value in the list?

Can you design an algorithm that searches for the maximum value in the list? The Science of Computing I Lesson 2: Searching and Sorting Living with Cyber Pillar: Algorithms Searching One of the most common tasks that is undertaken in Computer Science is the task of searching. We

More information

NRS Business Process Standards and Guidelines using BPMN

NRS Business Process Standards and Guidelines using BPMN Corporate Services for the Natural Resource Sector Information Management Branch NRS Business Process Standards and Guidelines using BPMN Last Updated: June 21, 2016 Version: 1.0.1 Document: NRS Business

More information

Module 10. Coding and Testing. Version 2 CSE IIT, Kharagpur

Module 10. Coding and Testing. Version 2 CSE IIT, Kharagpur Module 10 Coding and Testing Lesson 26 Debugging, Integration and System Testing Specific Instructional Objectives At the end of this lesson the student would be able to: Explain why debugging is needed.

More information

Guidelines for Effective Data Migration

Guidelines for Effective Data Migration Guidelines for Effective Data Migration Applies to: SAP R/3. All releases. For more information, visit the ABAP homepage. Summary Data Migration is an important step in any SAP implementation projects.

More information

Business Process Management IBM Business Process Manager V7.5

Business Process Management IBM Business Process Manager V7.5 Business Process Management IBM Business Process Manager V7.5 Application development process 2011 IBM Corporation This presentation provides information about developing process applications using IBM

More information