SOFTWARE QUALITY ASSURANCE Lesson 1 SOFTWARE WHAT IS SOFTWARE?

? It is a collection of computer programs, procedures and documentation that perform some tasks on a computer system. The first theory about software was proposed by Alan Turing. Paul Niquette claims to have coined the term "software" in this sense in 1953, and first used in print by John W. Tukey in 1958. COMPUTER SOFTWARE Computer software, or just software, is the collection of computer programs and related data that provide the instructions telling a computer what to do. The term was coined to contrast to the old term hardware (meaning physical devices). In contrast to hardware, software is intangible, meaning it "cannot be touched". Software is also sometimes used in a more narrow sense, meaning application software only. Sometimes the term includes data that has not traditionally been associated with computers, such as film, tapes and records. Computer software is so called to distinguish it from computer hardware, which encompasses the physical interconnections and devices required to store and execute (or run) the software. In computers, software is loaded into RAM and executed in the central processing unit.
Comment [A1]: State Comment [A2]: Create

Comment [A3]: Invent, create Comment [A4]: Slight Comment [A5]: Related Comment [a6]: Include, cover

Comment [a7]: Operating System is the software on a computer that manages the way different programs use its hardware, and regulates the ways that a user control the computer.

A layer structure showing where operating system is located on generally used software systems on desktops

SOFTWARE QUALITY ASSURANCE

Examples of computer software include: APPLICATION SOFTWARE includes end-user applications of computers such as word processors or Video games, and ERP software for groups of users.
Enterprise resource planning (ERP) is an integrated computer-based system used to manage internal and external resources including tangible assets, financial resources, materials, and human resources. It is a software architecture whose purpose is to facilitate the flow of information between all business functions inside the boundaries of the organization and manage the connections to outside stakeholders. Built on a centralized database and normally utilizing a common computing platform, ERP systems consolidate all business operations into a uniform and enterprise wide system environment. An ERP system can either reside on a centralized server or be distributed across modular hardware and software units that provide "services" and communicate on a local area network. The distributed design allows a business to assemble modules from different vendors without the need for the placement of multiple copies of complex and expensive computer systems in areas which will not use their full capacity.

Application software, also known as applications, is computer software designed to help the user to perform singular or multiple related specific tasks. Examples include Enterprise software, Accounting software, Office suites, Graphics software and media players. Application software is contrasted with system software and middleware, which manage and integrate a computer's capabilities, but typically do not directly apply them in the performance of tasks that benefit the user. A simple, if imperfect analogy in the world of hardware would be the relationship of an electric light bulb (an application) to an electric power generation plant (a system). The power plant merely generates electricity, not itself of any real use until harnessed to an application like the electric light that performs a service that benefits the user.
Comment [A8]: Categorization

Application software classification There are many types of application software: An application suite consists of multiple applications bundled together. They usually have related functions, features and user interfaces, and may be able to interact with each other, e.g. open each other's files. Business applications often come in suites, e.g. Microsoft Office, OpenOffice.org, and iWork, which bundle

SOFTWARE QUALITY ASSURANCE together a word processor, a spreadsheet, etc.; but suites exist for other purposes, e.g. graphics or music. iWork is an office suite of desktop applications created by Apple for the Mac OS X and iOS operating systems. The first version of iWork, iWork '05, was released in 2005. The suite originally bundled Keynote, a presentation program which had previously been sold as a standalone application, and Pages, a combined word processing and page layout application. In 2007, Apple released iWork '08, which contained a new spreadsheet application, Numbers. Enterprise software addresses the needs of organization processes and data flow, often in a large distributed environment. (Examples include Financial, Customer Relationship Management, and Supply Chain Management). Note that Departmental Software is a sub-type of Enterprise Software with a focus on smaller organizations or groups within a large organization. (Examples include Travel Expense Management, and IT Helpdesk)

Enterprise infrastructure software provides common capabilities needed to support enterprise software systems. (Examples include Databases, Email servers, and Network and Security Management). Information worker software addresses the needs of individuals to create and manage information, often for individual projects within a department, in contrast to enterprise management. Examples include time management, resource management, documentation tools, analytical, and collaborative. Word processors, spreadsheets, email and blog clients, personal information system, and individual media editors may aid in multiples information worker tasks. Content access software is software used primarily to access content without editing, but may include software that allows for content editing. Such software addresses the needs of individuals and groups to consume digital entertainment and published digital content. (Examples include Media Players, Web Browsers, Help browsers, and Games) Educational software is related to content access software, but has the content and/or features adapted for use in by educators or students. For example, it may deliver evaluations (tests), track progress through material, or include collaborative capabilities. Simulation software is computer software for simulation of physical or abstract systems for research, training or entertainment purposes. Media development software addresses the needs of individuals who generate print and electronic media for others to consume, most often in a commercial or educational setting. This includes Graphic Art software, Desktop Publishing

Comment [A9]: Joint, share, two-way Comment [a10]: Simulation is used in many contexts, including the modeling of natural systems or human systems in order to gain insight into their functioning. Other contexts include simulation of technology for performance optimization, safety engineering, testing, training and education.

SOFTWARE QUALITY ASSURANCE software, Multimedia Development software, HTML editors, Digital Animation editors, Digital Audio and Video composition, and many others. Product engineering software is used in developing hardware and software products. This includes computer aided design (CAD), computer aided engineering (CAE), computer language editing and compiling tools, Integrated Development Environments, and Application Programmer Interfaces. MIDDLEWARE controls and co-ordinates distributed systems. Middleware is computer software that connects software components or applications. The software consists of a set of services that allows multiple processes running on one or more machines to interact. This technology evolved to provide for interoperability in support of the move to coherent distributed architectures, which are most often used to support and simplify complex distributed applications. It includes web servers, application servers, and similar tools that support application development and delivery. Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.

Comment [A11]: A distributed system consists of multiple autonomous computers that communicate through a computer network. The computers interact with each other in order to achieve a common goal. A computer program that runs in a distributed system is called a distributed program, and distributed programming is the process of writing such programs. Distributed computing also refers to the use of distributed systems to solve computational problems. Comment [A12]: Interoperability is a property referring to the ability of diverse systems and organizations to work together (inter-operate). The term is often used in a technical systems engineering sense, or alternatively in a broad sense, taking into account social, political, and organizational factors that impact system to system performance. Comment [A13]: Extensible Markup Language is a set of rules for encoding documents in machine-readable form. XML's design goals emphasize simplicity, generality, and usability over the Internet Comment [A14]: Simple Object Access Protocol is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks Comment [A15]: Enterprise Application Integration EAI software connects applications within an enterprise. This is necessary in order to translate data and messages from different applications.

Middleware sits "in the middle" between application software that may be working on different operating systems. It is similar to the middle layer of three-tier single system architecture, except that it is stretched across multiple systems or applications. Examples include EAI software, telecommunications software, transaction monitors, and messaging-andqueuing software. The distinction between operating system and middleware functionality is, to some extent, arbitrary. While core kernel functionality can only be provided by the operating system itself, some functionality previously provided by separately sold middleware is now integrated in operating systems. A typical example is the TCP/IP stack for telecommunications, nowadays included in virtually every operating system. In simulation technology, middleware is generally used in the context of the high level architecture (HLA) that applies to many distributed simulations. It is a layer of software that lies between the application code and the run-time infrastructure. Middleware generally consists of a library of functions, and enables a number of applications simulations or federates in HLA terminology to page these functions from the common library rather than re-create them for each application

Comment [A16]: Study of meaning Comment [A17]: COBOL (pronounced /kobl/) is one of the oldest programming languages. Its name is an acronym for COmmon Business-Oriented Language, defining its primary domain in business, finance, and administrative systems for companies and governments. The COBOL 2002 standard includes support for object-oriented programming and other modern language features

PROGRAMMING LANGUAGES define the syntax and semantics of computer programs. For example, many matured banking applications were written in the COBOL language, originally invented in 1959. Newer applications are often written in more modern programming languages.

SOFTWARE QUALITY ASSURANCE Programming language is an artificial language designed to express computations that can be performed by a machine, particularly a computer. Programming languages can be used to create programs that control the behavior of a machine, to express algorithms precisely, or as a mode of human communication. Many programming languages have some form of written specification of their syntax (form) and semantics (meaning). Some languages are defined by a specification document. For example, the C programming language is specified by an ISO Standard. Other languages, such as Perl, have a dominant implementation that is used as a reference. The earliest programming languages predate the invention of the computer, and were used to direct the behavior of machines such as Jacquard looms and player pianos. Thousands of different programming languages have been created, mainly in the computer field, with many more being created every year. Most programming languages describe computation in an imperative style, i.e., as a sequence of commands, although some languages, such as those that support functional programming or logic programming, use alternative forms of description.

Comment [A18]:

Comment [A19]: Very important

SYSTEM SOFTWARE includes operating systems, which govern computing resources. Today large applications running on remote machines such as Websites are considered to be system software, because the end-user interface is generally through a Graphical user interface (GUI), such as a web browser. System software helps run the computer hardware and computer system. It includes a combination of the following: device drivers operating systems servers utilities windowing systems

The purpose of systems software is to unburden the applications programmer from the often complex details of the particular computer being used, including such accessories as communications devices, printers, device readers, displays and keyboards, and also to partition the computer's resources such as memory and processor time in a safe and stable manner. Examples are - Microsoft Windows, Linux, and Mac OS X. TESTWARE is software for testing hardware or a software package. Generally speaking, Testware is a sub-set of software with a special purpose, that is, for software testing, especially for software testing automation.
Comment [A20]: An example of a package is the java.io package which contains or groups together all the classes in the Java programming language that aid input and output of data, such as the buffered reader class which is used to accept user input from the keyboard. When a class is imported the user is free to use as if it were in their local directory.

SOFTWARE QUALITY ASSURANCE Automation testware for example is designed to be executed on automation frameworks. Testware is an umbrella term for all utilities and application software that serve in combination for testing a software package but not necessarily contribute to operational purposes. As such, testware is not a standing configuration but merely a working environment for application software or subsets thereof. It includes artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, setup and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing.

Comment [A21]: Simply

