How is test management done by the test director?

If you are familiar with all the concepts of the test director you can apply them to your software systems or applications since you know how it works.

The test director implements the test management via four major phases as mentioned below:

1. Specification of the requirements
2. Planning the tests
3. Execution of the tests
4. Tracking the defects

Throughout each of the phases the date can be analyzed by the detailed reports and graphs generated earlier. Firstly, you need to analyze your software system or application and determine all of your testing requirements. 

Phase I - specification of Requirements

The first phase of the test director test management process involves the following steps:

1. Examination of the documentation of the software system or application for the determining the testing scope i.e., test goals, strategies, objectives etc.
2. Building of a requirements tree for defining overall testing requirements.
3. Creation of a list of detailed testing requirements for each topic mentioned in the requirements tree.
4. Writing a description for each requirement, assigning a priority level to it and adding attachments if required.
5. Generation of the reports and graphs for providing assistance in the analyzation of the testing requirements.
6. Carrying out a review of the requirements to check if they meet the specifications.

Phase II - Planning the Tests

The second phase involves the following tasks:

1. Examination of the application, testing resources and system requirement for determining the test goals.
2. Division of the application in to modules to be tested and building of a test plan tree to divide the application in to testing units hierarchically.
3. Determination of the type of tests that are required for each module and adding a basic definition of each test to the test plan tree.
4. Linking each test to the corresponding testing requirement.
5. Developing manual tests where each test step describes the test operations and expected outcome. Deciding which tests are to be automated.
6. Creation of the test scripts for the tests that are to be automated using a custom testing tool such as mercury interactive testing tools.
7. Generation of the graphs and reports for the analyzation of the test planning data.
8. Reviewing the tests for determining their suitability to the testing goals.

Phase III - Execution of tests

Third phase involves the following activities:

1. Defining the tests in to groups so as to meet various testing goals of the project. This may involve testing a new version of the application or a specific function in it.
2. Deciding which all tests are to be included in the test set.
3. Scheduling the execution of the tests and assigning tasks to different application testers.
4. Execution of the tests either manually or automatically.
5. Viewing the results of the test runs for determining if a detect was detected in the application under test and generation of the reports and graphs for analyzation of the results.

Phase IV - Tracking the Defects

The last phase of the test management i.e., defect tracking involves the following activities:

1. Submitting new defects detected in the software system or application. Defects can be added during any phase by QA testers, project managers and developers etc.
2. Carrying out a review of the new defects and determining which ones are to be fixed.
3. Correcting the defects that were decided to be fixed.
4. Testing the new build of the software system or application and repeating the whole process until all the defects are fixed.
5. Generation of the graphs and reports to provide assistance in the analyzation of the progress of the defect fixes and determining the date when the application is to be released. 

How to start with Test Director?

Application testing is not an easy task, rather it is a very complex process but made easy with the test director. With the test director it has been possible to organize as well as manage all of the phases of the test director testing process. You can also specify the requirements of the testing process, plan the tests, execute them and keep an eye on the defects and so on.

Test director actually forms an organized frame work for the testing of the software systems or application before they are put under deployment. A central data repository is needed for the organization and management of the application testing process since the test plans have a way of evolving with any changes in the existing requirements or the new requirements. 

The following are the processes where you get a plenty of guidance from the test director:

1. Requirements specification
2. Test planning
3. Test execution
4. Defect tracking etc.

Basically the application testing process via test director consists of the following four phases:

1. Specifying requirements
2. Planning tests
3. Running tests
4. Tracking defects

First phase involves:

1. Define the testing scope
2. Create requirements
3. Detail requirements
4. Analyze requirements specification

Second phase involves:

1. Defining testing strategy
2. Define test subjects
3. Define tests
4. Creating the requirements coverage
5. Designing the test steps
6. Automating the tests
7. Analyzation of the test plan

3^rd phase involves:

1. Creating test sets
2. Scheduling the test runs
3. Running the tests
4. Analyzation of the test results

4^th phase involves:

1. Adding the defects
2. Reviewing the defects
3. Repairing the open defects
4. Testing new builds
5. Analyzing the defect data

How to start with Test Director?

- To start with the test director you need to go to your web browser and enter the URL of the test director in the test director options window. 

- When you press enter you will get a test director window.  

- If in case you are having some problem with opening the test director you can check whether or not the test director has been installed of the web server of your company.

- If it’s the very first time that you are running the test director, you will have to wait for a while so that the test director downloads and installs itself on your system. 

- If it had been a long since you last ran the test director the test director will update your version with the latest version. 

- Next, you will get a test director log-in window from where you have to log-in as a quality assurance tester. 

- While logging in you will asked to enter the domain and project name. 

- When you will be logged in you will get a test director window comprising of the following test director modules:

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

All of the above mentioned test director modules possess some common elements namely:

