Connecting Practice

And what are the inputs, guidelines, and outputs to bear in mind in obtaining estimates for testing phase of a software project?

Inputs

• Defined statement of project scope for clear goals and focus work
• Defined user requirements - use cases and functional specs for delivering the required functionality
• Defined technical requirements
• Other supporting documents

Guidelines to create a detailed estimates

• Determine all the effort (lists of tasks the testing work entails) to be performed. This includes getting all the next actions visible.
• Determine complexity of the system.
• Form initial estimate for each task. This includes involving the individuals who will be doing the tasks to figure out how long a task will take based on their experience implementing similar things.
• Assign each task a ‘risk.’ Assign ‘High‘ risk to tasks that you lack knowledge and/or experience; assign ‘Medium‘ risk to tasks that you are familiar with and can complete the tasks; and assign ‘Low‘ risk to tasks that you are confident about and/or have been done many times before.
• Document any other risks that might affect the test work deliverables to address and bring test work in on time.
• Document assumptions made. Note that each task figure should be accompanied by a note on the assumption(s) that you’ve made in coming to this figure and/or interpreting the task requirements.
• Apply adjustments and reserve allowances to account for external factors that the project will depend upon. External factor examples: Tasks that require approval; incomplete component from another project - here document the effect of the dependency if task is not being met; and failure from delivering the required component to a satisfactory standard that cause development delays.
• Include contingency in the estimate. The contingency should be listed separately. If tasks need to use some of the contingency for certain reasons then the Lead should ask the PM for a portion of the contingency. The reasons for needing to use some of the contingency will be discussed and the impact on the test work timelines will be shown in the test plan and shared with the team.

Guidelines to schedule the test work

• Work out how many people will be needed on the team in order to complete the test work in the required time.
• Add test work milestones. Note that every test work task listed in the estimate should become a task in the schedule.
• Assign test work tasks to people who have the skills needed to do the task. There should be some gaps between tasks to represent risk.
• Add dummy tasks to represent known outages, such as: Public holidays, annual leave, training courses, and so on.
• Try to move high risk tasks as near to the beginning of the schedule as possible so that there is as much time as possible to deal with problems.
  Ensure that dependencies between tasks are respected - reorganise the schedule if necessary.
• Keep the schedule up-to-date with latest progress and changes regularly.

Outputs

• A project schedule with allowances for risk, internal dependencies, and known outages
• A list of other assumptions made during the estimation
• A list of the project’s external dependencies
• A list of other risks to the project schedule

Join QAST Practitioner Group, download the attached sample detailed estimate template file in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=60.0

The attached sample detailed estimate template file is meant to be used to create detailed estimates for testing phase (support and regression testing) of a software project.

In “How Can You Develop A Test Specification Documents?” topic, it describes the specific activities to perform and achieve the development of test specification documents. In this piece, it describes the typical contents of test specification template for documenting test cases characteristically below.

Template Header
1. Project number - It should describe the project number accurately.

2. Test Specification name - It should describe the test specification name clearly.

Template Details
1. Test No. - It should describe the test number to ensure every test cases in a project has a unique number for traceability. Note: To ensure every test case in a project has a unique number for traceability, this number should start with the Use Case number (for example Use Case 3 Search, numbering will be 3.1, 3.1.1, 3.2, etc.) - 3.1, 3.2, etc will be section headings and not have tests associated with them, while 3.1.1…., 3.2.1 will contain the test cases. If a test does not have a Use Case associated with it, the test number must start with 0. There must be no blank rows in the “Test No.” column (Column A).

2. Tracking No. - It should describe the associated defect tracking number reference with the particular test case for traceability.

3. Found in Build - It should be the date of the build when the test case was run.

4. Use Case No. - It is important for traceability of every test case that this number matches the use case number.

5. Subject, Object, or Function Name - It should be the subject, object, or function Name where the test case was run.

6. Test Case Description - It should be clear, concise, and accurately describe the test case. It should have some mandatory fields like:

