1. With a diagram, explain the software testing process.

Ans:

 A commercial software system has to go through three stages of testing:

1. Development testing, where the system is tested during development to discover bugs and
defects. System designers and programmers are likely to be involved in the testing process.

2. Release testing, where a separate testing team tests a complete version of the system before
it is released to users. The aim of release testing is to check that the system meets the
requirements of system stakeholders.

3. User testing, where users or potential users of a system test the system in their own
environment. For software products, the ‘user’ may be an internal marketing group who decide
if the software can be marketed, released, and sold. Acceptance testing is one type of user
testing where the customer formally tests a system to decide if it should be accepted from the
system supplier or if further development is required

2. What are verification & validation activities related to software testing? Compare

them briefly.

Ans:
3. What are the various software inspections that can be carried out on software? Explain.

Ans:

4. What is test driven development? With a neat diagram, explain test driven development
process.

Ans: Test Driven Development

 Test-driven development (TDD) is an approach to program development in which testing
and code development are interleaved.

Test-driven development was introduced as part of agile methods such as Extreme

Programming.

The fundamental TDD process is shown in. The steps in the process are as follows:

1. Start by identifying the increment of functionality that is required. This should

normally be small and implementable in a few lines of code.

2. Write a test for this functionality and implement this as an automated test. This
means that the test can be executed and will report whether or not it has passed or failed.

3. Run the test, along with all other tests that have been implemented. Initially, the
functionality is not implemented, so the new test will fail. This is deliberate as it shows that
the test adds something to the test set.

4. You then implement the functionality and re-run the test. This may involve
refactoring existing code to improve it and add new code to what’s already there.

5. Once all tests run successfully, then move on to implementing the next chunk of
functionality.

5. With a neat diagram, explain six stages of acceptance testing process.

Ans: Acceptance testing, where customers test a system to decide whether or not it is ready to be
accepted from the system developers and deployed in the customer environment.

o There are six stages in the acceptance testing process.

o They are:

1. Define acceptance criteria: This stage should, ideally, take place early in the process
before the contract for the system is signed. The acceptance criteria should be part of the
system contract and be agreed between the customer and the developer. Detailed
requirements may not be available and there may be significant requirements change during
the development process.

2. Plan acceptance testing: This involves deciding on the resources, time, and budget for
acceptance testing and establishing a testing schedule. The acceptance test plan should also
discuss the required coverage of the requirements and the order in which system features
 are tested. It should define risks to the testing process, such as system crashes and
inadequate performance, and discuss how these risks can be mitigated

3. Derive acceptance tests: Once acceptance criteria have been established, tests have to be
designed to check whether or not a system is acceptable. Acceptance tests should aim to
test both the functional and non-functional characteristics (e.g., performance) of the system.

4. Run acceptance tests: The agreed acceptance tests are executed on the system. Ideally,
this should take place in the actual environment where the system will be used, but this may
be disruptive and impractical. Therefore, a user testing environment may have to be set up
to run these tests. It is difficult to automate this process as part of the acceptance tests may
involve testing the interactions between end-users and the system.

5. Negotiate test results: It is very unlikely that all of the defined acceptance tests will pass
and that there will be no problems with the system. If this is the case, then acceptance
testing is complete and the system can be handed over. More commonly, some problems
will be discovered. In such cases, the developer and the customer have to negotiate to
decide if the system is good enough to be put into use. They must also agree on the
developer’s response to identified problems.

6. Reject/accept system: This stage involves a meeting between the developers and the
customer to decide on whether or not the system should be accepted. If the system is not
good enough for use, then further development is required to fix the identified problems.
Once complete, the acceptance testing phase is repeated

6. What is component testing? List and explain the different types of interface errors.

Ans: Component testing, where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces.

o Interface errors falls into 3 categories:

* Interface misuse: A calling component calls some other component and makes an error in
the use of its interface. This type of error is common withparameter interfaces, where
parameters may be of the wrong type or be passed in the wrong order, or the wrong
number of parameters may be passed.

* Interface misunderstanding: A calling component misunderstands the specification of the

interface of the called component and makes assumptions about its behavior. The called
component does not behave as expected which then causes unexpected behavior in the
calling component.
 * Timing errors: These occur in real-time systems that use a shared memory or a message-
passing interface. The producer of data and the consumer of data may operate at different
speeds

7. What are the different types of interfaces to be tested during component testing? Explain

