Web portal testing - 4

Performance 1.Connection speed Users may differ greatly in connection speed. They may be on a 28.8 modem or on a T3 connection. Users expect longer download times when retrieving demos or programs, but not when requesting a homepage. If the transaction response time is to long, user will leave the site. Other issues to consider are time-out on a page that request logins. If load time is to long, users may be thrown out due to time-out. Database problem may occur if the connection speed is two low, causing data loss. Summary: Connection speed Time-out 2.Load What is the estimated number of users per time period and how will it be divided over the period? Will there be peak loads and how will the system react? Can your site handle a large amount of users requesting a certain page? Load testing is done to measure the performance at a given load level to assure that the site work within requirements for performance. The load level may be a certain amount of users using your site at the same time or large amount of data transactions from user such as online ordering. Summary: Many users requesting a certain page at the same time or using the site simultaneously Large amount of data from users 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. Typical areas to test are forms, logins or other information transaction components. Summary: Performance of memory, CPU, file handling etc. Error in software, hardware, memory errors (leakage, overwrite or pointers) 4. Continuous use 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? Test that the application is able to perform during those conditions. Will downtime be allowed or is that out of the question? Verify that the application is able to meet the requirements and does not run out of memory or disk space. Security Security is an area of immense extent, and would need extensive writing to be fairly covered. We will no more than point out the most central elements to test. First make sure that you have a correct directory setup. You dont want users to be able to brows through directories on your server. Logins are very common on todays web sites, and they must be error free. Make sure to test

both valid and invalid login names and passwords. Are they case sensitive? Is there a limit to how many tries that are allowed? Can it be bypassed by typing the URL to a page inside directly in the browser? Is there a time-out limit within your site? What happens when its exceeded? Are users still able to navigate through the site? Logfiles are a very important in order to maintain security at the site. Verify that relevant information is written to the logfiles and that the information is traceable. When secure socket layers are used, verify that the encryption is done correctly and check the integrity of the information. Scripting on the server often constitute security holes and are often used by hackers. Test that it isnt possible to plant or edit scripts on the server without authorisation. Summary: Directory setup Logins Time-out Logfiles SSL Scripting Languages Web application types and Questionnaire Checklist 1.This report presents four views into web applications. The application as: A set of requirements to be met. A design, which will meet those requirements. A static web of HTML content, or a collection of files to download with no other interaction. An "interactive" web consisting of CGI scripts and HTML forms which invoke the scripts Questionnaire Checklist for Requirements 1.Who is the customer? 2.What is the customer supposed to do with this system? (This could be a list of specific r requirements or features) 3.Is anything intentionally left out of this system that the customer might reasonably expect? 4.What are the primary risk factors? 5.Is the list of specific requirements complete? 6.Is the list of specific requirements consistent? 7.Is the list of specific requirements compatible with the goals of the organization and the customer? 8.How will your customers find out about your application? 9.How will the customer use this system? (This can be a series of scenarios of the user accomplishing a task or tasks using the system) 10.Will a published HTML standard be used to constrain markup? Which one? Will all important customers have browsers which support that standard? 11.How much training will the customer require?

12.Were all practical alternatives considered? 13.Are all the specific requirements supported in this design? 14.Does this design impose any new requirements upon the system? The user? The organization? 15.Is privacy an issue? User authentication? How are these issues handled? 16.Does this design allow for multiple, separate operating environments? In other words, is it amenable to separate systems for development, testing and production? 17.Is there any provision for robots to visit and index your site? This is the conclusion of web portal testing postings and am ending with this post. If you got good idea on all web portal testing posts, then you will be the perfect tester to test web applications :) Keep visiting www.testingfinder.com Will be back soon with another intresting topic. 0 comments Labels: web portal testing, website testing

Web portal testing - 3