Testware is produced by both verification and validation testing methods. Testware includes codes and binaries as well as test cases, test plan, test report and etc. Testware should be placed under the control of a configuration management system, saved and faithfully maintained. Compared to general software, testware is special because it has: 1. a different purpose 2. different metrics for quality and 3. different users The different methods should be adopted when you develop testware with what you use to develop general software. FIRMWARE is low-level software often stored on electrically programmable memory devices. Firmware is given its name because it is treated like hardware and run ("executed") by other software programs. In electronics and computing, firmware is a term often used to denote the fixed, usually rather small, programs and data structures that internally control various electronic devices. Typical examples of devices containing firmware range from end-user products such as remote controls or calculators, through computer parts and devices like hard disks, keyboards, TFT screens or memory cards, all the way to scientific instrumentation and industrial robotics. Also more complex consumer devices, such as mobile phones, digital cameras, synthesizers, etc., contain firmware to enable the device's basic operation as well as implementing higher-level functions. There are no strict boundaries between firmware and software, as both are quite loose descriptive terms. However, the term firmware was originally coined in order to contrast to higher level software which could be changed without replacing a hardware component, and firmware is typically involved with very basic low-level operations without which a device would be completely nonfunctional. Firmware is also a relative term, as most embedded devices contain

SOFTWARE QUALITY ASSURANCE firmware at more than one level. Subsystems such as CPUs, flash chips, communication controllers, LCD modules, and so on, have their own (usually fixed) program code and/or microcode, regarded as "part of the hardware" by the higher-level(s) firmware. Simple firmware typically resides in ROM or OTP/PROM, while more complex firmware (often on the border to software) typically employs flash memory to allow for updates, at least in modern devices. Common reasons for updating firmware include fixing bugs or adding features to the device. Doing so usually involves loading a binary image file (provided by the manufacturer) into the device, according to a specific procedure; this is sometimes intended (by the device manufacturer) to be done by the end user.

DEVICE DRIVERS control parts of computers such as disk drives, printers, CD drives, or computer monitors. In computing, a device driver or software driver is a computer program allowing higher-level computer programs to interact with a hardware device. A driver typically communicates with the device through the computer bus or communications subsystem to which the hardware connects. When a calling program invokes a routine in the driver, the driver issues commands to the device. Once the device sends data back to the driver, the driver may invoke routines in the original calling program. Drivers are hardware-dependent and operating-system-specific. They usually provide the interrupt handling required for any necessary asynchronous time-dependent hardware interface.

PROGRAMMING TOOLS help conduct computing tasks in any category listed above. For programmers, these could be tools for debugging, or reverse engineering older legacy systems in order to check source code compatibility. A programming tool or software development tool is a program or application that software developers use to create, debug, maintain, or otherwise support other programs and applications. The term usually refers to relatively simple programs that can be combined together to accomplish a task, much as one might use multiple hand tools to fix a physical object.

SOFTWARE QUALITY ASSURANCE PRELIM Lesson 2 QUALITY ASSURANCE What is Quality?

Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-inferiority or superiority of something. Quality is a perceptual, conditional and somewhat subjective attribute and may be understood differently by different people. Consumers may focus on the specification quality of a product/service, or how it compares to competitors in the marketplace. Producers might measure the conformance quality, or degree to which the product/service was produced correctly. Many different techniques and concepts have evolved to improve product or service quality. There are two common quality-related functions within a business. 1. quality assurance which is the prevention of defects, such as by the deployment of a quality management system. 2. The other is quality control which is the detection of defects, most commonly associated with testing which takes place within a quality management system typically referred to as verification and validation.
Comment [A24]: Use, operation, consumption, exploitation, employment Comment [A25]: A quality management system (QMS) can be expressed as the organizational structure, procedures, processes and resources needed to implement quality management. Elements of a Quality Management System 1.Organizational Structure 2.Responsibilities 3.Methods 4.Processes 5.Resources 6.Customer Satisfaction 7.Continuous Improvement Comment [a22]: Practical Comment [A23]: Poor standard, low standard, poor quality

What is Quality Assurance? It refers to any action directed toward providing consumers with products (goods and services) of appropriate. Quality assurance usually associated with some form of measurement and inspection activity, has been an important aspect of production operations throughout history. Different Responses to Quality (US based) Perfection a state of completeness and flawlessness (excellence). Consistency is one of the ACID properties that ensure that any changes to values in an instance
are consistent with changes to other values in the same instance. A consistency constraint is a predicate on data which serves as a precondition, post-condition, and transformation condition on any transaction. The Database Management System (DBMS) assumes that the consistency holds for each transaction in instances. On the other hand, ensuring this property of the transaction is the responsibility of the user. Eliminating Waste eliminate the unnecessary transport of materials and unnecessary movement of people.

Comment [a26]: Excellence Comment [a27]: Reliability, uniformity, stability Comment [A28]: Atomicity, consistency, isolation, durability Comment [A29]: Limitation Comment [A30]: magpatotoo, magpatunay Comment [a31]: Order Organize, arrange Comment [a32]: Remove, Reduce

How To Eliminate Muda (Waste) in IT and The Office Muda is a Japanese word that means waste. It has deeper meaning in that it refers to any activity that does not add value. In IT and the office we have many processes for getting work done. Each of these processes is subject to muda. In tough economic times like these we need to look at every area we can save money. Since time is money, wasted time is wasted money. By eliminating muda from the workplace we can save money and become more productive.
Comment [A33]: Hard, difficult

SOFTWARE QUALITY ASSURANCE

Some of the benefits of eliminating muda:

Saving money More productivity due to less time spent doing a job Equipment and supplies are available when they are needed Standardized procedures and processes Improved customer satisfaction Improved morale and better communications
Comment [A34]: Combination Comment [A35]: Kaizen (Japanese for "improvement" or "change for the better") refers to philosophy or practices that focus upon continuous improvement of processes in manufacturing, engineering, supporting business processes, and management. It has been applied in healthcare, government, banking, and many other industries. When used in the business sense and applied to the workplace, kaizen refers to activities that continually improve all functions, and involves all employees from the CEO to the assembly line workers. It also applies to processes, such as purchasing and logistics, that cross organizational boundaries into the supply chain. [1] By improving standardized activities and processes, kaizen aims to eliminate waste (see lean manufacturing). Kaizen was first implemented in several Japanese businesses after the Second World War.

Muda is often used in conjunction with Kaizen, a 5S System and Lean processes. While developed for a production environment, we can easily translate these practices into the IT and office environment.
The five main elements of kaizen Teamwork Personal discipline Improved morale Quality circles Suggestions for improvement

There are 7 categories of Muda 1. Over Production More information than the customer needs, more information than the next process needs, creating reports no one reads, or making extra copies. 2. Transportation Retrieving or storing files, carrying documents to and from shared equipment, taking files to another person, or going to get signatures. 3. Motion Searching for files, extra clicks or keystrokes, clearing away files on the desk, gathering information, looking through manuals and catalogs, or handling paperwork 4. Waiting Waiting for faxes or a copy machine, for the system to come back up, for a customer response, or a handed-off file to come back. 5. Unnecessary Processing Creating reports, repeated manual entry of data, use of outdated standard forms, or use of inappropriate software. 6. Inventory Files waiting to be worked on, open projects, too much office supplies, e-mails waiting to be read, or unused records in the database. 7. Rework/Rejects/Repairs Data entry errors, pricing errors, missing information, missed specifications, or lost records.

What is continuous improvement?

Continuous improvement is the process of improving quality, productivity and cost by eliminating waste.

CFO responsibilities for all businesses in the area of continuous improvement

View your business as a series of integrated processes rather than functions - All processes require shall

Comment [A36]: Chief Financial Officer

be followed or done, such process considered as function may not be performed which may be resulting to rejects.
Eliminate non-value added activities in all business processes

SOFTWARE QUALITY ASSURANCE

Relentlessly pursue reduction in cycle times in all aspects of all processes followed what will be standard requirement of the process. Reduction without due studies may give a big impact on the quality of the product. Hold productivity gains made by documenting process improvements in standardized policies and procedures what will be the changes it should be document for reference. Establish a corporate culture based upon the principles of teamwork, accountability, learning and empowerment influence all manpower with the principles of teamwork (initiative)
Comment [A37]: Insistently, persistently Comment [A38]: Practice

Comment [A39]: Production Comment [A40]: Increase, add, put on, expand

Waste hierarchy

1 Eliminate
Eliminating waste entirely may not always be possible, but by not creating it in the first place reduces costs of raw materials.

2 Reduce
Reducing the amount of waste you produce can be achieved in a number of ways, including the amount of packing used, reduce off-cuts and rejects, send information electronically, purchase material in bulk and use returnable containers.

3 Re-use
To limit extra spend of buying items in, many can be re-used to reduce waste.

SOFTWARE QUALITY ASSURANCE

For example:

Packaging - boxes can be re-used many times. Printer toner cartridges - choose a supplier that has a returns policy so that they can be re-filled and used again. Paper - re-use paper from misprints and drafts as scrap paper in the office. Drums - many raw materials are delivered in drums that can be washed and returned to the supplier, or re-used on site as waste containers. Furniture and textiles - waste furniture and textiles may be of use to charities or to waste exchange groups.

4 Recycle
Recycling is an increasing requirement through legislation in order to reduce the impact on the environment. Many items can now be recycled, speak to your local recycling centre or waste management contractor to find out what they are and how they should be segregated.

5 Disposal
Disposal is the last resort when the other hierarchy options have been exhausted. There are legal obligations that all producers and handlers of waste need to comply with, so it is important that you contact your waste management contractor to discuss options like recycling to make waste disposal more efficient and save money.

Speed of Delivery - Speed of delivery can be either... the measure of the number of function

points delivered in an elapsed month, or the measure of the number of function points delivered per person per month.

Compliance with Policies and Procedures follow the rules and regulation of government Providing good and usable product - Making Usable Products: An Informal Process for Good
User Interfaces. During the development of a product I'm the only resource for making user interface design decisions, simply because I'm the developer that's writing the user interface code. Most of the time there is great time pressure to complete the project, and any testers or documentation writers working on the project press hard for decisions to be made fast so they can start doing their jobs. In the frenzy of software development, how can we make sure that our product has a good user interface before its too late? We want to do the right thing, but we're afraid it will take us a lot more time, which we don't have.

Steve K. Johnson, TBDSystems, Chicago Illinois

Doing it right for the first time -

Do It Right The First Time - DRIFT What Does Do It Right The First Time - DRIFT Mean? A theory from managerial accounting that relates to just-in-time (JIT) inventory (where a company only receives goods as they are needed to cut down on inventory costs) and production management. The idea

SOFTWARE QUALITY ASSURANCE

