REQUIREMENTS BASED TESTING

IT project failure has become a very common factor during the past 10 years; statistics show that the root causes of many unsuccessful projects are due to poor requirements. James Martin shows in his study that 56% percent of bugs identified in projects are errors introduced in the requirements stage (Borland Software Corporation, 2005); therefore, getting the requirement right is essential. This can be achieved by requirements based testing approach, this essay is a discussion on what is requirement based testing, why it is important, how can it be applied to reduce bugs in software products, and what benefits can be gained.

 “Requirements Based Testing is the practice of aligning requirements at the beginning of a software project with quality expectations for testing –to ensure final deliverables consistently meet business needs.” (Alho, 2007). The above definition implies that using requirement based testing practices help ensure that the final outcome of the software consistently meets the business needs. Requirement based testing address two major concepts, first it focuses on validating whether the requirments are correct and makes sure that the requirements are up to the standards (ie complete,unambigous and logically consistent ), secondly it designs a set of test cases from the requirements. The design and the code should fully meet those requirements. This can be achived using black box testing. Therefore RBT can be defined as a methodology which defines set of rules to test the requirements and maximize the software quality by developing the right product.

However one can come to the conclution that the RBT process is tredious aditional work when developing a software product. But RBT is important because requirements are a critical factor when developing a software and you must get it right from the beginning of the development life cycle. Research has shown that most software failures are due to the following reasons

• Requirements and specifications are incomplete.
• Requirements and specifications change too often.
• There is a lack of user input (to requirements). (Mogyorodi, 2003)

All the above mention reasons are circled around requirements, therefore it is a critical need to verify and validate the requirements from the requirement stage itself.

Early bug detection reduces the cost of bug fixing; as mentioned above most root cause of bugs are due to inadequate requirements. According to the above definition of RBT, it improves the requirement and reduces software bugs from the requirement stage itself. This clarifies rather than following the traditional approach of testing which is performed after the code is delivered; therefore, it is important to follow the RBT process to eliminate software bugs and increase software quality.

To understand the RBT process it is important to know the RBT methodology. RBT methodology can be defined in 12 steps (Mogyorodi, 2003). Out of the 12 steps, five of the most important steps are taken in to consideration in-order to understand the effectiveness of the RBT process.

1.      Validation of requirements against business objectives – this ensures that the requirements satisfies the objectives of the project and meets the business need of the project.

2.      Review of requirements by stakeholders- refines the requirements by getting feedbacks from the stakeholder before going to the next phase.

3.      Development of use-cases - Map requirements against a task-oriented or interaction-oriented view of the system to make sure the requirements are complete.

4.      Application of language analysis techniques- Identify ambiguous, unclear or inconsistent phrases in the requirements and fix them to guarantee the consistency and clarity of the requirements.

5.      Logical consistency checks performed and test cases designed. - Design test cases that are 100% equivalent to the functionality in the requirements.

(Mogyorodi, 2003)

This gives a clear understanding on how the RBT process can improve the software quality and identify errors from the very first stage itself, due to validation of requirements against business objectives. This also indicates that the RBT process does not only detect bugs but it also address bug prevention by integrating testing throughout the development life cycle. At the same time RBT practices eliminates the most common risk of incomplete and changing requirement specifications issue because of its application of language analysis techniques and traceability functionalities. 

 

Figure 1: Requirements Based Testing process flow  (Aharonovitz, 2008)

Figure 1 show the actives which are undertaken by the RBT process. This shows the goals of RBT using separate boxes. Arrow heads direct how they can be achieved.

The first goal of the RBT process is ensuring the quality of requirement. It can be achieved by ensuring that business needs are met, maximizing user/domain expert’s involvement, and validating whether the requirements are correct and none conflicting. The following methods must be applied to ensure the quality of the requirements: Review of requirements against 

business objectives, by domain experts/business users, and map the requirements against use cases ambiguity analysis of requirements.  (Aharonovitz, 2008)

Designing logical test cases. This can be achieved by expressing the requirements using cause-effect cards, generation of test cases, and the use of truth tables or unique path detention can derive the equivalent test cases for the requirements to optimize the number of test cases.  (Aharonovitz, 2008)

The next two goals, ensuring the quality of the test cases, and the quality of design and code can be achieved by reviewing the test cases by requirement authors, domain experts, end users and also by reviewing test cases by designers and developers in the code review process.

Last goal of the RBT process is completing and executing tests which ensure that the actual behavior of the system is the expected behavior and meets the business needs. (Borland Software Corporation., 2006)

Moty Aharonovitz, senior director of Product Strategy at Borland Software, states that traceability plays a critical role in the RBT process; he claims that maintaining traceability information between requirements, test-cases and tests is crucial. This determines which test cases or tests should be changed when a specific requirement changes, and the impact of change. (Aharonovitz, 2008)

In conclusion RBT process and activities describe that RBT depends on two major functionalities 1) Quality assured requirements and 2) test cases. Using the following functionalities throughout the development life cycle development teams can guarantee that they are building the right product with the lowest defects.

To ease the RBT process and use it effectively organizations can use tools which automate the RBT process. For example Borland software cooperation has taken several approaches to automate the RBT process and has developed a set of tools, namely Borland Caliber DefineIT - designed to ensure that software requirements are defined completely and accurately from the beginning, Borland CaliberRM - designed to facilitate collaboration, impact analysis, and communication in the definition and management of changing requirements, and  SilkCentral Test Manager - delivers visibility and control of project quality aligned with business requirements and is integrated with CaliberRM to maintain bi-directional traceability and change impact analysis between business requirements and test activities (Borland Software

Corporation., 2006). By using an automated RBT process it would ease the software development cycle, and the final outcome will avoid downstream defects and project delays.

From the above discussion it is a fact that when a company follows RBT methodology, they will be rewarded with better products and profit. Considering the facts discussed above requirement based testing can be dived in to three forms from the business point of view; 1) Business benefits, 2) Operational benefits and 3) financial benefits.

According to the RBT methodology as discussed above each of the categorized benefits are analyzed using the RBT functionalities. Beginning with the business benefits which can be achieved by clear, complete and correct requirements which lead to developing what the customer really wants; thus resulting in higher customer satisfaction and improved market agility. Operational benefits focus on benefits while developing the software. As discussed above RBT has a well structured methodology to improve tractability and visibility of the requirements which eases the development cycle. This will optimize the QA activities ensuring the quality of the product. Furthermore it enhances the software quality by introducing requirements test coverage which will ensure all requirements are satisfied by the end product. Furthermore financial benefits can be looked at from the revenue prospect of an organization. By following the RBT process and activities development teams can reduce compliance risks and improve impact analysis. Moreover the most important aspect of financial benefits are related to profit;  by identifying the defects early and fixing them in a very early stages it reduces re-work, helping save time and money which will leads to gaining more profit.

Although there are many advantages of using the RBT process in the development life cycle Robin F. Goldsmith, JD claims that there can be draw backs associated with RBT process as well. He states that there are limitations imposed by inadequately defined requirements, assessing the extent to which the requirements are complete, the appropriate level of test case details, and inclusion of requirements based unit tests by developers. However he also states the above pitfalls can be overcome by identifying the strengths and often unrecognized weakness of requirement base tests, and understanding the importance of testing based on business as well as system requirements and discovering how to identify more of the necessary but often overlooked test cases (Goldsmith, 2008).

In conclusion the requirements based testing approach is a very important process to be followed due to the fact that many IT project failures are associated with requirements and requirement management. The requirements based testing process introduces a well formed procedure from the requirement gathering stage to the deploying stage of the product. It has an effective methodology to gather requirements without flaws, and defines how to test the requirements properly in-order to ensure that the right requirements are captured. At the same time it has methods to keep track of changing requirements, and ways to define requirement based test cases including maximum coverage with a minimum number of test cases. It is a fact that by following the above mentioned process most of the software bugs can be identified early, requirements specifications can be produced clearly, and requirements changes can be managed effectively. Even though there can be pit falls in the RBT process, if it is followed properly one can avoid many draw backs and gain a lot of benefits from it.