• Objective - General objective of the test case that clearly and accurately describe it.
• Pre-Test Condition - Optional, Pre-requisite for testing the feature
• Verification - Optional, Need to verify against the pre-condition or requirement
• Steps to Reproduce - It should be the clear step by step instructions on how to reproduce the test case. It should provide a verbatim transcript of the session and show what commands you typed and what output in response. It should be minimized and easy-to-follow steps.
• Expected Behavior - It should be the description of the correct or expected results where the defect is not present.
• Actual Result - It should be the clear and detailed description of what happens after the step by step instruction are followed. If you saw test failures then describe the errors, carefully and precisely, what they were. The developers need to know what has gone wrong. If available, include the error message number to get information or search for clues.

Important:

• All scenarios must be considered including negative testing.
• Boundary Analysis must be performed.
• It is not simply a case of sticking verify in front of each requirement - analysis must be carried out for completeness, effectiveness and efficiency.
• If something is not clear in the use case, now is the time to raise questions and ensure the answers form part of this document - it’s too late in the test execution phase.
• Consider information and/or things you will need to support testing, again now is the time to request for these information and/or things.

7. Test Data - Test Data to support every single test scenario must be included

8. Run - It is used to indicate which test are to be run for re-testing and regression testing. Setting the field to 1 indicates that the test case must be executed for re-testing.

9. Pass/Fail

• Pass - Test Passed
• Fail - Test failed if the actual results differ significantly from the test expectations.
• Can’t Test (CT) - A bug in another piece of functionality is restricting you from running this test
• Functionality Not available (FNA) - Functional no longer available or will be available in further phases
• Not Tested - Leave the pass/fail cell blank if you decide not to test the test case.

10. Comment - It should be any additional comments - keep them as consise as possible.

11. Tested By - It should be the tester’s name for traceability and accountability.

12. Tested Date - It should be the date when the test case was run.

13. Test Time (Hours)

• Estimated - Time estimated to execute test case
• Actual - Actual time spent executing test case (include time logging Defects, etc.)

14. Guidelines

a. The layout / format must not be changed from the original template.
b. There must be no blank rows in the “Test No.” column (Column A).
c. To insert further rows to allow you add more defects, highlight a row and click insert row (standard excel). Do not highlight row 5 when inserting rows!
d. If you need to add more test cycles, highlight the last eight columns and copy, then highlight the next eight columns and paste. Don’t forget to change the test cycle number. If you follow this instruction the formulas will also be copied and work!
e. Remember, you must keep the revision history sheet updated. If you update something - put a comment in the revision history. All test cycles must be tracked in the revision history. This number should match the SI revision number - this makes rolling back easier if needed.
f. To group test cases for convenience:

• Click on Data
• Then Settings
• Select “Summary Columns to right of detail” only
• Steps 2 and 3 will only need to be done once
• Select rows beneath your heading that you wish to group (heading should not be selected)
• Click Group and select Rows (Data/Group and Outline/Group)

Join QAST Practitioner Group, download the material in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=56.0

In “How to Report Bugs Effectively?” topic, one can identify the twofold strategy below to provide defect information effectively to developers.

1. Show the defects to the developers personally; Or
2. Provide all the information that the developers need; give them careful and detailed instructions on how to make it fail in the same way; and/or find pattern, symptoms, and/or answers to their own defects that concern them to know the cause. More information is almost always better than less - Simon Tatham. The intention is to enable them to reproduce the defects.

Moreover, reporting defects are task of showing or documenting the defects so that the developers responsible for repairing the defects can reproduce the failures and fix the defects.

Further, one can document the defects using a template for reporting defects, tracking defect status, and generating test summary report. The typical contents of the template for documenting defects includes:

Template Header

1. Project number - It should describe the project number accurately.

2. Test Specification name - It should describe the project test specification name clearly.

Template Details

1. Defect No. - It should describe the defect number to ensure every defects in a project has a unique number for traceability.

2. Tracking No. - It should describe the associated defect tracking number reference with the particular defect for traceability.