behind DRIFT is that management wants all of the processes that make up the JIT philosophy to be done correctly and efficiently so there are no delays in the production process. The importance of DRIFT arises from the fact that a JIT production system is heavily reliant on the movement of parts and information along the production process. Subsequently, if there is the slightest error at one of the stages of production the whole production process will be affected. By "doing it right the first time" a company is able to run a smooth production process without needing to carry excessive inventory and greatly diminish the costs of production.
Comment [A41]: Then, next, later, after, afterward, consequently

Pleasing Clients satisfying the needs of the clients Total Customer Satisfaction contentment or fulfillment of the customer/clients

Quality Criteria Judgmental Criteria is synonymous with superiority or excellence. It is defined as both absolute and universally recognizable, a mark of uncompromising standards and high achievement. Excellence is abstract (intangible) and subjective, however and standards of excellence may vary considerably among individuals. Product-based Criteria is a function of a specific, measurable variable and that differences in quality reflect differences in quantity of some product attribute. This implies that higher levels or amounts of product characteristics are equivalent to higher quality. User-based Criteria is based on the presumption that quality is determined by what a customer want. It is therefore defined as fitness for intended use, or how well the product performs its intended function. Value-based Criteria is based on value; that is, the relationship of usefulness or satisfaction to price. From this perspective, a quality product is one that is as usefulness or satisfaction at a comparable price. Manufacturing-based Criteria is a manufacturing-based definition that is defined as the desirable outcome of engineering and manufacturing practice, or conformance to specifications. Specifications are targets and tolerance determined by designers or products and services.
Comment [A42]: Identical Comment [A43]: Familiar Comment [A44]: In this sense, quality is both absolute and universally recognizable, a mark of uncompromising standards and high achievement. As such, it cannot be defined precisely you just know it when you see it. It is often loosely related to a comparison of features and characteristics of products and promulgated by marketing efforts aimed at developing quality as an image variable in the minds of consumers.

SOFTWARE QUALITY ASSURANCE MIDTERM Lesson 1 SOFTWARE QUALITY ASSURANCE What is Software Quality Assurance? SQA consists of a means of monitoring the software engineering processes and methods used to ensure quality. The methods by which this is accomplished are many and varied, and may include ensuring conformance to one or more standards, such as ISO 9000. SQA encompasses the entire SOFTWARE DEVELOPMENT PROCESS, which includes processes such as; software design coding source code control code reviews change management configuration management testing release management and; product integration
Comment [A45]: The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented Comment [a46]: Way, instrument, measures, method Comment [A47]: ISO 9000 is a family of standards for quality management systems. -a set of procedures that cover all key processes in the business; monitoring processes to ensure they are effective; keeping adequate records; checking output for defects, with appropriate and corrective action where necessary; regularly reviewing individual processes and the quality system itself for effectiveness; and facilitating continual improvement

Comment [A48]: Include, cover

SQA is organized into goals, commitments, abilities, activities, measurements, and verification. Software development (also known as Application Development; Software Design, Designing Software, Software Engineering, Software Application Development, Enterprise Application Development, Platform Development, Software Development, is the development of a software product in a planned and structured process. This software could be produced for a variety of purposes - the (3) three most common purposes are; 1. To meet specific needs of a specific client/business 2. To meet a perceived need of some set of potential users (the case with commercial and open source software) 3. or for personal use (e.g. a scientist may write software to automate a mundane task). The term software development is often used to refer to the activity of computer programming, which is the process of writing and maintaining the source code, whereas the broader sense of the term includes all that is involved between the conceptions of the desired software through to the final manifestation of the software. Therefore, software development may include research, new development, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.

Comment [a49]: Prepared, controlled Comment [a50]: Purposes, objective Comment [a51]: Assurance Comment [a52]: Capability Comment [a53]: Behavior Comment [a54]: Capacity, size, dimensions Comment [A55]: Confirmation, authentication

Comment [A56]: Different Comment [A57]: To become aware of directly through any of the senses, especially sight or hearing. Comment [A58]: Every day, routine Comment [A59]: But, while Comment [A60]: Concept, perception

SOFTWARE QUALITY ASSURANCE For larger software systems, usually developed by a team of people, some form of process is typically followed to guide the stages of production of the software. Especially the first phase in the software development process may involve many departments, including marketing, engineering, research and development and general management.

Comment [A61]: Marketing is the process by which companies create customer interest in products or services. It generates the strategy that underlies sales techniques, business communication, and business development.[1] It is an integrated process through which companies build strong customer relationships and create value for their customers and for themselves. Marketing is used to identify the customer, to keep the customer, and to satisfy the customer Comment [A62]: Engineering is the discipline, art and profession of acquiring and applying technical, scientific, and mathematical knowledge to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective or invention. Comment [A63]: The phrase research and development (also R and D or, more often, R&D), according to the Organization for Economic Cooperation and Development, refers to "creative work undertaken on a systematic basis in order to increase the stock of knowledge, including knowledge of man, culture and society, and the use of this stock of knowledge to devise new applications". R&D has a special economic significance apart from its conventional association with scientific and technological development. R&D investment generally reflects a government's or organization's willingness to forgo current operations or profit to improve future performance or returns, and its abilities to conduct research and development. Comment [A64]: Management in all business areas and organizational activities are the acts of getting people together to accomplish desired goals and objectives. Management comprises planning, organizing, staffing, leading or directing, and controlling an organization (a group of one or more people or entities) or effort for the purpose of accomplishing a goal. Resourcing encompasses the deployment and manipulation of human resources, financial resources, technological resources, and natural resources. Comment [A65]: Observance, obedience, loyalty

Implement, Study Efficacy, and Improve - [put into action, put into practice, put into operation, apply], [effectiveness, efficiency, usefulness], [develop] Scale-up and Study Effectiveness [increase, expand, improve] Synthesize and Theorize [manufacture, create, produce], [visualize- see in your minds eye, create in your mind] Explore, Hypothesize, and Clarify [Search], [imagine], [simplify] Design, Develop, and Test

CONCEPTS AND DEFINITIONS Software Quality Assurance (SQA) is defined as a planned and systematic approach to the evaluation of the quality and adherence to software product standards, processes, and procedures. SQA includes the process of assuring that standards and procedures are established and are followed throughout the software acquisition life cycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits. Software development and control processes should include quality assurance approval points, where an SQA evaluation of the product may be done in relation to the applicable standards.

Comment [A66]: achievement

SOFTWARE QUALITY ASSURANCE Standards and Procedures Establishing standards and procedures for software development is critical, since these provide the framework from which the software evolves. Standards are the established criteria to which the software products are compared. Procedures are the established criteria to which the development and control processes are compared. Standards and procedures establish the prescribed methods for developing software. SQA role is to ensure their existence and adequacy. Proper documentation of standards and procedures is necessary, since the SQA activities is process monitoring, product evaluation and auditing rely upon unequivocal definitions to measure project compliance. Types of standards include: Documentation Standards specify form and content for planning, control, and product documentation and provide consistency throughout a project. The NASA (National Aeronautics and Space Administration) Data Item Descriptions (DIDs) are documentation standards. Design Standards specify the form and content of the design product. They provide rules and methods for translating the software requirements into the software design and for representing it in the design documentation. Code Standards specify the language in which the code is to be written and define any restrictions on use of language features. They define legal language structures, style conventions, rules for data structures and interfaces, and internal code documentation. Procedures are explicit steps to be followed in carrying out a process. All processes should have documented procedures. Examples of processes for which procedures are needed are CONFIGURATION MANAGEMENT, NONCONFORMANCE REPORTING AND CORRECTIVE ACTION, TESTING, and FORMAL INSPECTIONS. CONFIGURATION MANAGEMENT (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.

Comment [A67]: Structure Comment [A68]: Grow, develop Comment [A69]: A technical standard is an established norm or requirement. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes and practices. Comment [A70]: Fixed, step-by-step sequence of activities or course of action (with definite start and end points) that must be followed in the same order to correctly perform a task. Repetitive procedures are called routines. A procedure is a specified series of actions or operations which have to be executed in the same manner in order to always obtain the same result under the same circumstances. Sequence of tasks, steps, decisions, calculations and processes, that when undertaken in the sequence laid down produces the described result, product or outcome. Comment [A71]: set, agreed, approved Comment [A72]: Survival, continuation, life Comment [A73]: Sufficiency, capability Comment [A74]: Absolute, having only one possible meaning or interpretation - (without doubt)

Comment [A75]:

Comment [A76]: clear

Comment [A77]: Configuration management is the process of managing change in hardware, software, firmware, documentation measurements, etc.

SOFTWARE QUALITY ASSURANCE For CM information assurance:

CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

Sometimes referred to a Secure Configuration Management, relies upon performance, functional, and physical attributes of IT platforms and products and their environments to determine the appropriate security features and assurances that are used to measure a system configuration state. For example: Configuration requirements may be different for a network firewall that functions as part of an organization's Internet boundary versus one that functions as an internal local network firewall. Configuration management was first developed by the United States Air Force for the Department of Defense in the 1950s as a technical management discipline of hardware. The concepts of this discipline have been widely adopted by numerous technical management functions, including systems engineering (SE), integrated logistics support (ILS), Capability Maturity Model Integration (CMMI), ISO 9000, Prince2 project management methodology, COBIT, Information Technology Infrastructure Library (ITIL), product lifecycle management, and application lifecycle management. Many of these functions and models have redefined configuration management from its traditional holistic approach to technical management. Some treat configuration management as being similar to a librarian activity, and break out change control or change management as a separate or stand alone discipline. However the bottom-line is and always shall be Traceability.

Comment [A78]: condition, situation

Comment [A79]: Regulation

Comment [A80]: ISO 9000 is a family of standards for quality management systems. -a set of procedures that cover all key processes in the business; monitoring processes to ensure they are effective; keeping adequate records; checking output for defects, with appropriate and corrective action where necessary; regularly reviewing individual processes and the quality system itself for effectiveness; and facilitating continual improvement Comment [A81]: whole, entire

Configuration management is widely used by many military organizations to manage the technical aspects of any complex systems, such as weapon systems, vehicles, and information systems. The discipline combines the capability aspects that these systems provide an organization with the issues of management of change to these systems over time. Outside of the military, CM is appropriate to a wide range of fields and industry and commercial sectors.

SOFTWARE QUALITY ASSURANCE

Configuration Management Activity Model

SOFTWARE QUALITY ASSURANCE Types of Configuration Management: Software Configuration Management Hardware Configuration Management

Software configuration management The traditional software configuration management (SCM) process is looked upon by practitioners as the best solution to handling changes in software projects. It identifies the functional and physical attributes of software at various points in time, and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle. The SCM process further defines the need to trace changes, and the ability to verify that the final delivered software has all of the planned enhancements that are supposed to be included in the release. It identifies four procedures that must be defined for each software project to ensure that a sound SCM process is implemented. They are: 1. 2. 3. 4. Configuration identification Configuration control Configuration status accounting Configuration audits
Comment [A82]: SCM products are assessed to assure product integrity throughout the life cycle.

Comment [a83]: veracity, reliability (consistency) Comment [A84]: more, added Comment [a85]: improvement, development

Comment [A86]: good Comment [A87]: design Comment [a88]: quality, characteristic, feature, aspect Comment [a89]: is a line that is a base for measurement or for construction. In configuration management is the process of managing change. Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison. A baseline may also be established (whose work products meet certain criteria) as the basis for subsequent select activities. Such activities may be attributed with formal approval. Standard of value to which other similar things are compared. Comment [A90]: Baselining is a method for analyzing computer network performance. The method is marked by comparing current performance to a historical metric, or "baseline". For example, if you measured the performance of a network switch over a period of time, you could use that performance figure as a comparative baseline if you made a configuration change to the switch. Baselining is useful for many performance management tasks, including: Monitoring daily network performance Measuring trends in network performance Assessing whether network performance is meeting requirements laid out in a service agreement

These terms and definitions change from standard to standard, but are essentially the same.

Configuration identification is the process of identifying the attributes that define every aspect of a configuration item. A configuration item is a product (hardware and/or software) that has an end-user purpose. These attributes are recorded in configuration documentation and baseline. Baselining an attribute forces formal configuration change control processes to be effected in the event that these attributes are changed. Configuration change control is a set of processes and approval stages required to change a configuration item's attributes and to re-baseline them. Configuration status accounting is the ability to record and report on the configuration baselines associated with each configuration item at any moment of time.

SOFTWARE QUALITY ASSURANCE

Configuration audits are broken into functional and physical configuration audits. They occur either at delivery or at the moment of effecting the change. A functional configuration audit ensures that functional and performance attributes of a configuration item are achieved, while a physical configuration audit ensures that a configuration item is installed in accordance with the requirements of its detailed design documentation.

Comment [A91]: Configuration audits verify that the configuration identification for a configured item is accurate, complete, and will meet specified program needs. TYPES OF CONFIGURATION AUDITS There are two types of configuration audits: 1.Functional Configuration Audit (FCA) 2.Physical Configuration Audit (PCA).

Configuration management should work closely with change management. All components of the IT infrastructure should be registered in the CMDB. The responsibilities of configuration management with regard to the CMDB are: Identification Configuration management component enables you to identify, control, maintain, and verify the configuration items that you manage. Control - Implementing a controlled change process. This is usually achieved by setting up a change control board whose primary function is to approve or reject all change requests that are sent against any baseline. Status accounting - Recording and reporting all the necessary information on the status of the development process. Verification Ensuring that configurations contain all their intended parts and are sound with respect to their specifying documents, including requirements, architectural specifications and user manuals.

1.The FCA is the formal examination of the "astested" functional characteristics of a configuration item (CI). The audit is to verify that the item has achieved the requirements specified in its functional baseline documentation, and to identify and record any discrepancies. Functional configuration audits are conducted on both hardware and a software configuration item to assure that the technical documentation accurately reflects the functional characteristics of each. 2.The PCA is the formal examination of the "asbuilt" configuration of a configuration item (hardware and software) against its technical documentation. The PCA normally includes a detailed audit of engineering drawings, specifications, and technical data (including COTScommercial off-the-shelf (ready-made products) documentation). The PCA for a CI shall not be started unless the FCA has already been accomplished. After successful completion of the audit and the establishment of a Product Base Line (PBL), all subsequent changes are processed by formal engineering change action.

Computer hardware configuration management Computer hardware configuration management is the process of creating and maintaining an up-to-date record of all the components of the infrastructure, including related documentation. Its purpose: - is to show what makes up the infrastructure and illustrate the physical locations and; - links between each item, which are known as configuration items. Computer hardware configuration goes beyond the recording of computer hardware for the purpose of asset management, although it can be used to maintain asset information. The extra value provided is the rich source of support information that it provides to all interested parties. This information is typically stored together in a configuration management database (CMDB). This concept was introduced by ITIL (Information Technology Infrastructure Library). The scope of configuration management is assumed to include, at a minimum, all configuration items used in the provision of live, operational services.
Comment [A92]: communications, road and rail network Comment [a93]: pattern, design

SOFTWARE QUALITY ASSURANCE Computer hardware configuration management provides direct control over information technology (IT) assets and improves the ability of the service provider to deliver quality IT services in an economical and effective manner. The scope of configuration management is assumed to include:

Comment [A94]: capacity, range, span Comment [A95]: For the process of assigning documents or software version numbers. see Revision control or Software versioning. A form of something that is different from other forms or from the original. The software comes in several versions for different types of computers. an updated/simplified or modified version

physical client and server hardware products and versions operating system software products and versions application development software products and versions technical architecture product sets and versions as they are defined and introduced live documentation networking products and versions live application products and versions definitions of packages of software releases definitions of hardware base configurations configuration item standards and definitions

The benefits of computer hardware configuration management are:

helps to minimize the impact of changes provides accurate information on CIs improves security by controlling the versions of CIs in use facilitates adherence to legal obligations helps in financial and expenditure planning

Comment [a96]: effect Comment [A97]: Configuration items A configuration item (CI) is any component of an information technology infrastructure that is under the control of configuration management. Configuration items (CIs) can be individually managed and versioned, and they are usually treated as self contained units for the purposes of identification and change control. All configuration items (CIs) are uniquely identified by names, version numbers, and other attributes. The lowest level CI is usually the smallest unit that will be changed independently of other components. CIs vary in complexity, size, and type. They can range from an entire service which may consist of hardware, software, and documentation to a single program module or a minor hardware component. A CI can also be one of the following levels: Composite CI Root CI Contained CI Composite configuration item A composite configuration item (CI) is a CI that consist of other CIs. It is made up of a root CI and other supporting CIs which are called contained CIs. Root configuration item A root configuration item (CI) is a required element of a composite CI. Contained configuration item A contained CI is a supporting element of a composite CI.

Configuration item The term configuration item or CI refers to the fundamental structural unit of a configuration management system. Examples of CIs include individual requirements documents, software, models, plans, and people. The Configuration management system oversees the life of the CIs through a combination of process and tools by implementing and enabling the fundamental elements of identification, change management, status accounting, and audits. The objective of this system is to avoid the introduction of errors related to lack of testing as well as incompatibilities with other CIs. Role in configuration management The term configuration item can be applied to anything designated for the application of the elements of configuration management and treated as a single entity in the configuration management system.

The entity must be uniquely identified so that it can be distinguished from all other configuration items. From the perspective of the implementer of a change, the CI is the "what" of the change. Altering a specific baseline version of a configuration item creates a new version of the same configuration item, itself a baseline. In examining the effect of a change, two of the questions that must be asked are:

SOFTWARE QUALITY ASSURANCE

1. What configuration items are affected? 2. How have the configuration items been affected?

Its use within a product can be traced in a robust status accounting system. It is subject to acceptance verification based on established criteria.

If developed according to the NASA DID, the Management Plan describes the software development control processes, such as configuration management, for which there have to be Procedures, and contains a list of the product standards. Standards are to be documented according to the Standards and Guidelines DID in the Product Specification. The planning activities required to assure that both products and processes comply with designated standards and procedures are described in the QA portion of the Management Plan. Software Quality Assurance Activities Product evaluation and process monitoring are the SQA activities that assure the software development and control processes described in the project's Management Plan are correctly carried out and that the project's procedures and standards are followed. Products are monitored for conformance to standards and processes are monitored for conformance to procedures. Audits are a key technique used to perform product evaluation and process monitoring. Review of the Management Plan should ensure that appropriate SQA approval points are built into these processes. Product evaluation is an SQA activity that assures standards are being followed. Ideally, the first products monitored by SQA should be the project's standards and procedures. SQA assures that clear and achievable standards exist and then evaluates compliance of the software product to the established standards. Product evaluation assures that the software product reflects the requirements of the applicable standard(s) as identified in the Management Plan. Process monitoring is an SQA activity that ensures that appropriate steps to carry out the process are being followed. SQA monitors processes by comparing the actual steps carried out with those in the documented procedures. The Assurance section of the Management Plan specifies the methods to be used by the SQA process monitoring activity. A fundamental SQA technique is the audit, which looks at a process and/or a product in depth, comparing them to established procedures and standards. Audits are used to review management, technical, and assurance processes to provide an indication of the quality and status of the software product. The purpose of an SQA audit is to assure that proper control procedures are being followed, that required documentation is maintained, and that the developer's status reports accurately reflect the status of the activity. The SQA product is an audit report to management consisting
Comment [a98]: Basic, primary Comment [a99]: Intensity, strength

SOFTWARE QUALITY ASSURANCE of findings and recommendations to bring the development into conformance with standards and/or procedures. SQA Relationships to Other Assurance Activities Some of the more important relationships of SQA to other management and assurance activities are described below. 1. Configuration Management Monitoring SQA assures that software Configuration Management (CM) activities are performed in accordance with the CM plans, standards, and procedures. SQA reviews the CM plans for compliance with software CM policies and requirements and provides follow-up for nonconformance. SQA audits the CM functions for adherence to standards and procedures and prepares reports of its findings. The CM activities monitored and audited by SQA include baseline control, configuration identification, configuration control, configuration status accounting, and configuration authentication. SQA also monitors and audits the software library. SQA assures that: Baselines are established and consistently maintained for use in subsequent baseline development and control. Software configuration identification is consistent and accurate with respect to the numbering or naming of computer programs, software modules, software units, and associated software documents. Configuration control is maintained such that the software configuration used in critical phases of testing, acceptance, and delivery is compatible with the associated documentation. Configuration status accounting is performed accurately including the recording and reporting of data reflecting the software's configuration identification, proposed changes to the configuration identification, and the implementation status of approved changes. Software configuration authentication is established by a series of configuration reviews and audits that exhibit the performance required by the software requirements specification and the configuration of the software is accurately reflected in the software design documents.
Comment [A103]: Is a line that is a base for measurement or for construction. In configuration management is the process of managing change. Generally, a baseline may be a single work product, or set of work products that can be used as a logical basis for comparison. A baseline may also be established (whose work products meet certain criteria) as the basis for subsequent select activities. Such activities may be attributed with formal approval. Standard of value to which other similar things are compared. Comment [A100]: Configuration Management Monitoring performed in accordance with the CM plans, standards and procedures. Also reviews the CM plans for compliance with software and policies and requirements and provides follow-up for nonconformance and prepare report of its findings Comment [A101]: Conformance In information technology, a state or acts of adherence (observance) to a certain specification, standard, or guideline. Sometimes used as a synonym for compliance.

Comment [a102]: Files, records

SOFTWARE QUALITY ASSURANCE Software development libraries provide for proper handling of software code, documentation, media, and related data in their various forms and versions from the time of their initial approval or acceptance until they have been incorporated into the final media. Approved changes to baseline software are made properly and consistently in all products, and no unauthorized changes are made. 2. Verification and Validation Monitoring SQA assures Verification and Validation (V&V) activities by monitoring technical reviews, inspections, and walkthroughs. The SQA role in reviews, inspections, and walkthroughs is to observe, participate as needed, and verify that they were properly conducted and documented. SQA also ensures that any actions required are assigned, documented, scheduled, and updated. Formal software reviews should be conducted at the end of each phase of the life cycle to identify problems and determine whether the interim product meets all applicable requirements. Examples of formal reviews are the Preliminary Design Review (PDR), Critical Design Review (CDR), and Test Readiness Review (TRR). A REVIEW looks at the overall picture of the product being developed to see if it satisfies its requirements. REVIEWS are part of the development process, designed to provide a ready/not-ready decision to begin the next phase. In formal reviews, actual work done is compared with established standards. SQA's main objective in reviews is to assure that the Management and Development Plans have been followed, and that the product is ready to proceed with the next phase of development. Although the decision to proceed is a management decision, SQA is responsible for advising management and participating in the decision. An inspection or walkthrough is a detailed examination of a product on a step-by-step or lineof-code by line-of-code basis to find errors. For inspections and walkthroughs, SQA assures, at a minimum that the process is properly completed and that needed follow-up is done. The inspection process may be used to measure compliance to standards. 3. Formal Test Monitoring SQA assures that formal software testing, such as acceptance testing, is done in accordance with plans and procedures. SQA reviews testing documentation for completeness and adherence to standards. The documentation review includes test plans, test specifications, test procedures, and test reports. SQA monitors testing and provides follow-up on nonconformance. By test monitoring, SQA assures software completeness and readiness for delivery. The objectives of SQA in monitoring formal software testing are to assure that: The test procedures are testing the software requirements in accordance with test plans.
Comment [A104]: Assures that the V&V monitor the technical reviews, inspections and the walkthroughs. What is the SQA role? Comment [a105]: Describing the consideration of a process at abstract level In video games, a walkthrough is a document which attempts to teach a player how to beat or solve a particular game Auditing In an audit, a walkthrough is the act of reviewing a process or activity in scope. The purpose is to confirm if a documented process is in use and is accurately reflecting current workflow. The walkthrough may also be used to test the accuracy of current or previously used control activities. Inflections (variation, variety) instructions for using software or computer game A set of instructions on how to use a piece of software or how to complete a computer game. Use an interactive model and simulation framework for requirements

Comment [A106]: Observance

SOFTWARE QUALITY ASSURANCE The test procedures are verifiable. The correct or "advertised" version of the software is being tested (by SQA monitoring of the CM activity). The test procedures are followed. Nonconformance occurring during testing (that is, any incident not expected in the test procedures) are noted and recorded. Test reports are accurate and complete. Regression testing is conducted to assure nonconformance have been corrected. Resolution of all nonconformances takes place prior to delivery. Software testing verifies that the software meets its requirements. The quality of testing is assured by verifying that project requirements are satisfied and that the testing process is in accordance with the test plans and procedures. E. Software Quality Assurance during the Software Acquisition Life Cycle 1. Software Concept and Initiation Phase SQA should be involved in both writing and reviewing the Management Plan in order to assure that the processes, procedures, and standards identified in the plan are appropriate, clear, specific, and auditable. During this phase, SQA also provides the QA section of the Management Plan. 2. Software Requirements Phase During the software requirements phase, SQA assures that software requirements are complete, testable, and properly expressed as functional, performance, and interface requirements. 3. Software Architectural (Preliminary) Design Phase SQA activities during the architectural (preliminary) design phase include: o Assuring adherence to approved design standards as designated in the Management Plan. o Assuring all software requirements are allocated to software components. o Assuring that a testing verification matrix exists and is kept up to date. o Assuring the Interface Control Documents is in agreement with the standard in form and content. o Reviewing PDR documentation and assuring that all action items are resolved. o Assuring the approved design is placed under configuration management.
Comment [A107]: Certifiable

Comment [a108]: Preliminary Design Review

SOFTWARE QUALITY ASSURANCE 4. Software Detailed Design Phase SQA activities during the detailed design phase include: o o o o Assuring that approved design standards are followed. Assuring that allocated modules are included in the detailed design. Assuring that results of design inspections are included in the design. Reviewing CDR documentation and assuring that all action items are resolved.

Comment [a109]: Critical Design Review

5. Software Implementation Phase SQA activities during the implementation phase include the audit of: o Results of coding and design activities including the schedule contained in the Software Development Plan. o Status of all deliverable items. o Configuration management activities and the software development library. o Nonconformance reporting and corrective action system. 6. Software Integration and Test Phase SQA activities during the integration and test phase include: o Assuring readiness for testing of all deliverable items. o Assuring that all tests are run according to test plans and procedures and that any nonconformances are reported and resolved. o Assuring that test reports are complete and correct. o Certifying that testing is complete and software and documentation are ready for delivery. o Participating in the Test Readiness Review and assuring all action items are completed. 7. Software Acceptance and Delivery Phase As a minimum, SQA activities during the software acceptance and delivery phase include assuring the performance of a final configuration audit to demonstrate that all deliverable items are ready for delivery. 8. Software Sustaining Engineering and Operations Phase During this phase, there will be mini-development cycles to enhance or correct the software. During these development cycles, SQA conducts the appropriate phasespecific activities described above.

SOFTWARE QUALITY ASSURANCE F. Techniques and Tools SQA should evaluate its needs for assurance tools versus those available for applicability to the specific project, and must develop the others it requires. Useful tools might include audit and inspection checklists and automatic code standards analyzers.

SOFTWARE QUALITY ASSURANCE MIDTERM Lesson 2 SOFTWARE DEVELOPMENT PROCESS SOFTWARE DEVELOPMENT PROCESS SOFTWARE DESIGN
Software design is a process of problem-solving and planning for a software solution. After the purpose and specifications of software are determined, software developers will design or employ designers to develop a plan for a solution. It includes low-level component and algorithm implementation issues as well as the architectural view.
Comment [A110]: Produce, generate

The software requirements analysis (SRA) step of a software development process yields specifications that are used in software engineering. If the software is "semi automated" or user centered, software design may involve user experience design yielding a story board to help determine those specifications. If the software is completely automated (meaning no user or user interface), a software design may be as simple as a flow chart or text describing a planned sequence of events. There are also semi-standard methods like Unified Modeling Language and Fundamental modeling concepts. In either case some documentation of the plan is usually the product of the design. A software design may be platform-independent or platform-specific, depending on the availability of the technology called for by the design. Software design topics Design concepts The design concepts provide the software designer with a foundation from which more sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are: 1. Abstraction - Abstraction is the process or result of generalization by reducing the information content of a concept or an observable phenomenon, typically in order to retain only information which is relevant for a particular purpose. 2. Refinement - It is the process of elaboration. A hierarchy is developed by decomposing a macroscopic statement of function in a stepwise fashion until programming language statements are reached. In each step, one or several instructions of a given program are decomposed into more detailed instructions. Abstraction and Refinement are complementary concepts. 3. Modularity - Software architecture is divided into components called modules. 4. Software Architecture - It refers to the overall structure of the software and the ways in which that structure provides conceptual integrity for a system. Software architecture is the development work product that gives the highest return on investment with respect to quality, schedule and cost. 5. Control Hierarchy - A program structure that represent the organization of program components and implies a hierarchy of control. 6. Structural Partitioning - The program structure can be divided both horizontally and vertically. Horizontal partitions define separate branches of modular hierarchy for each major program

Comment [A111]: Software that is platform independent does not rely on any special features of any single platform, or, if it does, handles those special features such that it can deal with multiple platforms In computing, a platform describes some sort of hardware architecture and software framework (including application frameworks), that allows software to run. Typical platforms include a computer's architecture, operating system, programming languages and related user interface (runtime libraries or graphical user interface). Comment [A112]: Abstraction is a conceptual process by which higher, more abstract concepts are derived from the usage and classification of literal, "real," or "concrete" concepts. Comment [A113]: The verifiable transformation of a formal specification into source code which can be compiled into an executable program. Comment [A114]: Furthermore explanation Comment [A115]: Modularity is designing a system that is divided into a set of functional units (named modules) that can be composed into a larger application. A module represents a set of related concerns. It can include components, such as views or business logic, and pieces of infrastructure, such as services for logging or authenticating users. Modules are independent of one another but can communicate with each other in a loosely coupled fashion. A composite application exhibits modularity. Imagine an online banking program. The user can access a variety of functions, such as transferring money between accounts, paying bills, and updating personal information from a single user interface (UI). However, behind the scenes, each of these functions is a discrete module. These modules communicate with each other and with back-end systems such as database servers. Application services integrate components within the different modules and handle the communication with the user. Comment [A116]: The software architecture of a program or computing system is the structure or structures of the system, which comprise software components,

SOFTWARE QUALITY ASSURANCE

function. Vertical partitioning suggests that control and work should be distributed top down in the program structure. 7. Data Structure - It is a representation of the logical relationship among individual elements of data. 8. Software Procedure - It focuses on the processing of each modules individually 9. Information Hiding - Modules should be specified and designed so that information contained within a module is inaccessible to other modules that have no need for such information. Design considerations There are many aspects to consider in the design of a piece of software. The importance of each should reflect the goals the software is trying to achieve. Some of these aspects are:

Compatibility - The software is able to operate with other products that are designed for interoperability with another product. For example, a piece of software may be backwardcompatible with an older version of itself. Extensibility - New capabilities can be added to the software without major changes to the underlying architecture. Fault-tolerance - The software is resistant to and able to recover from component failure. Maintainability - The software can be restored to a specified condition within a specified period of time. For example, antivirus software may include the ability to periodically receive virus definition updates in order to maintain the software's effectiveness. Modularity - the resulting software comprises well defined, independent components. That leads to better maintainability. The components could be then implemented and tested in isolation before being integrated to form a desired software system. This allows division of work in a software development project. Packaging - Printed material such as the box and manuals should match the style designated for the target market and should enhance usability. All compatibility information should be visible on the outside of the package. All components required for use should be included in the package or specified as a requirement on the outside of the package. Reliability - The software is able to perform a required function under stated conditions for a specified period of time. Reusability - the modular components designed should capture the essence of the functionality expected out of them and no more or less. This single-minded purpose renders the components reusable wherever there are similar needs in other designs. Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input. For example, it can be designed with resilience to low memory conditions. Security - The software is able to withstand hostile acts and influences. Usability - The software user interface must be usable for its target user/audience. Default values for the parameters must be chosen so that they are a good choice for the majority of the users.

Comment [A117]: ability to operate together The ability to operate successfully together.

CODING
Coding theory is studied by various scientific disciplines such as information theory, electrical engineering, mathematics, and computer science for the purpose of designing efficient and reliable data transmission methods. This typically involves the removal of redundancy and the correction (or

SOFTWARE QUALITY ASSURANCE

detection) of errors in the transmitted data. It also includes the study of the properties of codes and their fitness for a specific application. Thus, there are essentially two aspects to Coding theory: 1. Data compression (or, source coding) 2. Error correction (or, channel coding) These two aspects may be studied in combination. The first, source encoding, attempts to compress the data from a source in order to transmit it more efficiently. This practice is found every day on the Internet where the common "Zip" data compression is used to reduce the network load and make files smaller. The second, channel encoding, adds extra data bits to make the transmission of data more robust to disturbances present on the transmission channel. The ordinary user may not be aware of many applications using channel coding. A typical music CD uses the Reed-Solomon code to correct for scratches and dust. In this application the transmission channel is the CD itself. Cell phones also use coding techniques to correct for the fading and noise of high frequency radio transmission. Data modems, telephone transmissions, and NASA all employ channel coding techniques to get the bits through, for example the turbo code and LDPC codes.

SOURCE CODE CONTROL

Revision control, also known as version control, source control or software configuration management (SCM) is the management of changes to documents, programs, and other information stored as computer files. It is most commonly used in software development, where a team of people may change the same files. Changes are usually identified by a number or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision is associated with a timestamp and the person making the change. Revisions can be compared, restored, and with some types of files, merged. Version control systems (VCSs - singular VCS) most commonly run as stand-alone applications, but revision control is also embedded in various types of software such as word processors (e.g., Microsoft Word, OpenOffice.org Writer, KWord, Pages, etc.), spreadsheets (e.g., Microsoft Excel, OpenOffice.org Calc, KSpread, Numbers, etc.), and in various content management systems (e.g., Drupal, Joomla, WordPress). Integrated revision control is a key feature of wiki software packages such as MediaWiki, DokuWiki, TWiki etc. In wikis, revision control allows for the ability to revert a page to a previous revision, which is critical for allowing editors to track each other's edits, correct mistakes, and defend public wikis against vandalism and spam. Software tools for revision control are essential for the organization of multi-developer projects

Comment [A118]: "Source code control" refers to the practice of storing files containing program source code (and other project artifacts) in a common repository. Using source code control (SCC), multiple developers can work on the same project (including the same project file) at the same time. The SCC repository can be queried for a detailed listing of the changes that occurred each time a file was edited. Files under source code control that have been locally modified can also be reverted to their previous state.

SOFTWARE QUALITY ASSURANCE CODE REVIEWS

Code review is systematic examination (often as peer review) of computer source code intended to find and fix mistakes overlooked in the initial development phase, improving both the overall quality of software and the developers' skills. Code reviews can often find and remove common vulnerabilities such as format string exploits, race conditions, memory leaks and buffer overflows, thereby improving software security. Online software repositories based on Subversion (with Redmine or Trac), Mercurial, Git or others allow groups of individuals to collaboratively review code. Additionally, specific tools for collaborative code review can facilitate the code review process. Automated code reviewing software lessens the task of reviewing large chunks of code on the developer by systematically checking source code for known vulnerabilities. Capers Jones' ongoing analysis of over 12,000 software development projects showed that the latent defect discovery rate of formal inspection is in the 60-65% range. For informal inspection, the figure is less than 50%. The latent defect discovery rate for most forms of testing is about 30%. Code review practices fall into two main categories: formal code review and lightweight code review. FORMAL CODE REVIEW, such as a Fagan inspection, involves a careful and detailed process with multiple participants and multiple phases. Formal code reviews are the traditional method of review, in which software developers attend a series of meetings and review code line by line, usually using printed copies of the material. Formal inspections are extremely thorough and have been proven effective at finding defects in the code under review. Typical operations In a typical Fagan inspection the inspection process consists of the following operations:

Comment [A121]: Fagan inspection refers to a structured process of trying to find defects in development documents such as programming code, specifications, designs and others during various phases of the software development process. It is named after Michael Fagan who is credited with being the inventor of formal software inspections. Comment [A119]: Software peer review In software development, peer review is a type of software review in which a work product (document, code, or other) is examined by its author and one or more colleagues, in order to evaluate its technical content and quality. Comment [A120]: Vulnerability is the susceptibility to physical or emotional injury or attack. It also means to have one's guard down, open to censure or criticism. Vulnerability refers to a person's state of being liable to succumb, as to manipulation, persuasion or temptation.

Planning o Preparation of materials o Arranging of participants o Arranging of meeting place Overview o Group education of participants on the materials under review o Assignment of roles Preparation o The participants prepare their roles Inspection meeting o Actual finding of defect Rework o Rework is the step in software inspection in which the defects found during the inspection meeting are resolved by the author, designer or programmer. On the basis of the list of defects the low-level document is corrected until the requirements in the high-level document are met.

SOFTWARE QUALITY ASSURANCE

Follow-up o In the follow-up phase of software inspections all defect found in the inspection meeting should be corrected (as they have been fixed in the rework phase). The moderator is responsible for verifying that this is indeed the case. He should verify if all defects are fixed and no new defects are inserted while trying to fix the initial defects. It is crucial that all defects are corrected as the costs of fixing them in a later phase of the project will be 10 to 100 times higher compared to the current costs.

Figure 1: Fagan inspection basic model LIGHTWEIGHT CODE REVIEW typically requires less overhead than formal code inspections, though it can be equally effective when done properly. Lightweight reviews are often conducted as part of the normal development process:

Comment [A122]: Operating cost, operating expense

Over-the-shoulder One developer looks over the author's shoulder as the latter walks through the code. Email pass-around Source code management system emails code to reviewers automatically after checking is made. Pair Programming Two authors develop code together at the same workstation; such is common in Extreme Programming. Tool-assisted code review Authors and reviewers use specialized tools designed for peer code review.

Comment [A123]: Pair programming is an agile software development technique in which two programmers work together at one work station. One types in code while the other reviews each line of code as it is typed in. The person typing is called the driver. The person reviewing the code is called the observer (or navigator). The two programmers switch roles frequently. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between selforganizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, selforganization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. Comment [A124]: Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent "releases" in short development cycles (timeboxing), which is intended to improve productivity and introduce checkpoints where new customer requirements can be adopted.

Some of these may also be labeled a "Walkthrough" (informal) or "Critique" (fast and informal).

CHANGE MANAGEMENT
Change management is a structured approach to transitioning individuals, teams, and organizations from a current state to a desired future state. In project management, change management refers to a project management process where changes to a project are formally introduced and approved. The field of change management grew from the recognition that organizations are composed of people. And the behaviors of people make up the outputs of an organization. Examples of Organizational Change 1. 2. 3. 4. Strategic changes Technological changes Structural changes Changing the attitudes and behaviors of personnel

SOFTWARE QUALITY ASSURANCE

As a multidisciplinary practice, Organizational Change Management requires for example: creative marketing to enable communication between change audiences, but also deep social understanding about leaderships styles and group dynamics. As a visible track on transformation projects, Organizational Change Management aligns groups expectations, communicates, integrates teams and manages people training. It makes use of metrics, such as leaders commitment, communication effectiveness, and the perceived need for change to design accurate strategies, in order to avoid change failures or solve troubled change projects. An effective change management plan needs to address all above mentioned dimensions of change. This can be achieved in following ways: 1. Putting in place an effective Communication strategy which would bridge any gap in the understanding of change benefits and its implementation strategy. 2. Devise an effective skill upgrading scheme for the organization. Overall these measures can counter resistance from the employees of companies and align them to overall strategic direction of the organization. 3. Personal counseling of staff members (if required) to alleviate any change related fears.

CONFIGURATION MANAGEMENT (refer to the previous lesson) TESTING

Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. Software testing also provides an objective, independent view of the software to allow the business to appreciate and understand the risks at implementation of the software. Test techniques include, but are not limited to, the process of executing a program or application with the intent of finding software bugs. Software testing can also be stated as the process of validating and verifying that a software program/application/product: 1. meets the business and technical requirements that guided its design and development; 2. works as expected; and 3. can be implemented with the same characteristics. Software testing topics Scope A primary purpose for testing is to detect software failures so that defects may be discovered and corrected. This is a non-trivial pursuit. Testing cannot establish that a product functions properly under all conditions but can only establish that it does not function properly under specific conditions. The scope of software testing often includes examination of code as well as execution of that code in various environments and conditions as well as examining the aspects of code: does it do what it is supposed to do and do what it needs to do. In the current culture of software development, a testing organization may be separate from the development team. There are various roles for testing team members. Information derived from software testing may be used to correct the process by which software is developed.
Comment [A125]: Software Testing is the process of finding a bugs in a software. One question comes to our mind why we do testing? Why we do testing? 1.Testing improve the quality of the software 2.Increase the reliability of the software

SOFTWARE QUALITY ASSURANCE

Functional vs non-functional testing Functional testing refers to tests that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of "can the user do this" or "does this particular feature work". Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or security. Non-functional testing tends to answer such questions as "how many people can log in at once". Defects and failures Not all software defects are caused by coding errors. One common source of expensive defects is caused by requirement gaps, e.g., unrecognized requirements that result in errors of omission by the program designer. A common source of requirements gaps is non-functional requirements such as testability, scalability, maintainability, usability, performance, and security. Software faults occur through the following processes. A programmer makes an error (mistake), which results in a defect (fault, bug) in the software source code. If this defect is executed, in certain situations the system will produce wrong results, causing a failure. Not all defects will necessarily result in failures. For example, defects in dead code will never result in failures. A defect can turn into a failure when the environment is changed. Examples of these changes in environment include the software being run on a new hardware platform, alterations in source data or interacting with different software. A single defect may result in a wide range of failure symptoms. Compatibility A common cause of software failure (real or perceived) is a lack of compatibility with other application software, operating systems (or operating system versions, old or new), or target environments that differ greatly from the original (such as a terminal or GUI application intended to be run on the desktop now being required to become a web application, which must render in a web browser). For example, in the case of a lack of backward compatibility, this can occur because the programmers develop and test software only on the latest version of the target environment, which not all users may be running. This result in the unintended consequence that the latest work may not function on earlier versions of the target environment or on older hardware those earlier versions of the target environment was capable of using. Sometimes such issues can be fixed by proactively abstracting operating system functionality into a separate program module or library. Input combinations and preconditions A very fundamental problem with software testing is that testing under all combinations of inputs and preconditions (initial state) is not feasible, even with a simple product. This means that the number of defects in a software product can be very large and defects that occur infrequently are difficult to find in testing. More significantly, non-functional dimensions of quality (how it is supposed to be versus what it is supposed to do)usability, scalability, performance, compatibility, reliabilitycan be highly subjective; something that constitutes sufficient value to one person may be intolerable to another.

SOFTWARE QUALITY ASSURANCE

Static vs. dynamic testing There are many approaches to software testing. Reviews, walkthroughs, or inspections are considered as static testing, whereas actually executing programmed code with a given set of test cases is referred to as dynamic testing. Static testing can be (and unfortunately in practice often is) omitted. Dynamic testing takes place when the program itself is used for the first time (which is generally considered the beginning of the testing stage). Dynamic testing may begin before the program is 100% complete in order to test particular sections of code (modules or discrete functions). Typical techniques for this are either using stubs/drivers or execution from a debugger environment. For example, spreadsheet programs are, by their very nature, tested to a large extent interactively ("on the fly"), with results displayed immediately after each calculation or text manipulation. Software verification and validation Software testing is used in association with verification and validation:

Comment [A126]: In software engineering, a walkthrough or walkthrough is a form of software peer review "in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems SOFTWARE PEER REVIEW In software development, peer review is a type of software review in which a work product (document, code, or other) is examined by its author and one or more colleagues, in order to evaluate its technical content and quality. Comment [A127]: Static testing is a form of software testing where the software isn't actually used. Comment [A128]: Jump to: navigation, search Dynamic testing (or dynamic analysis) is a term used in software engineering to describe the testing of the dynamic behavior of code Dynamic testing means testing based on specific test cases by execution of the test object or running programs. Dynamic testing is used to test software through executing it.

Verification: Have we built the software right? (i.e., does it match the specification). Validation: Have we built the right software? (i.e., is this what the customer wants).

The terms verification and validation are commonly used interchangeably in the industry; it is also common to see these two terms incorrectly defined. According to the IEEE Standard Glossary of Software Engineering Terminology: Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase. Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements. The software testing team Software testing can be done by software testers. Until the 1980s the term "software tester" was used generally, but later it was also seen as a separate profession. Regarding the periods and the different goals in software testing, different roles have been established: manager, test lead, test designer, tester, automation developer, and test administrator. TESTING METHODS Software testing is a process of finding the bugs in the software, bugs problem in the software. One caution comes in mind that why we should test? Because testing improved the quality of the software and also testing increase the reliability of the software.

SOFTWARE QUALITY ASSURANCE

Two types of testing: Software testing methods are traditionally divided into white and black-box testing. These two approaches are used to describe the point of view that a test engineer takes when designing test cases. White box testing White box testing is when the tester has access to the internal data structures and algorithms including the code that implement these. Types of white box testing The following types of white box testing exist:

Comment [A129]: We generate test the case based on the source code of the software.

API testing (application programming interface) - testing of the application using public and private APIs Code coverage - creating tests to satisfy some criteria of code coverage (e.g., the test designer can create tests to cause all statements in the program to be executed at least once) Fault injection methods - improving the coverage of a test by introducing faults to test code paths Mutation testing methods Static testing - White box testing includes all static testing
Comment [A130]: We generate test the case based on the functionality of the software

Black box testing Black box testing treats the software as a "black box"without any knowledge of internal implementation. Black box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based testing, traceability matrix, exploratory testing and specification-based testing. Specification-based testing: Specification-based testing aims to test the functionality of software according to the applicable requirements. Thus, the tester inputs data into, and only sees the output from, the test object. This level of testing usually requires thorough test cases to be provided to the tester, who then can simply verify that for a given input, the output value (or behavior), either "is" or "is not" the same as the expected value specified in the test case. Specification-based testing is necessary, but it is insufficient to guard against certain risks. Advantages and disadvantages: The black box tester has no "bonds" with the code, and a tester's perception is very simple: a code must have bugs. Using the principle, "Ask and you shall receive," black box testers find bugs where programmers do not. But, on the other hand, black box testing has been said to be "like a walk in a dark labyrinth without a flashlight," because the tester doesn't know how the software being tested was actually constructed. As a result, there are situations when (1) a tester writes many test cases to check something that could have been tested by only one test case, and/or (2) some parts of the back-end are not tested at all. Therefore, black box testing has the advantage of "an unaffiliated opinion," on the one hand, and the disadvantage of "blind exploring," on the other.

SOFTWARE QUALITY ASSURANCE

Grey box testing Grey box testing (American spelling: gray box testing) involves having knowledge of internal data structures and algorithms for purposes of designing the test cases, but testing at the user, or black-box level. Manipulating input data and formatting output do not qualify as grey box, because the input and output are clearly outside of the "black-box" that we are calling the system under test. This distinction is particularly important when conducting integration testing between two modules of code written by two different developers, where only the interfaces are exposed for test. However, modifying a data repository does qualify as grey box, as the user would not normally be able to change the data outside of the system under test. Grey box testing may also include reverse engineering to determine, for instance, boundary values or error messages. TESTING LEVELS Tests are frequently grouped by where they are added in the software development process, or by the level of specificity of the test. Unit testing is attest that validates that individual units of source code are working properly. A unit is the smallest testable part of an application. Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors. These types of tests are usually written by developers as they work on code (white-box style), to ensure that the specific function is working as expected. One function might have multiple tests, to catch corner cases or other branches in the code. Unit testing alone cannot verify the functionality of a piece of software, but rather is used to assure that the building blocks the software uses work independently of each other. Unit testing is also called component testing. Integration testing is the phase of software testing in which individual software modules are combined and tested as group. Integration testing is any type of software testing that seeks to verify the interfaces between components against a software design. Software components may be integrated in an iterative way or all together ("big bang"). Normally the former is considered a better practice since it allows interface issues to be localised more quickly and fixed. Integration testing works to expose defects in the interfaces and interaction between integrated components (modules). Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system.
Comment [A132]: We combined the individual software modules and testing as a group. Comment [A131]: We check the individually source code are working properly or not.

SOFTWARE QUALITY ASSURANCE

System testing testing conducted on a complete, integrated system to evaluate the systems compliance with its specified requirements. System testing tests a completely integrated system to verify that it meets its requirements. System integration testing System integration testing verifies that a system is integrated to any external or third party systems defined in the system requirements. Regression testing Regression testing focuses on finding defects after a major code change has occurred. Specifically, it seeks to uncover software regressions, or old bugs that have come back. Such regressions occur whenever software functionality that was previously working correctly stops working as intended. Typically, regressions occur as an unintended consequence of program changes, when the newly developed part of the software collides with the previously existing code. Common methods of regression testing include re-running previously run tests and checking whether previously fixed faults have re-emerged. The depth of testing depends on the phase in the release process and the risk of the added features. They can either be complete, for changes added late in the release or deemed to be risky, to very shallow, consisting of positive tests on each feature, if the changes are early in the release or deemed to be of low risk. Acceptance testing Acceptance testing can mean one of two things: 1. A smoke test is used as an acceptance test prior to introducing a new build to the main testing process, i.e. before integration or regression. 2. Acceptance testing performed by the customer, often in their lab environment on their own hardware, is known as user acceptance testing (UAT). Acceptance testing may be performed as part of the hand-off process between any two phases of development. Alpha testing Alpha testing is simulated or actual operational testing by potential users/customers or an independent test team at the developers' site. Alpha testing is often employed for off-the-shelf software as a form of internal acceptance testing, before the software goes to beta testing. van Veenendaal, Erik. "Standard glossary of terms used in Software Testing". http://www.astqb.org/educationalresources/glossary.php#A. Retrieved 17 June 2010. Beta testing Beta testing comes after alpha testing. Versions of the software, known as beta versions, are released to a limited audience outside of the programming team. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes, beta versions are made available to the open public to increase the feedback field to a maximal number of future users.
Comment [A134]: Regression testing is any type of software testing that seeks to uncover software errors by partially retesting a modified program Comment [A133]: We check the software by giving real customer data.

Comment [A135]: Commercial, off-the-shelf (COTS) or simply off the shelf (OTS) is a term defining technology which is ready-made and available for sale, lease, or license to the general public.

SOFTWARE QUALITY ASSURANCE

Non-functional testing Special methods exist to test non-functional aspects of software. In contrast to functional testing, which establishes the correct operation of the software (correct in that it matches the expected behavior defined in the design requirements), non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-functional testing. Non-functional testing, especially for software, is designed to establish whether the device under test can tolerate invalid or unexpected inputs, thereby establishing the robustness of input validation routines as well as error-handling routines. Various commercial nonfunctional testing tools are linked from the software fault injection page; there are also numerous opensource and free software tools available that perform non-functional testing. Software performance testing and load testing Performance testing is executed to determine how fast a system or sub-system performs under a particular workload. It can also serve to validate and verify other quality attributes of the system, such as scalability, reliability and resource usage. Load testing is primarily concerned with testing that can continue to operate under a specific load, whether that be large quantities of data or a large number of users. This is generally referred to as software scalability. The related load testing activity of when performed as a non-functional activity is often referred to as endurance testing. Volume testing is a way to test functionality. Stress testing is a way to test reliability. Load testing is a way to test performance. There is little agreement on what the specific goals of load testing are. The terms load testing, performance testing, reliability testing, and volume testing, are often used interchangeably. Stability testing Stability testing checks to see if the software can continuously function well in or above an acceptable period. This activity of non-functional software testing is often referred to as load (or endurance) testing. Usability testing is a techniques used to evaluate a product by testing it on users. Usability testing is needed to check if the user interface is easy to use and understand. Security testing Security testing is essential for software that processes confidential data to prevent system intrusion by hackers. A sample testing cycle Although variations exist between organizations, there is a typical cycle for testing. The sample below is common among organizations employing the Waterfall development model.
Comment [A137]: Computer hackers are able access the information stored on computers, if these aren't properly protected. Hackers often do this using automated intruder programs. These programs usually look for 'Trojans' installed on people's computers. Comment [A136]: The users check the software by giving direct in prompt to it.

SOFTWARE QUALITY ASSURANCE

Requirements analysis: Testing should begin in the requirements phase of the software development life cycle. During the design phase, testers work with developers in determining what aspects of a design are testable and with what parameters those tests work. Test planning: Test strategy, test plan, testbed creation. Since many activities will be carried out during testing, a plan is needed. Test development: Test procedures, test scenarios, test cases, test datasets, test scripts to use in testing software. Test execution: Testers execute the software based on the plans and test documents then report any errors found to the development team. Test reporting: Once testing is completed, testers generate metrics and make final reports on their test effort and whether or not the software tested is ready for release. Test result analysis: Or Defect Analysis, is done by the development team usually along with the client, in order to decide what defects should be treated, fixed, rejected (i.e. found software working properly) or deferred to be dealt with later. Defect Retesting: Once a defect has been dealt with by the development team, it is retested by the testing team. AKA Resolution testing. Regression testing: It is common to have a small test program built of a subset of tests for each integration of new, modified or fixed software, in order to ensure that the latest delivery has not ruined anything, and that the software product as a whole is still working correctly. Test Closure: Once the test meets the exit criteria, the activities such as capturing the key outputs, lessons learned, results, logs, documents related to the project are archived and used as a reference for future projects.

Automated testing Many programming groups are relying more and more on automated testing, especially groups that use test-driven development. There are many frameworks to write tests in, and continuous integration software will run tests automatically every time code is checked into a version control system. While automation cannot reproduce everything that a human can do (and all the strange ways they think of doing it), it can be very useful for regression testing. However, it does require a well-developed test suite of testing scripts in order to be truly useful. Testing tools Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing/debug tools include features such as:

Program monitors, permitting full or partial monitoring of program code including: o Instruction set simulator, permitting complete instruction level monitoring and trace facilities o Program animation, permitting step-by-step execution and conditional breakpoint at source level or in machine code o Code coverage reports Formatted dump or symbolic debugging, tools allowing inspection of program variables on error or at chosen points Automated functional GUI testing tools are used to repeat system-level tests through the GUI Benchmarks, allowing run-time performance comparisons to be made

SOFTWARE QUALITY ASSURANCE

Performance analysis (or profiling tools) that can help to highlight hot spots and resource usage

Some of these features may be incorporated into an Integrated Development Environment (IDE). Measurement in software testing Usually, quality is constrained to such topics as correctness, completeness, security, but can also include more technical requirements as described under the ISO standard ISO/IEC 9126, such as capability, reliability, efficiency, portability, maintainability, compatibility, and usability. There are a number of frequently-used software measures, often called metrics, which are used to assist in determining the state of the software or the adequacy of the testing. Testing artifacts
Comment [A138]: Work of art

Software testing process can produce several artifacts. Test plan A test specification is called a test plan. The developers are well aware what test plans will be executed and this information is made available to management and the developers. The idea is to make them more cautious when developing their code or making additional changes. Some companies have a higher-level document called a test strategy. Traceability matrix A traceability matrix is a table that correlates requirements or design documents to test documents. It is used to change tests when the source documents are changed, or to verify that the test results are correct. Test case A test case normally consists of a unique identifier, requirement references from a design specification, preconditions, events, a series of steps (also known as actions) to follow, input, output, expected result, and actual result. Clinically defined a test case is an input and an expected result. This can be as pragmatic as 'for condition x your derived result is y', whereas other test cases described in more detail the input scenario and what results might be expected. It can occasionally be a series of steps (but often steps are contained in a separate test procedure that can be exercised against multiple test cases, as a matter of economy) but with one expected result or expected outcome. The optional fields are a test case ID, test step, or order of execution number, related requirement(s), depth, test category, author, and check boxes for whether the test is automatable and has been automated. Larger test cases may also contain prerequisite states or steps, and descriptions. A test case should also contain a place for the actual result. These steps can be stored in a word processor document, spreadsheet, database, or other common repository. In a database system, you may also be able to see past test results, which generated the results, and what system configuration was used to generate those results. These past results would usually be stored in a separate table. Test script The test script is the combination of a test case, test procedure, and test data. Initially the term was derived from the product of work created by automated regression test tools. Today, test scripts can be manual, automated, or a combination of both.

SOFTWARE QUALITY ASSURANCE

Test suite The most common term for a collection of test cases is a test suite. The test suite often also contains more detailed instructions or goals for each collection of test cases. It definitely contains a section where the tester identifies the system configuration used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests. Test data In most cases, multiple sets of values or data are used to test the same functionality of a particular feature. All the test values and changeable environmental components are collected in separate files and stored as test data. It is also useful to provide this data to the client and with the product or a project.

SOFTWARE QUALITY ASSURANCE

Test harness The software, tools, samples of data input and output, and configurations are all referred to collectively as a test harness. o In software testing, a test harness or automated test framework is a collection of software and test data configured to test a program unit by running it under varying conditions and monitoring its behavior and outputs. It has two main parts: the Test execution engine and the Test script repository. Test harnesses allow for the automation of tests. They can call functions with supplied parameters and print out and compare the results to the desired value. The test harness is a hook to the developed code, which can be tested using an automation framework. A test harness should allow specific tests to run (this helps in optimising), orchestrate a runtime environment, and provide a capability to analyse results. The typical objectives of a test harness are to:

Comment [A139]: A test execution engine is a type of software used to test software, hardware or complete systems.

Automate the testing process. Execute test suites of test cases. Generate associated test reports.

A test harness may provide some of the following benefits:

Increased productivity due to automation of the testing process. Increased probability that regression testing will occur. Increased quality of software components and application.

Certifications Several certification programs exist to support the professional aspirations of software testers and quality assurance specialists. No certification currently offered actually requires the applicant to demonstrate the ability to test software. No certification is based on a widely accepted body of knowledge. This has led some to declare that the testing field is not ready for certification. Certification itself cannot measure an individual's productivity, their skill, or practical knowledge, and cannot guarantee their competence, or professionalism as a tester. Software testing certification types

Exam-based: Formalized exams, which need to be passed; can also be learned by selfstudy [e.g., for ISTQB or QAI] Education-based: Instructor-led sessions, where each course has to be passed [e.g., International Institute for Software Testing (IIST)].

Testing certifications

Certified Associate in Software Testing (CAST) offered by the Quality Assurance Institute (QAI) CATe offered by the International Institute for Software Testing

SOFTWARE QUALITY ASSURANCE

Certified Manager in Software Testing (CMST) offered by the Quality Assurance Institute (QAI) Certified Software Tester (CSTE) offered by the Quality Assurance Institute (QAI) Certified Software Test Professional (CSTP) offered by the International Institute for Software Testing CSTP (TM) (Australian Version) offered by K. J. Ross & Associates ISEB offered by the Information Systems Examinations Board ISTQB Certified Tester, Foundation Level (CTFL) offered by the International Software Testing Qualification Board ISTQB Certified Tester, Advanced Level (CTAL) offered by the International Software Testing Qualification Board TMPF TMap Next Foundation offered by the Examination Institute for Information Science[43]

Quality assurance certifications

CMSQ offered by the Quality Assurance Institute (QAI) CSQA offered by the Quality Assurance Institute (QAI) CSQE offered by the American Society for Quality (ASQ) CQIA offered by the American Society for Quality (ASQ)

Controversy Some of the major software testing controversies include: What constitutes responsible software testing? Members of the "context-driven" school of testing believe that there are no "best practices" of testing, but rather that testing is a set of skills that allow the tester to select or invent testing practices to suit each unique situation. Agile vs. traditional Should testers learn to work under conditions of uncertainty and constant change or should they aim at process "maturity"? The agile testing movement has received growing popularity since 2006 mainly in commercial circles, whereas government and military software providers are slow to embrace this methodology in favor of traditional test-last models (e.g. in the Waterfall model). Exploratory test vs. scripted Should tests be designed at the same time as they are executed or should they be designed beforehand? Manual testing vs. automated Some writers believe that test automation is so expensive relative to its value that it should be used sparingly. More in particular, test-driven development states that developers should write unit-tests of the XUnit type before coding the functionality. The tests then can be considered as a way to capture and implement the requirements. Software design vs. software implementation Should testing be carried out only at the end or throughout the whole process? Who watches the watchmen? The idea is that any form of observation is also an interactionthe act of testing can also affect that which is being tested.

SOFTWARE QUALITY ASSURANCE

RELEASE MANAGEMENT Is the relatively new but rapidly growing discipline within software engineering of managing software releases.

A Release Manager is:

Comment [A140]: A software release is the distribution of software code, documentation, and support materials.

Facilitator serves as a liaison between varying business units to guarantee smooth and timely delivery of software products or updates. Gatekeeper holds the keys to production systems/applications and takes responsibility for their implementations. Architect helps to identify, create and/or implement processes or products to efficiently manage the release of code. Server Application Support Engineer help troubleshoot problems with an application (although not typically at a code level). Coordinator utilized to coordinate disparate source trees, projects, teams and components.

Some of the challenges facing a Software Release Manager include the management of:

Software Defects Issues Risks Software Change Requests New Development Requests (additional features and functions) Deployment and Packaging New Development Tasks

The function of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.

SOFTWARE QUALITY ASSURANCE References: http://itmanagersinbox.com/897/how-to-eliminate-muda-waste-in-it-and-the-office/ http://www.investopedia.com/terms/d/drift.asp http://en.wikipedia.org/wiki/Software_development http://en.wikipedia.org/wiki/Software_quality_assurance http://en.wikipedia.org/wiki/Configuration_management http://camstar.com/WhatAreYouLookingFor/NonconformanceReporting/tabid/273/Default. aspx