1. Test director tool bar
2. Menu bar
3. Module tool bar
4. Tools button
5. Help button
6. Log out button

- One can start off straightaway giving the specifications for testing requirements in the requirements module in detail so as to provide a foundation for the rest of the application testing process. 

- All these requirements will be stated in the form of a requirements tree i.e., in a graphical form. 

- Once specified, the requirements need to be linked to the tests. 

- If the defects are found they are also be linked to the requirements which are responsible for those defects. 

What is Perl Testing?

Various testing methodologies have become a corner stone for many of the development processes and PERL testing is one such testing methodology. 

"Perl testing is one such testing that is highly involved with the creation of automated test suites".

The creation of automated test suites with regard to the perl projects is assisted by around 400 testing and quality modules which are now available on the CPAN.

Now you must be thinking why only automated test suites in perl? 

The answer is that the with an automated test suite the developers as well as the project managers get a sense of confidence in the ability of the code that it can very well carry out a specification. 

What is Perl Testing?

- Perl development ethos has always viewed software testing as its central and critical part since years. 

- Gradually, a testing protocol by the name of TAP or ‘test anything protocol’ was set up for the perl in the year of 1987. 

- This TAP protocol is now available for so many languages. 

- Many of the test modules on CPAN like 100s make use of this TAP protocol. 

- With the help of this protocol it has been made possible to enable the following aspects:

1. Testing of data base queries
2. Testing of objects
3. Testing of web sites and so on.

- Around 250,000 tests have been developed for the core Perl language plus there are a same number of tests for the libraries that are associated with it. 

- There is one more advantage of the automated test suites which is that the additions are done to the code base as the changes in functional requirements are experienced. 

- But, while making the additions, re-factoring is required so as to avoid duplication. 

- Since, if there is enough code coverage the issues will automatically be highlighted by the test suite and then it becomes fairly easy to spot the changes that occur in the knock on effects of code. 

- The duty of the code coverage is to determine how much of the code has been tested since the execution of the test suite. 

- This metric however can be obtained from the developer and also the branches and sections of the code that are not being tested can also be reported. 

- Testers can combine the testing modules that are most frequently used and thus it serves a good starting point. 

- So, for the cases in which testing specific functionality is required, one only needs to add specific testing modules to the test.

- Perl has always recognized testing as a part of its culture. 

- With the TAP protocol, the communication between a test harness and several unit tests has been made possible. 

- The TAP producers can make communication regarding the test results to the testing harness in a way that is language agnostic. 

- Earlier the parser and producers were available for only this platform but now they are available for a variety of platforms. 

- The responsibility for the following purposes is taken up by the test anything web site:

1. Development of TAP
2. Standardization of TAP
3. Writing of test consumers
4. Writing of test producers
5. Evangelization of the language and so on.

- In many other testing methodologies, writing the tests and verifying them seems like to be a daunting task but it is pretty easy with the perl test facilities. 

- It is not always necessary that a large perl project must have an automated test suite. 

What is the difference between priority and severity?

Severity and priority have always been the most effective measure to characterize a bug. Severity and priority levels have been in use since a long time by most of the software development organizations and standards as a measure to calculate the degree of the harm that can be done by a bug.

"The severity of a bug is an indication of its harmfulness or badness whereas the priority level of a bug is an indication of the urgency for fixing it."

Role of Testing Team

- The testing team is responsible for setting up the severity as well the priority levels for the bugs.
- The way they set the severity and priority level, it should be meaningful, easy to understand, consistent and of course reasonable!
- A bug as we all know is a defect in the coding of a software program which hinders its development and meeting the expectations of the users.

About Priority

- Priority is way of rating the urgency for fixing or correcting a bug which in turn implies its importance also.
- The priorities are set keeping in mind the goals and the specifications of the software project.
- Priority has nothing to do with the quality of the software product as affected by the bug.
- Priority is nothing but a functional of the class and severity of the bug.

About Severity

- Severity is a means for the measurement of the harm and disruption caused by the bug to the functioning of the software system or application.
- It is the severity that gives the information regarding the impact as well as visibility of the bug on the quality of the software product and its functioning.
- Severity is an effective means for rating of the impact of a bug on the quality of a software product as it is perceived.
- Therefore, the severity of the bugs should be assigned very carefully.
- It is a commonly observed issue that the simple concept of severity is made over complicated due to a lack of data.

Sub-Components of Severity

To say severity has got many sub components but on a whole basis only two are considered:

1. Visibility
Visibility gives the probability of the occurrence of the bug again in the future in a particular feature and functionality of the program.

2. Impact
Impact gives the measure of the disruption caused to the user of the system when the bug is encountered.

How Severity and Priority Calculated?

