Software Certifications CSQA - CSQA Certified Software Quality Analyst

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.

Verification requires several types of reviews, including requirements reviews, design reviews, code walkthroughs, code inspections, and test reviews. The system user should be involved in these reviews to find defects before they are built into the system. In the case of purchased systems, user input is needed to assure that the supplier makes the appropriate tests to eliminate defects. The following table shows examples of verification. The list is not exhaustive, but it does show who performs the task and what the deliverables are. For purchased systems, the term “developers” applies to the supplier’s development staff.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-11 at 6.18.47 PM.png

Validation is accomplished simply by executing a real-life function (if you wanted to check to see if your mechanic had fixed the starter on your car, you’d try to start the car). Examples of validation are shown in the following table. As in the table above, the list is not exhaustive.

Determining when to perform verification and validation relates to the development, acquisition, and maintenance of software. For software testing, this relationship is especially critical because:

The corrections will probably be made using the same process for developing the software. If the software was developed internally using a waterfall methodology, that methodology will probably be followed in making the corrections; on the other hand, if the software was purchased or contracted, the supplier will likely make the correction. You’ll need to prepare tests for either eventuality.

Testers can probably use the same test plans and test data prepared for testing the original software. If testers prepared effective test plans and created extensive test data, those plans and test data can probably be used in the testing effort, thereby reducing the time and cost of testing.

Rahail HDD:Users:iMac:Desktop:Screen Shot 2015-01-11 at 6.20.18 PM.png

White-Box

White-box testing (logic driven) assumes that the path of logic in a unit or program is known. White-box testing consists of testing paths, branch by branch, to produce predictable results. Multiple white-box testing techniques are listed below. These techniques can be combined as appropriate for the application, but should be limited, as too many techniques can lead to an unmanageable number of test cases.

Statement Coverage Execute all statements at least once.

Decision Coverage Execute each decision direction at least once.

Black-Box

In black-box testing (data or condition driven), the focus is on evaluating the function of a program or application against its currently approved specifications. Specifically, this technique determines whether combinations of inputs and operations produce expected results. As a result, the initial conditions and input data are critical for black-box test cases.

Two successful techniques for managing the amount of input data required include:

Equivalence Partitioning

An equivalence class is a subset of data that represents a larger class. Equivalence partitioning is a technique for testing equivalence classes rather than undertaking exhaustive testing of each value of the larger class. For example, a program which edits credit limits within a given range (at least $10,000 but less than $15,000) would have three equivalence classes:

Less than $10,000 (invalid)

Equal to $10,000 but not as great as $15,000 (valid)

$15,000 or greater (invalid)

Boundary Analysis

This technique consists of developing test cases and data that focus on the input and output boundaries of a given function. In the credit limit example, boundary analysis would test the:

Low boundary plus or minus one ($9,999 and $10,001)

Boundaries ($10,000 and $15,000)

Upper boundary plus or minus one ($14,999 and $15,001)

Automated Enforcementis normally viewed as the most fair of all methods of enforcement. It isnormally performed by a computer. The rules are included in the computer system, and whenthose rules are violated, enforcement is automatic.

Automated enforcement is a predetermined enforcement decision. The computer merely executes the action. For example, if you need a password to enter into a system and you do not enter a correct password, access is denied. If you are charging items on your credit card and you have exceeded your credit limit, the computer action is to disallow the purchase.

Nominal Data

This data can be categorized. For example, a program can be classified as database software, operating system, etc. Nominal data cannot be subjected to arithmetic operations of any type, and the values cannot be ranked in any "natural order." The only possible operation is to determine whether something is the same type as something else. Nominal data can be objective or subjective, depending on the rules for classification.

Ordinal Data

This data can be ranked, but differences or ratios between values are not meaningful. For example, programmer experience level may be measured as low, medium, or high. For ordinal data to be used in an objective measurement the criteria for placement in the various categories must be well defined; otherwise, it is subjective.

Interval Data

This data can be ranked and can exhibit meaningful differences between values. Interval data has no absolute zero, and ratios of values are not necessarily meaningful. For example, a program with a complexity value of 6 is four units more complex than a program with a complexity of 2, but it

Level 1 – Constraint Requirements

This level involves staffing, budget, and schedule. The business requirements are frequently defined as a set of objectives described on several pages of narrative description. Thus, it becomes the role of the project team to expand the initial definition and build the software. However, management and the end user of the software will manage more by the constraint requirements than by the business requirements. The result is that the software put into production on the scheduled date may miss many key requirements, which will need to be installed after the operational date but under new budgets and schedules.

Level 2 – Business Requirements

