Search

Showing posts with label CMMI Six Sigma ISO 9000. Show all posts
Showing posts with label CMMI Six Sigma ISO 9000. Show all posts

Tuesday, March 24, 2009

IEEE Definitions in Software Testing

IEEE Definitions


1.Black-box testing , or 2.Functional testing: Testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions.



3.White-box testing , or 4.Stnsctural testing: Testing that takes into account the internal mechanism of a system or component Types include branch testing, path testing, statement testing. (Also Glass box or white box testing)



5.Unit testing: Testing of individual hardware or software units or groups of related units.

6.Integretion testing: Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them

7.system testing: Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements

8.Acceptance testing: Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system.

9.Regression testing: Selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements.

10.Anomaly: Anything observed in the documentation or operation of software that deviates from expectations based on previously verified software products or reference documents.

11.Performance testing: Testing conducted to evaluate the compliance of a system or component with specified performance requirements.

12.Formal testing: Testing conducted in accordance with test plans and procedures that have been reviewed and approved by a customer, user, or designated level of management.

13.1nformal testing: Testing conducted in accordance with test plans and procedures that have not been reviewed and approved by a customer, user, or designated level of management.

14.Stress testing: Testing conducted to evaluate a system or component at or beyond the limits of its specified requirements.

15.Test: An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component

16.Testing: The process of operating a system or component under specified conditions, Observing or recording the results, and making an evaluation of some aspect of the System or component

17.Test item: A software item, which is an object of testing

18.Test plan: A document describing the scope, approach, resources, and schedule of intended test activities. It identifies test items, the features to be tested, the testing tasks, who will do each task, and any risks requiring contingency planning.

19.Test log: A chronological record of all relevant details about the execution of a test

20.Test case: It has two definitions:
1.A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement.
2.Documentation specifying inputs, predicted results, and a set of execution conditions for a test item.

21.Test design: Documentation specifying the details of the test approach for a software feature or combination of software features and identifying the associated tests.

22.Test procedure: It has two definitions
1.Detailed instructions for the set-up, execution, and evaluation of results for a given
test case.
2. A document containing a set of associated instructions as in (1).
3.Documentation specifying a sequence of actions for the execution of a test.

23.Test report: A document that describes the conduct and results of the testing carried out for a system or component

24.Test Scenario: A test that verifies one specific instance of a single product feature.
For example, when testing a word-processing application, one scenario would be to verify that the Paste command correctly pastes text a the beginning of a line

Tuesday, February 24, 2009

ISO 9000-3 and ISO 9000:2000 Definitions

1.Regression Testing: Testing to determine that changes made in order to correct defects have not introduced additional defects.

2.Quality: Degree to which a set of inherent characteristics fulfills requirements.
Requirement Need or Expectation that is stated, generally implied or obligatory.

Characteristic A distinguishing feature
Inherent Existing permanently in something as opposed to assigned.
Example for assigned is Price of a product or owner of a product.

3.Quality Control: Part of Quality Management focused on fulfilling quality requirements.

4.Quaiity Assurance: Part of Quality Management focused on providing confidence that Quality Requirements will be fulfilled

5.Quality Management: Coordinated activities to direct and control an organization with regard to Quality.

6.Defect: A serious form of an anomaly (which affects an intended use).

7.Software, 8.software Product: The set of computer programs, procedures, and possibly associated documentation and data.

9.Software item: Any identifiable part of a software product.

10.Development: Software life cycle process that comprises the activities of requirements
analysis, design, coding, integration, testing, installation and support for acceptance of software products.

11.Life cycle model: A frame work containing the processes, activities, and tasks involved in the development, operation and maintenance of a software product spanning the life of the system from the definition of its requirements to the termination of its use.

12.incremental integration testing - continuous testing of an application as new functionality is added;

13.end-to-end testing - testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

14.sanity testing - typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or destroying databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.

15.load testing - testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.

16.usability testing - testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.

17.install/uninstall testing - testing of full, partial, or upgrade install/uninstall processes.

18.recovery testing - testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

19.security testing - testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.

20.compatability testing - testing how well software performs in a particular hardware/software/operating system/network/etc. environment.

21.exploratory testing - often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.

22.ad-hoc testing - a creative, informal software test that is not based on formal test plans or test cases, but often taken to mean that the testers have significant understanding of the software before testing it.

23.user acceptance testing - determining if software is satisfactory to an end-user or customer.

24.comparison testing - comparing software weaknesses and strengths to competing products.

25.alpha testing - testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.

26.beta testing - testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.

27.Reliability: Software is reliable if user depends on it or Extent to which software requirements

28.Correctness: A program is functionally correct it behaves according to the specification of the functions it provide. Any deviation from specification made the product incorrect. An incorrect project may be reliable

29.Usability: Easy to use or Effort required to learn and use the software

