1、Why is it often hard for organizations to get serious about quality assurance? Solving problems is a high-visibility process; preventing problems is low-visibility. This is illustrated by an old parable:In ancient China there was a family of healers, one of whom was known throughout the land and emp
2、loyed as a physician to a great lord. The physician was asked which of his family was the most skillful healer. He replied, “I tend to the sick and dying with drastic and dramatic treatments, and on occasion someone is cured and my name gets out among the lords.“My elder brother cures sickness when
3、it just begins to take root, and his skills are known among the local peasants and neighbors.“ “My eldest brother is able to sense the spirit of sickness and eradicate it before it takes form. His name is unknown outside our home.“ This is a problem in any business, but its a particularly difficult
4、problem in the software industry. Software quality problems are often not as readily apparent as they might be in the case of an industry with more physical products, such as auto manufacturing or home construction. Additionally, many organizations are able to determine who is skilled at fixing prob
5、lems, and then reward such people. However, determining who has a talent for preventing problems in the first place, and figuring out how to incentivize such behavior, is a significant challenge. Return to top of this pages FAQ list Who is responsible for risk management? Risk management means the a
6、ctions taken to avoid things going wrong on a software development project, things that might negatively impact the quality, timeliness, or cost of a project. This is, of course, a shared responsibility among everyone involved in a project. However, there needs to be a buck stops here person who can
7、 consider the relevant tradeoffs when decisions are required, and who can ensure that everyone is handling their risk management responsibilities. It is not unusual for the term risk management to never come up at all in a software organization or project. If it does come up, its often assumed to be
8、 the responsibility of QA or test personnel. Or there may be a risks or issues section of a project, QA, or test plan, and its assumed that this means that risk management has taken place. The issues here are similar to those for the LFAQ question “Who should decide when software is ready to be rele
9、ased?“ Its generally NOT a good idea for a test lead, test manager, or QA manager to be the buck stops here person for risk management. Typically QA/Test personnel or managers are not managers of developers, analysts, designers and many other project personnel, and so it would be difficult for them
10、to ensure that everyone on a project is handling their risk management responsibilities. Additionally, knowledge of all the considerations that go into risk management mitigation and tradeoff decisions is rarely the province of QA/Test personnel or managers. Based on these factors, the project manag
11、er is usually the most appropriate buck stops here risk management person. QA/Test personnel can, however, provide input to the project manager. Such input could include analysis of quality-related risks, risk monitoring, process adherence reporting, defect reporting, and other information. Return t
12、o top of this pages FAQ list Who should decide when software is ready to be released? In many projects this depends on the release criteria for the software. Such criteria are often in turn based on the decision to end testing, discussed in FAQ #2 item “How can it be known when to stop testing?“ Unf
13、ortunately, for any but the simplest software projects, it is nearly impossible to adequately specify useful criteria without a significant amount of assumptions and subjectivity. For example, if the release criteria is based on passing a certain set of tests, there is likely an assumption that the
14、tests have adequately addressed all appropriate software risks. For most software projects, this would of course be impossible without enormous expense, so this assumption would be a large leap of faith. Additionally, since most software projects involve a balance of quality, timeliness, and cost, t
15、esting alone cannot address how to balance all three of these competing factors when release decisions are needed. A typical approach is for a lead tester or QA or Test manager to be the release decision maker. This again involves significant assumptions - such as an assumption that the test manager
16、 understands the spectrum of considerations that are important in determining whether software quality is sufficient for release, or the assumption that quality does not have to be balanced with timeliness and cost. In many organizations, sufficient quality is not well defined, is extremely subjecti
17、ve, may have never been usefully discussed, or may vary from project to project or even from day to day. Release criteria considerations can include deadlines, sales goals, business/market/competitive considerations, business segment quality norms, legal requirements, technical and programming consi
18、derations, end-user expectations, internal budgets, impacts on other organization projects or goals, and a variety of other factors. Knowledge of all these factors is often shared among a number of personnel in a large organization, such as the project manager, director, customer service manager, te
19、chnical lead or manager, marketing manager, QA manager, etc. In smaller organizations or projects it may be appropriate for one person to be knowledgeable in all these areas, but that person is typically a project manager, not a test lead or QA manager. For these reasons, its generally not a good id
20、ea for a test lead, test manager, or QA manager to decide when software is ready to be released. Their responsibility should be to provide input to the appropriate person or group that makes a release decision. For small organizations and projects that person could be a product manager, a project ma
21、nager, or similar manager. For larger organizations and projects, release decisions might be made by a committee of personnel with sufficient collective knowledge of the relevant considerations. Return to top of this pages FAQ list What can be done if requirements are changing continuously? This is
22、a common problem for organizations where there are expectations that requirements can be pre-determined and remain stable. If these expectations are reasonable, here are some approaches: Work with the projects stakeholders early on to understand how requirements might change so that alternate test p
23、lans and strategies can be worked out in advance, if possible. Its helpful if the applications initial design allows for some adaptability so that later changes do not require redoing the application from scratch. If the code is well-commented and well-documented this makes changes easier for the de
24、velopers. Use some type of rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes. The projects initial schedule should allow for some extra time commensurate with the possibility of changes. Try to move new requirements to a Phase 2 version of an
25、application, while using the original requirements for the Phase 1 version. Negotiate to allow only easily-implemented new requirements into the project, while moving more difficult new requirements into future versions of the application. Be sure that customers and management understand the schedul
26、ing impacts, inherent risks, and costs of significant requirements changes. Then let management or the customers (not the developers or testers) decide if the changes are warranted - after all, thats their job. Balance the effort put into setting up automated testing with the expected effort require
27、d to refactor them to deal with changes. Try to design some flexibility into automated test scripts. Focus initial automated testing on application aspects that are most likely to remain unchanged. Devote appropriate effort to risk analysis of changes to minimize regression testing needs. Design som
28、e flexibility into test cases (this is not easily done; the best bet might be to minimize the detail in the test cases, or set up only higher-level generic-type test plans) Focus less on detailed test plans and test cases and more on ad hoc testing (with an understanding of the added risk that this
29、entails). If this is a continuing problem, and the expectation that requirements can be pre-determined and remain stable is NOT reasonable, it may be a good idea to figure out why the expectations are not aligned with reality, and to refactor an organizations or projects software development process
30、 to take this into account. It may be appropriate to consider agile development approaches. Also see What is Extreme Programming and whats it got to do with testing? in the S FAQ #2. Return to top of this pages FAQ list What if the application has functionality that wasnt in the requirements? It may
31、 take serious effort to determine if an application has significant unexpected or hidden functionality, and it could indicate deeper problems in the software development process. If the functionality isnt necessary to the purpose of the application, it should be removed, as it may have unknown impac
32、ts or dependencies that were not taken into account by the designer or the customer. (If the functionality is minor and low risk then no action may be necessary.) If not removed, information will be needed to determine risks and to determine any added testing needs or regression testing needs. Manag
33、ement should be made aware of any significant added risks as a result of the unexpected functionality. This problem is a standard aspect of projects that include COTS (Commercial Off-The-Shelf) software or modified COTS software. The COTS part of the project will typically have a large amount of fun
34、ctionality that is not included in project requirements, or may be simply undetermined. Depending on the situation, it may be appropriate to perform in-depth analysis of the COTS software and work closely with the end user to determine which pre-existing COTS functionality is important and which fun
35、ctionality may interact with or be affected by the non-COTS aspects of the project. A significant regression testing effort may be needed (again, depending on the situation), and automated regression testing may be useful. Return to top of this pages FAQ list How can Software QA processes be impleme
36、nted without reducing productivity? By implementing QA processes slowly over time, using consensus to reach agreement on processes, focusing on processes that align tightly with organizational goals, and adjusting/experimenting/refactoring as an organization matures, productivity can be improved ins
37、tead of stifled. Problem prevention will lessen the need for problem detection, panics and burn-out will decrease, and there will be improved focus and less wasted effort. At the same time, attempts should be made to keep processes simple and efficient, avoid a Process Police mentality, minimize pap
38、erwork, promote computer-based processes and automated tracking and reporting, minimize time required in meetings, and promote training as part of the QA process. However, no one - especially talented technical types - likes rules or bureaucracy, and in the short run things may slow down a bit. A typical sc
