Software Quality Assurance

Transcription

1 Sftware Quality Assurance Is it the same as Testing? Teji Chpra, Senir Test Cnsultant Planit Sftware Testing Abstract This paper attempts t dispel sme cmmn miscnceptins regarding the rles f Testing and Sftware Quality Assurance (SQA) by referring t existing industry infrmatin and extensive prfessinal experience. It prvides insights int the differences between these terms, while als utlining challenges and prviding recmmendatins fr successful SQA teams. Planit Sftware Testing in any frm r by any means, electrnic, mechanical, recrding, phtcpying, r therwise, withut the express written permissin f Planit Sftware Testing. 1

2 Starting pint The terms Testing and Sftware Quality Assurance (SQA) are ften used almst interchangeably in the IT industry with testing prfessinals ften classed as quality assurance prfessinals. S, are these terms the same? Althugh bth have quality as their verall bjective, a fundamental difference between the tw is that testing is perfrmed after a prduct has been built, r in the case f static testing, after a dcument has been written. In cntrast, quality assurance cnsists f activities t ensure that quality will be built int the prduct. T appreciate the differences between Testing and SQA further, it is imprtant t first understand the clsely related cncepts, Quality Cntrl (QC) and Quality Assurance (QA). Quality cntrl ISO9000 defines Quality Cntrl as a part f Quality Management fcussed n fulfilling quality requirements. Quality Cntrl is a set f activities designed t evaluate whether a develped prduct (prject dcument, develped system etc.) meets custmer requirements. It ensures that delivered prducts are checked fr quality and determines hw well it is built. Its fcus is t find defects and t ensure that they are crrected. Quality assurance ISO9000 defines Quality Assurance as a part f quality management fcused n prviding cnfidence that quality requirements will be fulfilled. The gal f QA is t prvide assurance that a prduct will meet the custmer s quality expectatins. It cnsists f activities designed t ensure that quality will be built int the prduct. These activities usually precede develpment f the prduct and cntinue while the develpment is in prgress. It is a QA respnsibility t develp and implement prcesses and standards t imprve the develpment life cycle and t make sure that these prcedures are fllwed. The fcus f QA is defect preventin, prcesses and cntinual imprvement f these prcesses. While QA is a practive activity, QC is reactive. Examples f QA activities include establishing standards and prcesses, quality audits, selectin f tls and training. The relatinship between QA and QC is depicted in Figure 2 belw. Quality Cntrl Testing Quality Assurance QC is the respnsibility f the prject team. Testing frms an integral part f Quality Cntrl, as displayed in Figure 1. Hwever, nt all QC activities are testing activities. Cde inspectins, technical reviews and stage gates are ther examples f Quality Cntrl activities. Quality Cntrl Testing FIGURE 2 Hw d test and QA team respnsibilities differ? Test teams perfrm test basis dcument reviews, test planning, test analysis and design, test validatin and verificatin, and test reprting thrugh the different test levels. In cntrast, SQA teams perfrm the fllwing functins: FIGURE 1 Implement rganisatinal quality plicies, standards and prcesses in any frm r by any means, electrnic, mechanical, recrding, phtcpying, r therwise, withut the express written permissin f Planit Sftware Testing. 2

3 Assist prjects with preparing sftware quality assurance r prject quality plans Assure that prject prcesses cnfrm t quality plans Cnduct regular audits f prject prducts and prcesses, and present regular assessments t senir management Escalate situatins where there are deviatins frm guidelines r standards Assure that: Independent reviews are cnducted Change cntrl prcedures fr prjects are in place Cnfiguratin management prcedures fr prjects are in place Prcedures are in place fr identificatin and management f Risks There are retrspectives r lessns learned prcesses planned and cnducted Prvide assurance thrugh the system develpment life cycle Cnduct cntinuus imprvements t QA prcess and guidelines based n lessns learned Althugh these attributes are labelled as QA team respnsibilities, it shuld be nted that this des nt mean that the QA team will develp these artefacts, but rather assure they are prduced in a manner that is fit fr purpse. As part f their assurance rle, QA teams may als review requirement traceability matrices, prject dcument samples, sftware cnfiguratin management activities, design, cde etc. Hw d test and SQA planning and dcumentatin differ? Test teams prepare test strategies and plans based n test basis dcuments such as business requirements and slutin design dcuments. These test planning dcuments cver test prcesses acrss the varius planned test levels including details such as the test apprach, entry and exit criteria between levels, detailed test schedules, envirnment requirements, defect management, test management and reprting. In cntrast, sftware quality assurance r quality plans deal with a brader set f activities acrss the life cycle. This ties in with prject management methdlgies such as Prince2 that encurage the use f prject quality plans and quality lgs that are develped early in the life cycle, when initiating a prject. A typical Prject Quality Plan includes custmer quality expectatins, acceptance criteria, quality respnsibilities, planned quality cntrl and audit prcesses, stage gates, cnfiguratin management plans and change management prcedures. Quality plans fr prjects use the rganisatin s quality plicies, standards r guidelines as a basis, where they exist. Mnitring f the Prject Quality Plan during the prject is dne by cntinually updating results f planned quality activities in the Quality Lg. There is an verlap between Risk Management and Quality Management and therefre, the Risk Register can play an imprtant input int the preparatin f Quality Plans. Wh shuld perfrm the QA functin in an rganisatin? The need fr a sftware quality assurance team grws with the rganisatin s size and its level f quality plicies. Where such a team is required, it is essential that the QA functin remains independent frm prject and peratinal teams. Their reprting line, hwever, must prvide them with strng supprt, as and when required. Prject management methdlgies, fr example, Prince2 are cnsistent with this aspect f retaining independence f the quality assurance functin. Prince2 recgnises three interests that must be represented n the Prject Bard at all times Business, User and Supplier, and ges n t recmmend prject assurance rles that align t each f these interests. Imprtantly, Prince 2 recgnises that all f these prject assurance rles must be independent f the prject manager. Prject Bard members may use members f the independent QA team t mnitr quality aspects f their individual interest. Sme rganisatins have the QA functin embedded within their enterprise Prject Management Office (PMO) departments. This meets the independence criteria, hwever, rganisatins fllwing this mdel must ensure that this team has trained and/r specialised quality assurance analysts. in any frm r by any means, electrnic, mechanical, recrding, phtcpying, r therwise, withut the express written permissin f Planit Sftware Testing. 3