- The total severity is calculated as an average of the values of the visibility and impact factors.
- This characteristic of severity allows us to view it as a measure of the quality of the software product s it is perceived.
- Using priority as a quality indicator is a great mistake.
- Unlike severity, the priority is measured as an attribute of the bug and the defined goals of the project.

Priority on the basis of Urgency

- Some testers define priority on the basis of the urgency which is an absolutely wrong way.
- The urgency should be defined on the basis of the priority level.
- Urgency is directly proportional to the priority.
- The priority levels range from 1 to 7 where 1 being the highest priority level and 7 being the lowest.
- By default the priority of each discovered bug is 3.
- It will be more good if one priority scheme is followed across all the projects i.e., to have a global priority scheme.
- Priority tells us how important or urgent is to get the bug fixed.

In some cases it happens that going gets tough without rectifying the bugs in the lower levels. Such situations demand the highest priority.

How to test software requirements specification?

Software requirements specifications is often called “SRS” in its short form. We
can simply put it as a specific requirement for a software system or application.

PURPOSE OF SOFTWARE REQUIREMENTS SPECIFICATION

- These requirements specifications give a view of how exactly the system should and how it should behave.
- The software requirements specification comes with a set of cases describing all the possible interactions of the users with the software system or application.
- Such test cases have been termed as ‘use cases”.
- The software requirements specifications contains both kinds of requirements i.e., functional requirements as well as non functional requirements.
- Software requirements specification is an important sub field under the software engineering field.
- The software requirement specification provides a way to enlist all the requirements necessary for the development of the software project in one place.
- It deals with the following issues with regard to the software system or application:


1. Specification
2. Elicitation
3. Analysis and
4. Validation


OVERVIEW OF SOFTWARE REQUIREMENT SPECIFICATION

1.Introduction
This mentions the purpose of the software along with its scope, definitions, a brief overview and a set of references.

2.Overall Description
This section of the SRS describes the perspective, functions, user characteristics, constraints, dependencies and assumptions of the software application.

3. Specific Requirements
This is the most important part of an SRS and includes description of functions, interfaces, logical data base requirements, performance requirements, design constraints and key features.

HOW TO PRODUCE AN EFFECTIVE SOFTWARE REQUIREMENTS SPECIFICATION?

- For producing an effective software requirements specification, you need to test it.
- Therefore a software requirements specification testing has been designed.
- It is popularly known as requirements analysis.
- Requirements analysis analyzes all those tasks that help in identifying the requirement specifications of the software system as well as the requirements specifications itself.
- This actually forms the initial stage of the requirements engineering which is again concerned with the above listed activities.
- The analysis of the requirements specification is crucial for any software system or application.
- All the identified requirements should have the following properties:


1.Actionable
2.Can be documented
3.Testable
4.Traceable
5.Measurable and
6.Defined


PHASES OF SOFTWARE REQUIREMENTS SPECIFICATION TESTING
The software requirements specification testing comprises of the following three phases:

#1. Elicitation of the Requirements:
- This phase involves the identification of the requirements of the consumers.
- This process of communicating with the users and gathering requirements is very well known as requirements gathering.

#2. Analysis of the Requirements:
- This phase involves the determination of the clarity, completeness, ambiguity, contradiction of the requirements.
- If issues are found, they are resolved.

#3. Recording of the Requirements
- There are various ways in which the requirements might be documented.
- Whatever the way maybe, it should be clear and concise.
- Some commonly used methods are: natural language documents, user stories, process specifications and use cases.

What is a template for a test plan?

Testing is responsible for checking the quality level of a program and effective testing requires an effective and efficient test plan.

HOW SHOULD A TEST PLAN BE?
- The test plan should be practical so that it can be easily implemented.
- A test plan is prepared keeping in view the test approach which is suitable for a particular kind of software testing.
- The other important things that are kept in mind while drawing out the test plan are functional specs, design specs and requirements.
- The test plan is a way of implementing the test approach.
- It makes use of test cases specifically designed for a kind of particular testing.

DOCUMENTATION OF TEST PLAN
The test plan is also documented and the documentation serves the following purposes:

1. It gives the details about the test approach used to test the software system or application.
2. The different aspects of a software system or application are identified.
3. The procedure to be followed for the testing is specified.
4. The tools to be used in the software testing are also mentioned in the documentation.
5. The resources to be used in the testing of the software product are specified.
6. The scheduling plan for the test plan is listed.
7. Sometimes it may also include the contact information of the people who are involved in the whole testing process.
8. It lists all the risks that may affect the software and also mentions their effect on the software.
9. The contingency plan is also included.
10.The test plan also specifies the bugs and errors and procedures to manage them.
11.The criterion for the development of the software is specified.

The scheduling plan or the test schedule is prepared by the lead tester. It is based up on the project schedule prepared by the product manager. A test plan template is like a sample on which you can build up your own test plan.