Would use of design by contract have prevented the Ariane 5 disaster?

 

Ariane 5 was a European expendable launch system designed for delivering satellites to space, exploded 40 seconds after the lift –off which caused around 500 million damage to the world.  When developing the Ariane 5 software, some codes were reused from the Ariane 4 system which was used successfully for Ariane 4 but had  different flight characteristics than Ariane 5. Soon after the explosion an inquiry board was called to investigate the disaster and they found that explosion was due to a software error in the inertial reference system. Specifically a 64 bit floating point number relating to the horizontal velocity of the rocket with respect to the platform was converted to a 16 bit signed integer. The number was larger than 32,767, the largest integer storable in a 16 bit signed integer, and thus the conversion failed. (Ladkin, 1998)

The most simplest answer is Yes but if i elaborate more ..

It is known Ariane 5 had failed due to a reuse specification error (Ladkin, 1998). If software engineers and designers had followed the design by contract methodology this disaster could have been avoided.

Design by contract follows set of methods which provide some tools for formulate the contracts, to increase the quality of the software with correctness and robustness. Which would also enhance the performance of  the reusability of software components, which could have avoided and prevented its destruction. Author would like to discuss the following key concepts of DBC which would have prevented Ariane 5 disaster.

• Explicitly handle exceptions from the design stage.

Design by contract force all the fundamental constraints in each code module must be explicitly handled and mentioned from the design state itself. Design by contract propose several approaches to be taken to satisfy the above conditions. Such as preconditions and post conditions which validates fundamentals inside the functions, and invariant which specify the legitimate values of the class attributes(validate the fundamental contracts inside a class). In Ariane 4 if the  software crew had mentioned the constraints, from designing the module itself and put  the needed preconditions post conditions and invariants, this error would have detected from the reusing state  and change the values accordingly in Ariane 5 module. And assertions can be verified during the testing stage to verify the boundaries.

• Provide systematic documentation for the software components.

 “The requirement that the horizontal bias should fit on 16 bits was in fact stated in an obscure part of a document. But in the code itself it was nowhere to be found!” (Jézéquel, 1997)

            If all the critical assertions and exceptions were documented and all the constraints were mentioned in the design specification document, QA team and review team would have given the proper attention to the validations and done the unit tests accordingly. One cannot blame QA team and the review team that they have not done their job right because you cannot test all software components in a large system to a given restricted timeline (you can test a lot but not all). Therefore if the documents are systematically produced reusing stage itself one can identify the defect and fix it. And QA team would give a critical testing on the boundaries and exceptions which had fundamental constraints mentioned in the documentation. Design by contract make the documentation easy and it explicitly mention the pre conditions post conditions and invariant to make the documents more clear.

Design by contract make the code self documenting it clearly classify the exceptions and the constraint which must be handled inside each functions and classes. And if the proper assertions are mention from the code itself review team would identify the critical points of the code, but in Ariane 5 code had not mentioned about the fundamental constraints which leads review team to abound the above error. 

     

File management system in Windows XP and Linux (Ubuntu)

Directory Structures

Directory structure is the method used to organize the directory data within the directory

Both Windows and Unix Directory structures have lot of common features like the way files and directories are organized on a hard disk. They implement a tree-structure, or hierarchical, file system. A directory can contain any number of files. A directory can also contain other directories. The main difference between windows and linux file directory is windows can have many roots while

linux Directory structure

Linux directory structure is organized into a hierarchical structure which is similar to an upside down tree. The top-most directory is known as the root the starting point of the directory structure When the operating system is first installed, it creates a root file system and it is written as a forward slash (/).

Eg- /usr/data/cat

The root can contain many directories, each directory can contain subdirectories; each of these can contain more subdirectories, and so on. A subdirectory is said to be the "child" of the directory that holds it (it's "parent")

Eg- The following diagram shows file organization structure used in linux

If you want to go to the DB directory u have to go like “ /Data/Tutorials/DB”

Windows Directory structure

Windows file system has lot of similarities with Unix file system, it is also organize in a hierarchical structure .And also it can contain directories and sub directories inside it

The main difference between windows and linux is Windows can have many roots while

Linux only has one root. Microsoft Windows storage devices such as hard disks, floppy disks, CDROM's and Zip drives that contain file systems have a drive letter prefix. Floppy drives are typically A: drives, hard disks typically C:, etc.

In linux when you need to use a storage device user has to mount the device and go from the root directory because it has only one root structure

And also another important thing in directory structure is that in windows uses a backslash (\) as a delimiter between directory names while UNIX uses a front slash (/)

Eg- C:\Sun\AppServer\jdk\bin

H:\Course work IIP\Images

Both windows and linux can share files and folders with other computers by connecting to a network

Location of various task and users

Various task and operations which are done by linux operatin system

An operating system must provide a number of operations associated with files so that users can safely store and retrieve data. Typical operations are open close create coppy rename and list. In addition, operations on a single data elements within a file are supported by Read Write and Seek. Both operation system act as the same way

User location

Both linux and windows can be used by different users but in linux system allow to have multi users at the same time, but in windows only one user can log in at a one time

File organization

Linux file organization

Unix files and directories numbered, using node numbers called inodes, and that’s how unix keeps tracks of the files and directories. An inode is a data structure on the disk that describes a file. It holds most of the important information about the file, including the on-disk address of the file's data blocks (the part of the file that you care about). Each inode has its own identifying number, called an i-number

Each i-node entry contains

1. The user and group id of the owner
2. It’s protection bits
3. The physical file address
4. File size
5. Number of links to the files
6. A code indicating if the file is a directory, special,symbolic link or ordinary file
7. date/time of access, creation and modification.

When a file gets deleted under Unix, the name is removed from the file system but the file doesn't go away until the INode is deleted. this happens when the last process using the file closes it . if you create a new file with the same name, while the old one is open, you get a new Inode.

Windows File Organization

Windows does not have inodes , the file name and file are managed as a single entity,and windows cannot identify the separation between name and identity. The good thing in unix using inode is it can have many different files open simultaneously,all of which may have shared a common name at some point

In Windows file access is done by the file system if we look at windows XP the file system they use is NTFS ,and the information about the files are stored in the file system

Types of files

Linux

Main types of files in the unix file directory

1	Fifo	8	regular
2	character special	A	symbolic link
4	directory	C	socket
6	block special	D	door

1.Ordinary files –Ordinary file may contains text, a program or other data.It can be

either an ASCII file, or a binary file

2.Directory files(socket)

3.Device Files –Physical devices(printers,speakers ect) are represent as file

In linux these devices are read as files and can access them as

Separate files not as devices.When we use the device we have to attatch

to the tree structure and use it not as a separate device

4.Link files – A symbol link is a filename that links to another file.it can appear to

have two diferant names , or alternatively appear to be in two

different places in a directory hierarchy. . Directory entries point to

file difining i-node It important to remember in unix if the original

file is deleted the The link becomes useless and also you cannot create

links to directories

Windows

In windows is also the same as linux file types. In windows they have shortcuts as the symbolic link. It also has the similar qualities.

In windows Physical devices are identified separately and can be accessed as a another root

Extension

A file extension is a more or less arbitrary component of a filename, used to identify the type A failing of file extensions is that any extension can be applied to any file, so the extension is no guarantee of contents. The extension takes the form of a 'dot' and various letters, usually three, appended to the filename.

Linux File extension

We use file extension to identify the file types.The main difference between unix and windows file extension is that in unix we can use multiple extension

Eg name.tar.gz -Tarred-then-gzipped files

Tute1.cc -C++ program source code

And also in linux file extention is not needed to identify the file type but in windows extention is used to identify the file type

Some of the extensions used in Unix

.bak Backup copy of file .bz2 bzip2 compressed file

.c C program source code .C C++ program source code .cc C++ program source code .cgi CGI web page program .dat Data or other information .doc Explanatory text file

Windows file extension

In windows we can only use single extension. If the user gives more than one extension ,the extension is taken as the last word which starts with the period and the left hand side of the last period is taken as the file name.In Windows operating systems, the file type is derived from the filename extension. Typical file types and their extensions are

File Extension	File Type
.bas	basic source program
.c	c source program
.dll	system library
.doc	Word document
.exe	executable program
.txt	text file

Windows associates applications (programs) with specific file types. For example, the default application that opens to process a file of type .txt is the Notepad editor.

Overall, Unix/Linux file extension development has been fairly random. Since extensions are so useful and indicative, and as Unix/Linux has become increasingly graphically oriented (thus needing to execute applications and load files indirectly), extensions have become more prevalent and naturalized.  

Disk fragmentation

When the system is used for some time,constant creation and removal of files ceates a situation called disk fragmentation. When files are created and data written to the file, the operating system allocates space for the file from the free cluster list. Over a period of time, the clusters that are allocated to a file may no longer be sequential (contiguous or one after the after) but scattered over the disk.This means files in the files system are written in small pieces on the hard disk, thus scattering the available disk space. Disk fragmentation increases access time and reduces filesystem efficiency.

Both operating system may suffer from disk fragmentation

Unix

Unix file system is designed largely to prevent fragmentation. In Linux we have a separate swap partition that has several advantages

- The swap file system is optimized for its purpose, it's faster.

- No time wasted resizing.

- Much less fragmentation.

Its needless to do disk fragmentation in linux, because most of the time in linux fragmentation will not reach higher. Most of the time fragmentation will not increase more than 5%.

To defragment a file system is to back up the files system with a program such as

dump or ufsdump, rebuild the file system with a command such as newfs or mkfs, and then reload the file system from the backup.

Windows

Windows gets fragmented so quickly is that it uses a swap file in the same partition as the rest of the system, and this file changes in size all the time, pushing bits and pieces of other files around.

Disk Defragmenter MMC is based on the full retail version of Executive Software Diskeeper. The version that is included with Windows XP and later provides limited functionality in maintaining disk performance by defragmenting volumes that use the FAT, FAT32, or NTFS file system.

Harmony and Melody and Rythem

Music is made out of three basic elements as melody, harmony and rythem. Melody is a group of notes played one after the other (monophonic), it is the basic tune of a song which can be hummed. (Jones, 2007). Harmony is a series of notes in combination (chords) which will be played simultaneously and can completely change the mood of the music. Rhythm is the beat of the music. Jesse Gress claims rhythm is the bonding agent that allows musical pitches to be organized in time. He further stated that rhythm can exsist without melody but melody cannot exsist without a rythem (Gress, 2001). Therefore it is essential to have a rythem in melody. Victor Zuckerkandl author of the book Sense of Music claims that melody can be defined melody as horizontal aspect of music and harmony, comprising of blocks of tones or chords that makes up the vertical aspect in music (Zuckerkandl, 1971).

MacPherson and Hunt state that melody is one of the prime factors in determining the choice of chords. Further they state that harmony must be used to fit the tune for a melody to be colourful (MacPherson & Hunt, 2003). On the other hand Cynthia explains that harmonic music consists of two or more notes played simultaneously. When three or more tones are sounded together, a chord is produced (Cynthia, 2001) therefore movement of chords can be represented the harmony which makes the music pollyphonic.

The evidence above suggests that melody is the basic tune of a song which is superimposed over a specific rhythm and harmony on the other hand harmony makes the melody rich and colorful by adding variations and moods. This further indicates that harmony strongly depends on its melody and harmonizing can vary according to the composer’s moods. Therefore one song can have more than one harmony and a harmony depends on the composer’s preference.