Embed Doc
Copy Link
Readcast
Collections

CommentGo Back

Download

What is 'Software Quality Assurance'?

Software QA involves the entire software development PROCESS - monitoring andimproving the process, making sure that any agreed-upon standards and procedures arefollowed, and ensuring that problems are found and dealt with. It is oriented to'prevention'.

What is 'Software Testing'?

Testing involves operation of a system or application under controlled conditions andevaluating the results (eg, 'if the user is in interface A of the application while usinghardware B, and does C, then D should happen'). The controlled conditions shouldinclude both normal and abnormal conditions. Testing should intentionally attempt tomake things go wrong to determine if things happen when they shouldn't or things don'thappen when they should. It is oriented to 'detection'.Organizations vary considerably in how they assign responsibility for QA and testing.Sometimes they're the combined responsibility of one group or individual. Also commonare project teams that include a mix of testers and developers who work closely together,with overall QA processes monitored by project managers. It will depend on what bestfits an organization's size and business structure.

Does every software project need testers?

While all projects will benefit from testing, some projects may not require independenttest staff to succeed.Which projects may not need independent test staff? The answer depends on the size andcontext of the project, the risks, the development methodology, the skill and experienceof the developers, and other factors. For instance, if the project is a short-term, small, lowrisk project, with highly experienced programmers utilizing thorough unit testing or test-first development, then test engineers may not be required for the project to succeed.In some cases an IT organization may be too small or new to have a testing staff even if the situation calls for it. In these circumstances it may be appropriate to instead usecontractors or outsourcing, or adjust the project management and development approach(by switching to more senior developers and agile test-first development, for example).Inexperienced managers sometimes gamble on the success of a project by skippingthorough testing or having programmers do post-development functional testing of their own work, a decidedly high risk gamble.For non-trivial-size projects or projects with non-trivial risks, a testing staff is usuallynecessary. As in any business, the use of personnel with specialized skills enhances anorganization's ability to be successful in large, complex, or difficult tasks. It allows for both a) deeper and stronger skills and b) the contribution of differing perspectives. For

example, programmers typically have the perspective of 'what are the technical issues inmaking this functionality work?'. A test engineer typically has the perspective of 'whatmight go wrong with this functionality, and how can we ensure it meets expectations?'.Technical people who can be highly effective in approaching tasks from both of those perspectives are rare, which is why, sooner or later, organizations bring in test specialists.

Why does software have bugs?

•

miscommunication or no communication - as to specifics of what an applicationshould or shouldn't do (the application's requirements).

•

software complexity - the complexity of current software applications can bedifficult to comprehend for anyone without experience in modern-day softwaredevelopment. Multi-tiered applications, client-server and distributed applications,data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/systemcomplexity.

•

programming errors - programmers, like anyone else, can make mistakes.

•

changing requirements (whether documented or undocumented) - the end-user may not understand the effects of changes, or may understand and request themanyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardwarerequirements that may be affected, etc. If there are many minor changes or anymajor changes, known and unknown dependencies among parts of the project arelikely to interact and cause problems, and the complexity of coordinating changesmay result in errors. Enthusiasm of engineering staff may be affected. In somefast-changing business environments, continuously modified requirements may bea fact of life. In this case, management must understand the resulting risks, andQA and test engineers must adapt and plan for continuous extensive testing tokeep the inevitable bugs from running out of control

•

time pressures - scheduling of software projects is difficult at best, often requiringa lot of guesswork. When deadlines loom and the crunch comes, mistakes will bemade.

•

egos - people prefer to say things like:

'no problem''piece of cake''I can whip that out in a few hours''it should be easy to update that old code'instead of:'that adds a lot of complexity and we could end upmaking a lot of mistakes''we have no idea if we can do that; we'll wing it''I can't estimate how long it will take, until Itake a close look at it''we can't figure out what that old spaghetti codedid in the first place'

If there are too many unrealistic 'no problem's', theresult is bugs.

•

poorly documented code - it's tough to maintain and modify code that is badlywritten or poorly documented; the result is bugs. In many organizationsmanagement provides no incentive for programmers to document their code or write clear, understandable, maintainable code. In fact, it's usually the opposite:they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read').

•

software development tools - visual tools, class libraries, compilers, scriptingtools, etc. often introduce their own bugs or are poorly documented, resulting inadded bugs.

How can new Software QA processes be introduced in an existing organization?

•

A lot depends on the size of the organization and the risks involved. For largeorganizations with high-risk (in terms of lives or property) projects, seriousmanagement buy-in is required and a formalized QA process is necessary.

•

Where the risk is lower, management and organizational buy-in and QAimplementation may be a slower, step-at-a-time process. QA processes should be balanced with productivity so as to keep bureaucracy from getting out of hand.

•

For small groups or projects, a more ad-hoc process may be appropriate,depending on the type of customers and projects. A lot will depend on team leadsor managers, feedback to developers, and ensuring adequate communicationsamong customers, managers, developers, and testers.

•

The most value for effort will often be in (a) requirements management processes,with a goal of clear, complete, testable requirement specifications embodied inrequirements or design documentation, or in 'agile'-type environments extensivecontinuous coordination with end-users, (b) design inspections and codeinspections, and (c) post-mortems/retrospectives.

•

Other possibilities include incremental self-managed team approaches such as'Kaizen' methods of continuous process improvement, the Deming-ShewhartPlan-Do-Check-Act cycle, and others.

What is verification? validation?

Verification typically involves reviews and meetings to evaluate documents, plans, code,requirements, and specifications. This can be done with checklists, issues lists,walkthroughs, and inspection meetings. Validation typically involves actual testing andtakes place after verifications are completed. The term 'IV & V' refers to IndependentVerification and Validation.

What is a 'walkthrough'?

A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.