4 Observatins and recmmendatins fr successful SQA teams While assuming respnsibility fr sftware quality assurance, I experienced a number f challenges. Sme f these challenges are utlined belw tgether with learnings and recmmendatins fr rganisatins cnsidering creating a SQA team. Independence As utlined abve, t be successful, SQA teams need t be independent frm prject and delivery teams. This prvides the team with the ability t cnduct bjective assessment f prjects. A questin that arises is whether the Testing and SQA functin shuld reside in the same team. Althugh this may wrk well in smaller rganisatins, in my experience, this has the disadvantage f creating a pssible cnflict f interest when mnitring testing activities. It als tends t emphasise the miscnceptin that testing and SQA are essentially the same. An ptin t reslve this is t embed the SQA functin within the enterprise PMO, r depending upn the size and quality plicies f the rganisatin, have a separate team reprting t a senir manager wh is respnsible fr the functin. Prject team relatinships If quality assurance analysts are t prcess-riented, insisting n prcesses r dcumentatin that may nt add much value, it culd strain relatinships with prject managers. Fr example, the level f discipline impsed n smaller and lwer risk prjects wuld be different frm that fr cmplex, higher risk nes. There may als be differences based n the methdlgy used, fr example, Waterfall r Agile. SQA teams wuld find it much easier t wrk with prject teams if they keep in mind the fit fr purpse principle. Prviding guidance and assistance t prject teams, frms a basis fr maintaining gd relatinships, which is an imprtant aspect f successful QA teams. Senir management supprt I have managed a SQA team that was strngly supprted by senir management and als ne that had nly lukewarm supprt. There was a wrld f difference between the tw experiences. With the latter, fr example, escalatins were nt dealt with in time and prblems were carried thrugh the life cycle leading t prductin prblems and higher than anticipated csts. In such instances, it is essential that SQA managers have pen discussins with the leadership team. SQA teams can nly ensure adherence t prcesses and rganisatinal plicies if there is strng and cnsistent leadership team supprt. Emplying the right peple Anther ingredient fr successful SQA teams is emplying the right staff. Peple with experience in the system develpment life cycle r sftware engineering make gd candidates fr QA rles. Sme training in ISO and/r CMMI principles wuld supplement knwledge f smene with a prir develpment backgrund and keen interest in quality principles. Checklists Standard checklists are a useful mechanism t cnduct reviews r audits f prjects, particularly if they are develped in line with the phases f the develpment life cycle. Fr example, in the Design phase a checklist questin culd be Is there traceability between design and requirement elements? T avid frustratin frm prject managers, I learnt that it is imprtant t ensure early stakehlder engagement t gain their feedback when a prject is initiated, and when changes are prpsed t checklists. Cmmunicatin and reprting Althugh, regular reprting t senir management is imprtant, develping the right templates and metrics that prvide the senir managers with what they require ensures that these reprts are given due cnsideratin. This is best accmplished by cnducting meetings with relevant senir management prviding them with ptins and btaining their feedback. SQA teams need t cntinually get apprval fr changes t quality prcesses and standards and ensure effective cmmunicatin with stakehlders. Cntinuus imprvement Lessns learned frm prjects prvide a SQA team with a basis fr evaluating its quality prcesses and guidelines, in any frm r by any means, electrnic, mechanical, recrding, phtcpying, r therwise, withut the express written permissin f Planit Sftware Testing. 4

5 and incrprating cntinual imprvements. We learned several lessns that required making changes t ur prcedures. This included develping checklists, flexibility, maintaining gd stakehlder relatinships and making imprvements t ur regular management reprts. Higher quality prducts Cnsistency in prcesses used fr delivery Cntinued imprvement f rganisatin prcesses Lwer verall csts f delivery Increased applicatin supprt dcumentatin Since cntinuus imprvements may als require changes t the System Develpment Methdlgy, it is recmmended that a SQA team maintains an IT department s develpment methdlgy. Benefits Disadvantages Upfrnt csts in staffing f quality assurance analysts Increased prcesses that culd generate frustratin in sme staff A successful SQA team can add cnsiderable value fr an rganisatin. Sme f these benefits include, Cnclusin Cmparing the differences in activities and respnsibilities between Quality Cntrl and Quality Assurance prvides us with a gd appreciatin f these different terms. QC validates that a specific deliverable meets standards and specificatins. In cntrast, QA is a brad functin cvering practive planning and mnitring thrughut the develpment life cycle. Testing n the ther hand, frms an integral part f QC. Fr an rganisatin t effectively implement Quality Management prcesses, these streams must wrk in tandem. It is recmmended that rganisatins carefully cnsider the varius pssible challenges and have apprpriate plans in place prir t embarking n quality management prcesses. Abut the Authr Teji Chpra is a Senir Test Cnsultant with Planit Sftware Testing. He has extensive IT experience in cmmercial and gvernment sectrs that include rles in test management, sftware quality assurance and prject management in any frm r by any means, electrnic, mechanical, recrding, phtcpying, r therwise, withut the express written permissin f Planit Sftware Testing. 5