Get Certified: Proven Methods to Pass the Software Certifications CSQA Exam

There are four main testing stages in a structured software development process. They are:

Unit Testing

These tests demonstrate that a single program, module, or unit of code function as designed. For example, observing the result when pressing a function key to complete an action. Tested units are ready for testing with other system components such as other software units, hardware, documentation, or users.

Integration Testing

These tests are conducted on tasks that involve more than one application or database, or on related programs, modules, or units of code, to validate that multiple parts of the system interact according to the system design. Each integrated portion of the system is then ready for testing with other parts of the system.

System Testing

These tests simulate operation of the entire system and confirm that it runs correctly. Upon completion, the validated system requirements result in a tested system based on the specification developed or purchased.

User Acceptance Testing

This real-world test is the most important to the business, and it cannot be conducted in isolation. Internal staff, customers, vendor, or other users interact with the system to ensure that it will function as desired regardless of the system requirements. The result is a tested system based on user needs.

If an organization is not ready, and also lacks the sales skills to convince the management group, the probability of success is so low that it is best not to bother with implementation at this time. A ready organization with good salesmanship can take care of itself. The other scenarios present different challenges. Organizations that are not ready, but have the salesmanship, are referred to as

“Challenge 1.” Organizations that are ready, but lack the salesmanship, are referred to as

“Challenge 2.” Each challenge is analyzed separately.

Challenge 1

The solution is to get ready. To get ready, an organization needs the following:

The presence of a competent, trained staff that is capable of performing quality work when building and maintaining systems. Additionally, there must be backup for these individuals. In a moderate-size organization, quality initiatives might be assigned to one person. With the substantial effort to get it going, it can be traumatic if that individual becomes promoted or should leave.

A good IT management team that is capable of setting up the quality function, monitoring it, and making it work. The existence of good management tools, especially project management and systems development methodologies that spell out what to do when,and are specific about where the quality review functions belong in the development cycle and in maintenance.

A limit on the number of internal improvement projects to be done at once.

Good credibility. If there has been a history of not doing things that were promised it may be premature to initiate a quality function until a track record of satisfying promises has been accomplished.

To be mentally prepared for the length of time (measured in months and years, not weeks) to get a new and important function like this into operation and stabilized.

Challenge 2

The process of selling a new quality function is similar to the process of selling anything associated with internally improving an organization. Some items to consider include the following:

To be an issue of real value to the total organization, the quality function must be heartfelt to the salesperson. Without a very strong belief in quality, no one can sell it.

When the proposition is taken to the management group, it is essential for the salesperson to speak the language of the listener.

Management values their time, which places a burden on the presenter to think the proposition through, present the case, ask for a clear decision, and then leave the room when receiving an affirmative answer. Most executive managers will buy into any well thought-out plan that has the necessary controls built in and where they can conceptually see the logic of how the pieces fit together.

It is essential to present a realistic picture. Extreme benefits should not be promised, nor should the salesperson claim that problems could be solved in a very short period of time. Most executive managers are astute enough to see through the unrealistic claims rapidly, weakening the total case.

There is an important principle of getting some things accepted, which is referred to as the Mafia Rule. This is an offer that management can't refuse. Offer that the management group can make all of the decisions on quality issues, while the proponents of the quality function will handle the administrative details.

Ideas are typically accepted only after the person presenting the ideas is accepted. If the salesperson’s personal relationship with management is weak, some "fencemending" should be done before asking management for a major decision.

Using outsiders can sometimes help in getting the right decision. The simple process of paying for advice somehow makes that advice seem more important.

Verification ensures that the system (software, hardware, documentation, and personnel) complies with an organization’s standards and processes, relying on review of non-executable methods. Validation physically ensures that the system operates according to plan by executing the system functions through a series of tests that can be observed and evaluated. Verification answers the question, “Did we build the right system?” while validation addresses, “Did we build the system right?”