3. Priority - It should correspond to how urgent it is that the defect be fixed. If the defect needs to be fixed immediately, it should have its priority set to P1 (P1 being the highest priority and P5 being the lowest). Most serious bugs should have their priority set to P2.

P1 - Very High
P2 - High
P3 - Medium
P4 - Low
P5 - Very Low

Moreover, priority should be based on the failed functionality importance and the risk of failure to the business. Where possible the priority should be assigned based on discussions between QA group, Project Manager, BA, and Software Development Lead.

4. Dev Assigned - It should be the assigned developer for fixing a bug.

5. Reported By - It should be the tester’s name for traceability and accountability.

6. Reported Date - It should be the date when the defect was recorded.

7. Found in Build - It should be the date of the build when the defect was found.

8. State - It should be New, Open, or Closed.

9. Status - It should be:

• Disregarded - Defects that were disregarded in the bug report.
• NTReview - Defects that were New in the bug report for review.
• CNNWE - Defects that were Closed-NeverFix as not worth the effort.
• CWAD - Defects that were closed-Withdrawn as designed.
• CWCR - Defects that were closed-Withdrawn as cannot reproduce.
• CWD - Defects that were closed-Withdrawn as duplicate.
• CWNAB - Defects that were closed-Withdrawn as not a bug.
• CWTP - Defects that were closed-Withdrawn as third party.
• CWUE - Defects that were closed-Withdrawn as user error.
• CDLI - Defects that were closed-Deferred as Low Impact.
• Withdrawn - Defects that were closed-Withdrawn.
• OTClosing - Opened Defects that were found for closing.
• Fixed - Defects that were closed as fixed.
• ToTest - Defects that were opened to test.
• ToFix - Defects that were opened to fix.
• ToDefer - Defects that were opened to defer. It will be addressed in a later release.
• OTNMI - Defects that need more information.
• OTCR - Defects that can’t reproduce, functionality no longer available, or will be available in further phases. It is returned when the person assigned cannot replicate the incident.
• OTHNI - Defects that have new information.
• OTHD - “Defects that have dependency or a bug in another piece of functionality is restricting you from running this test.
• OTFNMI - Opened ToFix Defects that need more information.
• OTFHNI - Opened ToFix Defects that have new information.
• NNMI - New Defects that need more information.
• NCR - New Defects that can’t reproduce.

10. Bug Severity - It should correspond to the seriousness of the defect. it should be set to Critical, Major, Minor, or Low severity type. Severity Types are scheme to assist the project team in identifying the severity of the defect and managing the defect log.

Moreover, the number and severity level of open defects may affect timely completion of a project, so it is important to a have a consistent approach to assign severity level to errors; and critical that everyone know how to identify the severity of defects, and how severity levels affect the delivery of the system.

The following are definition of severity levels for defects. Notice that in addition to identifying what the severity levels are, we also present some example of what types of defects qualify for each severity. This helps the project team subjectively in deciding the severity of an error.

Critical: Business process and system functionality are SEVERELY affected - software HALTS. In most cases, they are defects in which will not allow the tester to proceed with the tests - a system inoperable or showstopper issue. Critical defects must be corrected before the code is released to production. Examples are as follows:

• Endless loop - A sequence of instructions in a computer program that are constantly repeated. In most cases, you get an incomplete page displays, or are unable to control the status of the mouse.
• Fatal errors - A condition that halts processing due to program bugs, read errors, or other anomalies. In most cases, generally you cannot recover from it.
• Program Hangs - A condition that software stops responding.

Major: Business process and system functionality are seriously affected; system and/or data is exposed to potential loss or interruption. It is a severe error that causes a program not to perform properly or to produce unreliable results. Normally, the user cannot find an appropriate “workaround” for this type of error. Also it needs immediate attention. It must be corrected before the code is released to the production. Near-term system workaround is required. Examples are as follows:

• Computation errors - Incorrect/Inaccurate calculation - a great deal. Sign errors are surely the most common errors of all. Causes: Loss of invisible parentheses, belief that a minus sign means a negative number, or out of formula/carelessness.
• Incorrect functionality - Fails to satisfy the target specifications or requirements.
• Erroneously displayed/unexpected display of error messages
• Database/table errors

Minor: Business process and system functionality are moderately affected - software is not at risk. Critical system(s) and/or data are not at risk. It needs to be resolved as soon as possible but not a showstopper. Also it is an error in which a “workaround” solution can be found or available for the user. These defects do not significantly impact the execution or performance of the software and need not necessarily be corrected before the code is released to production. Examples are as follows:

• If you click the button, the code does not work, but if you choose the command from the menu, it works fine.
• Incorrect display - In most cases, it is a condition wherein the display contains inconsistencies with the specification or requirement documents.
• Incorrect location - In most cases, it is a condition wherein the display contains inconsistencies with the specification or requirement documents.
• Data was excluded from display - In most cases, it is a condition wherein the specified or required data is not displayed.
• Unexpected behavior of link - In most cases, link is broken and goes not to the correct/intended page.
• Unexpected display of alert message - In some cases, the system responds with an alert message to the user.
• Major grammatical errors in warning/error messages
• Incorrect value for essential fields in the logs
• Obvious cosmetic errors in screens
• Incorrect default values

Low: Business process and system functionality are marginally affected or unaffected. System(s) and/or data are not at risk. In most cases, they are defects in which minimal error, a cosmetic change, or an enhancement is needed. Low level defects do not need to be corrected before release to production. Examples are as follows:

• Incorrect format
• Undeleted line space
• No line space
• No space between character
• Undeleted character
• Undeleted text
• Wrong alignment
• Wrong caption
• Wrong spelling
• Minor grammatical errors
• Wrong text position on screen
• Wrong data position on screen
• Wrong window position on screen

11. DC No. - It should be the defect category Number for analysis.

12. Subject, Object, or Function Name - It should be the subject, object, or function Name where the defect was found.

13. Defect Description - It should be clear, concise, and accurately describe the defect with actual facts so that developer doesn’t have to come looking for tester to get them. and it should have some mandatory fields like:

• Title - General description of the defect that clearly and accurately describe the defect.
• Steps to Reproduce The Bug - It should be the clear step by step instructions on how to reproduce the bug. It should provide a verbatim transcript of the session and show what commands you typed and what output in response. From Development point of view, it is very important. It should be minimized and easy-to-follow steps.
• Actual Result - It should be the clear and detailed description of what happens after the step by step instruction are followed. If you saw test failures then describe the errors, carefully and precisely, what they were. The developers need to know what has gone wrong. If available, include the error message number to get information or search for clues.
• Expected Behavior - It should be the description of the correct or expected results where the bug is not present.

14. Remarks - It should be any additional comments - keep them as consise as possible.

15. Screen Dump - It should be the captured image that could help in motivating developers to fix bugs that are hard to recreate.

16. Test Time - It should be the estimated (Time estimated to re-test the bug) and actual (Actual time spent re-testing the bug) in hours.

Join QAST Practitioner Group, download the material in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=58.0

Beginnings are important in a company that your quality assurance and software testing work is just started. It is then that expectations are formed. These early stages involve:

1. Gaining access to the developers at the outset; and
2. Forming effective relationships with the developers, and maintaining it. This includes developing and concentrating on the most important aspects of your relationship with the developers, such as:

• Rapport - Rapport is that state of interaction where you and the developers are “in tune.” The initial step in building rapport is to give all your attention to the developers.
• Assertiveness - It is when you engage to prove that you can look after yourself to commit, promote, and contribute quality change.

Moreover, in ensuring that you and developers have the sort of relationship that can weather any project issues, use your influencing styles to influence them in any actions and/or events. In this, you may consider any of the guidelines below:

1. Expressing values - Here your values about what is good or bad and important or unimportant features in a project touch a chord in developers and you capture interest. You invoke respect and admiration. You attract developers by strengthening what is good and important project features to achieve results.

