lab evaluation-4 Nagaraj

1)  Clauses of 9126

ISO 9126 Std                              Description Related ITD procedure
1)Functionality The functionality characteristic allows draw conclusions about how well software provides desired functions. QM
a)Suitability It correlates with metrics which measure attributes of software that allow to conclude the presence and appropriateness of a set of functions for specified tasks. QM
b)Accuracy The accuracy sub-characteristic allows to draw conclusions about how well software achieves correct or agreeable results QM
c)Interoperability It correlates with metrics which measure attributes of software that allow to conclude about its ability to interact with specified systems.

 

QM
d)Security The security sub-characteristic allows to draw conclusions about how secure software is QM
     
2)Reliability The reliability characteristic allows to draw conclusions about how well software maintains the level of system performance when used under specified conditions. DC
a)maturity It correlates with metrics which measure attributes of software that allow to conclude about the frequency of failure by faults in the software.

 

DC
b)Fault Tolerance It correlates with metrics which measure attributes of software that allow to conclude on its ability to maintain a specified level of performance in case of software faults or infringement of its specified interface.

 

QM
c)Recoverability The recoverability sub-characteristic allows to draw conclusions about how well software recovers from software faults or infringement of its specified interface.

 

QM
d)compliance It correlates with metrics which measure attributes of software that allow to conclude about the adherence to application related standards, conventions, and regulations in laws and similar prescriptions.

 

QM
     
3)Usability The usability characteristic allows to draw conclusions about how well software can be understood, learned, used and liked by the developer. QP
a)Understandability Internal understandability reuse metrics assess whether new software engineers/developers can understand: whether the software is suitable;

 

DC
b)Learn ability Internal learn ability metrics assess how long software engineers or developers take to learn how to use particular functions, and the effectiveness of documentation. Learn ability is strongly related to understandability, and understandability measurements can be indicators of the learn ability potential of the software. QM
c)operability Internal programmability metrics assess whether software engineers/developers can integrate and control the software. QM
     
     
4)Re usability Internal usability metrics are used for predicting the extend of which the software in question can be understood, learned, operated, is attractive and compliant with usability regulations and guidelines where here using means integrating it in a larger software system. QM
a)Understandability for

reuse

Software engineers/developers should be able to select a software product which is suitable for their intended use. Internal understandability reuse metrics assess whether new software engineers/developers can understand: whether the software is suitable; how it can be used for particular tasks. QM
b)Learn ability for re use , internal learn ability metrics assess how long software engineers or developers take to learn how to use particular functions, and the effectiveness of documentation. Learn ability is strongly related to understandability, and understandability measurements can be indicators of the learn ability potential of the software. DC
     
5) Efficiency The efficiency characteristic allows to draw conclusions about how well software provides required performance relative to amount of resources used. It can be used for assessing, controlling and predicting the extent to which the software product (or parts of it) in question satisfies efficiency requirements. QP
a)time  behavior The time behavior sub-characteristic allows to draw conclusions about how well the time behavior of software is for a particular purpose. DC
b)resource utilization . It correlates with metrics which measure attributes of software that allow to conclude about the amount and duration of resources used while performing its function.

 

 

QM
     
6)Maintainability The maintainability characteristic allows to draw conclusions about how well software can be maintained. It can be used for assessing, controlling and predicting the effort needed to modify the software product (or parts of it) in question. QM
a)Analyzability The analyzability sub-characteristic allows to draw conclusions about how well software can be analyzed. It correlates with metrics which measure attributes of software that allow to conclude about the effort needed for diagnosis of deficiencies or causes of failures, or for identification of parts to be modified. QM
b)Stability The stability sub-characteristic allows to draw conclusions about how stable software is. It correlates with metrics which measure attributes of software that allow to conclude about the risk of unexpected effects as result of modifications.

 

QM
c)Testability The testability sub-characteristic allows to draw conclusions about how well software can be tested and is tested. It correlates with metrics which measure attributes of software that allow to conclude about the effort needed for validating the software and about the test coverage. QM
     
7)Portability The portability characteristic allows to draw conclusions about how well software can be ported from one environment to another. It can be used for assessing, controlling and predicting the extend to which the software product (or parts of it) in question satisfies portability requirements. QM
a)Adaptability The adaptability sub-characteristic allows to draw conclusions about how well software can be adapted to environmental change. It correlates with metrics which measure attributes of software that allow to conclude about the amount of changes needed for the adaptation of software to different specified environments.

 

QM
b)Install ability The installability sub-characteristic allows to draw conclusions about how well software can be installed in a designated environment. It correlates with metrics which measure attributes of software that allow to conclude about the effort needed to install the software in a specified environment.

 

 

QP
c)Replace ability The replaceability sub-characteristic allows to draw conclusions about how well software can replace other software or parts of it. It correlates with metrics which measure attributes of software that allow to conclude about opportunity and effort using it instead of specified other software in the environment of that software.

 


 

QM
     
     

 

2) The traditional SCM identifies four procedures that must be defined for each software project to ensure a good SCM process is implemented. They are

  • Configuration Identification
  • Configuration Control
  • Configuration Status Accounting
  • Configuration Authentication

3. The testing for the features are as follows.

Reliability : Software Reliability Testing requires checking features provided by the software,the load that software can handle and regression testing.

Feature test

feature test for software conducts in following steps

  • Each operation in the software is executed once.
  • Interaction between the two operations is reduced and
  • Each operation each checked for its proper execution.

