Preferred Requirements Gathering Techniques - 1

Preferred Requirements Gathering Techniques

Following are a set of recommended requirements elicitation techniques. These techniques can be used in combination. Their advantages are that they are effective in emerging the real requirements for planned development efforts.

Interviews
Interviews are used to gather information. However, the predisposition, experience, understanding, and bias of the person being interviewed influence the information obtained. The use of context-free questions by the interviewer helps avoid prejudicing the response . A context-free question is a question that does not suggest a particular response. For example, who is the client for this system? What is the real reason for wanting to solve this problem? What environment is this product likely to encounter? What kind of product precision is required?

Document Analysis
All effective requirements elicitation involves some level of document analysis such as business plans, market studies, contracts, requests for proposals, statements of work, existing guidelines, analyses of existing systems, and procedures. Improved requirements coverage results from identifying and consulting all likely sources of requirements.

Brainstorming
Brainstorming involves both idea generation and idea reduction. The goal of the former is to identify as many ideas as possible, while the latter ranks the ideas into those considered most useful by the group. Brainstorming is a powerful technique because the most creative or effective ideas often result from combining seemingly unrelated ideas. Also, this technique encourages original thinking and unusual ideas.

Requirements Workshops.
Requirements workshops are a powerful technique for eliciting requirements because they can be designed to encourage consensus concerning the requirements of a particular capability. They are best facilitated by an outside expert and are typically short (one or a few days). Other advantages are often achieved -- participant commitment to the work products and project success, teamwork, resolution of political issues, and reaching consensus on a host of topics. Benefits of requirements workshops include the following:

Workshop costs are often lower than are those for multiple interviews.
They help to give structure to the requirements capture and analysis process.
They are dynamic, interactive, and cooperative.
They involve users and cut across organizational boundaries.
They help to identify and prioritize needs and resolve contentious issues.
When properly run, they help to manage user's expectations and attitude toward change

A special category of requirements workshop is a Joint Application Development (JAD) workshop. JAD is a method for developing requirements through which customers, user representatives, and developers work together with a facilitator to produce a requirements specification that both sides support.



Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Glossary - A (part 1)

A

Acceptance Testing: Testing conducted to enable a user/customer to determine whether to accept a software product. Normally performed to validate the software meets a set of agreed acceptance criteria.

Accessibility Testing: Verifying a product is accessible to the people having disabilities (deaf, blind, mentally disabled etc.).

Ad Hoc Testing: A testing phase where the tester tries to 'break' the system by randomly trying the system's functionality. Can include negative testing as well. See also Monkey Testing.

Agile Testing: Testing practice for projects using agile methodologies, treating development as the customer of testing and emphasizing a test-first design paradigm. See also Test Driven Development.

Application Binary Interface (ABI): A specification defining requirements for portability of applications in binary forms across defferent system platforms and environments.

Application Programming Interface (API): A formalized set of software calls and routines that can be referenced by an application program in order to access supporting system or network services.

Automated Software Quality (ASQ): The use of software tools, such as automated testing tools, to improve software quality.

Automated Testing:

Testing employing software tools which execute tests without manual intervention. Can be applied in GUI, performance, API, etc. testing.
The use of software to control the execution of tests, the comparison of actual outcomes to predicted outcomes, the setting up of test preconditions, and other test control and test reporting functions.


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Why White box testing when black box testing

Why White box testing when black box testing is there to test conformance to requirements

Logic errors and incorrect assumptions most likely to be made when coding for "special cases". Need to ensure these execution paths are tested.

May find assumptions about execution paths incorrect, and so make design errors. White box testing can find these errors.

Typographical errors are random. Just as likely to be on an obscure logical path as on a mainstream path.


Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Regression Testing

Testing conducted for the purpose of evaluating whether or not a change to the system (all CM items) has introduced a new failure. Regression testing is often accomplished through the construction, execution and analysis of product and system tests.

Regression testing is an expensive but necessary activity performed on modified software to provide confidence that changes are correct and do not adversely affect other system components. Four things can happen when a developer attempts to fix a bug. Three of these things are bad, and one is good:

Because of the high probability that one of the bad outcomes will result from a change to the system, it is necessary to do regression testing.

It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Most industrial testing is done via test suites; automated sets of procedures designed to exercise all parts of a program and to show defects. While the original suite could be used to test the modified software, this might be very time-consuming. A regression test selection technique chooses, from an existing test set, the tests that are deemed necessary to validate modified software.

There are three main groups of test selection approaches in use:

Minimization approaches seek to satisfy structural coverage criteria by identifying a minimal set of tests that must be rerun.

Coverage approaches are also based on coverage criteria, but do not require minimization of the test set. Instead, they seek to select all tests that exercise changed or affected program components.

Safe attempt instead to select every test that will cause the modified program to produce different output than original program.

An interesting approach to limiting test cases is based on whether we can confine testing to the "vicinity" of the change. (Ex. If I put a new radio in my car, do I have to do a complete road test to make sure the change was successful?) A new breed of regression test theory tries to identify, through program flows or reverse engineering, where boundaries can be placed around modules and subsystems. These graphs can determine which tests from the existing suite may exhibit changed behavior on the new version.

Regression testing has been receiving more attention as corporations focus on fixing the 'Year 2000 Bug'. The goal of most Y2K is to correct the date handling portions of their system without changing any other behavior. A new 'Y2K' version of the system is compared against a baseline original system. With the obvious exception of date formats, the performance of the two versions should be identical. This means not only do they do the same things correctly, they also do the same things incorrectly. A non-Y2K bug in the original software should not have been fixed by the Y2K work.

A frequently asked question about regression testing is 'The developer says this problem is fixed. Why do I need to re-test?’ to which the answer is 'The same person probably told you it worked in the first place'





Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Performance Testing - Volume Testing

Volume Testing: Testing where the system is subjected to large volumes of data. As regards faults that should be found through volume testing are those, where the behaviour of the software deviates from that expected for a specified volume of data. Thus a bank system will be tested for faults at much larger volumes of data, than that of small retailer software. A fault which is only manifested on a table with a million records will be of no concern to the retail software, but will be picked up by the bank testers.

For example, a window often used window object is populated with data, by calling a database object which runs a complex SQL query. Supposing the component is tested against tables with only 4-5 records. Of course it will return within seconds. Everything seems fine. It is then integrated with the window, and system tested. Again everything seems ok. It is only when the application is in User Acceptance (or even gone live) and it is tested against 100,000 records, is it discovered that, the SQL was not properly optimized and the tables not indexed. Thus it should have been tested at the component level.

Volume testing needs two things. Firstly clear expected outcomes of how the software is to behave for a given level of data. Secondly, data, and lots of it.

The expected behaviour at various levels, should be in the specification documentation. Ideally this will say something like "the customers details will be returned returned on the screen within 3 seconds, from a database with 1 million customer records." This gives the tester a benchmark to base a test case on.

The second requirement for data, needs either real life data, or simulated data. Usually, real life data will come in the form of a customer database, that has had private information, such as names and account numbers scrambled. Alternatively records can be created from scratch using automated tools or by adding rules directly on to the database, with SQL.

As with all testing, proper records must be kept showing the inputs, outputs other information, to aid potential debugging and audit purposes.





Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Performance Testing - Stress testing

Stress testing :is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts, etc.) needed to process that load. The idea is to stress a system to the breaking point in order to find bugs that will make that break potentially harmful. The system is not expected to process the overload without adequate resources, but to behave (e.g., fail) in a decent manner (e.g., not corrupting or losing data). Bugs and failure modes discovered under stress testing may or may not be repaired depending on the application, the failure mode, consequences, etc. The load (incoming transaction stream) in stress testing is often deliberately distorted so as to force the system into resource depletion.




Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum

Performance Testing - Load testing

Load testing: is subjecting a system to a statistically representative (usually) load. The two main reasons for using such loads is in support of software reliability testing and in performance testing. The term "load testing" by itself is too vague and imprecise to warrant use. For example, do you mean representative load," "overload," "high load," etc. In performance testing, load is varied from a minimum (zero) to the maximum level the systemcan sustain without running out of resources or having, transactions suffer (application-specific) excessive delay.




Software Testing Training


Software testing institute


corporate training software testing



For More Visit Site
http://www.crestechsoftware.com/

For discussion FORUM
http://www.crestechsoftware.com/forum