Software QA/Testing Technical FAQs

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45   46  47 

How do you test data integrity?
Data integrity is tested by the following tests:
Verify that you can create, modify, and delete any data in tables.
Verify that sets of radio buttons represent fixed sets of values.
Verify that a blank value can be retrieved from the database.
Verify that, when a particular set of data is saved to the database, each value gets saved fully, and the truncation of strings and rounding of numeric values do not occur.
Verify that the default values are saved in the database, if the user input is not specified.
Verify compatibility with old data, old hardware, versions of operating systems, and interfaces with other software.
Why do we perform data integrity testing? Because we want to verify the completeness, soundness, and wholeness of the stored data. Testing should be performed on a regular basis, because important data could, can, and will change over time.

What is the difference between data validity and data integrity?
Difference number one: Data validity is about the correctness and reasonableness of data, while data integrity is about the completeness, soundness, and wholeness of the data that also complies with the intention of the creators of the data.
Difference number two: Data validity errors are more common, and data integrity errors are less common.
Difference number three: Errors in data validity are caused by human beings - usually data entry personnel - who enter, for example, 13/25/2010, by mistake, while errors in data integrity are caused by bugs in computer programs that, for example, cause the overwriting of some of the data in the database, when somebody attempts to retrieve a blank value from the database.

What is the difference between static and dynamic testing?
Difference number 1: Static testing is about prevention, dynamic testing is about cure.
Difference number 2: The static tools offer greater marginal benefits.
Difference number 3: Static testing is many times more cost-effective than dynamic testing.
Difference number 4: Static testing beats dynamic testing by a wide margin.
Difference number 5: Static testing is more effective!
Difference number 6: Static testing gives you comprehensive diagnostics for your code.
Difference number 7: Static testing achieves 100% statement coverage in a relatively short time, while dynamic testing often often achieves less than 50% statement coverage, because dynamic testing finds bugs only in parts of the code that are actually executed.
Difference number 8: Dynamic testing usually takes longer than static testing. Dynamic testing may involve running several test cases, each of which may take longer than compilation.
Difference number 9: Dynamic testing finds fewer bugs than static testing.
Difference number 10: Static testing can be done before compilation, while dynamic testing can take place only after compilation and linking.
Difference number 11: Static testing can find all of the followings that dynamic testing cannot find: syntax errors, code that is hard to maintain, code that is hard to test, code that does not conform to coding standards, and ANSI violations.

What testing tools should we use?
Ideally, you should use both static and dynamic testing tools. To maximize software reliability, you should use both static and dynamic techniques, supported by appropriate static and dynamic testing tools.
Reason number 1: Static and dynamic testing are complementary. Static and dynamic testing find different classes of bugs. Some bugs are detectable only by static testing, some only by dynamic.
Reason number 2: Dynamic testing does detect some errors that static testing misses. To eliminate as many errors as possible, both static and dynamic testing should be used.
Reason number 3: All this static testing (i.e. testing for syntax errors, testing for code that is hard to maintain, testing for code that is hard to test, testing for code that does not conform to coding standards, and testing for ANSI violations) takes place before compilation.
Reason number 4: Static testing takes roughly as long as compilation and checks every statement you have written.

Why should I use static testing techniques?
There are several reasons why one should use static testing techniques.
Reason number 1: One should use static testing techniques because static testing is a bargain, compared to dynamic testing.
Reason number 2: Static testing is up to 100 times more effective. Even in selective testing, static testing may be up to 10 times more effective. The most pessimistic estimates suggest a factor of 4.
Reason number 3: Since static testing is faster and achieves 100% coverage, the unit cost of detecting these bugs by static testing is many times lower than detecting bugs by dynamic testing.
Reason number 4: About half of the bugs, detectable by dynamic testing, can be detected earlier by static testing.
Reason number 5: If one uses neither static nor dynamic test tools, the static tools offer greater marginal benefits.
Reason number 6: If an urgent deadline looms on the horizon, the use of dynamic testing tools can be omitted, but tool-supported static testing should never be omitted.

What is the definiton of top down design?
Top down design progresses from simple design to detailed design. Top down design solves problems by breaking them down into smaller, easier to solve subproblems. Top down design creates solutions to these smaller problems, and then tests them using test drivers. In other words, top down design starts the design process with the main module or system, then progresses down to lower level modules and subsystems. To put it differently, top down design looks at the whole system, and then explodes it into subsystems, or smaller parts. A systems engineer or systems analyst determines what the top level objectives are, and how they can be met. He then divides the system into subsystems, i.e. breaks the whole system into logical, manageable-size modules, and deals with them individually.

What is the future of software QA/testing?
In software QA/testing, employers increasingly want us to have a combination of technical, business, and personal skills. By technical skills they mean skills in IT, quantitative analysis, data modeling, and technical writing. By business skills they mean skills in strategy and business writing. By personal skills they mean personal communication, leadership, teamwork, and problem-solving skills. We, employees, on the other hand, want increasingly more autonomy, better lifestyle, increasingly more employee oriented company culture, and better geographic location. We continue to enjoy relatively good job security and, depending on the business cycle, many job opportunities. We realize our skills are important, and have strong incentives to upgrade our skills, although sometimes lack the information on how to do so. Educational institutions increasingly ensure that we are exposed to real-life situations and problems, but high turnover rates and a rapid pace of change in the IT industry often act as strong disincentives for employers to invest in our skills, especially non-company specific skills. Employers continue to establish closer links with educational institutions, both through in-house education programs and human resources. The share of IT workers with IT degrees keeps increasing. Certification continues to keep helping employers to quickly identify us with the latest skills. During boom times, smaller and younger companies continue to be the most attractive to us, especially those that offer stock options and performance bonuses in order to retain and attract those of us who are the most skilled. High turnover rates continue to be the norm, especially during economic boom. Software QA/testing continues to be outsourced to offshore locations. Software QA/testing continues to be performed by mostly men, but the share of women keeps increasing.

How can I be effective and efficient, when I'm testing e-commerce web sites?
When you're doing black box testing of an e-commerce web site, you're most efficient and effective when you're testing the site's visual appeal, content, and home page. When you want to be effective and efficient, you need to verify that the site is well planned; verify that the site is customer-friendly; verify that the choices of colors are attractive; verify that the choices of fonts are attractive; verify that the site's audio is customer friendly; verify that the site's video is attractive; verify that the choice of graphics is attractive; verify that every page of the site is displayed properly on all the popular browsers; verify the authenticity of facts; ensure the site provides reliable and consistent information; test the site for appearance; test the site for grammatical and spelling errors; test the site for visual appeal, choice of browsers, consistency of font size, download time, broken links, missing links, incorrect links, and browser compatibility; test each toolbar, each menu item, every window, every field prompt, every pop-up text, and every error message; test every page of the site for left and right justifications, every shortcut key, each control, each push button, every radio button, and each item on every drop-down menu; test each list box, and each help menu item. Also check, if the command buttons are grayed out when they're not in use.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45   46  47