BASIC TEST SAMPLE
1. Introduction
The introduction part covers up the description of the documentation, schedules and other related documents.
(a) Description:
- This documentation contains a test plan for the project: “project name” which has been produced by both quality control and quality assurance.
- The test plan enlists and describes the test strategy and also the test approach.
- Quality assurance has been used for validating the quality of this software product prior to its release.
- Apart from software product, there are other resources which are required for successful execution of this software project.
- The “ project name” aims at improving the development strategy, maintenance and deployment by providing the following new features:

(b) Schedule: (schedule coverage and information based on the estimates of the quality assurance.)
(c) Related documents: (related documents attached to the documentation like design specifications list and functional and non functional specifications list.)

2. Resource Requirements:
It describes all the hardware and software components of the software product.
(a) Hardware:(hardware requirements of the project)
(b) Software:(software requirements of the project and tools used in the testing of the software)
(c) Staffing:(list of the names of the people who are involved in the project along with their responsibilities and what all trainings are required.)

3. Aspects to be tested and test approach: (provides the list of the aspects tested).
4. Aspects not to be tested.
5. Test outcomes
6. Risks
7. Exit criteria

What is specification based testing? What are its advantages and disadvantages?

Specification testing as its name suggests can be defined as the type of testing in which the software product’s performance and conformance is checked with every statement mentioned in all the available documents for reference.

- This specification based testing is carried out by specification based tester.
- The documents used for specification based checking might be user manuals, formal specifications check lists, third party documents or even advertisements.
- Specification based testing ought not to cover automatic extraction of ideas of testing from the mentioned specifications and it also not covers the use of the automated program comprehension tools.
- While carrying out the specification based testing an assumption is made in which we assume that a natural language specification exists that is to be analyzed by a human being.

The following tasks are carried out by specification tester:
- To identify the sets of reference 3 documents.
- To develop the ideas for testing those are based on contradictions and ambiguities in the documents that are being used for reference.
- To develop the list of claims and items that are to be tested based on certain assertions to be tested and are listed in the reference documents. Later the ideas are associated with each other.
- To create the matrices that are traceable and that lists the assertions and the items to be tested and test cases associated with those assertions and ideas.

One of the most important unifying features of specification based testing is that the testing starts with the reference documents and the testing strategies and cases are based on what is there in the reference documents.

The following examples will make the use of specification based testing clear:

- Undo tool in paint: does not performs as specified.
- Zoom in tool in open office presentation: does not perform as specified.
- File and folder naming function in windows XP does not perform as specified.
- New profile creation tool in fire fox.
- Function for deleing form information tool.
- Help documentations are incorrect.
- Keyboard short cuts for closing windows.
- Conflict between the dream weaver and inbox manual.

The specification based testing has got both advantages and disadvantages.

- Specification based testing though being necessary is not sufficient to guard or detect certain risks.
- One of the advantages of specification based testing is that it reduces the number of test cases.
- It proves very efficient in find most of the comer cases.

- Though the bugs discovered are very small, the cannot be discovered by testing in the real system since the command sequences that have lead to these bugs would have never been caused in the real system.

- Specification based testing states the specifications as the executable properties.
- Errors can either be in the program or in the specifications.

- Specification based testing can be defined as a process that tests a software system or application based on what its behavior should be based on its specifications.

- In specification based testing, test cases are developed based on the specifications of the software system or application.

- Tests can be developed even before the actual creation of the program and its implementation.

- Without actually writing the program, a set of input data for testing can be generated based only on the given specifications and without even knowing the implementation of the test cases.

- This generated test data will be sufficient to test a software system or program that would have been written in accordance with these specifications.

- If the specifications seem to be incomplete, the assumptions can be stated about how the specifications can be clarified and completed.

What is application programming interface testing?

An application programming interface or API as it is known by its abbreviated form can be defined as a specification based on source code. Typically application programming interface is intended to be used as an interface in the software components in order to communicate with each other. An application programming interface includes specifications and requirements basically for required data structures, routines, variables, and object classes.

The requirements and specifications of application programming interface can take many forms such as POSIX which is an international standard or Microsoft windows API which is vendor documentation or standard template library or STL (in java AP or C++) which is the library of the programming languages.

Application programming interface and application binary interface are in great contrast to each other. The basic difference is that the application programming interface is based on source whereas the application binary interface is a binary interface. The best example is given by POSIX and Linux standard base. The POSIX is an application programming interface, whereas the Linux standard base in an application binary interface.

An application programming interface has got any features.
- It is language dependent. It means that the application programming interfaces is only available by using the elements and syntax of a particular programming language. This feature makes the application programming interface more easy and convenient to use.

- An application programming interface can also be independent of language. This feature helps in calling the application programming interface from several programming languages. This is the most desirable feature for an application programming interface that is service oriented. Such an API is not bound to specific system or process. It may be provided as a web service or remote procedure calls.