This level places its emphasis on the functional and operating requirements. Level 2 establishes the criteria that the deliverables must meet in order to be accepted by the end user. At this level, standards are established for the requirements document which specifies the totality of requirement attributes that must be included for the requirements to be considered complete. These often include defining how the requirements will be tested, the objective of therequirement, the problem that the requirement is designed to solve, a detailed description of the requirement, and how the requirement is related to the objectives to be accomplished. Many information organizations at this level introduce uniquely identifying requirements, and then utilize processes that trace requirements through the entire software-building process.

Level 3 – Relational Requirements

This level emphasizes relationships within an information system and between information systems. Level 2 defines relationships, but normally at a much lower level than Level 3. Level 2 relationship specifications tend to be within an individual application system. Level 3 relationships focus on organizational databases, processing sequences and priorities, intersystem relationships, and processing cycle relationships. Data relationships help eliminate data redundancy and help assure consistency of use of data throughout an organization. Processing relationships address processing priorities and processing sequences. The system relationships deal with interfaces between systems and changes to systems. The larger challenge is assuring that all systems are changed concurrently when they are impacted by a common change(s). The processing cycle or timing relationship assures that all data that belongs in a particular accounting processing cycle is processed during that cycle.

Level 4 – Quality Requirements

Quality requirements are the characteristics surrounding the functional requirements that facilitate end user satisfaction. An example of quality requirements is ease of use. The functional requirements deal with the data specified for a particular product, but if it is very difficult to use (i.e., not meeting the quality ease of use requirement); the end user tends to be dissatisfied.

Level 5 – Reliability Requirements

Reliability primarily deals with mean time between failures. To achieve reliability requirements necessitates building a database of processing information and performing adequate statistical analysis on that data. Then a statistical prediction of reliability can be made. While the end user needs to specify reliability requirements, they can only be measured and achieved through the use of statistical tools. Figure 44 shows the best practices for deliveries process.

Measurement Dashboards

Measurement dashboards (also called key indicators) are used to monitor progress and initiate change. A measurement dashboard is analogous to the dashboard on a car. Various key indicators are presented in comparison to their own desired target value (i.e., speed, oil temperature). Arrayed together, they provide an overall snapshot of the car's performance, health, and operating quality. Measurement dashboards help ensure that all critical performance areas are analyzed in relation to other areas. Indicators evaluated alone can lead to faulty conclusions and decision-making.

Key Indicators

Key indicators are the metrics used by management to help them fulfill their management responsibilities. Managers decide what key metrics they need. A dashboard is comprised of the total number of key indicators used by a single manager. The concept of “key” means the metric is considered important by the user in managing job responsibilities. Normally the key indicator is created from many different measures. For example, the Dow Jones Average is created from the combining of stock prices from approximately 40 different stocks.

Reduce the Number of Vendors

Requiring statistical evidence of quality control in the purchase of hardware and software will mean, in most companies, drastic reduction in the number of vendors with whom they deal. Companies will have to consider the cost of having two or more vendors for the same item. A company will be lucky to find one vendor that can supply statistical evidence of quality. A second vendor, if they cannot furnish statistical evidence of their quality, will have higher costs than the one that can furnish the evidence, or they will have to chisel on their quality, or go out of business. A person that does not know his/her costs or whether today's distribution of quality can be repeated tomorrow is not a good business partner.

Use Statistical Methods to Find Sources of Trouble

Which are user faults? Which faults belong to IT? Put responsibility where it belongs. Do not rely on judgment because it always gives the wrong answer on the question of where the fault lies. Statistical methods make use of knowledge of the subject matter where it can be effective, but supplant it where it is a hazard.

Constantly improve the system. This obligation never ceases. Most people in management do not understand that the system (their responsibility) is everything not under the governance of a user.

Institute Modern Aids to Training on the Job

Training must be totally reconstructed. Statistical methods must be used to learn when training is finished, and when further training would be beneficial. A person once hired and trained and in statistical control of his/her own work, whether it be satisfactory or not, can do no better. Further training cannot help. If their work is not satisfactory, move them to another job, and provide better training there.

Define the Scope of the Process

Use the Process Inventory, Process Maps, and existing standards and procedures to clarify the scope of the process. This involves developing a high-level process flow (major workbenches and interfaces with other processes), major inputs and outputs (deliverables), and major customers and their requirements.

Develop the Workflow

Brainstorm the tasks and deliverables in the process and then group the tasks. Select the current best practices, adding missing tasks or deliverables and correcting flaws in the workflow. Define the workbenches internal to the process, their sequence, and major interim deliverables. Typically processes contain 3-5 workbenches, with each workbench containing 3-7 process steps or task procedures.

Develop Policies

A policy states why the workbench or deliverable exists, and indicates desired results (desirable attributes of process performance or desirable product quality characteristics). Policies should link to the organization’s strategic goals, and support customer needs or requirements. A policy should be realistic, stating a desire that the organization is currently capable of accomplishing.