Server Side Interface 1.Server Interface Due to the complex architecture of web systems, interface and compatibility issues may occur on several areas. The core components are web servers, application servers and database servers (and possibly mail servers). Web servers normally hosts HTML pages and other web services. Application severs typically contains objects such as programs, scripts, DLLs or third party products, that provide and extend functionality and effects for the web application. Test the communication between the different servers by making transactions and view logfiles to verify the result. Depending on the configuration of the server side compatibility issues may occur depending on, for example, server hardware, server software or network connections. Database compatibility issues may occur depending on different database types (SQL, Oracle, Sybase etc.). Issues to test: Verify that communication is done correctly, web server-application server, application serverdatabase server and vice versa. Compatibility of server software, hardware, network connections Database compatibility (SQL, Oracle, Sybase etc.) 2.External Interface Several web pages have external interfaces, such as merchants verifying credit card numbers to allow transactions to be made or a site like http://www.pris.nu/ that compares prices and delivery times on different merchants on the web. Verify that is sent and retrieved in correct form. Client Side compatibility

1.Platform There are several different operating systems that are being used on the market today, and depending on the configuration of the user system, compatibility issues may occur. Different applications may work fine under certain operating systems, but fail under another. The following are the most commonly used: Windows (95, 98, 2000, NT) Unix (different sets) Macintosh Linux 2.Browsers The browser is the most central component on the client side of the web. Browsers come in different brands and versions and have different support for Java, JavaScript, ActiveX, plugins or different HTML specifications. ActiveX, for example, is a Microsoft product and therefore designed for Internet Explorer, while JavaScript is produced by Netscape and Java by Sun. This substantiates the fact that compatibility problems commonly occur. Frames and Cascading style sheets may display differently on different browsers, or not at all. Different browsers also have different settings for e.g. security or Java support. A good way to test browser compatibility is to create a compatibility matrix where different brands and versions of browsers are tested to a certain number of components and settings, for example Applets, scripting, ActiveX controls or cookies. Summary: Internet Explorer (5.X,6.X,7.X,8.X) Netscape Navigator (3.X,4.X,6.X) Mozilla Firefox (2.X,3.X) Opera (8.X,9.X) AOL Browser settings (security settings, graphics, Java etc.) Frames and Cascade Style sheets Applets, ActiveX controls, DHTML, client side scripting HTML specifications Graphics 3.Settings, Preferences Depending on settings and preferences of the client machine, web applications may behave differently. Try and vary the following: Screen resolution (check that text and graphic alignment still work, font are readable etc.) Colour depth (256, 16-bit, 32-bit) 4.Printing Despite the paperless society the web was to introduce, printing is done more than ever. Verify that pages are printable with considerations on: Text and image alignment Colours of text, foreground and background

Scalability to fit paper size Tables and borders 0 comments Labels: manual testing, software testing, Testing tools, web portal testing, website testing

Web portal testing -2

Usability 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. To determine whether or not your page is easy to navigate through consider the following. Is the applications navigation intuitive? Are the main features of the site accessible from the main page? Do the site need a site map, search engine, or other navigational help. Be careful though that you dont over do your site. Too much information often has the opposite effect as to what was intended. Users of the web tend to be very goal driven and scan a site very quickly to see if it meets their expectations. If not, they quickly move on. They rarely take the time to learn about the sites structure, and it is therefore important to keep the navigational help as concise as possible. Another important aspect of navigation is if the site is consistent in its conventions regarding page layout, navigation bars, menus, links etc. Make sure that users intuitively know that they are still within the site by keeping the page design uniform throughout the site. As soon as the hierarchy of the site is determined, testing of how users navigate can commence. Have real users try and navigate through ordinary papers describing how the layout is done. Summary: Intuitive navigation Main features accessible from main page Site map or other navigational help Consistent conventions (navigation bars, menus, links etc.) 2.Graphics The graphics of a web site include images, animations, borders, colours, movie clips, fonts, backgrounds, buttons etc. Issues to check are: Make sure that the graphics serve a definite purpose and that images or animations dont just clutter up the visual design and waste bandwidth Verify that fonts are consistent in style Suitable background colours combined with font- and foreground colour. Remember that a computer display exceptionally well presents contrasts apposed to printed paper Three-dimensional effects on buttons often gives useful cues When displaying large amount of images, consider using thumbnails. Check that the original picture appears when a thumbnail is clicked Size quality of pictures, usage of compressed formats (JPG or GIF) Mouse-over effects

3.Content Content testing is done to verify the correctness, accuracy and relevancy of information presented on the site, or in a database, in forms of text, images or animations. Correctness is whether the information is truthful or contains misinformation. For example wrong prices in a price list may cause financial problems or even induce legal issues. The accuracy of the information is whether it is without grammatical or spelling errors. These kinds of verifications are often done in e.g. Word or other word processors. Remove irrelevant information from your site. This may otherwise cause misunderstandings or confusion. Content testing should be done as early as possible, i.e. when the information is posted. Summary: Correctness Accuracy Relevancy 4.General Appearance Does the site feel right when using it? Do you intuitively know where to look for information? Is the design consistent throughout the site? Make sure that the design and aim goes hand in hand. Too much design can easily turn a conservative corporate site in to a publicity stunt. Important to all kinds of usability tests is to involve external personnel that have little or no connection to the development of the site. Its easy to get fond of ones own solution, so having actual users evaluating the site may be critical. Summary: Intuitive design Consistent design If using frames, make sure that the main area is large enough Consider size of pages. Several screens on the same page or links between them Do features on the site need help systems or will they be intuitive 0 comments Labels: manual testing, software testing, Testing tools, web portal testing, website testing

Web portal testing - 1

Portal Test Areas: Following are the main areas to test when developing and publishing a web site. It is a checklist that presents the most important features to test under each area and how to perform them. Functionality testing 1. Links Links are maybe the main feature on web sites. They constitute the mean of transport between pages and guide the user to certain addresses without the user knowing the actual address itself. Linkage testing is divided into three sub areas. First - check that the link takes you to the page it said it would. Second That the link isnt broken i.e. that the page youre linking to exists. Third

 Ensure that you have no orphan pages at your site. An orphan page is a page that has no links to it, and may therefore only be reached if you know the correct URL. Remember that to reduce redundant testing, there is no need to test a link more than once to a specific page if it appears on several pages; it needs only to be tested once. Summary: Verify that you end up at the designated page Verify that the link isnt broken Locate orphan pages if present 2. Forms Forms are used to submit information from the user to the host, which in turn gets processed and acted upon in some way. Testing the integrity of the submitting operation should be done in order to verify that the information hits the server in correct form. If default values are used, verify the correctness of the value. If the forms are designed to only accept certain values this should also be tested for. For example, if only certain characters should be accepted, try to override this when testing. These controls can be done both on the client side as well as the server side, depending on how the application is designed, for example using scripting languages such as Jscript, JavaScript or VBScript. Check that invalid inputs are detected and handled. Summary: Information hits the server in correct form Acceptance of invalid input Handling of wrong input (both client an server side) Optional versus mandatory fields Input longer than field allows Radio buttons Default values 3. Cookies Cookies are often used to store information about the user and his actions on a particular site. When a user accesses a site that uses cookies, the web server sends information about the user and stores it on the client computer in form of a cookie. These can be used to create more dynamic and custom-made pages or by storing, for example, login info. If you have designed your site to use cookies, they need to be checked. Verify that the information that is to be retrieved is there. If login information is stored in cookies check for correct encryption of these. If your applications require cookies, how does it respond to users that disabled the use of such? Does it still function or will the user get notified of the current situation. How will temporary cookies be handled? What will happen when cookies expire? Depending on what cookies are used for, one should examine the possibilities for other solutions. Summary: Encryption of e.g. login info Users denying or accepting Temporary and expired cookies

4. Web Indexing There are a number of different techniques and algorithms used by different search engines to search the Internet. Depending on how the site is designed using Meta tags, frames, HTML syntax, dynamically created pages, passwords or different languages, your site will be searchable in different ways. Summary: Meta tags Frames HTML syntax Passwords Dynamically created pages 5. Programming Language Differences in web programming language versions or specifications can cause serious problems on both client or server side. For example, which HTML specification will be used (for example 3.2 or 4.0)? How strictly? When HTML is generated dynamically it is important to know how it is generated. When development is done in a distributed environment where developers, for instance, are geographically separated, this area becomes increasingly important. Make sure that specifications are well spread throughout the development organization to avoid future problems. Except HTML classes, specifications on e.g. Java, JavaScript, ActiveX, VBScript or Perl need to be verified. There are several tools on the market for validating different programming languages. For languages that need compiling e.g. C++, this kind of check is often done by the compiling program. Since this kind of testing is done by static analysis tools and needs no actual running of the code, these tests can be done as early as possible in the development process. Language validation tools can be found in compilers, online as well as for download, free or by payment. Resources: http://arealvalidator.com/ http://www.delorie.com/web/purify.html, Summary: Language specifications Language syntax (HTML, C++, Java, Scripting languages, SQL etc.) 6. Dynamic Interface Components Web pages are not just presented in static HTML anymore. Demands for more dynamic features, custom made sites and high interactivity have made the Internet a more vivid place than before. Dynamic Interface Components reside and operate both on server and client side of the web, depending on the application. The most important include Java applets, Java Servlets, ActiveX controls, JavaScript, VBScript, CGI, ASP, CSS and third-party plug-ins (QuickTime, ShockWave or RealPlayer). The issue here is to test and verify the function of the components,

not compatibility issues. An example of what to test can be a Java applet constructing and displaying a chart of company statistics, where the information first have to be retrieved and then interpreted and displayed on the screen. Since server-side components dont have user interface, event logging (logfiles) can be used to record events by applications on the server side in order to determine functionality. Resources: Java Specific tools: JavaSpec and JavaStar. Summary: Do client side components (applets, ActiveX controls, JavaScript, CSS etc.) function as intended (i.e. do the components perform the right tasks in a correct way) User disabling features (Java-applets, ActiveX, scripts etc.) Do server side components (ASP, Java-Servlets, server-side scripting etc.) function as intended (i.e. do the components perform the right tasks in a correct way) 7. Databases Databases play an important role in web application technology, housing the content that the web application manages, running queries and fulfilling user requests for data storage. The most commonly used type of database in web applications is the relational database and its managed by SQL to write, retrieve and editing of information. In general, there are two types of errors that may occur, data integrity errors and output errors. Data integrity errors refer to missing or wrong data in tables and output errors are 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. Issues to test are: Creation of tables Indexing of data Writing and editing in tables (for example valid numbers or characters, input longer than field etc.) Reading from tables Read more: http://www.testingfinder.com/search/label/website%20testing#ixzz0zugkT7Tx GET Requests a representation of the specified resource. Note that GET should not be used for operations that cause side-effects, such as using it for taking actions in web applications. One reason for this is that GET may be used arbitrarily by robots or crawlers, which should not need to consider the side effects that a request should cause. POST Submits data to be processed (e.g., from an HTML form) to the identified resource. The data is included in the body of the request. This may result in the creation of a new resource or the updates of existing resources or both. Example

HTTP status codes

HTTP status codes-1 1xx Class, Informational. Means Request received, continuing process. This class of status code indicates a provisional response, used in experimental conditions only. 100 Continue This means that the server has received the request headers, and that the client should proceed to send the request body 101 Switching Protocols 102 Processing 122 Request-URI too long HTTP status codes-2 2xx Class Success The action was successfully received, understood, and accepted. This class of status code indicates that the client's request was successfully received, understood, and accepted. - 200 OK - Standard response for successful HTTP requests. 202 Accepted

- The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. - 203 Non-Authoritative Information (since HTTP/1.1) - 204 No Content

HTTP status codes-3 - 3xx Redirection - The client must take additional action to complete the request. - This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. - 301 Moved Permanently This and all future requests should be directed to the given URI. - 302 Found This is the most popular redirect code, but also an example of industrial practice contradicting the standard. HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"), but popular browsers implemented it as a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to disambiguate between the two behaviors. However, the majority of Web applications and frameworks still use the 302 status code as if it were the 303. - 305 Use Proxy (since HTTP/1.1) Many HTTP clients (such as Mozilla and Internet Explorer) don't correctly handle responses with this status code, primarily for security reasons. - 307 Temporary Redirect (since HTTP/1.1) In this occasion, the request should be repeated with another URI, but future requests can still use the original URI. In contrast to 303, the request method should not be changed when reissuing the original request. For instance, a POST request must be repeated using another POST request.

HTTP status codes-4 4xx Class Client Error The 4xx class of status code is intended for cases in which the client seems to have erred. These are typically the most common error codes encountered while online. 400 Bad Request

The request contains bad syntax or cannot be fulfilled. 401 Unauthorized Similar to 403 Forbidden, but specifically for use when authentication is possible but has failed or not yet been provided. 403 Forbidden The request was a legal request, but the server is refusing to respond to it. Unlike a 401 Unauthorized response, authenticating will make no difference. 404 Not Found The requested resource could not be found but may be available again in the future. Subsequent requests by the client are permissible.