Article: (PPQA) MEASURING SOFTWARE PROJECT HEALTH DURING QUALIFICATION PHASE IN 4 STEPS By Eric Mariacher

www.demix.org - Abstract
"Modern" software development companies use a change management methodology and an associated tool to
manage change requests or bugs between developers and testers.
In CMMI V1.2, this is addressed in Process and Product Quality Assurance (PPQA) process area, specifically to “SP 2.1 Communicate and Ensure Resolution of Noncompliance Issues” where typical work products are “Evaluation reports” and “Quality trends”.
To get a feeling of where a software project is heading in terms of schedule, quality and performance, while in testing phase, an obvious practice is to look at how many bugs are opened. But what you get is a snapshot, you don't know if the project is in a stabilization phase or if it is out of control.
I am going to concretely present a 4 steps method of gathering, presenting and interpreting data extracted from any bug tracking tool.

Article: (PPQA) Who’s Watching the Hen House? by Ron Starbuck

https://seir.sei.cmu.edu - Who’s Watching the Hen House?
Abstract
The answer to this question is a snap if your using the Software Engineering Institute’s (SEI) Software Capability Maturity Model® (SW-CMM) for software development. Software Configuration Management (SCM) may be the keeper of the keys to the product’s configuration, but it’s the Software Quality Assurance (SQA) Key Process Area (KPA) who ensures the approved, right products get in the Hen House and are maintained thereafter. Unfortunately, not every organization’s interpretation of the SW-CMM includes this not so obvious practice in their implementation. Sometimes even just getting SQA into place for them requires overcoming the misunderstanding that it polices quality into products. The purpose of this article is to examine how SQA ensures the software products developed are the right ones and how it interacts with the SCM Key Process Area to capture and maintain their integrity correctly in the Hen House.

Article: (PPQA) AN EVALUATION OF THE REINSPECTION DECISION POLICIES FOR SOFTWARE CODE INSPECTIONS by M.Sc. Serkan NALBANT

https://seir.sei.cmu.edu - 1. Introduction
Today, realization of software generally requires completion of complex projects which are deemed as successful if delivered on time, within budget and with high quality. The delivery of such software is achieved by eliminating the defects injected in various phases of the software development life cycle, such as requirements analysis, software design, coding. Software organizations employ numerous techniques to remove the defects from the software, thus preventing their propagation to the user. One of these techniques is peer review. In the scope of peer review a software artifact is examined by the related project personnel (other than the software author) with the aim of pointing out to defects and improvements.
 
 

Article: (PPQA) AUTOMATED SOFTWARE TESTING TOOLS – AN OVERVIEW by Jimmy L. Miller

https://seir.sei.cmu.edu- INTRODUCTION
Why automate? Writing and maintaining automated test scripts can be expensive. If test scripts are to be reused from build to build of an application, the test system must be designed properly and the scripts themselves may require major modifications after the application’s GUIs are captured and replayed. On the other hand, test automation can easily pay for itself given the right conditions. If a wisely chosen software testing tool is used in conjunction with a wellplanned test methodology and a dedicated team of test writers and maintainers, testing releases of software from a developer could eventually cost virtually nothing.

(Read more)

Presentation: (PPQA) Is There Such a Thing as a Dumb Question?The art and science of effective PPQA  by Mark Janning

https://seir.sei.cmu.edu - Download