Ans: * Parameter interfaces: These are interfaces in which data or sometimes function references
are passed from one component to another. Methods in an object have a parameter
interface.

* Shared memory interfaces: These are interfaces in which a block of memory is shared
between components. Data is placed in the memory by one subsystem and retrieved from
there by other sub-systems.

* Procedural interfaces: These are interfaces in which one component encapsulates a set of
procedures that can be called by other components. Objects and reusable components have
this form of interface.
* Message passing interfaces: These are interfaces in which one component requests a
service from another component by passing a message to it. A return message includes the
results of executing the service.

8. With a neat diagram, explain software evolution process.

Ans: Evolution processes

o Software evolution processes vary depending on the type of software being maintained,
the development processes used in an organization and the skills of the people involved.

o In some organizations, evolution may be an informal process where change requests

mostly come from conversations between the system users and developers.

o In other companies, it is a formalized process with structured documentation produced at

each stage in the process.

o The processes of change identification and system evolution are cyclic and continue
throughout the lifetime of a system

o The process includes the fundamental activities of change analysis, release planning,
system implementation, and releasing a system to customers.

o The cost and impact of these changes are assessed to see how much of the system is
affected by the change and how much it might cost to implement the change.

o If the proposed changes are accepted, a new release of the system is planned.

o During release planning, all proposed changes (fault repair, adaptation, and new
functionality) are considered.

o A decision is then made on which changes to implement in the next version of the system.
o The changes are implemented and validated, and a new version of the system is released.
o The process then iterates with a new set of changes proposed for the next release.
o Change implementation can be thought of as an iteration of the development process,
where the revisions to the system are designed, implemented, and tested.

o However, a critical difference is that the first stage of change implementation may involve
program understanding, especially if the original system developers are not responsible for
change implementation.

o During this program understanding phase, it becomes necessary to understand how the
program is structured, how it delivers functionality, and how the proposed change might
affect the program.

o This understanding is required to make sure that the implemented change does not cause
new problems when it is introduced into the existing system.

o The change implementation stage of this process should modify the system specification,
design, and implementation to reflect the changes to the system

o During the evolution process, the requirements are analyzed in detail and implications of
the changes emerge that were not apparent in the earlier change analysis process.
So This means that the proposed changes may be modified and further customer discussions
may be required before they are implemented
9. Write and explain Lehman’s laws related to system change.

Ans:

10.What is software maintenance? Draw the general model of reengineering process and explain.

Ans: Software Maintenance

o Software maintenance is the general process of changing a system after it has been
delivered.

o There are three different types of software maintenance:

1. Fault repairs
2. Environmental adaptation
3. Functionality addition

Reengineering process:

o The activities in the reengineering process are as follows:

1. Source code translation: Using a translation tool, the program is converted from an old
programming language to a more modern version of the same language or to a different
language.

2. Reverse engineering: The program is analyzed and information extracted from it. This
helps to document its organization and functionality. Again, this process is usually
completely automated.

3. Program structure improvement: The control structure of the program is analyzed and
modified to make it easier to read and understand. This can be partially automated but
some manual intervention is usually required.
 4. Program modularization: Related parts of the program are grouped together and, where
appropriate, redundancy is removed. In some cases, this stage may involve architectural
refactoring (e.g., a system that uses several different data stores may be to use a single
repository). This is a manual process.

5. Data reengineering: The data processed by the program is changed to reflect program
changes. This may mean redefining database schemas and converting existing databases to
the new structure

11.What are the strategic options involved in legacy system management? Discuss.

Ans: o There are four strategic options:

1. Scrap the system completely: This option should be chosen when the system is not
making an effective contribution to business processes. This commonly occurs when
business processes have changed since the system was installed and are no longer reliant on
the legacy system.

2. Leave the system unchanged and continue with regular maintenance: This option should
be chosen when the system is still required but is fairly stable and the system users make
relatively few change requests.

3. Reengineer the system to improve its maintainability: This option should be chosen when
the system quality has been degraded by change and where a new change to the system is
still being proposed. This process may include developing new interface components so that
the original system can work with other, newer systems

4. Replace all or part of the system with a new system: This option should be chosen when
factors, such as new hardware, mean that the old system cannot continue in operation or
where off-the-shelf systems would allow the new system to be developed at a reasonable
cost
12.What are “Bad Smells” in program code? Explain.

Ans: