Here is some difference, please correct me If I'm wrong.
Error : The Error is the mistakes which is mainly found while writing the code program by the developer. like syntax error, logical error etc.
Defects : Which is founded or traced by the client side while using or checking.
Bug : Bug refers where expected result is not equals to the actual result, and it's affects on the output of the program.
Hello my friends,
Here is also a video on boundary testing available by James Bach + Mike Kelley:
http://www.testingr
Hi Friends,
Traceability matrix is a powerful tool, not just another Excel or Word
Document.
You would have a set of Requirements to start with in any project.
Each of the requirement is checked whether it has been covered in the
Analysis Phase, Design Phase, Coding Phase, Testing phase, Bug
Tracking etc...
All this is done to make sure the set of requirements (Functional and
non-Functional) are delivered as expected by the client.
Instead of giving the field names directly, I have given a link to
another site.
http://www.jiludwig
Stub: A piece of code that simulates the activity of missing components.
Driver: A piece of code that passes test cases to another piece of code.
An Example: Consider an example in which we need to develop a "calculator" that converts between different units (e.g., feet to inches).
Testing
3GPP home page
BetaSoft Software Testing group
Bret Pettichord's Presentations
Bret Pettichord's Publications
Bret Pettichord's Software Testing Hotlist
Cem Kaner - Home Page
Classification of Errors by Severity
CMS Acceptance Testing
Differences Between Various Browsers
Exploration Through Example
GeekInterview
GlobalTester (Metrics and Measures)
GUI Testing
Included Page Header
Indian Testing Board
Load and performance tests
Load and Performance Tools
Mantis Bug Tracker
On-line magazine
Open Source Testing
OWASP - Testing
ReadySET Pro White Papers
Software Metrics Ten Traps To Avoid
Software Test Automation
Software Testing FAQs
Software Testing Glossary
Software Testing Online Resources
Software Testing Search Engine
Software Testing Stuff
Software Testing Techniques
SPIN Hyderabad
SQAtester.com
Sticky Minds - Books List
Testing Hotlist Update
Testware Associates - Error Gallery
Welcome to QAI - Facilitating 'Operational Excellence'
Welcome to the SICP Web Site
whatistesting.com-qpatterns
http://www.testingeducation.org/
http://www.whatistesting.com/news.htm
Testing Blogs
Cem Kaner's blog
Classic Testing Mistakes
Exploration Through Example
How To Ask Questions Smart Way
Kulkarni's bLog on Software Testing
Martin Fowler's Bliki
Pat's Weblog
Raymond Lewallen SDLC blog
SMOKE Vs SANITY blog
Srini - Test Notes blog
Tester Tested !
TesterThoughts
Testing Hotlist Update
Testing Interview Questions
WebSite Testing
Quality & Process
BetaSoft Software Testing and Quality Assurance Consulting Services, Automated and Performance
http--www.whatistesting.com-qpatterns-qpatternintro.htm
ISO 9000, 9001, 13485, 14001, 17799 Translated into Plain English
NASA - Glossary and Definitions
Process Impact
Software Metrics
Software Testing Search Engine - Quality Assurance Links and Resources Directory Tools-Automate
White Papers
Security Testing
Penetration Testing Guide
Tech papers on Security
Usability Testing · Testing for the Disabled: Accessibility Testing Software is written to be used. That sounds pretty obvious, but it's sometimes forgotten in the rush to design, develop, and test a complex product. So much time and effort is spent on the technology aspects of writing the code that the development team ignores the most important aspect of software that someone will eventually use the stuff. It really doesn't matter whether the software is embedded in a microwave oven, a telephone switching station, or an Internet stock trading website. Eventually the bits and bytes bubble up to where a live person will interact with it. Usability is how appropriate, functional, and effective that interaction is. You may have heard the term ergonomics, the science of designing everyday things so that they're easy and functional to use. An ergonomist's main concern is in achieving usability. Now, you're not going to get the knowledge of a four-year ergonomics degree in the 15 or so pages of this chapter, nor do you need to. The software is difficult to understand, hard to use, slow, or in the software tester's eyes will be viewed by the end user as just plain not right. That's your blank check for usability testing. You're likely the first person, other than the programmers, to use the software. You've become familiar with the specification and investigated who the customers will be. If you have problems using the software while you're testing it, odds are the customers will, too. Because there are so many different types of software, it's impossible to go into detail about usability issues for all of them. Usability of a nuclear reactor shutdown sequence is pretty different from usability of a voicemail menu system. What you'll learn in this chapter are the basics of what to look for with a bias toward software that you use on your PC every day. You can then take those ideas and apply them to whatever software you have to test. Highlights of this chapter include · What usability testing involves · What to look for when testing a user interface · What special usability features are needed by the disabled
|
What Makes a Good UI? Many software companies spend large amounts of time and money researching the best way to design the user interfaces for their software. They use special usability labs run by ergonomic specialists. The labs are equipped with one-way mirrors and video cameras to record exactly how people use their software. Everything the users (subjects) do from what keys they press, how they use the mouse, what mistakes they make, and what confuses them is analyzed to make improvements to the UI. You may be wondering what a software tester could possibly contribute with such a detailed and scientific process. By the time the software is specified and written, it should have the perfect UI. But, if that's the case, why are there so many VCRs blinking 12:00? First, not every software development team designs their interface so scientifically. Many UIs are just thrown together by the programmerswho may be good at writing code, but aren't necessarily ergonomics experts. Other reasons might be that technological limitations or time constraints caused the UI to be sacrificed. The reason might be that the software wasn't properly localized. In the end, the software tester needs to assume the responsibility of testing the product's usability, and that includes its user interface. You might not feel that you're properly trained to test a UI, but you are. Remember, you don't have to design it. You just have to pretend you're the user and find problems with it. Here's a list of seven important traits common to a good UI. It doesn't matter if the UI is on a digital watch or is the Mac OS X interface, they all still apply. · Follows standards and guidelines · Intuitive · Consistent · Flexible · Comfortable · Correct · Useful If you read a UI design book, you may also see other traits being listed as important. Most of them are inherent or follow from these seven. For example, "easy to learn" isn't listed above, but if something is intuitive and consistent, it's probably easy to learn. As a tester, if you concentrate on making sure your software's UI meets these criteria, you'll have a darn good interface. Each trait is discussed in detail in the following sections. Follows Standards and Guidelines The single most important user interface trait is that your software follows existing standards and guidelinesor has a really good reason not to. If your software is running on an existing platform such as Mac or Windows, the standards are set. Apple's are defined in the book Macintosh Human Interface Guidelines, published by Addison-Wesley, also available online at developer.apple.com/documentation/mac/ HIGuidelines/HIGuidelines-2.html. Microsoft's are in the book Microsoft Windows User Experience, published by Microsoft Press, with the online version at msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/welcome.asp. Each book goes into meticulous detail about how software that runs on each platform should look and feel to the user. Everything is defined from when to use check boxes instead of an option button (when both states of the choice are clearly opposite and unambiguous) to when it's proper to use the information, warning, and critical messages as shown in Figure 11.1. Figure 11.1. Did you ever notice that there are three different levels of messages in Windows? When and how to use each one is defined in the user interface standards for Windows.
NOTE If you're testing software that runs on a specific platform, you need to treat the standards and guidelines for that platform as an addendum to your product's specification. Create test cases based on it just as you would from the product's spec. These standards and guidelines were developed (hopefully) by experts in software usability. They have accounted for a great deal of formal testing, experience, and trial and error to devise rules that work well for their users. If your software strictly follows the rules, most of the other traits of a good UI will happen automatically. Not all of them will because your team may want to improvise on them a bit, or the rules may not perfectly fit with your software. In those cases, you need to really pay attention to usability issues. It's also possible that your platform doesn't have a standard, or maybe your software is the platform. In those situations, your design team will be the ones creating the usability standards for your software. You won't be able to take for granted the rules that someone else has already figured out, and the remaining traits of a good user interface will be even more important for you to follow. Intuitive In 1975 the MITS (Micro Instrumentation Telemetry Systems) Altair 8800 was released as one of the first personal computers. Its user interface (see Figure 11.2) was nothing but switches and lightsnot exactly intuitive to use. Figure 11.2. The MITS Altair 8800 and its less-than-intuitive user interface. (Photo courtesy of the |
Testing for the Disabled: Accessibility Testing A serious topic that falls under the area of usability testing is that of accessibility testing or testing for the disabled. A 1997 government Survey of Income and Program Participation (SIPP) used by the U.S. Census Bureau found that about 53 million people (nearly 20% of the population) in the country had some sort of disability. Table 11.1 shows a more detailed breakdown.
Cutting the data another way, reveals that 7.7 million people have difficulty seeing the words and letters in a newspaper. 1.8 million People are legally blind and 8 million people have difficulty hearing. With our aging population and the penetration of technology into nearly every aspect of our lives, the usability of software becomes more important every day. Although there are many types of disabilities, the following ones make using computers and software especially difficult: · Visual impairments. Color blindness, extreme near and far sightedness, tunnel vision, dim vision, blurry vision, and cataracts are examples of visual limitations. People with one or more of these would have their own unique difficulty in using software. Think about trying to see where the mouse pointer is located or where text or small graphics appear onscreen. What if you couldn't see the screen at all? · Hearing impairments. Someone may be partially or completely deaf, have problems hearing certain frequencies, or picking a specific sound out of background noise. Such a person may not be able to hear the sounds or voices that accompany an onscreen video, audible help, or system alerts. · Motion impairments. Disease or injury can cause a person to lose fine, gross, or total motor control of his hands or arms. It may be difficult or impossible for some people to properly use a keyboard or a mouse. For example, they may not be able to press more than one key at a time or may find it impossible to press a key only once. Accurately moving a mouse may not be possible. · Cognitive and language. Dyslexia and memory problems may make it difficult for someone to use complex user interfaces. Think of the issues outlined previously in this chapter and how they might impact a person with cognitive and language difficulties. Legal Requirements Fortunately, developing software with a user interface that can be used by the disabled isn't just a good idea, a guideline, or a standard it’s often the law. In the · The Americans with Disability Act states that businesses with 15 or mores employees must make reasonable accommodations for employees, or potential employees, with disabilities. The · Section 508 of the Rehabilitation Act is very similar to the · Section 255 of the Telecommunications Act requires that all hardware and software that transfers information over the Internet, a network, or the phone lines be made so that it can be used by people with disabilities. If it's not directly usable, it must be compatible with existing hardware and software accessibility aids. Accessibility Features in Software Software can be made accessible in one of two ways. The easiest is to take advantage of support built into its platform or operating system. Windows, Mac OS, Java, and Linux all support accessibility to some degree. Your software only needs to adhere to the platform's standards for communicating with the keyboard, mouse, sound card, and monitor to be accessibility enabled. Figure 11.7 shows an example of the Windows accessibility settings control panel. Figure 11.7. The Windows accessibility features are set from this control panel.
If the software you're testing doesn't run on these platforms or is its own platform, it will need to have its own accessibility features specified, programmed, and tested. The latter case is obviously a much larger test effort than the first, but don't take built-in support for granted, either. You'll need to test accessibility features in both situations to make sure that they comply. If you're testing usability for your product, be sure to create test cases specifically for accessibility. You'll feel good knowing that this area is thoroughly tested. Each platform is slightly different in the features that it offers, but they all strive to make it easier for applications to be accessibility enabled. Windows provides the following capabilities: · StickyKeys allows the Shift, Ctrl, or Alt keys to stay in effect until the next key is pressed. · FilterKeys prevents brief, repeated (accidental) keystrokes from being recognized. · ToggleKeys plays tones when the Caps Lock, Scroll Lock, or NumLock keyboard modes are enabled. · SoundSentry creates a visual warning whenever the system generates a sound. · ShowSounds tells programs to display captions for any sounds or speech they make. These captions need to be programmed into your software. · High Contrast sets up the screen with colors and fonts designed to be read by the visually impaired. Figure 11.8 shows an example of this. Figure 11.8. The Windows desktop can be switched to this high contrast mode for easier viewing by the visually impaired.
· MouseKeys allows use of keyboard keys instead of the mouse to navigate. · SerialKeys sets up a communications port to read in keystrokes from an external non-keyboard device. Although the OS should make these devices look like a standard keyboard, it would be a good idea to add them to your configuration testing equivalence partitions. For more information about the accessibility features built into the popular OS platforms, consult the following websites: · www.linux.org/docs/ldp/howto/Accessibility-HOWTO | ||||||||||||||||||||
