Software Quality Assurance

SEN-420

Assignmen
t2
Instructions:

 This Assignment must be submitted on LMS (WORD format only) via the allocated folder.
Student Details:
 Email submission will not be accepted.
Name: MUHAMMAD Class (Section): BS CS 7TH
REHAN  You are advised to make your work clear and well-presented, marks may be reduced for
poor presentation. This includes filling your information on the cover page.
Enrollment:
 You03-134201-007
MUST show all your work, and text must not be converted into an image, unless
specified otherwise by the question.

 Late submission will result in ZERO marks being awarded.

 The work should be your own, copying from students or other resources will result in
ZERO marks.

 Use Times New Roman font for all your answers.

Pg. 1 Question OneQuestion One

3 Mark
Question One
a) List and briefly describe the various causes of software errors.
b) Classify the causes of errors according to the group/s responsible for the
error –the client staff, the system analysts, the programmers, the testing
staff – or is the responsibility a shared one, belonging to more than one
group?

Answer:

a) Software errors have several causes, including:

 Programming Errors: These are errors made during the

coding process, such as syntax errors, logical errors, or
misuse of variables and functions.
 Design error: This occurs during the design phase when the
entire structure and functionality of the software is planned.
Design errors can lead to problems such as poor
performance, data misuse, or security vulnerabilities.

 Requirement error: This occurs when the customer's

requirements are not understood or misinterpreted. This can
Pg. 2 Question OneQuestion One

lead to software solutions that do not meet the customer's

needs.

 Test error: This occurs when the test is not comprehensive

enough or not performed correctly. Test errors can result in
missed defects or reported false positives.
 Configuration error: This occurs when the software is not
configured correctly for the environment in which it is being
used. Configuration errors can cause problems such as
crashes, data loss, or incorrect output.
 Documentation errors: This occurs when the software
documentation is incorrect, incomplete, or unclear.
Documentation errors can lead to confusion among users or
improper use of the software.
 Coding Errors: These occur during the coding phase of
software development where errors occur in the syntax, logic
or structure of the code.

 Integration errors: Occur when software components are

integrated and there are inconsistencies between the
components.

 Human errors: Errors can occur due to human factors such

as lack of attention to detail, fatigue, or insufficient training.
Pg. 3 Question OneQuestion One

b): Responsibility for software errors can be shared among several

teams involved in software development or it can be the
responsibility of a specific team. Here is a partial breakdown of
some of the causes of software errors by the group responsible:

 Customer Service: Errors in claims are the responsibility of

customer service. If the customer's requirements are unclear
or incomplete, the software developer will not be able to
create a solution that meets their needs.

 System Analyst: Design errors are the responsibility of the

system analyst. If the entire structure and functionality of this
software is poorly designed, the resulting solution may not
meet the customer's needs or may be prone to errors.
 Programmer: Programming errors are the responsibility of
the programmer. If the code contains syntax errors, logical
errors, or misuse of variables and functions, the software may
not function properly.
 Test Staff: Test errors are the responsibility of the test staff.
Defects can be missed or false positives can be reported if
the test is not complete enough or not performed correctly.
Pg. 4 Question OneQuestion One

However, it should be noted that responsibility for software errors is

often shared among multiple teams. For example, a requirement
error can lead to a design error, which in turn can lead to a
programming error. Therefore, it is essential that all teams involved
in software development work together to prevent errors and ensure
that the final solution meets the customer's needs.
Pg. 5 Question OneQuestion One

2 Marks

Question Two
Some people claim that testability and verifiability are different terms for
the same factor.

a. Do you agree?
b. If not, explain your reasoning.

Answer:

a. I don't fully agree that tests and tests are the same factor.
Although they are interdependent and complementary, they refer to
different aspects of software quality.

b. Testability refers to the ease with which a software system or

component can be tested to determine whether it meets the desired
requirements. A highly tested system that is easy to test and
diagnose for errors and defects. Testability is generally considered
a positive feature of software because it helps improve the quality of
the system and reduce the cost and effort required to detect and fix
defects.

Verification, on the other hand, refers to the ability to verify that a

system or component meets specified requirements. The process of
testing and verifying that the system performs as expected and
meets the desired specifications and requirements. Testing is
Pg. 6 Question OneQuestion One

necessary to ensure that the system is reliable and performs its

intended function properly.

In conclusion, while testing and validation are concepts that

contribute to software quality, they are not the only ones. Testability
helps ensure that the software can be tested easily and efficiently,
while verification ensures that the software performs as expected
and meets specific requirements.
Pg. 7 Question OneQuestion One

3 Marks

Question Three
Many organizations do not apply their contract review procedures to internal
projects even though they perform comprehensive contract reviews for all their
external projects.

 List arguments that support this approach.

 List arguments that oppose this approach.

Answer:

Arguments against using contract review procedures in internal

projects:

 Time and cost savings: Conducting extensive contract

reviews for internal projects can be time-consuming and
expensive. By not using these procedures, organizations can
save time and resources that can be better used for other
important tasks.

 Streamlining: Internal projects may not require the same

level of documentation and scrutiny as external projects.
Streamlining the contract review procedure for internal
projects can simplify the process and allow the team to focus
on effective project implementation.

 Reduce bureaucracy: Comparing contract review

procedures and internal projects versus external projects can
create bureaucratic red tape and delay project delivery. By not
using this procedure, the team can work faster and more
efficiently.
Pg. 8 Question OneQuestion One

 Trust: Internal projects are often managed by employees who

are familiar with the company's processes and culture, and
may not require the same level of contractual oversight as
external parties.

Arguments against not using contract review procedures in internal

projects:

 Lack of oversight: Failure to apply contract review

procedures for internal projects may result in a lack of
oversight, resulting in the risk of error, fraud, or non-
compliance with legal or regulatory requirements.

 Inconsistent standards: Applying different audit levels and

standards to internal and external projects can create conflict
and confusion within the organization, resulting in a lack of
transparency and accountability.

 Opportunities created: In-house projects can offer

opportunities for innovation, revenue growth and savings. By
not using contract review procedures, organizations may miss
these opportunities and fail to maximize the value of their
internal projects.

 Legal Requirements: Depending on the industry and

jurisdiction, there may be legal requirements that require
certain contract review procedures for all projects, whether
internal or external.

 Accountability: Implementing contract review procedures for

internal projects can help define accountability and ensure
Pg. 9 Question OneQuestion One

that project goals and expectations are clearly defined and

understood by all parties.

In summary, although there are valid arguments for and against the
use of contract review procedures on internal projects, it is up to the
organization to determine what level of control and monitoring is
appropriate for its internal projects. Organizations must weigh the
benefits and risks of using contract review procedures on their
internal projects and make informed decisions that align with overall
business goals.