Develop Standards

A standard states what must happen to meet the intent of the policy. Standards are more specific than policies in that they convert intentions into specific rules. Workbench standards deal withperformance issues related to time frames, prerequisites, or sequencing of tasks while deliverable standards typically specify content.

Develop Procedures

Procedures describe how work is done, and indicate the "best current way" to meet standards. Ideally, if the procedures are followed, the standards will automatically be followed and the intent of the policy will be met.

A task is a single step in a procedure. Procedures may have many tasks. Task procedures should refer to people, accessible tools, known techniques or methods, and templates for deliverables. If appropriate, tasks can also refer to more detailed work instructions, such as training or user’s manuals.

Risk management is the process used to identify, analyze, and respond to a risk. Identifying, analyzing, and prioritizing risks require knowledge of the business functions, and user involvement. The Project Management Institute's Project Management Body of Knowledge(PMBOK) defines the following four processes to address risk management. The PMBOK also notes that different application areas may use different names for these four processes.

Risk Identification

Risk Quantification

Risk Response Development

Risk Response Control

This discussion of risk management addresses six processes, which have the following mapping to the PMBOK processes.

Risk Identification

Risk Identification – this process answers the question "What are the risks?"

Risk Quantification

Risk Analysis - this process answers the question "Which risks do we care about?"

Risk Prioritization - this process answers the question "How are the risks prioritized?"

Risk Response Development

Planning - this process answers the question "What should be done about the risk?"

Risk Response Control

Risk Resolution – this process executes the plan that was developed in the prior step.

Risk Monitoring – this process evaluates the action taken, documents the risk results and repeats the cycle of identification, quantification and response.

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

Force field analysis is a visual team tool used to determine and understand the forces that drive and restrain a change. Driving forces promote the change from the existing state to the desired goal. Opposing forces prevent or fight the change. Understanding the positive and negative barriers helps teams reach consensus faster.

The steps below show how a team uses force field analysis:

Establish a desired situation or goal statement.

Brainstorm and list all possible driving forces.

Brainstorm and list all possible restraining forces.

Determine the relative importance of reaching consensus on each force.

Draw a force field diagram that consists of two columns, driving forces on one side and restraining forces on the other.

Select the most significant forces that need to be acted upon using the nominal group technique to prioritize and reduce the number, if there are too many.

Proceed to a plan of action on the forces selected in the previous step

It is a concept that enriches an employee’s job and enables quick actions to be taken. Customer and user satisfaction is normally increased when they can get quick action from front line staff.

To be effective, empowerment must be part of a process. The empowered employee must know their limits of empowerment, and when and how they can make decisions. For example, a help desk employee may be empowered to hire a courier to deliver a report needed quickly by a user; but only up to a cost of $100. Another empowerment example would be in a “charge-out” environment where a programmer can fix a program at no charge to the user if the programmer believes the problem was caused by incorrect programming.

The concerns that need to be addressed during contract negotiations include the following factors.

Warranty

The guarantees provided by the contractor that the deliverables will meet the specifications. This segment of the contract should state specifically what the contractor warrants, and what the contractor will do if the deliverables fail to meet the warranty guarantees. For example, if the contractor guarantees the application will provide a one-second response, and the implemented application fails to meet those specifications, this contract defines recourse against the contractor.

Installation

The contractor’s and customer’s commitment for installing the application should be specified. If the contractor is to have personnel present to help during the installation, that should be specified. If the contractor is to provide machine time on certain days, that, too, should be specified in the contract.

Penalties

Penalties assessed in the event of failure on the part of either the contractor or the customer to meet contractual obligations should be covered in the contract. Where dollar penalties are to be assessed, the amount should be specified in the contract. For example, if the contractor is late in delivering the product, a per-day dollar penalty can be assessed, as well as a dollar penalty for failure of the customer to make computer time available, etc.

Service discontinuance

If the contractor decides to discontinue service on the application system, the customer’s rights in those instances should be specified. For example, if any of the training material or application system is copyrighted then those copyrights should be passed to the customer in the event that service on the purchased products is discontinued.

Consider questions such as:

How big is the risk?

What exactly is being exposed to the risk?

Can this be considered an acceptable risk?

What alternatives are there?

Will alternatives invoke additional risks?

As it is impossible to be completely certain of the impact or likelihood of many events, these events are estimated using a combination of historical data, knowledge of the event, and experience and judgment. Tools such as simulation, decision trees, or calculating a monetary value are used. Risk can be calculated by structured (associated with data) and unstructured (focus on judgment and experience) methods. Regardless of the method used, two elements must always be considered:

The probability of such an event occurring

The resulting impact if the event occurs