- Sometimes the term “application programming interface” is used to refer to a complete programming interface, a set of APIs that have been provided by an organization or a single function. Therefore, the scope of the meaning of an API is usually determined according to its usage.

- In some cases an application programming testing may describe the way in which a task is performed. An action is usually meditated by a function call in procedural programming languages like C. hence; here API usually describes all the functions and routines provided.

- Other times the application programming interface can be interpreted as a collection of the files included by the C language and its readable descriptions.

- There are various programs development environments that provide the documentations associated with an application programming interface in digital format. Example of such language is Perl which comes with a tool perldoc.

When it comes to object oriented languages, application programming interface provides a description of definitions and behaviors associated with a set of class.

- An application programming interface generally prescribes the methods using which one can interact or handle the class derived objects.
- An application programming interface is closely related to a software library.
- Library is the actual implementation of the rules that are set by the application programming interface.
- Like other this API factor also needs to be tested. For this, API testing is employed.
- API testing is somewhat different from other types testing since GUI is rarely involved in it. for API testing, one needs to set up the testing environment and invoke the API with its respective parameters and then analyze the result.
- The problems come while setting up the environment as the GUI is not involved. For cases that don’t return anything one needs to have some mechanism to check the API’s behavior.

There are 3 main challenges faced by API testing:
- Parameter combination
- Parameter selection
- Call sequence

What are different characteristics of performance testing?

Performance means a lot more than actually just testing the performance of a software system or application. It covers a wide range of concepts of software engineering and functionalities.

In performance testing, a software system is not merely tested on the basis of its functionalities, specifications and requirements but, it is also tested on the basis of the software system’s or application’s final performance characteristics which are measurable.

- Performance testing is both quantitative and qualitative kind of testing.
- In the field of software engineering, performance testing is typically done to determine the effectiveness and speed of a software system, hardware system, computer or device etc.

- Being a quantitative process, performance testing involves some lab tests like measurement of response time and MIPS (short form for “millions of instructions per second”) at which a software system performs.

- It also involves tests for testing the qualitative assets of a system like scalability, reliability and inter- operability.

- Often performance testing and stress testing are performed conjunction-ally.

- It’s a general kind of testing done to determine the behavior of a system whether hardware or software in the terms of stability and responsiveness when the system is provided with a significant workload.

- It is also carried out to measure, validate, verify and investigate the qualitative attributes of the system like resilience and resource usage.

- Performance testing is a sub category under performance engineering.
- It’s a kind of testing which aims to incorporate performance into the architecture and design of software or a hardware system.
- It’s basically done before the actual coding of the program.

Performance testing consists of many sub categories of testing. Few have been discussed in details below:

1.Stress testing:
This testing is done to determine the limits of the capacity of the software application. Basically this is done to check the robustness of the application software. Robustness is checked against heavy loads i.e., to say above the maximum limit.

2. Load testing:
This is simplest of all the testings. This testing is usually done to check the behavior of the application software or program under different amounts of load. Load can either be several users using the same application or the difficulty level or length of the task. Time is set for task completion. The response timing is recorded simultaneously. This test can also be used to test the databases and network servers.

3. Spike testing:
This testing is carried out by spiking the particular and observing the behavior of the concerned application software under each case that whether it is able to take the load or it fails.

Endurance testing:
As the name suggests the test determines if the application software can sustain a specific load for a certain time. This test also checks out for memory leaks which can lead to application damage. Care is taken for performance degradation. Throughput is checked in the beginning, at the end and at several points of time between the tests. This is done to see if the application continues to behave properly under sustained use or crashes down.

5.Isolation testing:
This test is basically done to check for the faulty part of the program or the application software.

6.Configuration testing:
This testing tests the configuration of the application software application. It also checks for the effects of changes in configuration on the software application and its performance.

Before carrying out performance testing some performance goals must be set since performance testing helps in many ways like:

- Tells us whether the application software meets the performance criteria or not.
- It can compare the performance of two application soft wares.
- It can find faulty parts of the program.

What are different characteristics of Compliance testing?

Compliance testing perhaps sounds a very rare kind of testing, less often heard about. It can be defined as the audit of a software system or application which is carried out against well known criteria.

There are many kinds of compliance testing and some are even developed as per the requests of the customers or the clients. Basically the compliance tests are of the following types:

Systems in Development
It refers to the compliance testing in which the verification of the fact that the intended software system or application under development meets the lock down standards, configurations and specifications as requested by the client or the customer is done.

Operating systems and applications
- It refers to the compliance testing in which the verification of the fact that an operating system and software system or applications have been configured and designed appropriately and properly as per the requirements, specifications and lock down standards given by the clients and the customers is done.

