How do you define and view requirements in Test Director?

Test director is currently available as a plug in or add – on as a support for HP quality center and works like a test management tool. The earlier versions of the test director i.e., version 6 and below worked as stand-alone desk top applications.

However, the next version i.e., the test director 7 was a standalone web application and was known to work on any of the browsers that happened to be supporting active technology. For all the testers world wide it has been easy to integrate with the other mercury interactive tools via test director.

Three facts regarding test director:

1. This tool is not going to work out for the collection of the requirements of a software system or application.
2. It is not an automated testing tool.
3. It cannot be integrated with the products save mercury interactive products.

Test director comes with four specific modules namely:

1. Requirements module
2. Test plan module
3. Test lab module and
4. Defects module

How can we define and view requirements in the test director?

- This is done using the requirements module. 

- In every test management process, specification of the requirements is the first important step. 

- It involves analyzation of the software system or application under test and determination of the requirements of testing that application.

- Requirements analysis somewhat helps in carrying out the coverage analysis. - The following tasks are involved:

1. Addition of new requirements or editing of the previously added ones.
2. Addition and editing of the child requirements.
3. Linking of the requirements to the associated defects.
4. Analyzation of the coverage.

- The requirements analyzation phase follows through the below mentioned steps:

1. Defining the scope: The scope of the requirements includes test goals and objectives and can be determined using the requirements documentation.
2. Creation of the requirements: A requirements tree needs to be built so that all of the testing requirements can be defined.
3. Providing details for the requirements: Detailing involves adding attachments, assigning priority levels to all the requirements if required for testing.
4. Analyzation of the requirements: This phase involves generation of the reports consisting of the graphs to provide an assistance in the analyzation of the testing requirements.

Steps for Defining Requirements

Follow the below mentioned steps for defining the requirements:

1. Launch the test director demo project. You will require to log on to the project if in case the project is not open.
2. Now clicking on the requirements tab will display the requirements module or the requirements tree.
3. One thing that you need to be sure of is that the document view of the requirements is also displayed.
4. Click on the new requirement option which will open the new requirement dialog box. Fill in the details and hit OK.
5. Click new child requirement button for adding a requirement as a lower level of hierarchy.

Steps for Viewing Requirements

For viewing the requirements follow the below mentioned steps:

1. First step is making sure that the requirements module is displayed and if not click on the requirements and turn on the document view of the requirements tree.
2. You can zoom in as well as zoom out of the requirements tree using the zoom in and zoom out buttons.
3. In some cases you may require to view the numeration of requirements. 
4. To view numerations go to view menu and click on the numeration option. If you make any changes in the requirements the same is updated by the test director and numerations are renumbered. 

Understanding the Structure of a C Program

The best way to get started with any programming language is to study a program, so in order to make you understand C program structure, we will take into consideration an example program whose code is:

1. /* this is a simple c program
2. Written to explain basic program structure */ -------------------------multiple line comment
3. #include //header file. ---------------------- single line comment
4. int main()
5. {
6. return 0;
7. }

This is the simplest C program and this program unfortunately doesn’t do anything. “#include” is called a preprocessor command. It tells the compiler to do processing before the compilation. This command tells the compiler to include the header file “stdio.h” in the program.

Functions are the basic building blocks of any program. The function “main()” is the most important function in any C program. You can say that this is the point of execution of a program. This function should exist as an entry point. Following the main is a pair of parentheses. These two parentheses indicate that the main is a function. Now coming to the opening and closing pair of braces in lines 5 and 7, are used to define the limits of a function or the program. Usually these braces contain executable statements of a function. The main() is preceded by word int. it means that this function returns an integer value. This value is returned using the “return” statement.

Now let’s take a program “abc.C” that does something. It’s same as the previous except that it has an executable statement between the braces in addition to the obligatory return statement. The executable statement calls a function which is already included in the header files as a part of the C library. The function is namely “printf()” and in order to make it print text the desired text is written with quotation marks within the parentheses of the function. The text will be displayed on the monitor when program is run. Notice the semicolon at the end of the executable statements. A semi colon in C is used as a statement terminator.

Consider the following statement:
printf("Hello World!\n");

Notice the “\n” character. The back slash is used to indicate to the compiler that a special character is being inserted. Here “n” indicates a new line. This is used whenever you want to print something in a new line. The function “printf()” prints the text and returns the carriage. Consider the following statements:

int index;

the key word int stands for integer and is used to declare a variable of type integer called index. Always keep in mind that the number of field descriptors and the number of variable definitions must be the same or else the runtime system will generate something we are not expecting. Another common and important part of C program structure is “comments”.Comments are optional but it’s good to include because they make the program more readable although they don’t mean anything to the compiler. Comments are of two types: single line comments and multiple line comments. Single line comments are used to give only one line description of a function or any other statement. A multiple line comment spans through several lines and is used to give a detailed description of a program or function.Look at the above program code for an example of comments. Another important part of a program are statements and expressions which combine variables and constants and can be assignments, function calls etc.Coming to the line breaks they are necessary to for good style formatting of your programs. This makes it easy for you to understand how your program flows when you want to maintain or modify it.You can also use “blank lines” after pre compiler declarations and declaration of new variables.Indentation should also be used in order to make your program more readable and to define the body of functions.

Overview of Aspect Oriented Software Development (AOSD)

Aspect oriented software development defines aspects that express customer concerns that cut across multiple system functions, features, and information. It provides a process and methodological approach for defining, specifying, designing, and constructing aspects - mechanisms beyond subroutines and inheritance for localizing the expression of a crosscutting concern.
Aspect Oriented Programming (AOP) provides the ability to intercept code execution with the purpose of inserting a process before, in place of, or after the code that would normally execute.

Predominant reasons for AOSD are:
- Help solve the issue of messy object architectures.
- Object oriented programming has difficulty dealing with global information.
- Also, functionality that requires the involvement of several different objects (possibly collected into a component) results in interdependency between those objects/components. This makes the application susceptible to the implementation changes of a dependent object/component.
- Maintenance and enhancement are also problems, as the interaction between these objects/components are typically hard coded within the containing object.

AOSD programming technologies (aspect-oriented programming, or AOP) provide linguistic mechanisms for separate expression of concerns, along with implementation technologies for weaving these separate concerns into working systems. Aspect-oriented software engineering (AOSE) technologies are emerging for managing the process of developing systems within this new paradigm.

Architectural Design - Refining the Architecture into Components and Describing Instantiations of the System

Refining the Architecture into Components

As the software architecture is refined into components, structure of the system begins to emerge. Components of the software architecture are derived from three sources:
- the application domain
- the infrastructure domain
- the interface domain
Because analysis modeling does not address infrastructure, one should allocate sufficient design time to consider it carefully.
In order to find the components that are most suitable for refining the software architecture, you need to start by using the classes which were described in the analysis model. The analysis classes in turn are representations of business entities that architecture is trying to describe. You could also base these components on an infrastructure model rather than the business model. If you went purely by the business model, you would not be able to depict many of those infrastructure components such as database components, components used for communication etc.
Whatever interfaces are described in the architecture context diagram imply one or more specialized components that process the data that flow across the interface.

Describing Instantiations of the System

The context of the system has been represented, the archetypes indicating important abstractions are defined, the overall structure of system apparent and major software components are identified, however further refinement is necessary which is accomplished by developing an actual instantiation of architecture. The architecture is applied to a specific problem with the intent of demonstrating that the structure and components are appropriate.

Architectural Design - Representing the System in Context and Defining Archetypes

As architectural design begins, the design should define the external entities that the software interacts with and nature of the interaction. Once the context is modeled and all external interfaces are described, the structure of the system is specified by the designer. It is done by defining and refining software components that implement the architecture.

REPRESENTING THE SYSTEM IN CONTEXT

Architectural context represents how the software interacts with entities external to its boundaries. A system context diagram accomplishes this requirement by representing the flow of information into and out of the system. At the architectural design level, a software architect uses an architectural context diagram to model the manner in which software interacts with entities external to its boundaries.

How do systems inter-operate with the target system?
Superordinate Systems
These systems use the target system as part of some higher level processing scheme.
Subordinate Systems
These systems are used by the target system and provide data or processing that are necessary to complete target system.
Peer-level Systems
These systems interact on a peer-to-peer basis.
Actors
These entities interact with the target system by producing or consuming information necessary for requisite processing.
Each of these external entities communicates with target systems through an interface.

DEFINING ARCHETYPES

Archetypes are the abstract building blocks of an architectural design. It is a class or pattern that represents a core abstraction that is critical to design of an architecture for the target system. Archetypes can be derived by examining analysis classes defined as part of analysis model.Target system architecture is composed of these archetypes which represent stable elements of the architecture. Some kind of archetypes are:
- Nodes
- Detector
- Indicator
- Controller

What are different tasks representing WebApp interface design?

The user interface design begins with
- identification of user.
- identification of task.
- identification of environmental requirements.
Once these are identified, user scenarios are created and analyzed.

TASKS REPRESENTING WEB APPLICATION INTERFACE DESIGN ARE:

- The information that is contained in the analysis model is reviewed and refined as required.
- A rough sketch of web application interface layout is developed.
- The user objectives should be mapped into specific interface actions.
- A set of user tasks associated with action should be defined.
- Each interface action should have a storyboard screen image which depicts the interface response to user interaction.
- The input from aesthetic design should be used to refine the interface layout and storyboards.
- Implementing interface requires user interface objects. These user interface objects should be identified which may require a search through an existing object library.
- A procedural representation of user's interaction with interface is developed.
- A behavioral representation of the interface is also developed. It may use UML state diagrams to represent state mechanisms.
- Each state's interface layout is described using design information developed in tasks 2 and tasks 5.
- The interface design model should be refined and reviewed.