Keep in mind that verification and validation techniques can be applied to every element of the computerized system. You’ll find these techniques in publications dealing with the design and implementation of user manuals and training courses, as well as in industry publications.

1

Just-in-time principles can be used in IT in the following ways:

Systems development and maintenance tasks become driven when the user of an internal or external product or service needs them. Programs would not be developed before they are needed for test or production.

Systems analysts and programmers would not be given information and documents to store until they need them.

Internal information processes would be designed so individuals can move from job to job with minimal delay. For example, programmers should be able to stop working on one program and start another within the JIT ten-minute turnover standard.

Assure Completeness of Needs Requirements

This step determines whether you have adequately defined your requirements. Your requirements should be defined in terms of the following two categories of outputs:

1. Output Products and Output Reports -Output products and output reports are specific documents that you want produced by the computer system. In many instances, such as the previous payroll check example, the style and format of these output products is important. This does not mean that the specific location of the check has to be defined but, rather, the categories of information to be included on the check. Computer-produced reports may also be important for tax information (e.g., employee withholding forms sent to governmental units), financial statements where specific statements are wanted (e.g., balance sheets or statements of income and expense), or customer invoice and billing forms which you might want preprinted to include your logo and conditions of payment.

2.Management decision information. This category tries to define the information needed for decision-making purposes. In the computer product/report category you were looking for a document; in this case you are looking for information. How that information is provided is unimportant. Thus, the structure of the document, what the documents are, or their size, frequency, or volume are not significant. All you need is information.

Define Critical Success Factor

This step tells whether the COTS software will be successful in meeting your requirements. Critical success factors (CSFs) are those criteria or factors that must be present in the acquired software for it to be successful. You might ask whether the needs are the same as the critical success factors. They are, but they are not defined in a manner that makes them testable, and they may be incomplete. Often the needs do not take into account some of the intangible criteria that make the difference between success and failure. In other words, the needs define what we are looking for, and the critical success factors tell us how we will evaluate that product after we get it. They are closely related and complementary, but different in scope and purpose.

The following list indicates the needs or requirements for the automobile, and is then followed by the CSFs on which the automobile will be evaluated:

Seats six people

Four doors

Five-year guarantee on motor

Gets 20 miles per gallon or greater

Costs under $12,000

Critical success factors:

Operates at 20.5 cents or less per mile

Experiences no more than one failure per year

Maintains its appearance without showing signs of wear for two years

Some of the more common critical success factors for COTS you may want to use are:

Ease of use - The software is understandable and usable by the average person.

Expandability - The contractor plans to add additional features in the future.

Maintainability - The contractor will provide support/assistance to help utilize the package in the event of problems.

Cost-effectiveness - The software package makes money for your business by reducing costs, and so on.

Transferability - If you change your computer equipment the contractor indicates that they will support new models or hardware.

Reliability - In computer language, the system is friendly, meaning that it will help you get your transactions entered into the system so that you can produce your results readily.

Security - The system has adequate safeguards to protect the data against damage (for example, power failures, operator errors, or other goofs that could cause you to lose your data).

Determine Compatibility with Hardware, Operating System, and Other COTS Software

This is not a complex step. It involves a simple matching between your processing capabilities and limitations, and what the contractor of the software says is necessary to run the software package. The most difficult part of this evaluation is ensuring the multiple software packages can properly interface.

This step is best performed by preparing a checklist defining your compatibility needs. Software contractors are generally good about identifying the needed hardware and operating system compatibility. They are generally not good in identifying compatibility with other software packages.

A mission statement explains why a company, organization, or activity exists, and what it is designed to accomplish. It clearly and concisely describes the work that is done, providing direction and a sense of purpose. The mission should focus on products and services and be customer-oriented. During implementation, the mission is constrained by the vision and values. Examples of mission statements include:

From Arco Transportation Company Information Services: "The mission of information services is to provide the appropriate computing network, products, and services and support of the strategies, goals, and objectives of the company."