30.Portability: Effort required to shift the software from one operating system to other
Components of SRS

i. Functional Requirements or constraints
ii. Design requirements or constraints
1. Architectural design
2. Detailed design
iii. Security Requirements
iv. Internal Requirements
1. Software Interface
2. Human Interface
3. Hardware Interface
v. Performance Requirements
1. Static performance
2. Dynamic Performance

31.Functional Requirements: Functions Required to develop Software

32.Architectural design: Identifying Modules, Integration between Modules

33.Detailed design: Internal logic design written in this phase
Psudocode(algorithm), complete database (Triggers, Procedures) written in detailed design.

34.Software Interface: Operating system, Languages to develop Software

35.Human Interface: User Interface (Design of Screens)

36.Hardware Interface(Design requirements): what Hardware is required for the Project

37.Static performance: In this we identify whether it is single user or Multi user

38.Dynamic Performance : Response time of Request

39.Functional Requirements: Functions Required to develop Software

ISO(international Organization for Standardization)

It is established in 1947, Geneva, Switzerland. It is non-governmental organization.

Work of ISO is to Promote International standards or series, they are related to Quality Management System.
In 1994 2nd version
In 2000 3rd version.

Advantages: 1. Productivity Improvement.
2. Improvement of profits
3. Congesting of Activities
4. New employees can be easily trained
5. International Reorganization.
6. Marketing advantages.

ISO 9000:2000-Quality Management- Fundamentals and Vocabulary

ISO 9001:2000-Quality Management- Requirements, design/development, production, installation, service.

ISO 9002:2000-Except design/development all the aspects of ISO 9001:2000

ISO 9003:2000- Quality Management-Testing and Installation

ISO 9004:2000-Quality Management- Guidelines for performance and improvement.

For certificate you have to follow Quality Manual, Quality Procedures, Records, work instructions if any

Quality Manual: A document specifying Quality Management system of an organization.

Quality procedure: A specified way of doing an activity

Quality policy: Overall intentions and direction of an organization towards quality as formally expressed by company.

Quality Objectives: Something aimed at related to Quality

Types of Audits
1.First part audit or Internal Audit
2.Second party audit or Customer Audit
3. Third party audit or Certification by Audits.

Types of certification Audits
1.Initial Audit
Adequacy audit or Documentation audit or Desk top audit
Site audit or conformance audit or compliance audit
2.Surveillance Audit: For every 3 or 6 months.
3. Re-certification audit: For 3 years.

Adequacy Audit: In Adequacy audit, Auditors verify Manuals & Procedures with ISO 9001:2000

Site Audit: In site audit, Auditors verify whether company is following Manuals, procedures by interviewing or checking.

Clauses
1. Scope
2. Non-motive Reference
3. Definition
4. Quality Management System
5. Management Responsibility
6. Resource Management
7. Project Realization
8. Measurement, Analysis and Improvement
7.5.1: Control of Production and service provision
8.2.4: Monitoring & Measurement of product
8.3: Control of Non conforming product
SEI-CMM
SEI-Software Engineers Institution
CMM-Capacity Maturity Model
CMM is only for software companies
CMM v1.0 →1991
CMM v1.1 →1993 [current]
By the end of 2003 CMM levels are ignored and Capability Maturity Model Integration (CMMI) will Introduced

Process: A set of Activity is Process, Process is what we do.

Process performance: A way of performing a process is process performance. Process performance determine the actual results achieved by a software product.

Process Capability: Process capability determine the range of expected results that can be achieved by following software process. Process capability is ability to achieve Results.

Process Maturity: Process Maturity determines the extent to which specify process explicitly defined, Manage, Measure control and effective.

There are 5 Levels in CMM
1. Initial
2.Repeatable
3. Defined
4. Managed
5. Optimizing

18 key process areas overall in 5 Levels
At Level one there is no key process areas. Even they have they don’t follow
Process Capability of Level 2 Organization is Disciplined process
Process Capability of Level 3 Organization is Standard and congested process
Process Capability of Level 4 organization is Predictable
Process Capability of Level 5 is Continuously improving process

Key Process areas at Level 2
At Level 2 Basic Management Process is Established
1. Requirements Management
2. Software Project Planning
3. Software Project tracking & Over sighting
4. Software Subcontract Management
5. Software Quality Assurance
6. Software Configuration Management.

Key Process Areas at Level 3
1.Organization process focus
2.Organization Process Definition
3. Training Program
4. Integrated Software Management
5. Software product Engineering: Actual Development Process
6. Inter-group Co-ordination
7. Peer reviews: To identify defects affectivity

Key Process Areas at Level 4
1. Quantitative Process Management.
2. Software Quality Management.

Key Process Areas at Level 5
1. Defect Prevention
2. Technology change Management
3. Process Change Management