- Thus, this kind of compliance testing provides robust, adequate and efficient controls to ensure the availability, integrity and confidentiality of the software system or application is not affected during its normal usage and is maintained throughout the whole working process.

Management of IT and enterprise architecture
- It refers to the compliance testing in which the verification of the fact that the all the in-place IT management infrastructure aspects of the software system or the application have been put in their appropriate place is done.

- This is generally done to ensure that the audit, change in controls, security procedures and business continuity have been documented, formulated and put in their proper place and remain effective.

Inter- connection Policy
It refers to the compliance testing in which the verification of fact that the business continuity controls and adequate security measures that govern the connection of the software system with other systems like the systems for tele- communication, extranets, intranets, internet and so on, have been put in their appropriate place, have been cross checked with the specifications and requirements stated by the clients and the customers and have been fully documented is carried out.

These were some standard compliance tests.
Apart from these there are some normal compliance tests which encompass either a few or all of the compliance tests mentioned above.
- Some lockdown policies are applied to the underlying applications or software systems and operating systems.
- Some of these policies are passed by the clients or the customers and some by the concerned parties.
- These policies can be referred and can be used as a guidelines as and when required by the customers or clients when the software testers or developers have already performed a compliance test.
- They can also be referred after the penetration testing and vulnerability assessment of the software system or application so that more security measures can be applied to the system’s enterprise in order to improve its security.

The national security agency or NSA as it is often abbreviated has provided a number of lock down policies and guidelines to increase the awareness of the security affairs that are affecting our operating systems, software systems and applications etc.
The policies cover the following:

- Database servers
(a) oracle 10g
(b) oracle 9i
(c) Microsoft SQL server

- Operating systems
(a) Apple server operating systems
(b) Apple Mac OS
(c) Microsoft Windows NT
(d) Microsoft windows XP
(e) Microsoft windows 2000
(f) Sun Solaris 8
(g) Sun Solaris 9
(h) Microsoft windows server 2003


- Routers
- Switches
- Web servers and browsers
- IP and VoIP telephony
- SQL Server 2000
- BIND
- Novell eDirectory

How to define effective metrics? What is the use of quality metrics?

The goal of software engineering is to develop a product that is of high quality. Metrics that are derived from these measures indicates the effectiveness of individual. Metric is a standard for measurement. A metric is a measure that captures performance and allows comparisons and supports business strategy.

The use of quality metrics is to spot the performance trends, comparing alternatives and predicting the performance. However, the costs and benefits of a particular quality metric should be considered as collecting data will not necessarily result in higher performance levels.

Effective metrics should define performance in quantifiable entity and a capable system exists to measure the entity. Effective metrics allow for actionable responses if the performance is unacceptable.

Identifying effective metrics is a bit difficult. Ranges can be identified for an acceptable performance of a metric. It can be referred as breakpoints in case metrics are defined for services and targets, tolerances, or specifications for manufacturing.

Breakpoints are levels where there is a chance that the improved performance will change the behavior of the customer. A target is a desired value of a characteristic. A tolerance is an allowable deviation from target value.

Flow oriented Modeling - Creating a Control Flow Diagram and The Control Specification

Flow models focus on the flow of data objects as they are transformed by processing functions. There are applications which are driven by events rather than data and produce information that is controlled and process information keeping in mind the time and performance. In such situations, control flow diagrams comes into picture along with data flow modeling.

There are some guidelines to select potential events for a control flow diagram:
- all sensors that are read by the software are listed.
- all interrupt conditions are listed.
- all switches actuated by operator are listed.
- all data conditions are listed.
- all control items are reviewed.
- all states that describe the behavior of a system are listed.
- all transitions between states are defined.
- all possible omissions should be kept in focus.

The Control Specification contains a state diagram which is sequential specification of behavior. It contains a program activation table which is a combinatorial specification of behavior. Control specification does not give any information about the inner working of the processes activated as a result of this behavior.

Eliciting Requirements - what are basic guidelines for conducting collaborative requirements gathering meeting? PART 1

For collaborative requirements gathering, stakeholders and developers work together to identify the problem, propose a solution and negotiate approaches. The basic guidelines include:
- software engineers and customers attend meetings.
- rules for preparation and participation are established.
- agenda that covers important points and encourage free flow of ideas.
- meeting is controlled by a facilitator who can be a customer, developer or an outsider.
- worksheets, wall stickers, chat room etc. are used.
- goal is to identify the problem, propose a solution and negotiate approaches.

If a system or product will serve many users, one should be certain that requirements are elicited from representative cross-section of users. If only one user defines all requirements, acceptance risk is high. As requirements gathering meeting begins, the first point of discussion is need and justification of the new product. Once agreement is established, each participant presents his lists for discussion in one particular area. After this, combined list is prepared by group after which facilitator coordinates discussion.
Avoid the impulse to shoot down a customer's idea as "too costly" or impractical. The idea is to negotiate a list that is acceptable to all.