2. Getting ready with the undertaking - Here you utilize and review general requirements and supporting documents. You think about what needs to be done, develop ideas, and collaborate with developers for assistance and information. You attract developers by understanding the project facts.

3. Ensuring that quality goals and objectives are clearly understood by developers - Here you provide coordinated plans. By setting plan, you manage situations and channel efforts. You attract developers by providing and bringing direction into their thinking.

4. Creating “pictures” of a desirable results - Here you are able to communicate what needs to be done to create a better results; bring developers to a quality review; expose them to the complexities and potential quality problems, technical issues, concerns, exceptions, assumptions, and/or risks; and give them understanding of what could happen. You attract developers by expressing readiness, practicality, and awareness.

5. Developing schedule - Here you negotiate work loads and time for project planning and estimation. You enable developers to identify needs, evaluate options, formulate action programs, and take initiatives for themselves. You attract developers by collaborating with them for agreement and decision making.

6. Presenting information - Here you collect data, evaluate information, built a logical case, make valid points, and appeal to reason to develop test specifications. You work closely with the developers to review use cases; describe the test cases clearly, concisely, and unambiguously with actual facts; and develop correct and accurate test data. You attract developers by demonstrating logically sound artifacts.

7. Finding defects - Here you identify developer’s defects, supply all the information, and show how these can be fulfilled to get the fix faster. You work at being a useful and helpful resource to them in providing all the information that they need, giving them careful and detailed instructions on how to make it fail in the same way, and/or finding answers to their own defects that concern them to know the cause. You attract developers by reporting defects effectively.

8. Finding issues - Here you identify specific project issues from inception, design, development, product rollout, product updates, and support in daily work. You record, analyze the risk, communicate, and join in the conversation with them. You attract developers by reporting issues effectively.

9. Meeting schedule - Here you deliver quality products. You meet the functional specifications that have been defined and ensure that defects are captured and fixed in the project before reaching our client’s environment. You attract developers by achieving specified quality goals and objectives within specified time and resource constraints.

10. Identifying and recommending improvements to quality process - Here you cause developers to discover that the current quality process is, in some ways, inadequate. You establishing quality standards, templates, checklists, criteria, guidelines, procedures, tools, and metrics in the framework of the quality initiative. This includes giving them quality process training. You attract developers by causing them to re-evaluate their works around them and learn new ways of thinking.

This piece is a quality material file which supports quality guidelines.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=57.0

Given the topic, I feel a need to acknowledge that I have to thank the owner of Here for software Testers!!!!!!!!!!! - All about Testing and Quality blog at for finding this guide materials, a good information in choosing a bug tracking system. The owner’s post (Saturday, January 6, 2007) influences my thinking to share more details about the topic.

A Bug Tracking System is constructed as a database. Usually it is designed to make bug tracking activities easy for project team to manage their specific bugs, generate reports, and assess the product (under test) situation on a build-by-build basis.

Moreover, a bug tracking system is evaluated usually by the manager for its viability and the results is reviewed by project sponsor or management for adoption. What could strike, inspire, and/or interest the management as positive about the bug tracking system are its features. The “what’s in it for us” reality could lead the management to approve or reject it.

Furthermore, the quality manager must identify and understand the requirements of the system needed to solve their certain problems and/or concerns before s/he can start to evaluate the bug tracking systems. Identifying and understanding these requirements will help him/her to build a list of features that s/he can use to guide his/her evaluations.

The following observation questions could help the quality manager to identify his/her bug tracking requirements:

• What are the different roles and responsibilities of the people who will use the system?
• What is your workflow for managing and resolving bugs? Identify the steps in the process,
  and determine who is responsible for each step.
• What information do you need to track for each bug?
• What reports and metrics do you need?
• Do you need to provide different levels of access to different users?

Further, the identified requirements for the system can be translated into a feature list. the feature list is the standard attributes or criteria of the system against which the quality of the bug tracking system to be measured or rated.

Below provides an example of a feature list that could be used to evaluate a bug tracking solution based on the identified requirements to achieve:

