Scribd Logo
Upload

Welcome to Scribd!

  • 50 views

    Unit Testing

    Uploaded by

    murtajiz110
    This document outlines goals and procedures for unit testing software to improve quality. It discusses establishing clear guidelines for unit testing with objective goals like proving the existence of bugs, and subjective goals like increasing programmer satisfaction. It recommends defining minimum testing standards and procedures, collecting bug data, and rewarding programmers for discovered bugs. Finally, it suggests educating staff on quality assurance goals and defining testing documentation and review standards.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd

    Unit Testing

    Uploaded by

    murtajiz110
    50 views2 pages
    This document outlines goals and procedures for unit testing software to improve quality. It discusses establishing clear guidelines for unit testing with objective goals like proving the existence of bugs, and subjective goals like increasing programmer satisfaction. It recommends defining minimum testing standards and procedures, collecting bug data, and rewarding programmers for discovered bugs. Finally, it suggests educating staff on quality assurance goals and defining testing documentation and review standards.

    Original Description:

    unit testing

    Original Title

    Unit testing

    Copyright

    © © All Rights Reserved

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    This document outlines goals and procedures for unit testing software to improve quality. It discusses establishing clear guidelines for unit testing with objective goals like proving the existence of bugs, and subjective goals like increasing programmer satisfaction. It recommends defining minimum testing standards and procedures, collecting bug data, and rewarding programmers for discovered bugs. Finally, it suggests educating staff on quality assurance goals and defining testing documentation and review standards.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    50 views2 pages

    Unit Testing

    Uploaded by

    murtajiz110
    This document outlines goals and procedures for unit testing software to improve quality. It discusses establishing clear guidelines for unit testing with objective goals like proving the existence of bugs, and subjective goals like increasing programmer satisfaction. It recommends defining minimum testing standards and procedures, collecting bug data, and rewarding programmers for discovered bugs. Finally, it suggests educating staff on quality assurance goals and defining testing documentation and review standards.

    Copyright:

    © All Rights Reserved
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    of 2

    UNITS, ELEMENTS and QA

    Notes taken from Boris Beizer books:

    Establish methods for finding potential common code and the avoidance of redundant program elements
    Define the ritual and steps therein by which a unit is admitted as a trustworthy public elopement. Create the
    ceremony and the signs by which such units can be recognized
    Educate the programming staff, group leaders, section heads and management as to the objective, subjective,
    subsidiary and auxiliary goals of unit testing:
    Subjective goals:
    Programmer job satisfaction
    Trust
    Objective goals:
    To prove there are bugs and not to prove the software is bug free
    Establish clear guidelines for unit testing, defining not only minimum standards, but maximum standards too.
    Reward the programmer's discovery of bugs-say "Great!" when a bug I discovered and brought to your attention.
    Cheer when a bug is found instead of scowling.
    Artificially formalize the conclusion of unit testing so that the mark thereof is tangible - make a ceremony out of
    it, pass out certificates of merit or gold stars
    Avoid guilt induction. Don't be judgemental.
    Does the programs intention match the requirements?
    Does the execution match the intentions?
    Does the unit conform to published interface conventions and calling sequences?
    Is the unit consistent to the data base?
    Are all private data items (e.g. data objects not in the data dictionary) justified?
    Are all absolute addresses, relative addresses, address modifications, and other potentially dangerous constructs
    justified?
    Does the unit meet performance and size objectives (if specified)?
    Is the documentation complete and meaningful (rather than verbose but inadequate)?
    Was the test plan published in advance?
    Are all identified bugs corrected?
    Was the test plan revised to reflect the correction?
    Was regression testing done to verify the corrections?
    Subsidiary goals:
    Does the coding conform to published project style standards?
    Are mnemonic and label conventions followed?
    Auxiliary goals:
    Start the bug counter. Unit testing, because it is formal, is the first place where reliable bug data can be gathered.
    QA needs bug counts to predict system quality. Management needs bug counts to predict testing costs and duration,
    and programmer quality.
    Gather data on: bug types established by categories, bug severity, and bug correction costs.
    Obtain feedback on the effectiveness of test techniques used, bug prevention methods employed, and quality
    assurance efforts.
    Revise estimates of labour, elapsed time, project completion costs, testing resource requirements, and testing
    schedules.
    Define in detail the minimum unit testing procedures and associated forms and documents
    Establish a reward system for discovered bugs
    Define the objective goals to be verified by programmers, group leaders and QA
    Define QA data gathering formats and procedures that are effective but not obnoxious. Distribute collective results
    periodically in a QA bulletin.
    Define standards and procedures for testing partially complete code and for follow-up of incomplete units and

    incompletely tested units.


    Define standards and procedures for conditional unit acceptance
    Define unit test plans standards, associated documents and forms.
    Define unit test plan review procedures - what, with what, how, and by whom
    Define style guides
    Define coding standards
    Work with programming management to:
    Get adequate test tools, resources, facilities and schedules
    Get a fair share of those tools and resources for QA's use
    Define the test environment (e.g. real vs. simulated) for unit testing. Create methods to track the environment in
    which tests are run.
    Agitate for good automated analyzers. Agitate enough for on-line computer time so that analyzers and tools can be
    used effectively.
    Define desk-checking objectives, procedures, and methods. Educate programming staff, group leaders, and
    managers regarding desk checking.
    Define initial documentation objectives
    Create standard agendas for reviews at every level, defining who, what, and when
    Define and publish what is to be covered by each type of audit and the procedures for deficiencies found by audits.
    Plan a grand strategy of implementation in which QA appears to have the least contribution - wherever possible, let
    the programmers believe that they are initiating QA measures. Accept and incorporate any sensible suggestion you
    get from programming staff and be sure they get the credit for it.
    Don't ignore the importance of informal and private practices - that's where most of the unit-level bugs are caught. It
    works. Don't fight it. Just try to make it better.
    READ THE CODE.

    You might also like