SQA Engineer Interview Preparation Guide

Download PDF

There are some interesting challenges for SQA role & activities in my organization. This is with reference to Software Industry.

Basically there is at a gross level lack of compliance to Quality Management system (This is more to do with a mindset issue & ego, high esteem perspective, 'I can delivery without QMS')

Even the people in escalation path just listen, but do not take much action.

SQA is supposed to co-ordinate reviews (tech and management) However the fact is that practitioners preciously know when a review is required as they have higher and bigger stake in the project and they do it exactly when required irrespective of what SQA says. SQA is then merely a coordinator.

If SQA recommends a practice, no one follows (even though it is understood that SQA is a customer advocate), when the same thing is asked by customer, without fail everyone follows!

I find something wrong with the way SQA Roles/Responsibilities are defined & implemented in the organization I work with.

In one of the CMM Books I came across a Disadvantage of SQA concept that was indicative of organizations would not want to assign their best technical talent into such roles.

GET method is mainly used when the client requests are made
to the server. This is like a query made to the server.

POST method is used to submit a set of data to the server.

We have defined middleware and firmware and understand that they are different, yet have many characteristics in common
when it comes to testing. The discussion of test strategy for these types of software will include both middleware
and firmware, and can be extended to test any software which is not accessed by a user interface.

Early testing will multiply the testing effectiveness of any software application, regardless of technology. However, in the world of middleware and firmware early testing is most critical because finding defects at later stages carries a higher penalty of rework. This is due to the extent of integration with hardware and other software.

The problem with early testing in this environment is that with so many integration dependencies, how does someone
create test harnesses and stubs that allow for an accurate test? Manually, the job is possible, but can be
overwhelming when there are many interfaces involved. If you are developing in a language that has tool support for
structural test case design and testing, you may find that the job can be very easy. Specifically, for C++ and Java,
Parasoft has a great toolset to design and perform structural tests, with a feature to automatically create a test harness and test stubs.

Developer testing is essential to avoid high rework costs. To the testers, the software is a black box. Only the developers have the view and access to the code to test all conditions. In addition, not only are functional cases at stake, but also the structural tests for memory boundary violations and memory leaks.

My experience is that developers can test software if the have a good process to follow, standards to show what is expected of them in terms of testing, and a way to hold developers accountable for the quality of their work. Management must also be making the message loud and clear that testing is part of the job and that quality is a shared responsibility between developers, testers, QA, and management.

In the object-oriented view of testing, tests are isolated at a smaller scope, yet can have high complexity due to the interfaces with other objects. The object-oriented view of testing must be able to deal with classes, methods, and attributes and to validate those at a high level of coverage.

In Shel Siegel's book, "Object-Oriented Software Testing," he describes the Hierarchical approach to O-O testing.

The hierarchical approach is at the heart of the object-oriented testing system. This test approach uses and builds upon several well-understood testing techniques, tying them together into a comprehensive testing system. The hierarchical approach leverages the fact that "everything is a system." It defines and applies testing standards for several levels of software component: objects, classes, foundation components, and systems. The hierarchical approach designates as SAFE those components that meet the testing standards for that kind of component. Once you designate a component as SAFE, you can integrate it with other SAFE components to produce the next-level component. In turn, you test this component to the level of safety
associated with the component level it represents. SAFE is always a relative state. It depends entirely on the standards you choose to enforce, your application, your attitude toward risk, and the specific risks and risk management practices you adopt in your project. The hierarchical approach provides guidelines for minimum safety; you decide what is right for you.

A quality management system in accordance with ISO 9001:2000will provide your organization with a set of processes thatensure a common sense approach to the management of yourorganization.

The system should ensure consistency and improvement ofworking practices, which in turn should provide products andservices that meet customer's requirements. ISO 9000 is themost commonly used international standard that provides aframework for an effective quality management system.

The difference is that the CMM is a way to communicate capabilities, and ISO is a way to communicate the process. They are not necessarily incompatible.

The Capability Maturity Model is a very specific way of classifying an organization's software development methods. In a certain way, it tells how the quality of its softwaredesigns is likely to be repeated.

ISO-9000 procedures describe a (possibly) definite development process but gives no indication of the likely quality of the designs or whether multiple software efforts are likely to produce software of similar quality.