Once the lists are completed, team is divided into sub teams and each works to develop mini specifications. Additions, deletions and elaborations are made. After this, each attendee makes a list of validation criteria and finally one or more participant is assigned the task of writing a complete draft specification.

Why is documentation necessary in QA? What steps are needed to develop and run software tests?

Documentation is very necessary in quality assurance. Everything should be documented. User manuals, test plans, bug reports, business reports, code changes, specifications, design and all other reports should be documented. Any changes in the process should be documented.
A properly documented requirement specification is very necessary. Requirements are the details of what is to be done. Requirements should be clear, complete, detailed, testable. Details should be determined and organized in an efficient way but it can be difficult to handle. Some type of documentation with detailed requirements is very important to properly plan and execute tests.

There are some steps that are needed to develop and run software tests:
- The requirements, design specifications are necessary.
- Budget and cost should be known.
- What people will be responsible, responsibilities, standards and processes should be listed.
- Risk aspects should be determined.
- Test approaches should be defined.
- Test environment should be defined.
- Tasks should be identified.
- Inputs should be determined.
- Test plan document should be prepared.
- Test cases should be written.
- Test environment and test ware should be prepared.
- Tests are performed and results are evaluated.
- Problems are tracked, re-testing is done and test plans are maintained and updated.

What are different tasks of requirement engineering - Elaboration,Negotiation,Specification,Validation,Management

Elaboration involves the information that is obtained from team during inception and elicitation is expanded and refined. It focuses on defining, redefining and refining of models. It tries to model the "WHAT" rather than the "HOW".
- Requirement is created using methods that capitalize on user scenarios.It describes how the end-users and actors interact with the system.
- The analysis model is derived from the requirements model where each scenario is analyzed to get the analysis classes.
- The requirements model and the analysis model are the main workproduct of this task.

Negotiation involves customers, stakeholders and software development team reconcile conflicts. The purpose of negotiation is to develop a project plan that meets the requirements of the user while reflecting real-world constraints such as time,people and budget. Negotiation includes:
- always remember negotiation is not completion.
- always have a strategy.
- always listen effectively.
- always focus on other party's interest.
- never make it personal.
- always be creative.
- be ready to commit.

Specification is the final artifact or work product produced by the software engineer during requirements engineering. It serves as the foundation for design and construction of software.

In Validation,the work products produced as a consequence of requirements engineering are assessed for quality. It checks whether inconsistencies, omissions, and errors have been detected and corrected. The
review team that validates the requirements look for errors in content or interpretation,areas where clarification is required, missing information, inconsistencies,conflicting and unrealistic requirements.

Management is a set of activities that help the project team identify, control, and track requirements and their changes at any time as the project progresses.

Cleanroom Software Engineering - Advantages, Principles and Process Teams

Cleanroom software engineering involves the integrated use of software engineering modeling, program verification and statistical software quality assurance.
- Cleanroom software engineering verifies design specification using mathematically-based proof of correctness.
- Cleanroom software engineering relies heavily on statistical use testing to uncover high impact errors.
- Cleanroom software engineering generally follows an incremental development process.

CLEANROOM PRINCIPLES

- Small Teams include independent specification, development, and certification sub-teams.
- Incremental development under statistical quality control.
- Software development is based on mathematical principles. The box principle is used for specification and design. The formal verification is used to confirm correctness of implementation of specification. The program correctness is verified by team reviews using questionnaires.
- Testing is based on statistical principles.

CLEANROOM PROCESS TEAMS

- Specification team develops and maintains the system specification.
- Development team develops and verifies software. The software is not compiled or executes during verification.
- Certification team develops set of statistical test to exercise software after development. Reliability growth models are used to assess reliability.

BENEFITS OF CLEANROOM SOFTWARE ENGINEERING

- Zero failures in the field which is a goal but a realistic expectation is<5 failures per KLOC on first program execution in the first team project.
- Short development cycles
- Longer product life.

Model Driven Architecture (MDA) - Advantages and MDA Process

The MDA is a new way of writing specifications, based on a platform-independent
model.

Why should we use Model Driven Architecture

- Portability
- Interoperability
- Domain facilities provide much wider interoperability.
- MDA allows to model the functionality and behavior only once, therefore saves a lot of time.
- Requirements are always changing.
- New technology is arising.
- Require to integrate old system with new system, and any other system in future.
- MDA makes it easier to integrate applications and facilities across middle-ware boundaries.

Model Driven Architecture Process

THE BASIC PROCESS
- To construct a MDA application, the first step is to create a computation independent model(CIM) by a business analyst.
- The CIM is transformed into platform independent model(PIM) by enterprise architect.
- The resulting PIM has to be targeted to a platform to complete the build process.
- The transformation of a PIM to a PSM will be done by a platform specialist.