• Adaptability
• Change history
• Version control integration
• Customizable fields
• Ease of use
• E-mail notifications
• Reports
• Security
• Web-based client
• Workflow

The A Guide To Evaluating a Bug Tracking System By Stephen Blair, MetaQuest Software. The rest of this document provides tips and guidelines for evaluating these features. Hopefully these guidelines will help the quality manager choose a bug tracking system that meets his/her requirements.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=47.0

In this context, the measurements to track progress toward achieving the quality goals generally fall into two categories:

1. Perception Measures - These measures are of the customers’ perceptions of the organization (obtained, for example, from customer surveys, focus groups, vendor ratings, compliments and complaints).
2. Performance Indicators - These measures are the internal ones used by the organization in order to monitor, understand, predict and improve the performance of the organization and to predict perceptions of its external customers.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=44.0

A workflow can usually be described using formal or informal flow diagramming techniques, showing directed flows between processing steps. Single processing steps or components of a workflow can basically be defined by three parameters:

1. input description: the information, material and energy required to complete the step
2. transformation rules, algorithms, which may be carried out by associated human roles or machines, or a combination
3. output description: the information, material and energy produced by the step and provided as input to downstream steps.

Components can only be plugged together if the output of one previous (set of) component(s) is equal to the mandatory input requirements of the following component. Thus, the essential description of a component actually comprises only in- and output that are described fully in terms of data types and their meaning (semantics). The algorithms’ or rules’ description need only be included when there are several alternative ways to transform one type of input into one type of output - possibly with different accuracy, speed, etc..

Especially when the components are non-local services that are invoked remotely via a computer network, like Web services, additional descriptors like QoS, availability, etc. have to be considered, too.

Source: Wikipedia, the free encyclopedia

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=42.0

Below are some lists of quality reviews that typically are used to help build, measure quality, and prevent defects of work, product, service, and/or process deliverables.

Expert Review. Work, product, service, and/or process deliverables are reviewed by QA member who is considered have expert knowledge in the area to check the accuracy of content. This includes finding and correcting defects in the development of the process. Example: To ensure the information is accurate and well constructed prior to submission to project sponsor and client, the QA member needs to deliver Preliminary Business Case by performing Expert Review using the Template for Business Case and Approved Business Case for the Project.

Self-Checking Review. A self-checking review is usually the initial quality inspection for a task, and it may be the only one. The QA member who performs the task checks correctness, completeness, consistency, and conformance to quality standards and fulfillment of quality criteria.

Peer review. Co-workers carry out the peer review of work, product, service, and/or process structure to check quality, spread experience, and communicate ideas and approaches. They check the output of the task, make constructive suggestions, and take the opportunity to learn. Example: To review the final draft for completeness and construction, one needs to perform Peer Review of final draft.

Multi-person Review. A review carried out independently by several QA members to gain agreement between different stakeholders. Meeting or workshop is carried out to resolve differences and reach agreement.

Walk-through - A useful technique to validate both the content and structure of a deliverable, identify potential problems, uncover inconsistencies, find defects, and educate the audience. It encourages critical analysis and is therefore effective for design reviews. Thus, material should be circulated in advance. If particular participants have not done their homework, they should be excluded from this activity. Example: To review early draft for completeness, QA member needs to deliver Project Definition by performing Walk-through of early draft using the Template for Project Definition.

Workshop. Workshop brings stakeholders together with key developers and a professional facilitator to collectively define, analyze, or review solutions. They can be an effective way to build in and verify quality.

Formal review. The project manager or project team holds formal reviews with the project sponsor and client to obtain agreement on an issue or acceptance of work, product, service, and/or process. The contract sometimes specifies the scheduling and content of formal reviews. Typically, they are held on completion of a milestone. Example: To ensure the Business Case is in a fit state to be submitted to the Finance Review Committee, QA member needs to deliver Final Business Case by performing the Formal Inspection using the Template for Business Case.

