How can I tell if a web page is secure?

The below takes you ssl.com aritcle on web page secure.  This brilliantly written article answers almost everything you need to know bout how to tell if a website is secure.

http://info.ssl.com/Article.aspx?id=10068

Also read the below releated articles on subject:

http://www.iisfaq.com/default.aspx?View=P20&P=145

http://www.lloydstsb.com/security/web_page_security.asp [click 'check a site certificate' link at the end of description]

Below article explains the process of procuring and installing a SSL server certificate [article focus on SSL.com products, but worth to read as the process should be common to all vendors]

http://info.ssl.com/article.aspx?id=10694

Cheers

posted @ Thursday, August 23, 2007 4:29 AM | Feedback (0) | Filed Under [ Web Testing ]

What are Load, Stress, Volume, etc. testing?

A:

- Volume testing is a way to test functionality.

- Stress testing is a way to test reliability.

- Load testing is a way to test performance.

Testing an application under heavy but expected loads is known as load
testing. It generally refers to the practice of modeling the expected usage of a software program by simulating multiple users accessing the system's services concurrently. As such, load testing is most relevant for a multi-user system, often one built using a client/server model, such as a web server tested under a range of loads to determine at what point the system's response time degrades or fails. Although you could perform a load test on a word processor by or graphics editor forcing it read in an extremely large document; on a financial package by forcing to generate a report based on several years' worth of data, etc.

When the load placed on the system is accelerated beyond normal usage
patterns, in order to test the system's response at unusually high or peak loads, it is known as stress testing. Stress testing is often incorrectly used interchangeably with load and performance testing.

In a stress test, the load is usually so great that error conditions are the expected result, although there is a grey area between the two domains and no clear boundary exists where you could say that an activity ceases to be a load test and becomes a stress test.

There is little agreement on what the specific goals of load testing are. The term is often used synonymously with performance testing, reliability testing, and volume testing.

Performance testing is usually performed to determine how fast some aspect of a system performs under a particular workload. It can serve different purposes: to demonstrate that the system meets performance criteria; to compare two systems to find which performs better; to measure what parts of the system or workload cause the system to perform badly.

In the diagnostic case, software engineers use tools such as profilers to measure what parts of a device or software contribute most to the poor performance. In performance testing, it is often crucial (and often difficult to arrange) for the test conditions to be similar to the expected actual use.

A reliability test determines how likely a piece of hardware (or sometimes software) is to fail. It is part of reliability theory, used originally as a tool to help nineteenth century insurance companies compute profitable rates to charge their customers. Statistical models appropriate for any of these are generically called "time-to-event" models. Death or failure is called an "event", and the goal is to project or forecast the rate of events for a given population or probability of an event for an individual.

Volume testing is used to determine if the system under test can handle the required amounts of data, user requests, etc.

Soak testing occurs when running a system at normal to high levels of load for prolonged periods of time. A soak test would normally execute several times more transactions in an entire day than would be expected in a busy day. This should identify any performance problems that appear after a large number of transactions have been executed.

For some of the basics on this type of testing, please read the following series:

Web Page Response Time 101
http://www.stickyminds.com/r.asp?F=DART_5030

Web Load Test Planning
http://www.stickyminds.com/r.asp?F=DART_5084

The Science and Art of Web Site Load Testing
http://www.stickyminds.com/r.asp?F=DART_1939

Getting Started : Stressing Web Applications Stress Early -- Stress Often
http://www.amibug.com/getinfo.shtm?present=webstress

http://www.perftestplus.com
http://www.performancetester.com

posted @ Wednesday, November 16, 2005 2:14 PM | Feedback (1) |

HTTP Error Codes

