Alert Message Rules
Posted On 05 January, 2009 at 10:23 AM by Rajeev PrabhakaranIn all web applications and OS based application, validation is very important for that we are using different types of validation or alert or error messages , is that have any rules ? yes just check it ,
1. Should start with capital letter(In a standard format)
2. Error messages should be accessible for as many users as possible regardless of culture, age and impairment.
3. It should be easy to understand that an error has occurred.
4. It should be clear what the user has to do to correct the error.
5. It should be clear for the user where the error was found in the form.
6. It should be possible to be notified about errors before submitting the form, especially if it is a complex form that takes time to process on the server.
7. All errors should be displayed at the same time. No one wants to re-submit the form to find a new error.
8. Do not give any hint about any security event (For example Sign in of an application Incorrect error message -”Password is invalid” , Correct one- “Agent Name or Password is Invalid “)
Where to display these error messages ? Let’s see
1. Should start with capital letter(In a standard format)
2. Error messages should be accessible for as many users as possible regardless of culture, age and impairment.
3. It should be easy to understand that an error has occurred.
4. It should be clear what the user has to do to correct the error.
5. It should be clear for the user where the error was found in the form.
6. It should be possible to be notified about errors before submitting the form, especially if it is a complex form that takes time to process on the server.
7. All errors should be displayed at the same time. No one wants to re-submit the form to find a new error.
8. Do not give any hint about any security event (For example Sign in of an application Incorrect error message -”Password is invalid” , Correct one- “Agent Name or Password is Invalid “)
Where to display these error messages ? Let’s see
- sure the user can see that an error has occurred. Error messages need to stand out from the rest of the layout. They should be placed at the top of the page if that is the area displayed after the form has been submitted with errors.
- An error icon if your layout makes it difficult to visually separate errors from the rest of the page
- Be consistent when you present errors (the user will expect errors to be displayed at the same location and with the same style on all pages)
- Update the page title to indicate that the user is on the same page but with errors (e.g. if the page title is “Registration” you could change it to “Registration - Error occurred”).
Error message text standard
- Make sure the error message identifies the related field with the name as it is written in the label for that field
- Do not use complicated words
- Describe what the user should do to correct the error, especially if it could be difficult to understand
- Make it clear if there were more than one error so that the user can correct all errors at once
Error Messages View
- Make sure all user agents can parse error details. Use a heading to identify the error area.
- Present each error as an item in a list. This makes it easy for the user to understand what has to be corrected. Also, screen reader users will find it easier to keep errors apart
- If you use software specific error id numbers do not hesitate to add them to the id-attribute of the list element. If you use automated functional tests (e.g. Rational Robot) it will be much easier for the test robot to parse and identify errors
- Provide an access key for the error message section. This is valuable if your form can generate many errors and enables the user to move back and forth between the error list and the form
- Make it possible to navigate from the error message to the related field. This makes it easier for users that navigate with the keyboard
Tips for developers
It is better to use some client side validations in forms (like in .net applications)
Example
<——————————————————————————->
4 Errors were found while registration ,Please Correct these errors and Submit again
#Your user name must be between 6 and 30 characters long.
#Email is invalid
#Password is too short (minimum is 8 characters)
#Terms of Service must be accepted
<——————————————————————————>
It is better to use some client side validations in forms (like in .net applications)
Example
<——————————————————————————->
4 Errors were found while registration ,Please Correct these errors and Submit again
#Your user name must be between 6 and 30 characters long.
#Email is invalid
#Password is too short (minimum is 8 characters)
#Terms of Service must be accepted
<——————————————————————————>
Priority of Bug
Posted On 08 December, 2008 at 9:51 PM by Rajeev PrabhakaranPriority indicates how important it is to fix the bug and when it should be fixed
Immediate Priority: The bug is of immediate priority if it blocks further testing and is very visible
At the earliest Priority: The bug must be fixed at the earliest before the product is released
Normal Priority: The bug should be fixed if time permits
Later Priority: The bug may be fixed, but can be released as it is
Immediate Priority: The bug is of immediate priority if it blocks further testing and is very visible
At the earliest Priority: The bug must be fixed at the earliest before the product is released
Normal Priority: The bug should be fixed if time permits
Later Priority: The bug may be fixed, but can be released as it is
Severity of Bug
Posted On at 9:47 PM by Rajeev PrabhakaranBugs Severity indicates how serious the bug is and reflects its impact on the product and customers of the product. It can be critical, major, minor, cosmetic or suggestion.
Critical severity: The bug is of critical severity if it causes system crash, data loss or data corruption.
Major severity: The bug is of major severity if it causes operational errors, wrong results and loss of functionality.
Minor severity: The bug is of minor severity if it causes defect in user interface layout or spelling mistakes.
Critical severity: The bug is of critical severity if it causes system crash, data loss or data corruption.
Major severity: The bug is of major severity if it causes operational errors, wrong results and loss of functionality.
Minor severity: The bug is of minor severity if it causes defect in user interface layout or spelling mistakes.
Black Box and Functional Testing
Posted On 07 December, 2008 at 10:07 PM by Rajeev PrabhakaranBlack Box Testing is testing without knowledge of the internal workings of the item being tested. The Outside world comes into contact with the test items, only through the application interface, an internal module interface, or the INPUT/OUTPUT description of a batch process. They check whether interface definitions are adhered to in all situations and whether the product conforms to all fixed requirements. Test cases are created based on the task descriptions
Black Box Testing assumes that the tester does not know anything about the application that is going to be tested. The tester needs to understand what the program should do, and this is achieved through the business requirements and meeting and talking with users.
Functional testing: This type of tests will evaluate a specific operating condition using inputs and validating results. Functional tests are designed to test boundaries. A combination of correct and incorrect data should be used in this type of test.
Black Box Testing assumes that the tester does not know anything about the application that is going to be tested. The tester needs to understand what the program should do, and this is achieved through the business requirements and meeting and talking with users.
Functional testing: This type of tests will evaluate a specific operating condition using inputs and validating results. Functional tests are designed to test boundaries. A combination of correct and incorrect data should be used in this type of test.
Scalability and Performance Testing
Posted On at 2:15 PM by Rajeev PrabhakaranScalability and performance testing is the way to understand how the system will handle the load cause by many concurrent users. In a Web environment concurrent use is measured as simply the number of users making requests at the same time.
Performance testing is designed to measure how quickly the program completes a given task. The primary objective is to determine whether the processing speed is acceptable in all parts of the program. If explicit requirements specify program performance, then performance test are often performed as acceptance tests.
As a rule, performance tests are easy to automate. This makes sense above all when you want to make a performance comparison of different system conditions while using the user interface. The capture and automatic replay of user actions during testing eliminates variations in response times.
This type of test should be designed to verify response and execution time. Bottlenecks in a system are generally found during this stage of testing.
Performance testing is designed to measure how quickly the program completes a given task. The primary objective is to determine whether the processing speed is acceptable in all parts of the program. If explicit requirements specify program performance, then performance test are often performed as acceptance tests.
As a rule, performance tests are easy to automate. This makes sense above all when you want to make a performance comparison of different system conditions while using the user interface. The capture and automatic replay of user actions during testing eliminates variations in response times.
This type of test should be designed to verify response and execution time. Bottlenecks in a system are generally found during this stage of testing.
System Testing Check List
Posted On 05 December, 2008 at 6:46 PM by Rajeev Prabhakaran- Run time behavior on various operating system or different hardware configurations.
- Install ability and configure ability on various systems
- Capacity limitation (maximum file size, number of records, maximum number of concurrent users, etc.)
- Behavior in response to problems in the programming environment (system crash, unavailable network, full hard-disk, printer not ready)
- Protection against unauthorized access to data and programs
Web Testing- Functional System Testing
Posted On at 6:44 PM by Rajeev PrabhakaranSystem tests check that the software functions properly from end-to-end. The components of the system include: A database, Web-enable application software modules, Web servers, Web-enabled application frameworks deploy Web browser software, TCP/IP networking routers, media servers to stream audio and video, and messaging services for email. A common mistake of test professionals is to believe that they are conducting system tests while they are actually testing a single component of the system. For example, checking that the Web server returns a page is not a system test if the page contains only a static HTML page