From the Ford Motor Company (listed in their Ford Q-101 Quality Systems Standard, January 1986): “Ford Motor Company is a worldwide leader in automotive and automotive-related products and services as well as in newer industries such as aerospace, communications, and financial services. Our mission is to improve continually our products and services to meet our customers’ needs, allowing us to prosper as a business and to provide a reasonable return for our stockholders, the owners of our business.”

Vision

Leaders provide a vision, which is a clear definition of the result to be achieved. Organizations without a vision flounder. The vision establishes where the organization desires to move from its current state. It gives everyone a direction to work towards. Senior management should establish the vision, ensuring how it contributes to the business is clear. A vision is simple and concise, and it should be understood and supported by all.

Examples of visions include:

From the Quality Assurance Institute: “Our vision is to produce competent and successful quality assurance analysts.”

From the Eastman Kodak Company: "We see ourselves now and in the future as a company with a strong customer franchise, known for reliability, trust, and integrity in all relationships. Our business will be based on technologies that have evolved over our long history, and which will give us unique advantages over our competition. These technologies will span our core businesses, and will also go beyond boundaries we can see today.”

From the Ford Motor Company: "A worldwide leader in automotive and automotive related products and services as well as in newer industries such as aerospace, communications, and financial services."

President Kennedy had a vision of putting a man on the moon before 1970.

QA analysts should have a vision of improving quality, productivity, and customer satisfaction.

There is a high correlation between process maturity and cycle time. As shown in the figure below, as processes mature, there is a decrease in the cycle time to build software products. The maturity of processes, people, and controls has associated with it a search for the root cause of problems. It is these problems that lead to rework which, in turn, extends the cycle time. Thus, improvements also focus on facilitating transitions of deliverables from work task to work task, which also significantly reduces cycle time.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-12 at 12.47.42 PM.png

At a minimum, the tool selected should support the recording and communication of all significant information about a defect. For example, a defect log could include:

ƒ Defect ID number

ƒ Descriptive defect name and type

ƒ Source of defect - test case or other source that found the defect

ƒ Method – SDLC phase of creation

ƒ Phases – SDLC phase of detection

The concerns that arise in maintaining a relationship of harmony and good will include:

Contractor obligations met - The contractor should meet their requirements as specified in the contract.

Customer obligations met - The customer should meet their requirements as specified in the contract.

Need met - It is to the benefit of both parties to have the customer satisfied with the application system. Even when the initial deliverables meet the customer’s need, there will be ongoing maintenance required to meet the continually evolving needs of the customer. The methods of doing this should be specified in the contract, and those requirements should form the basis for both parties specifying and delivering new contractual obligations.

Limits on cost increases - The cost specified in the contract should include provisions for ongoing costs. In an inflationary economy, it may be advantageous to have limits placed on cost increases. For example, if service is provided at an hourly rate, the increases in that rate might be specified in the contract.

1. Develop a charter.

Determine the responsibilities and activities of the quality function.

2. Identify the quality manager.

Select a quality "fanatic" to head the quality function.

3. Locate organizationally the IT quality function.

Determine to whom the quality leader reports.

4. Build support for quality.

Initiate programs that will encourage both management and staff to support quality processes.

5. Staff and train the quality function.

Determine what is needed to make quality happen, identify and select the people to do it, and provide them with the training they need.

6. Build and deploy the quality toolbox.

Select effective quality tools and implement them throughout the organization.

7. Drive the implementation of the quality management environment.

The quality manager will need to spend a significant amount of time maturing the quality management environment.

The framework defines risk and enterprise risk management, and provides a foundational definition, conceptualizations, objectives categories, components, principles and other elements of a comprehensive risk management framework. It provides direction for companies and other organizations in determining how to enhance their risk management architectures, providing context for and facilitating application in the real world. This document is also designed to provide criteria for companies’ use in determining whether their enterprise risk management is effective and, if not, what is needed to make it so.