Standard Audit. Carried out by QA member who is only focused on ensuring the deliverable meets a particular standard(s) and specification(s). That is, it focuses on compliance with the standard(s) and specification(s). It should be planned and implemented during each phase of the project.

Formal Inspection. A review of a deliverable by an inspector who would typically be external to the project team. The inspector captures statistics on suspected defects. It is a useful technique for use with documentation.

Process Review. A review of existing quality Processes in an organization that determines whether the existing quality processes are being followed and achieving the desired results, all necessary procedures and actions are being undertaken, and information is being recorded. Process Review is usually conducted by Project Office or Internal Audit who are independent from the project team. Moreover, it is appropriate to have processes reviewed for quality once the project is initially established. This may be useful to give the project sponsor and client a level of confidence in the team.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=27.0

Quality program is an operational activities that refer to the existing quality materials, procedures, tools, training, organization, and metrics that can be defined and used within an organization in achieving best practices characteristically with the following components:

1. Quality Materials - An artifacts used within an organization that detail how a particular aspect of the project must be undertaken to assist a QA team apply and improve quality in the project. Usually they are gathered and established in the framework of the quality initiative and lead to QA team activities improvement, such as:

• Adherence to relevant design, programming, documentation, security, and naming standards - there can be no deviation from Standards unless a formal variation process is undertaken, and approval granted;
• policies;
• templates;
• checklists;
• criteria; and
• guidelines.

Note it is also useful to have some representation from the receivers of these quality materials in order to ensure the QA team are not using jargon that makes it clear to the producers, but unclear to the receivers. This includes consulting any applicable client quality standards, templates, checklists, criteria, and guidelines; and incorporating them into the definition of quality materials.

2. Procedures - An outlined quality and/or design Control activities undertaken to help review and achieve quality of the project. Describe and establish how the project team will build these quality procedures into works, products, services, and processes. Use of best practice methods, techniques, and/or know-how steps for development, such as:

• document Control to control Project Documents at each Project Phase;
• define conditions and availability of required documentation;
• defining quality standards for the deliverables;
• design Waivers of requirements;
• configuration change control;
• change or problem reporting;
• define responsibilities;
• corrective actions;
• Quality Records;
• design changes;
• Nonconformance;
• risk management;
• Quality review;
• design review;
• sign-off; and
• others.

3. Training - The following activities may be necessary:

• Identifying skill needs;
• Specifying and designing any training requirements and strategies for the project team;
• Developing or identifying course materials;
• Integrating skill development, quality concepts, and motivational training; and
• Recording training needs as notes for training plan.

4. Tools - Support tools, such as:

• performance modeling;
• project planning;
• tracking; and
• others.

5. Organization - Clearly describe and assign the quality roles and responsibilities of all stakeholders for executing each element of the quality process, such as: Responsibility for gathering; and interpreting and reporting on measurements of effectiveness.

6. Metrics - Statistics or any status assessment in the project definition that demonstrate measurements and indicators of evidence are captured and established during the various activities undertaken as part of “Quality Assurance” to measure the progress and effectiveness of quality improvement activities. This includes identifying areas where quality improvements can be made. It is used to establish the baseline.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=24.0

The following are some general quality process guidelines:

1. Ensure that the quality process reflects the project sponsor and client’s requirements. The project sponsor and client may mandate that you adopt certain standards and tools. If you do not find them sufficient to achieve the level of quality defined for the project, augment the standards and tools necessary. You may tell your project sponsor and/or client that the resources are not sufficient enough to achieve the level of quality you believe necessary for the project. Do some research for defining the supporting details.
2. If you are using subcontractors or vendors, make sure they understand the quality process and are committed to uphold it. Include reviews of their works. products, services, and/or processes. If the client requires you to certify that subcontractor processes meet certain requirements then record such requirements, and the corresponding reviews in the quality process.
3. Make sure that all team members understand the quality process and know that you expect them to participate in and support it.
4. If the quality process is extensive or complex, you may need to run training programs.
5. Make sure team members understand how their work contributes to achieving the quality process and commit to providing them with feedback about their performance in this area.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=23.0