lab evaluation 4- manjunath m

test.jpgThe test cases code for online book store

The c clauses of ISO 9001 and ISO 9126 standards for online book store ara as follows

1) This part of ISO/IEC 9126 enables software product quality to be specified and evaluated from
different perspectives by those associated with acquisition, requirements, development, use,
evaluation, support, maintenance, quality assurance and audit of software. It can for example be used
by developers, acquirers, quality assurance staff and independent evaluators, particularly those
responsible for specifying and evaluating software product quality. Examples of uses of the quality
model defined in this part of ISO/IEC 9126 are to:
• validate the completeness of a requirements definition;
• identify software requirements;
• identify software design objectives;
• identify software testing objectives;
• identify quality assurance criteria;
• identify acceptance criteria for a completed software product.

The following are some of the main objectives of an organization’s documentation, independent of
whether or not it has implemented a formal QMS;
a) Communication of Information
– as a tool for information transmission and communication. The type and extent of the
documentation will depend on the nature of the organization’s products and processes, the
degree of formality of communication systems and the level of communication skills within
the organization, and the organizational culture.
b) Evidence of conformity
– provision of evidence that what was planned, has actually been done.
c) Knowledge sharing
– to disseminate and preserve the organization’s experiences. A typical example would be a
technical specification, which can be used as a base for design and development of a new

ISO 9001:2008 clause 4.1 General requirements requires an organization to “establish, document,
implement, and maintain a quality management system and continually improve its effectiveness in
accordance with the requirements of this International Standard”
Clause 4.2.1 General explains that the quality management system documentation shall include
documented statements of a quality policy and quality objectives;
a quality manual
documented procedures required by this International Standard
documents needed by the organization to ensure the effective planning, operation and control of its
processes, and
records required by this International Standard;

2) Starts during the early phases of the project
All products of the software process may have
to be managed
A) Specifications
b) Designs
c) Programs
d) Test data
e) User manuals
Thousands of separate documents may be generated
for a large software system

The CM plan

–>Defines the types of documents to be managed and a document naming scheme
–>Defines who takes responsibility for the CM procedures and creation of “baselines”
–>Defines policies for change control and version management
–>Defines the CM records which must be maintained
–>Describes the tools which should be used to assist the CM process and any limitations on their use

Configuration item identification

Large projects typically produce thousands of documents which must be uniquely identified

Some of these documents must be maintained for the lifetime of the software
Document naming scheme should be defined so that related documents have related names.
A hierarchical scheme with multi-level names is probably the most flexible approach

The configuration database

All CM information should be maintained in a
configuration database
This should allow queries about configurations to be answered

Who has a particular system version?
What platform is required for a particular version?
What versions are affected by a change to component X?
How many reported faults in version T?
The CM database should preferably be linked to the software being managed

3) Load test

This test is conducted to check the performance of the software under maximum work load. Any software performs better up to some extent of load on it after which the response time of the software starts degrading. For example, a web site can be tested to see till how many simultaneous users it can function without performance degradation. This testing mainly helps for Databases and Application servers. Load testing also requires to do software performance testing where it checks that how well some software performs under workload.
Regression test

Regression testing is used to check if any bug fixing in the software introduced new bug. One part of the software affects the other is determined. Regression testing is conducted after every change in the software features. This testing is periodic. The period depends on the length and features of software.

Compatibility:- The Compatibility testing can be done as follows
Computing capacity of Hardware Platform (IBM 360, HP 9000, etc.)..
Bandwidth handling capacity of networking hardware
Compatibility of peripherals (Printer, DVD drive, etc.)
Operating systems (Linux, Windows, etc.)
Database (Oracle, SQL Server, MySQL, etc.)
Other System Software (Web server, networking/ messaging tool, etc.)
Browser compatibility (Chrome, Firefox, Netscape, Internet Explorer, Safari, etc.)

Browser compatibility testing, can be more appropriately referred to as user experience testing. This requires that the web applications are tested on different web browsers, to ensure the following:

Users have the same visual experience irrespective of the browsers through which they view the web application.
In terms of functionality, the application must behave and respond the same way across different browsers.
Carrier compatibility (Verizon, Sprint, Orange, O2, AirTel, etc.)
Backwards compatibility.
Hardware (different phones)
Different Compilers (compile the code correctly)
Runs on multiple host/guest Emulators

Usability testing:

The best way to implement usability testing is two fold – firstly from a design & development perspective, then from a testing perspective.

From a design viewpoint, usability can be tackled by (1) Including actual Users as early as possible in the design stage. If possible, a prototype should be developed – failing that, screen layouts and designs should be reviewed on-screen and any problems highlighted.. The earlier that potential usability issues are discovered the easier it is to fix them.

(2) Following on from the screen reviews, standards should be documented i.e. Screen Layout, Labelling/Naming conventions etc. These should then be applied throughout the application.

Where an existing system or systems are being replaced or redesigned, usability issues can be avoided by using similar screen layouts – if they are already familiar with the layout the implementation of the new system will present less of a challenge, as it will be more easily accepted (provided of course, that that is not why the system is being replaced).



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: