Topic: What's the role of documentation in QA?

Message

     What's the role of documentation in QA?

		Critical. (Note that documentation can be

electronic, not necessarily paper, may be embedded in code comments, etc.) QA

practices should be documented such that they are repeatable. Specifications,

designs, business rules, inspection reports, configurations, code changes, test

plans, test cases, bug reports, user manuals, etc. should all be documented in

some form. There should ideally be a system for easily finding and obtaining

information and determining what documentation will have a particular piece of

information. Change management for documentation should be used if possible.

What's the big deal about requirements'?

		One of the most reliable methods of ensuring

problems, or failure, in a large, complex software project is to have poorly

documented requirements specifications. Requirements are the details describing

an application's externally-perceived functionality and properties. Requirements

should be clear, complete, reasonably detailed, cohesive, attainable, and

testable. A non-testable requirement would be, for example, 'user-friendly' (too

subjective). A testable requirement would be something like 'the user must enter

their previously-assigned password to access the application'. Determining and

organizing requirements details in a useful and efficient way can be a difficult

effort; different methods are available depending on the particular project.

Many books are available that describe various approaches to this task. (See the

Bookstore section's 'Software Requirements

Engineering' category for books on Software Requirements.)

click here for more details:

http://www.onestopfaqs.com/faqs/1624/

Author	Message
appurva Newbie Joined: 09Apr2007 Online Status: Offline Posts: 1	Topic: What's the role of documentation in QA? Posted: 09Apr2007 at 10:01pm
	What's the role of documentation in QA? Critical. (Note that documentation can be electronic, not necessarily paper, may be embedded in code comments, etc.) QA practices should be documented such that they are repeatable. Specifications, designs, business rules, inspection reports, configurations, code changes, test plans, test cases, bug reports, user manuals, etc. should all be documented in some form. There should ideally be a system for easily finding and obtaining information and determining what documentation will have a particular piece of information. Change management for documentation should be used if possible. What's the big deal about requirements'? One of the most reliable methods of ensuring problems, or failure, in a large, complex software project is to have poorly documented requirements specifications. Requirements are the details describing an application's externally-perceived functionality and properties. Requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something like 'the user must enter their previously-assigned password to access the application'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project. Many books are available that describe various approaches to this task. (See the Bookstore section's 'Software Requirements Engineering' category for books on Software Requirements.) click here for more details: http://www.onestopfaqs.com/faqs/1624/ Post Resume: Click here to Upload your Resume & Apply for Jobs

	IP Logged


One Stop Testing Forum : Quality Assurance @ OneStopTesting : Defect Management@ OneStopTesting