HTTP Error Codes
Information Codes
Error #	Error Code	Description
100	Continue	The request was successful. The process can now continue.
101	Switching Protocols	The request for the server to switch protocols was accepted, such as a switch from ftp to http.
Success Codes
Error #	Error Code	Description
200	OK	The item requested of the server is available (keep in mind, available, not accepted or completed).
201	Created	A new address has been created through the use of form posting, perl, cgi, etc.
202	Accepted	The request has been accepted (keep in mind that the request has been accepted, not completed)
203	Non-Authoritative Information	The information received is not from the server that the information was requested from, but from another source.
204	No Content	There was no content to be given for the request. For instance if you click on a hyperlink, imagemap, or button that isn't linked to anything or doesn't do anything.
205	Reset Content	A script has reset the displayed content.
206	Partial Content	Only partial content has been displayed. This could be due to bandwidth, poor caching, bad html, or other reasons.
Redirection Codes
Error #	Error Code	Description
300	Multiple choices	You will either get a choice of pages or an error message when this occurs. The address is actually pointing to two multiple files and/or locations.
301	Moved Permanently	The requested page has been permanently moved. The server will automatically redirect you to the new location.
302	Found	The requested page has been temporarily moved. The server will automatically redirect you to the new location.
303	See Other	The requested data is stored in an alternate location and the GET method will be used to retrieve the data. If the actual error is returned then this may be due to a web server misconfiguration.
304	Not Modified	The requested data has not been modified since the last request.
305	Use Proxy	The requested data may only be accessed via the use of a proxy server.
307	Temporary Redirect	The requested page has been moved. The server will automatically redirect you to the new location. Unlike Error 301 and 302 however, the server has not specified whether the move is temporary or permanent.
Client Error Codes
Error #	Error Code	Description
400	Bad Request	The request was denied due to a syntax error in the request.
401	Unauthorized	Your IP address or the username/password you entered were not correct. Your request was denied as you have no permission to access the data.
402	Payment Required	The data is not accessible at the time. The owner of the space has not yet payed their service provider.
403	Forbidden	Your IP address or the username/password you entered were not correct. Your request was denied as you have no permission to access the data. OR The server was unable to serve the data that was requested.
404	Not Found	The document that has been requested either no longer exists, or has never existed on the server.
405	Method Not Allowed	The document that has been requested either no longer exists, or has never existed on the server.
406	Not Acceptable	The client (webbrowser) does not accept the document format. The formats that may be specified not to accept are charset, encoding, certain file types, languages, or ranges.
407	Proxy Authentication Required	The browser has not been authenticated on the required proxy server to access the data. This error is probably most commonly returned by content filters/parental controls.
408	Request Timeout	The server has closed the socket due to communications between the client and server taking too long. This could be due to server load, bandwidth issues, the client being disconnected from the internet, etc.
409	Conflict	Too many requests for the same file at one time. OR There is a conflict with an established software rule. (ie: you are trying to copy over a file with an older version, or you do not have permissions to delete a file) OR This could be caused by a DNS issue
410	Gone	This is like a 404 error in that the document requested is not on the server, however this differs in that the server 'knows' that the file used to be there and 'believes' that the file may be back, so it returns 410 rather 404.
411	Length Required	When trying to send a document to the server the server did not recieve a Content-Length specification in the header.
412	Precondition Failed	A precondition setting required by the client or server has not been met.
413	Request Entity Too Large	The process is too large to process. (ie: a file you are trying to upload is too large to fit on the server, or a webpage you are trying to download is too large for the server to process)
414	Request-URI Too Large	The URL requested is simply too long. It is most likely more than 1024, 2048, or 4096 characters in length.
415	Unsupported Media Type	This usually occurs if the server does not support the type of media the client is requesting. (ie: the server does not support streaming media, but streaming media is on the server and the client is attempting to access it)
416	Requested Range Not Satisfiable	The client request included a range for acceptable file size, however the document requested did not fit into that range.
417	Expectation Failed	The client's expect header requested certain server behaviors that the server could not perform.
Server Error Codes
Error #	Error Code	Description
500	Internal Server Error	The server encountered an error. This is most often caused by a scripting problem, a failed database access attempt, or other similar reasons.
501	Not Implemented	The method you are using to access the document can not be performed by the server. Possible methods include: CONNECT DELETE GET HEAD OPTIONS POST PUT TRACE
502	Bad Gateway	The document requested resides on a 3rd party server and the original server received an error from the 3rd party server.
503	Service Unavailable	The server is overloaded or down for maintenance and due to this was unable to process the client request.
504	Gateway Timeout	Most likely the client has lost connectivity (disconnected from the internet) or the cleint's host is having technical difficulties. This could also mean that a server that allows access to the requested server is down, having bandwidth/load issues, or otherwise unavailable.
505	HTTP version not supported	The server does not support the HTTP version used by the client. (This usually occurs if the server is using an OLDER version of HTTP than the client.)

posted @ Thursday, October 06, 2005 9:39 AM | Feedback (3) |

Computer Bug

Computer Bug

http://en.wikipedia.org/wiki/Software_bug

 

Bug Tracking and Reporting

http://www.stickyminds.com/r.asp?F=DART_5898

 

http://www.stickyminds.com/r.asp?F=DART_5043

 

http://www.cs.uwm.edu/classes/cs657/cs657-7/library/writingEffectiveDefectReports.pdf

 

http://www.daveeaton.com/scm/PMTools.html

 

http://testingfaqs.org/t-track.html

posted @ Monday, September 26, 2005 9:41 AM | Feedback (1) |

Testing Client/Server Systems

Courtesy: Paul Gerrard, Systeme Evolutif Ltd. www.evolutif.co.uk

What's different about testing client/server?

Client/server architectures allow complex systems to be assembled from components. However, multiple operating systems, changing technologies and greater architectural complexity make integration more difficult. Risks such as poor reliability, performance, configuration management, security and other non-functional issues are more prominent. None of the risks in client/server are new, but there has been a change in emphasis. Since its purpose is to address risk, the emphasis of testing in client/server must change.

The complexity of client/server also makes testing more difficult. Complex systems can be delivered faster because they are assembled from bought-in components. Testing is often estimated to be in proportion with the development cost but in a typical client/server system, the development cost may be small compared with the overall cost of the system. The end-result in such projects, is that testers are presented with more complex systems, but the time left for testing is squeezed. In client/server, testers often have to do MORE WITH LESS!

Client/server test process

A client/server test strategy must identify the risks of concern and define a test process that ensures these risks are addressed. It is axiomatic that a problem is cheaper to fix if identified early, so the test process should be aligned very closely to the development process. Testing of a deliverable should occur as soon as possible after it has been built.

Functionality is usually tested in three stages: a unit or component test, often performed by programmers; a system test, of the complete system in a controlled environment performed by a dedicated test resource; finally, an acceptance test under close to production conditions, often performed by users. The objectives, techniques and responsibility for these three test stages are directly comparable to test stages in more traditional host-based systems.

The changed emphasis in testing client/server is associated with integration and non-functional testing.

Integration is a big issue because client/server systems are usually assembled from around twelve components (for a simple 2-Tier system) to perhaps twenty components for a complex architecture. These components are usually sourced from multiple suppliers. Although standards are emerging, client/server architectures often use components which have never been used before in combination.

The sheer number of interfaces involved make interface problems and inter-component conflicts more likely. Assumptions made by developers of one component from one supplier may contradict assumptions made by another developer. These problems may be encountered for the first time ever in your installation. Getting suppliers to take such problems seriously may be difficult because in client/server, it is the system integrator who takes responsibility for integration testing.

Performance consistently presents a problem in client/server. `Intelligent clients' may call for and process large volumes of data across networks. The amount of code exercised in large numbers of architectural layers may be substantial. Delays between distributed processes may be only ten or twenty milliseconds, but when a transaction requires hundreds of network messages, delays can be considerable.

Other non-functional issues such as security, backup and recovery and system administration also present risks. What was taken for granted in a mainframe environment often presents problems in client/server.

The test strategy must address all these risks, but testing does not happen `at the end'. Testing occurs at all stages and includes reviews, walkthroughs and inspections. Developers should be responsible for the products they deliver and should test their own code. System tests should cover non-functional areas as well as the functionality. The overarching principle is test early, test often.

Managing testing

To ensure testing gets attention, define testing as a specific activity within the development phase. Instil a regime that says components are delivered and acceptable only when tested without error and signed off.

Promote better test practices within the development team. Developers are often reluctant (or incapable) of testing their own code, so implement a `buddy scheme', where pairs of programmers test each others code. If practical, put testers into the development team to obtain the benefits of independence.

When a project moves from the development phase into system and acceptance testing, the nature of the project changes. Incident logging, management and reporting become the project manager's main method of project control. Progress is measured by tests performed, errors detected, fixed and retested. A simple PC database is usually adequate for recording incidents and providing useful progress reports and statistics.

Without a strong configuration management and change control regime, systematic testing can be ineffective. Complexity makes this more important, but also more difficult. Ensure a definitive inventory of components exists, system builds are automated where possible and releases are base-levelled.

Test automation

If you are not planning to conduct formal, documented functional tests, do not buy a tool to `do regression testing'. It will probably be a distraction, and lose you both time and money. If you do intend to implement regression tests, formulate a highly selective and economically viable regression test policy and only attempt to create automated regression tests when the software is sufficiently stable.

Integration and interface testing using test drivers or harnesses should be encouraged. Given test running and dynamic analysis tools, your developers can usually build test harnesses quickly. Where object-oriented languages, such as C++ are used, dynamic analysis tools are essential to detect memory leaks and give programmers invaluable insights into the behaviour of their code. Consider developing extended or `soak' tests of components where bespoke, low level code has been written.

Architectural components should be load and stress tested individually and as a complete system if resilience or performance are of concern. Whether you adopt a top-down, bottom-up or other integration strategy, the principle is to gain confidence in one build configuration, before integrating the next components for test.

System performance testing requires considerable tool support. Load generation, response time measurement, server, database and client monitoring and performance analysis may all be required. Although several vendors offer sophisticated test running tools with load regulation and performance analysis facilities, there is no one solution available. A combination of proprietary test tools, in-house utilities and innovation are usually needed to build, execute and analyse comprehensive tests.

Performance testing and tuning tends to follow three stages. Early tests tend to cause failures in the system caused by bugs or gross mis-setting of system parameters. In stage two, application design errors, such as inefficient SQL are identified. Finally, when the system is reliable and the application tuned, the database and server operating system parameters can then be tuned to achieve optimal performance.

Testing skills

Testing is a skill which requires a disciplined, systematic approach. Few developers, testers or users have ever received formal training in testing. Training helps testers not only to do better testing but helps them to be more motivated. Users, in particular, can benefit from testing training because they will better understand how to organise themselves, to prepare more comprehensive tests and be more critical of the systems they are expected to accept. If RAD is used, responsibility for testing shifts from the developer to the user, so user testing skills are essential.

posted @ Wednesday, April 20, 2005 9:35 PM | Feedback (0) |

Defect Severity and Defet Priority

This document defines the defect Severity scale for determining defect criticality and the associated defect Priority levels to be assigned to errors found in software. It is a scale which can be easily adapted to other automated test management tools.

ANSI/IEEE Std 729-1983 Glossary of Software Engineering Terminology defines Criticality as,

"A classification of a software error or fault based on an evaluation of the degree of impact that error or fault on the development or operation of a system (often used to determine whether or when a fault will be corrected)."

The severity framework for assigning defect criticality that has proven most useful in actual testing practice is a five level scale. The criticality associated with each level is based on the answers to several questions.

First, it must be determined if the defect resulted in a system failure. ANSI/IEEE Std 729-1983 defines a failure as,

"The termination of the ability of a functional unit to perform its required function."

Second, the probability of failure recovery must be determined. ANSI/IEEE 729-1983 defines failure recovery as,

"The return of a system to a reliable operating state after failure."

Third, it must be determined if the system can do this on its own or if remedial measures must be implemented in order to return the system to reliable operation.

Fourth, it must be determined if the system can operate reliably with the defect present if it is not manifested as a failure.

Fifth, it must be determined if the defect should or should not be repaired.

The following five level scale of defect criticality addresses the these questions.

The five Levels are:

1. Critical

2. Major

3. Average

4. Minor

5. Exception

1. Critical - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system.

2. Major - The defect results in the failure of the complete software system, of a subsystem, or of a software unit (program or module) within the system. There is no way to make the failed component(s), however, there are acceptable processing alternatives which will yield the desired result.

3. Average - The defect does not result in a failure, but causes the system to produce incorrect, incomplete, or inconsistent results, or the defect impairs the systems usability.

4. Minor - The defect does not cause a failure, does not impair usability, and the desired processing results are easily obtained by working around the defect.

5. Exception - The defect is the result of non-conformance to a standard, is related to the aesthetics of the system, or is a request for an enhancement. Defects at this level may be deferred or even ignored.

In addition to the defect severity level defined above, defect priority level can be used with severity categories to determine the immediacy of repair. A five repair priority scale has also be used in common testing practice. The levels are:

1. Resolve Immediately

2. Give High Attention

3. Normal Queue

4. Low Priority

5. Defer

1. Resolve Immediately - Further development and/or testing cannot occur until the defect has been repaired. The system cannot be used until the repair has been effected.

2. Give High Attention - The defect must be resolved as soon as possible because it is impairing development/and or testing activities. System use will be severely affected until the defect is fixed.

3. Normal Queue - The defect should be resolved in the normal course of development activities. It can wait until a new build or version is created.

4. Low Priority - The defect is an irritant which should be repaired but which can be repaired after more serious defect have been fixed.

5. Defer - The defect repair can be put of indefinitely. It can be resolved in a future major system revision or not resolved at all.

posted @ Saturday, January 22, 2005 2:27 PM | Feedback (10) |

Professional Tester - Magazine for testing professionals

Professional Tester is a magazine for testing professionals.  Anyone can subscribe to this magazine and receive by email.  Articles from the January 2004 are available for DOWNLOAD

posted @ Tuesday, March 29, 2005 4:01 PM | Feedback (2) |

Some good links on performance testing (Load testing)

1) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vsent7/html/vxcontestingforperformance.asp

2) http://msdn.microsoft.com/msdnmag/issues/03/01/LoadTesting/

3) http://www.softwaretesting.nildram.co.uk/cont383.htm (Good site, refer for other testing concepts too)

4) http://www.theserverside.com/news/thread.tss?thread_id=3396 (Performance Testing with the MS Web Application Stress Tool)

5) http://www.theserverside.com/news/thread.tss?thread_id=23988 (Performance Testing your Distributed J2EE Applications)

6) http://www.theserverside.com/articles/article.tss?l=Tips-On-Performance-Testing-And-Optimization (Tips on Performance Testing and Optimization)

posted @ Tuesday, March 29, 2005 3:29 PM | Feedback (0) |

Requirements Traceability Matrix

Project Name

Requirements Traceability Matrix

 Description of Matrix Fields

Develop a matrix to trace the requirements back to the project objectives identified in the Project Plan and forward through the remainder of the project life cycle stages. Place a copy of the matrix in the Project File. Expand the matrix in each stage to show traceability of work products to the requirements and vice versa. The requirements traceability matrix should contain the following fields:

• A unique identification number containing the general category of the requirement (e.g., SYSADM) and a number assigned in ascending order (e.g., 1.0; 1.1; 1.2).
• The requirement statement.
• Requirement source (Conference; Configuration Control Board; Task Assignment, etc.).
• Software Requirements Specification/Functional Requirements Document paragraph number containing the requirement.
• Design Specification paragraph number containing the requirement.
• Program Module containing the requirement.
• Test Specification containing the requirement test.
• Test Case number(s) where requirement is to be tested (optional).
• Verification of successful testing of requirements.
• Modification field. If requirement was changed, eliminated, or replaced, indicate disposition and authority for modification.
• Remarks.

posted @ Friday, December 10, 2004 11:50 AM | Feedback (15) |

Guidelines and Checklist for Website Testing

1. Functionality:

 

1.1               Links

 

Objective is to check for all the links in the website.

 

1.1.1          All Internal Links

1.1.2          All External Links

1.1.3          All mail to links

1.1.4          Check for orphan Pages

1.1.5          Check for Broken Links

 

1.2               Forms

 

Test for the integrity of submission of all forms.

 

1.2.1          All Field Level Checks

1.2.2          All Field Level Validations.

1.2.3          Functionality of Create, Modify, Delete & View.

1.2.4          Handling of Wrong inputs (Both client & Server)

1.2.5          Default Values if any

1.2.6          Optional versus Mandatory fields.

 

1.3               Cookies

 

Check for the cookies that has to be enabled and how it has to be expired.

 

    

1.4               Web Indexing

 

Depending on how the site is designed using Meta tags, frames, HTML syntax, dynamically created pages, passwords or different languages, our site will be searchable in different ways.

 

1.4.1          Meta Tags

1.4.2          Frames

1.4.3          HTML syntax.

 

 

1.5               Database

 

Two types of errors that may occur in Web applications:

A.      Data Integrity:

Missing or wrong data in table.

 

B.      Output Error:

Errors in writing, editing or reading operations in the tables.

 

The issue is to test the functionality of the database, not the content and the focus here is therefore on output errors. Verify that queries, writing, retrieving or editing in the database is performed in a correct way.

 

 

2. Usability:

 

2.1               Navigation

 

Navigation describes the way users navigate within a page, between different user interface controls (buttons, boxes, lists, windows etc.), or between pages via e.g. links.

 

2.1.1          Application navigation is proper through tab

2.1.2          Navigation through Mouse

2.1.3          Main features accessible from the main/home page.

2.1.4          Any hot keys, control keys to access menus.

 

2.2               Content

 

Correctness is whether the information is truthful or contains misinformation. The accuracy of the information is whether it is without grammatical or spelling errors. Remove irrelevant information from your site. This may otherwise cause misunderstandings or confusion.

 

2.2.1          Spellings and Grammars

2.2.2          Updated information

 

2.3               General Appearance

 

2.3.1          Page appearance

2.3.2          Color, font and size

2.3.3          Frames

2.3.4          Consistent design

 

3. Server Side Interfaces:

 

3.1               Server Interface

 

3.1.1          Verify that communication is done correctly, Web server-application server, application server-database server and vice versa.

3.1.2          Compatibility of server software, hardware, network connections.

3.1.3          Database compatibility (SQL, Oracle etc.)

 

3.2               External Interface (if any)

 

 

4. Client Side Compatibility:

 

4.1               Platform

 

Check for the compatibility of

a. Windows (95, 98, 2000, NT)

b. Unix (different sets)

c. Macintosh (If applicable)

d. Linux

e. Solaris (If applicable)

 

4.2               Browsers

 

Check for the various combinations:

Internet Explorer (3.X 4.X, 5.X)

Netscape Navigator (3.X, 4.X, 6.X)

AOL

Browser settings (security settings, graphics, Java etc.)

Frames and Cascade Style sheets

Applets, ActiveX controls, DHTML, client side scripting

HTML specifications.

 

 

Graphics:

Loading of images, graphics, etc.,

 

4.3               Printing

 

Despite the paperless society the web was to introduce, printing is done more than ever. Verify that pages are printable with considerations on:

 

a. Text and image alignment

b. Colours of text, foreground and background

c. Scalability to fit paper size

d. Tables and borders

 

 

5. Performance:

 

5.1               Connection speed

 

a. Try with Connection speed: 14.4, 28.8, 33.6, 56.6, ISDN, cable, DSL, T1, T3

b. Time-out

 

5.2               Load

 

Check/Measure the following:

 

1. What is the estimated number of users per time period and how will it be divided over the period?
2. Will there be peak loads and how will the system react?
3. Can your site handle a large amount of users requesting a certain page?
4. Large amount of data from users.

 

5.3               Stress

 

Stress testing is done in order to actually break a site or a certain feature to determine how the system reacts. Stress tests are designed to push and test system limitations and determine whether the system recovers gracefully from crashes. Hackers often stress systems by providing loads of wrong in-data until it crash and then gain access to it during start-up.

 

a. Typical areas to test are forms, logins or other information transaction components.

b. Performance of memory, CPU, file handling etc.

c. Error in software, hardware, memory errors (leakage, overwrite or pointers)

 

5.4               Continuous use

 

1. Is the application or certain features going to be used only during certain periods of time or will it be used continuously 24 hours a day 7 days a week?
2. Will downtime be allowed or is that out of the question?
3. Verify that the application is able to meet the requirements and does not run out of memory or disk space.

 

 6. Security:

 

6.1               Valid and Invalid Login

6.2               Limit defined for the number of tries.

6.3               Can it be bypassed by typing URL to a page inside directly in the browser?

6.4               Verify Log files are maintained to store the information for traceability.

6.5               Verify encryption is done correctly if SSL is used (If applicable)

6.6               No access to edit scripts on the server without authorization.

 

 

Checklist before hosting a website:

 

** Enter “Not Applicable” whichever test not carried out.

 

Test Carried out	Expected	Actual	Remarks	Ticket Reference
1. Functionality
1.1 Links
Internal Links	Should be present
External Links	Should be present
Mail to links	Should open mailbox
Orphan pages	Should not be present
Broken links	Should not be present
1.2 Forms
Field Level checks	Checked for length, special characters, numerical characters etc.,
Field Level Validation	Checked Unique records, Date validation
Functional checks	Create, modify, view and delete are working.
Error Handling for wrong inputs or actions.	Appropriate error messages to be displayed.
Optional and mandatory fields.	Mandatory field should not be left blank. Optional should allow the user to skip the field.
1.3 Cookies
Check whether cookies are enabled.	**Depends on project
1.4 Web Indexing
Meta tags	Should be present.
Html Syntax	Should be valid
Frames	To be found ok
1.5 Database
Data Integrity	Should not be any missing or wrong data in the database
Output Errors	Errors in writing, reading or editing operations should not be present
2. Usability
2.1 Navigation
Navigation through Mouse	Should be proper
Navigation through Tab	Should be proper
Main features access	Should be accessed from home/Main page
Hot Keys, Control Keys for menu or action	Should be present
2.2 Content
Spelling and Grammar	To be proper
Updated information’s.	Past events/ information’s to be removed.
2.3 General Appearance
Page Appearance	Should not be any overlapping, missing etc.,
Colour, font and size	Should be as per standard
Frames	All frames to be appeared
Consistent Design	Everywhere in the website consistent layout and design should be carried out.
3. Server Side Interface
3.1 Server Interface	Communication should be correct with respect to Web server, App server and DB server
Compatibility with server hardware, Sw, network connections	Should be proper.
Database compatibility[s1]	Should be easily portable to other database.
4. Client side Compatibility
4.1 Platform
Windows2000, NT	Should be working
Unix	Should be working
Linux	Should be working
Solaris	Should be working
Macintosh	Should be working
4.2 Browsers
I.E	Should work in all versions above 4.x
Netscape Navigator	Should work in all versions above 3.x
AOL
Any ActiveX controls
Graphics	Load of images, graphics should be proper
4.3 Printing
Text and alignment	Should be proper
Colours of text, foreground and background	Should be readable.
Scalability to fit paper size.	Should print in A4, Letter size.
Tables and borders.	Should be proper.
5. Performance
5.1 Connection speed
Should be measured in 14.4, 28.8, 33.6, 56.6, ISDN, Cable and DSL
Timeout	Should give appropriate time to search. Incorrect message, data loss should not be present.
5.2 Load
Estimated users.	Per requirements
Peak load	Should withstand
Large amount of data from users	Should accept
5.3 Stress
System Crash	Should not be present
Error in Sw, HW, Memory	Leakage, overwrite should not happen.
5.4 Continuous use
Estimate whether available for 24 Hrs, 7 days a week	Try with various timings.
Downtime	Measure the downtime
Memory or disk space	Should not run out of memory or disk space.
6. Security
6.1 Valid and Invalid	Should not enter with Invalid login
Number of tries	Should not be more than 3 times for invalid try.
Enter url directly without logging in.	Should not display information.
Log files	Should be maintained
Access to server scripts	Authenticated.

 

posted @ Wednesday, December 22, 2004 3:55 PM | Feedback (8) |