THE COMPLEX PROCESS
The process from computation independent model to platform specific model can be a bit more complex.
- Between the models, there can be some gaps present which makes transformation difficult.
- As a result, you can have interrelated models having different layers of abstraction.
- One consequence is that a single layer of abstraction can have horizontal transformations. Consider the example where a PIM is converted multiple times into more detailed PIMs. And there are vertical transformations in addition to vertical transformation of models.

Model Driven Architecture (MDA) - Characteristics and Viewpoints

OMG was formed as a standards organization to help reduce complexity, lower costs, and hasten the introduction of new software applications.
- The Object Management Group (OMG) adopted the Model Driven Architecture as an approach for using models in software development.
- Its three primary goals are portability, interoperability and reusability through architectural separation of concerns.

Characteristics of Model Driven Architecture(MDA)

- MDA enables development of new specifications.
- MDA provides a comprehensive, structured solution for application interoperability and portability into the future.
- MDA consists of services specified by OMG. It also includes directory services, event handling, persistence, transactions, and security.
- MDA enables the creation of standardized domain models for some vertical industries.
- MDA separates the operation of the system from the way it uses its capabilities of its platform.
- MDA enables converting platform-independent models to produce platform-specific models using mappings.

What are different viewpoints of Model Driven Architecture

- The first viewpoint is called Computation Independent Viewpoint which focuses on environment and requirements of the system rather than the details of system's structure and processing.
- The second viewpoint is called Platform Independent Viewpoint which focuses on how the system operates. It hides the details necessary for a particular platform. The part of complete specification does not change when the platform changes.
- The third viewpoint is called Platform Specific Viewpoint which focus on the detail of the use of a specific platform in addition to platform independent viewpoint.

Define Unit Test Case, Integration Test Case, System Test case

UNIT TEST CASES(UTC)
The unit test cases are very specific to a particular unit. The basic functionality of the unit is to be understood based on the requirements and the design documents. Generally, design document will provide a lot of information about the functionality of a unit. The design document has to be referred before a unit test case is written because it provides the actual functionality of how the system must behave, for given inputs.

INTEGRATION TEST CASES
Before designing the integration test cases the testers should go through the integration test plan. It will give complete idea of how to write integration test cases. The main aim of integration test cases is that it tests the multiple modules together. By executing these test cases the user can find out the errors in the interfaces between the modules.
The tester has to execute unit and integration test cases after coding.

SYSTEM TEST CASES
the system test cases meant to test the system as per the requirements; end to end. This is basically to make sure that the application works as per the software requirement specification. In system test cases, the testers are supposed to act as an end user. so, system test cases normally do concentrate on the functionality of the system, inputs are fed through the system and each and every check is performed using the system itself. Normally, the verifications are done by checking the database tables directly or running programs manually are not encouraged in the system test.
The system test must focus on functional groups, rather than identifying the program units. When it comes to system testing, it is assumed that the interfaces
between the modules are working fine.
Ideally the test cases are nothing but a union of the functionalities tested in the unit testing and the integration testing. Instead of testing the system inputs and outputs through database or external programs, everything is tested through the system itself. In system testing, the tester will mimic as an end user and hence checks the application through its output.
Sometimes, some of the integration and unit test cases are repeated in system testing also especially when the units are tested with test stubs before and not actually tested with other real modules, during system testing those cases will be performed again with real modules.

What are Test Case Documents and what is the general format of test cases?

The test cases will have a generic format as below:
- Test Case ID : The test case id must be unique across the application.
- Test case description : The test case description should be very brief.
- Test Prerequisite : The test pre-requisite clearly describes what should be present in the system, before the test executes.
- Test Inputs : The test input is nothing but the test data that is prepared to be fed to the system.
- Test Steps : The test steps are the step-by-step instructions on how to carry out the test.
- Expected Results : The expected results are the ones that say what the system must give as output or how the system must react based on the test steps.
- Actual results : The actual results are the ones that say outputs of the action for the given inputs or how the system reacts for the given inputs.
- Pass/Fail : If the expected and actual results are same then test id Pass otherwise Fail.

The test cases are classified into positive and negative test cases.Positive test cases are designed to prove that the system accepts the valid inputs and then process them correctly. Suitable techniques to design the positive test cases are specification derived tests. The negative test cases are designed to prove that the system rejects invalid inputs and does not process them. Suitable techniques to design the negative test cases are error guessing, boundary value analysis, internal boundary value testing and state transition testing. The test cases details must be very clearly specified, so that a new person can go through the test cases step by step and is able to execute it.
In an online shopping application, at the user interface level, the client request the web server to display the product details by giving email id and username. The web server processes the request and will give the response. For this application, we design the unit, integration and system test cases.