feature test is followed by the load test.

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).

3). Including provisions for usability within the design specification will assist later usability testing. Usually for new application developments, and nearly always for custom application developments, the design team should either have an excellent understanding of the business processes/rules/logic behind the system being developed; and include users with first hand knowledge of same. However, although they design the system, they rarely specifically include usability provisions in the specifications.

An example of a usability consideration within the functional specification may be as simple as specifying a minimum size for the ‘Continue’ button.

4). At the unit testing stage, there should be an official review of the system – where most of those issues can more easily be dealt with. At this stage, with screen layout & design already reviewed, the focus should be on how a user navigates through the system. This should identify any potential issues such as having to open an additional window where one would suffice. More commonly though, the issues that are usually identified at this stage relate to the default or most common actions. For example, where a system is designed to cope with multiple eventualities and thus there are 15 fields on the main input screen – yet 7 or 8 of these fields are only required in rare instances. These fields could then be set as hidden unless triggered, or moved to another screen altogether.

5). All the previous actions could be performed at an early stage if Prototyping is used. This is probably the best way to identify any potential usability/operability problems. You can never lessen the importance of user-centered design, but you can solve usability problems before they get to the QA stage (thereby cutting the cost of rebuilding the product to correct the problem) by using prototypes (even paper prototypes) and other “discount usability” testing methods.
6). From a testing viewpoint, usability testing should be added to the testing cycle by including a formal “User Acceptance Test”. This is done by getting several actual users to sit down with the software and attempt to perform “normal” working tasks, when the software is near release quality. I say “normal” working tasks because testers will have been testing the system from/using test cases – i.e. not from a users viewpoint. User testers must always take the customer’s point of view in their testing.

User Acceptance Testing (UAT) is an excellent exercise, because not only will it give you there initial impression of the system and tell you how readily the users will take to it, but this way it will tell you whether the end product is a closer match to their expectations and there are fewer surprises. (Even though usability testing at the later stages of development may not impact software changes, it is useful to point out areas where training is needed to overcome deficiencies in the software.

(7) Another option to consider is to include actual users as testers within the test team. One financial organization I was involved with reassigned actual users as “Business Experts” as members of the test team. I found their input as actual “tester users” was invaluable.

8). The final option that may be to include user testers who are eventually going to be (a) using it themselves; and/or (b) responsible for training and effectively “selling” it to the users.

Affordability testing:

A way to do affordability testing is to ask customer what is his buget and if the project manager thinks that he can do it then  affordability can be met else there is no way.

 

2) TEST CASES

 

Online Book Store Test

Baseline test

Baseline:

  1. Stakeholders (Application users) are two identical users, customer and administrator.
  2. Customer shall register their information to the database (ID, password, name, address, phone number, email, credit card number, etc)
  3. The application shall support simple search of books (by ISBN, title and author etc)
  4. User be able to order books (registered user only)
  5. Administrator shall add the inventory list.
  6. Administrator shall delete the inventory list.

Test Number #1

 

Test case

: Stakeholders (Application users) are two identical users, customer and administrator.

 

Test procedure:

  1. Check whether the webpage exists for customer.

Test resultSatisfied.

  1. Check whether the webpage separated with one for administrator exists for customer.

Test resultSatisfied.

 

Test Number #2

 

Test case

: Customer shall register their information to the database (ID, password, name, address, phone number, email, credit card number, etc)

 

Test procedure:

  1. Move to the webpage for customer.
  2. Check whether the menu for registration exists or not.

Test resultSatisfied. In the right top part of the webpage

  1. Check whether the menu for registration is linked correctly.

Test resultSatisfied.

  1. Check whether the customer be able to register successfully.

Test resultSatisfied.

 

Test Number #3

 

Test case

: The registered customer should be able to search books. (By ISBN, title and author)

 

Test procedure:

  1. Check whether the menu for simple search exists or not.

Test resultSatisfied. In the right top part of the webpage for the customer logged in.

  1. Check whether the menu for search is linked correctly.

Test resultSatisfied.

  1. Check whether the customer be able to search books by ISBN successfully.

Test resultSatisfied.

  1. Check whether the customer be able to search books by title successfully.

Test resultSatisfied.

  1. Check whether the customer be able to search books by author successfully.

Test resultSatisfied.

 

Test Number #4

 

Test case

: The registered customer should be able to order a book.

 

Test procedure:

  1. Check whether the menu for ordering a book exists or not.

Test resultSatisfied. In the right top part of the webpage for the customer logged in.

  1. Check whether the menu for ordering a book is linked correctly.

Test result: Satisfied.

  1. Check whether the administrator be able to order a book successfully.

Test resultSatisfied.

 

Test Number #5

 

Test case

: Administrator shall add the inventory list

 

Test procedure:

  1. Move to the webpage for administrator
  2. Check whether the menu for adding and deleting exists or not.

Test resultSatisfied. In the right top part of the webpage

  1. Check whether the menu for adding a book is linked correctly.

Test resultSatisfied.

  1. Check whether the administrator be able to add a book successfully.

Test resultSatisfied.

 

Test Number #6

 

Test case

: Administrator shall delete the inventory list

 

Test procedure:

  1. Move to the webpage for administrator
  2. Check whether the menu for deleting exists or not.

Test resultSatisfied. In the right top part of the webpage

  1. Check whether the menu for adding a book is linked correctly.

Test resultSatisfied

  1. Check whether the administrator be able to delete a book successfully.

Test resultSatisfied.

 

 

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: