Showing posts with label General. Show all posts
Showing posts with label General. Show all posts
Tuesday, February 28, 2012
Latent Bug
Latent Bug is a bug which is not identified in present version and can be able to identified in later versions. Also called as Golden Bug.
Gap Analysis
The gap analysis process involves determining, documenting and approving the variance between business requirements and current capabilities.It is the comparison study of general expectation of performance in the industry and the level of performance at
which the company currently functions.
Gap analysis provides a foundation for measuring investment of time, money and human resources required to achieve a particular outcome (e.g. to turn the salary payment process from paper based to paperless with the use of a system).
Such analysis can be performed at the strategic or operational level of an organization.'Gap analysis' is a formal study of what a business is
doing currently and where it wants to go in the future. It can be conducted, in different perspectives, as follows:
Organization (e.g., human resources)
Business direction
Business processes
Information technology
Also
Banking and financial services organizations often ask this question, as they face the risk of missing or incompletely covered Business Requirements (BR) in Functional Specifications Documents (FSDs). This risk arises as business users may not always articulate their basic requirements under the misconception that development vendors know them already. However, that is not often the case because technology focused developers do not understand the nuances of banking like a domain specialist can.
Inconsistencies between Business Requirements and Functional Specifications result in critical requirement gaps later in the product life cycle. This often proves very costly for the client and the vendor, in terms of both monetary and reputation loss.
which the company currently functions.
Gap analysis provides a foundation for measuring investment of time, money and human resources required to achieve a particular outcome (e.g. to turn the salary payment process from paper based to paperless with the use of a system).
Such analysis can be performed at the strategic or operational level of an organization.'Gap analysis' is a formal study of what a business is
doing currently and where it wants to go in the future. It can be conducted, in different perspectives, as follows:
Organization (e.g., human resources)
Business direction
Business processes
Information technology
Also
Banking and financial services organizations often ask this question, as they face the risk of missing or incompletely covered Business Requirements (BR) in Functional Specifications Documents (FSDs). This risk arises as business users may not always articulate their basic requirements under the misconception that development vendors know them already. However, that is not often the case because technology focused developers do not understand the nuances of banking like a domain specialist can.
Inconsistencies between Business Requirements and Functional Specifications result in critical requirement gaps later in the product life cycle. This often proves very costly for the client and the vendor, in terms of both monetary and reputation loss.
Defect Leakage
Defect leakage occurs at the Customer or the End user side after the application delivery.After the release of the application to the client, if the end user gets any type of defects by using that application then it is called as Defect Leakage.This is also called as Bug Leakage.
Monday, February 27, 2012
Difference Between Authorization And Authentication
Authentication is the process to test whether the specific user is allowed to use or login to the application.
And
Authorization we test whether the specific user allowed to access some controls or features of the system/application/software.
Eg: In an office automation tool, every employee can login to the application, but only accounts manager can access accounts related features, only HR manager or executive can access company information
And
Authorization we test whether the specific user allowed to access some controls or features of the system/application/software.
Eg: In an office automation tool, every employee can login to the application, but only accounts manager can access accounts related features, only HR manager or executive can access company information
Sunday, January 9, 2011
The 'Oracle Assumption'
For most systems it is possible to predict the expected results for any test case but there are a few systems where this is not the case.
For example, systems that predict situations or perform long and complex calculations that cannot practically be performed manually.
The Oracle Assumption is the name given to the assumption that it is possible to predict the expected results.
For example, systems that predict situations or perform long and complex calculations that cannot practically be performed manually.
The Oracle Assumption is the name given to the assumption that it is possible to predict the expected results.
Friday, August 20, 2010
Tuesday, August 17, 2010
What is a staging area?
The staging area is:-
1. One or more database schema(s) or file stores used to “stage” data extracted from the source OLTP systems prior to being published to the “warehouse” where it is visible to end users.
2. Data in the staging area is NOT visible to end users for queries, reports or analysis of any kind. It does not hold completed data ready for querying.
3. It may hold intermediate results, (if data is pipelined through a process)
4. Equally it may hold “state” data – the keys of the data held on the warehouse, and used to detect whether incoming data includes New or Updated rows. (Or deleted for that matter).
5. It is likely to be equal in size (or maybe larger) than the “presentation area” itself.
6. Although the “state” data – eg. Last sequence loaded may be backed up, much of the staging area data is automatically replaced during the ETL load processes, and can with care avoid adding to the backup effort. The presentation area however, may need backup in many cases.
7. It may include some metadata, which may be used by analysts or operators monitoring the state of the previous loads (eg. audit information, summary totals of rows loaded etc).
8. It’s likely to hold details of “rejected” entries – data which has failed quality tests, and may need correction and re-submission to the ETL process.
9. It’s likely to have few indexes (compared to the “presentation area”), and hold data in a quite normalised form. The presentation area (the bit the end users see), is by comparison likely to be more highly indexed (mainly bitmap indexes), with highly denormalised tables (the Dimension tables anyway).
The staging area exists to be a separate “back room“ or “engine room” of the warehouse where the data can be transformed, corrected and prepared for the warehouse.
It should ONLY be accessible to the ETL processes working on the data, or administrators monitoring or managing the ETL process.
In summary. A typical warehouse generally has three distinct areas:-
1. Several source systems which provide data. This can include databases (Oracle, SQL Server, Sybase etc) or files or spreadsheets
2. A single “staging area” which may use one or more database schemas or file stores (depending upon warehouse load volumes).
3. One or more “visible” data marts or a single “warehouse presentation area” where data is made visible to end user queries. This is what many people think of as the warehouse – although the entire system is the warehouse – it depends upon your perspective.
The “staging area” is the middle bit.
Staging area is place where you hold temporary tables on data warehouse server. Staging tables are connected to work area or fact tables. We basically need staging area to hold the data and perform data cleansing and merging before loading the data into warehouse.
1. One or more database schema(s) or file stores used to “stage” data extracted from the source OLTP systems prior to being published to the “warehouse” where it is visible to end users.
2. Data in the staging area is NOT visible to end users for queries, reports or analysis of any kind. It does not hold completed data ready for querying.
3. It may hold intermediate results, (if data is pipelined through a process)
4. Equally it may hold “state” data – the keys of the data held on the warehouse, and used to detect whether incoming data includes New or Updated rows. (Or deleted for that matter).
5. It is likely to be equal in size (or maybe larger) than the “presentation area” itself.
6. Although the “state” data – eg. Last sequence loaded may be backed up, much of the staging area data is automatically replaced during the ETL load processes, and can with care avoid adding to the backup effort. The presentation area however, may need backup in many cases.
7. It may include some metadata, which may be used by analysts or operators monitoring the state of the previous loads (eg. audit information, summary totals of rows loaded etc).
8. It’s likely to hold details of “rejected” entries – data which has failed quality tests, and may need correction and re-submission to the ETL process.
9. It’s likely to have few indexes (compared to the “presentation area”), and hold data in a quite normalised form. The presentation area (the bit the end users see), is by comparison likely to be more highly indexed (mainly bitmap indexes), with highly denormalised tables (the Dimension tables anyway).
The staging area exists to be a separate “back room“ or “engine room” of the warehouse where the data can be transformed, corrected and prepared for the warehouse.
It should ONLY be accessible to the ETL processes working on the data, or administrators monitoring or managing the ETL process.
In summary. A typical warehouse generally has three distinct areas:-
1. Several source systems which provide data. This can include databases (Oracle, SQL Server, Sybase etc) or files or spreadsheets
2. A single “staging area” which may use one or more database schemas or file stores (depending upon warehouse load volumes).
3. One or more “visible” data marts or a single “warehouse presentation area” where data is made visible to end user queries. This is what many people think of as the warehouse – although the entire system is the warehouse – it depends upon your perspective.
The “staging area” is the middle bit.
Staging area is place where you hold temporary tables on data warehouse server. Staging tables are connected to work area or fact tables. We basically need staging area to hold the data and perform data cleansing and merging before loading the data into warehouse.
What is the methodology and process followed for ETL testing in Data warehouse environment?
Like ETL SPEC they create a document containing the source table (Schema name) and a target table (another schema name) with the logic used in transforming source to target. We have to write database query with the logic contained in the document using source schema and take its output. Now write a simple select statement in the target schema and take its output. Compare the two outputs if they are same well and fine else it's a bug.
Database knowledge is a must for ETL testing.
Database knowledge is a must for ETL testing.
What are the things to consider while testing ETL ?
The process of Testing the web based application and ETL application is quit diffrent.the major difference is in web based application we test the GUI part of the applicaytion as well as the main functional tesitng.but as it in ETL first
We have to understand the source structure like how many records are comming from source and how many records are loaded in to the target this is the basic motivation for testing the ETL. then how many records are rejecting and waht is the reason for rejecting.
Second we have to test the Back-end data driven test.
We have to test ETL components by execuitng SQL PL/SQL queyries.
We have to test the mapping naming convertion is done with respect to SRS.
Things to be considered :
1.Check we can get the existing data
2.Check we can clean up the data
3.Check we can add new data
4.Check we can merge data
5.Check for the limitation of the data
6.Check for the security purpose of using data
7.Check whether it is overlimited how much time we needed to get from the extraction
We have to understand the source structure like how many records are comming from source and how many records are loaded in to the target this is the basic motivation for testing the ETL. then how many records are rejecting and waht is the reason for rejecting.
Second we have to test the Back-end data driven test.
We have to test ETL components by execuitng SQL PL/SQL queyries.
We have to test the mapping naming convertion is done with respect to SRS.
Things to be considered :
1.Check we can get the existing data
2.Check we can clean up the data
3.Check we can add new data
4.Check we can merge data
5.Check for the limitation of the data
6.Check for the security purpose of using data
7.Check whether it is overlimited how much time we needed to get from the extraction
ETL CHANNEL
Extract, transform and load (ETL) is the core process of data integration and is typically associated with data warehousing. ETL tools extract data from a chosen source(s), transform it into new formats according to business rules, and then load it into target data structure(s). Managing rules and processes for the increasing diversity of data sources and high volumes of data processed that ETL must accommodate, make management, performance and cost the primary and challenges for users. The traditional ETL approach requires users to map each physical data item with a unique metadata description; newer ETL tools allow the user to create an abstraction layer of common business definitions and map all similar data items to the same definition before applying target-specific business rules, isolating business rules from data and allowing easier ETL management.
ETL Testing
Extract, Transform and Load (ETL)
General goals of testing an ETL application:
1. Data completeness. Ensures that all expected data is loaded.
2. Data transformation. Ensures that all data is transformed correctly according to business rules and/or design specifications.
3. Data quality. Ensures that the ETL application correctly rejects, substitutes default values, corrects or ignores and reports invalid data.
4. Performance and scalability. Ensures that data loads and queries perform within expected time frames and that the technical architecture is scalable.
5. Integration testing. Ensures that the ETL process functions well with other upstream and downstream processes.
6. User-acceptance testing. Ensures the solution meets users' current expectations and anticipates their future expectations.
7. Regression testing. Ensures existing functionality remains intact each time a new release of code is completed.
For more details please visit ETL Testing
General goals of testing an ETL application:
1. Data completeness. Ensures that all expected data is loaded.
2. Data transformation. Ensures that all data is transformed correctly according to business rules and/or design specifications.
3. Data quality. Ensures that the ETL application correctly rejects, substitutes default values, corrects or ignores and reports invalid data.
4. Performance and scalability. Ensures that data loads and queries perform within expected time frames and that the technical architecture is scalable.
5. Integration testing. Ensures that the ETL process functions well with other upstream and downstream processes.
6. User-acceptance testing. Ensures the solution meets users' current expectations and anticipates their future expectations.
7. Regression testing. Ensures existing functionality remains intact each time a new release of code is completed.
For more details please visit ETL Testing
Thursday, May 20, 2010
Bug Tracking System
A bug tracking system is a software application that is designed to help quality assurance and programmers keep track of reported software bugs in their work. It may be regarded as a sort of issue tracking system.
Many bug-tracking systems, such as those used by most open source software projects, allow users to enter bug reports directly. Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other software project management applications.
Having a bug tracking system is extremely valuable in software development, and they are used extensively by companies developing software products.
Many bug-tracking systems, such as those used by most open source software projects, allow users to enter bug reports directly. Other systems are used only internally in a company or organization doing software development. Typically bug tracking systems are integrated with other software project management applications.
Having a bug tracking system is extremely valuable in software development, and they are used extensively by companies developing software products.
Defect Prevention
The objective of defect prevention is to identify the defects and take corrective action to ensure they are not repeated over subsequent iterative cycles. Defect prevention can be implemented by preparing an action plan to minimize or eliminate defects, generating defect metrics, defining corrective action and producing an analysis of the root causes of the defects.
Defect prevention can be accomplished by actioning the following steps:
1) Calculate defect data with periodic reviews using test logs from the execution phase: this data should be used to segregate and classify defects by root causes. This produces defect metrics highlighting the most prolific problem areas;
2) Identify improvement strategies;
3) Escalate issues to senior management or customer where necessary;
4) Draw up an action plan to address outstanding defects and improve development process.This should be reviewed regularly for effectiveness and modified should it prove to be ineffective.
5) Undertake periodic peer reviews to verify that the action plans are being adhered to;
6) Produce regular reports on defects by age. If the defect age for a particular defect is high and the severity is sufficient to cause concern, focussed action needs to be taken to resolve it.
7) Classify defects into categories such as critical defects, functional defects, and cosmetic defects.
Defect prevention can be accomplished by actioning the following steps:
1) Calculate defect data with periodic reviews using test logs from the execution phase: this data should be used to segregate and classify defects by root causes. This produces defect metrics highlighting the most prolific problem areas;
2) Identify improvement strategies;
3) Escalate issues to senior management or customer where necessary;
4) Draw up an action plan to address outstanding defects and improve development process.This should be reviewed regularly for effectiveness and modified should it prove to be ineffective.
5) Undertake periodic peer reviews to verify that the action plans are being adhered to;
6) Produce regular reports on defects by age. If the defect age for a particular defect is high and the severity is sufficient to cause concern, focussed action needs to be taken to resolve it.
7) Classify defects into categories such as critical defects, functional defects, and cosmetic defects.
Defect Tracking
Defect tracking is the process of finding defects in a product (by inspection, testing, or recording feedback from customers), and making new versions of the product that fix the defects. Defect tracking is important in software engineering as complex software systems typically have tens or hundreds or thousands of defects: managing, evaluating and prioritizing these defects is a difficult task: defect tracking systems are computer database systems that store defects and help people to manage them.
Wednesday, April 28, 2010
Test Execution Engine
A test execution engine is a type of software used to test software, hardware or complete systems.
A test execution engine may appear in two forms:
1) Module of a test software suite (test bench) or an integrated development environment
2) Stand-alone application software
The test specification is software. Test specification is sometimes referred to as test sequence, which consists of test steps.
The test specification should be stored in the test repository in a text format (such as source code). Test data is sometimes generated by some test data generator tool. Test data can be stored in binary or text files. Test data should also be stored in the test repository together with the test specification.
Test specification is selected, loaded and executed by the test execution engine similarly, as application software is selected, loaded and executed by operation systems. The test execution engine should not operate on the tested object directly, but though plug-in modules similarly as an application software accesses devices through drivers which are installed on the operation system.
The difference between the concept of test execution engine and operation system is that the test execution engine monitors, presents and stores the status, results, time stamp, length and other information for every Test Step of a Test Sequence, but typically an operation system does not perform such profiling of a software execution.
Advantages of using a test execution engine:
1) Test results are stored and can be viewed in a uniform way, independent of the type of the test
2) Easier to keep track of the changes
3) Easier to reuse components developed for testing
A test execution engine may appear in two forms:
1) Module of a test software suite (test bench) or an integrated development environment
2) Stand-alone application software
The test specification is software. Test specification is sometimes referred to as test sequence, which consists of test steps.
The test specification should be stored in the test repository in a text format (such as source code). Test data is sometimes generated by some test data generator tool. Test data can be stored in binary or text files. Test data should also be stored in the test repository together with the test specification.
Test specification is selected, loaded and executed by the test execution engine similarly, as application software is selected, loaded and executed by operation systems. The test execution engine should not operate on the tested object directly, but though plug-in modules similarly as an application software accesses devices through drivers which are installed on the operation system.
The difference between the concept of test execution engine and operation system is that the test execution engine monitors, presents and stores the status, results, time stamp, length and other information for every Test Step of a Test Sequence, but typically an operation system does not perform such profiling of a software execution.
Advantages of using a test execution engine:
1) Test results are stored and can be viewed in a uniform way, independent of the type of the test
2) Easier to keep track of the changes
3) Easier to reuse components developed for testing
Sunday, April 25, 2010
Some Major Test cases for web application cookie testing:
The first obvious test case is to test if your application is writing cookies properly on disk.
You can use the Cookie Tester application also if you don’t have any web application to test but you want to understand the cookie concept for testing.
Test cases:
1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.
2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.
3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.
4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)
5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.
6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.
7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.
8) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.
9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.
10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.
To more information about What is Cookie? visit : Cookie
You can use the Cookie Tester application also if you don’t have any web application to test but you want to understand the cookie concept for testing.
Test cases:
1) As a Cookie privacy policy make sure from your design documents that no personal or sensitive data is stored in the cookie.
2) If you have no option than saving sensitive data in cookie make sure data stored in cookie is stored in encrypted format.
3) Make sure that there is no overuse of cookies on your site under test. Overuse of cookies will annoy users if browser is prompting for cookies more often and this could result in loss of site traffic and eventually loss of business.
4) Disable the cookies from your browser settings: If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. Then try to access the web site under test. Navigate through the site. See if appropriate messages are displayed to user like “For smooth functioning of this site make sure that cookies are enabled on your browser”. There should not be any page crash due to disabling the cookies. (Please make sure that you close all browsers, delete all previously written cookies before performing this test)
5) Accepts/Reject some cookies: The best way to check web site functionality is, not to accept all cookies. If you are writing 10 cookies in your web application then randomly accept some cookies say accept 5 and reject 5 cookies. For executing this test case you can set browser options to prompt whenever cookie is being written to disk. On this prompt window you can either accept or reject cookie. Try to access major functionality of web site. See if pages are getting crashed or data is getting corrupted.
6) Delete cookie: Allow site to write the cookies and then close all browsers and manually delete all cookies for web site under test. Access the web pages and check the behavior of the pages.
7) Corrupt the cookies: Corrupting cookie is easy. You know where cookies are stored. Manually edit the cookie in notepad and change the parameters to some vague values. Like alter the cookie content, Name of the cookie or expiry date of the cookie and see the site functionality. In some cases corrupted cookies allow to read the data inside it for any other domain. This should not happen in case of your web site cookies. Note that the cookies written by one domain say rediff.com can’t be accessed by other domain say yahoo.com unless and until the cookies are corrupted and someone trying to hack the cookie data.
8) Checking the deletion of cookies from your web application page: Some times cookie written by domain say rediff.com may be deleted by same domain but by different page under that domain. This is the general case if you are testing some ‘action tracking’ web portal. Action tracking or purchase tracking pixel is placed on the action web page and when any action or purchase occurs by user the cookie written on disk get deleted to avoid multiple action logging from same cookie. Check if reaching to your action or purchase page deletes the cookie properly and no more invalid actions or purchase get logged from same user.
9) Cookie Testing on Multiple browsers: This is the important case to check if your web application page is writing the cookies properly on different browsers as intended and site works properly using these cookies. You can test your web application on Major used browsers like Internet explorer (Various versions), Mozilla Firefox, Netscape, Opera etc.
10) If your web application is using cookies to maintain the logging state of any user then log in to your web application using some username and password. In many cases you can see the logged in user ID parameter directly in browser address bar. Change this parameter to different value say if previous user ID is 100 then make it 101 and press enter. The proper access message should be displayed to user and user should not be able to see other users account.
To more information about What is Cookie? visit : Cookie
Sunday, April 18, 2010
xUnit
xUnit refers to the various testing frameworks which were originally ported from sUnit.
Tools such as jUnit, qUnit, and nUnit fall into the xUnit family.
Tools such as jUnit, qUnit, and nUnit fall into the xUnit family.
Friday, April 9, 2010
JUnit
JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and is one of a family of unit testing frameworks collectively known as xUnit that originated with SUnit.
Sunday, March 21, 2010
What should be tested in web site testing?
1. Functionality :
Links:
a)All Internal Links
b)All External Links
c)All mail links
d)Check for Broken Links
Forms:
a)All Field Level Checks
b)All Field Level Validations
c)Functionality of Create, Modify, Delete & View
d)Handling of Wrong inputs (App Error messages has to be Displayed)
e)Optional and mandatory fields checks
2. Usability :
Navigation:
a)Application navigation is proper through tab
b)Navigation through Mouse
c)Main features accessible from the main/home page
d)Any hot keys, control keys to access menus
Content:
a)Spellings and Grammars
b)Updated information
General Appearance:
a)Page appearance [Eg… Overlapping, Missing]
b)Color, font and size
c)Consistent design
3. Server Side Interfaces :
Server Interface:
a)Verify that communication is done correctly, Web server-application server, application server-database server and vice versa.
b)Compatibility of server software, hardware, network connections
c)Database compatibility (SQL, Oracle etc.)
4. Client Side Compatibility :
Platform:
Check for the compatibility of
a)Windows (98, 2000, NT)
b)Unix (different sets)
c)Macintosh (If applicable)
d)Linux
e)Solaris (If applicable)
Browsers:
Check for the various combinations
a)Internet Explorer (5.X, 6.X, 7.X)
b)Netscape Navigator
c)AOL
d)Mozilla
e)Browser settings
Graphics:
a)Loading of images, graphics, etc.
Printing:
a)Text and image alignment
b)Colures of text, foreground and background
c)Scalability to fit paper size
d)Tables and borders
Performance:
a)Connection speed : Try with various connection speeds, Time out
b)Load :
Check/Measure the following:
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?
Large amount of data from users.
c)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)
d)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?
Verify that the application is able to meet the requirements and does not run out of memory or disk space.
5. Security :
a)Valid and Invalid Login
b)Limit defined for the number of tries.
c)Can it be bypassed by typing URL to a page inside directly in the browser?
Links:
a)All Internal Links
b)All External Links
c)All mail links
d)Check for Broken Links
Forms:
a)All Field Level Checks
b)All Field Level Validations
c)Functionality of Create, Modify, Delete & View
d)Handling of Wrong inputs (App Error messages has to be Displayed)
e)Optional and mandatory fields checks
2. Usability :
Navigation:
a)Application navigation is proper through tab
b)Navigation through Mouse
c)Main features accessible from the main/home page
d)Any hot keys, control keys to access menus
Content:
a)Spellings and Grammars
b)Updated information
General Appearance:
a)Page appearance [Eg… Overlapping, Missing]
b)Color, font and size
c)Consistent design
3. Server Side Interfaces :
Server Interface:
a)Verify that communication is done correctly, Web server-application server, application server-database server and vice versa.
b)Compatibility of server software, hardware, network connections
c)Database compatibility (SQL, Oracle etc.)
4. Client Side Compatibility :
Platform:
Check for the compatibility of
a)Windows (98, 2000, NT)
b)Unix (different sets)
c)Macintosh (If applicable)
d)Linux
e)Solaris (If applicable)
Browsers:
Check for the various combinations
a)Internet Explorer (5.X, 6.X, 7.X)
b)Netscape Navigator
c)AOL
d)Mozilla
e)Browser settings
Graphics:
a)Loading of images, graphics, etc.
Printing:
a)Text and image alignment
b)Colures of text, foreground and background
c)Scalability to fit paper size
d)Tables and borders
Performance:
a)Connection speed : Try with various connection speeds, Time out
b)Load :
Check/Measure the following:
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?
Large amount of data from users.
c)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)
d)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?
Verify that the application is able to meet the requirements and does not run out of memory or disk space.
5. Security :
a)Valid and Invalid Login
b)Limit defined for the number of tries.
c)Can it be bypassed by typing URL to a page inside directly in the browser?
Subscribe to:
Posts (Atom)
