Friday, September 26, 2008
Compatability Testing
Testing whether software is compatible with other elements of a system with which it should operate, e.g. browsers, Operating Systems, or hardware.
Breadth Testing
A test suite that exercises the full functionality of a product but does not test features in detail
Parallel Testing
In general, parallel testing involves testing multiple products or subcomponents simultaneously. A parallel test station typically shares a set of test equipment across multiple test sockets, but, in some cases, it may have a separate set of hardware for each unit under test (UUT).
Control Testing
Usage: Control is a management tool to ensure that processing is performed in accordance with what management desires or intends.
Objective:
Accurate and complete data.
Authorized transactions.
Maintenance of adequate audit trail of information.
Efficient, effective and economical process.
Process meeting the needs of the user.
Objective:
Accurate and complete data.
Authorized transactions.
Maintenance of adequate audit trail of information.
Efficient, effective and economical process.
Process meeting the needs of the user.
Test Summary Report
A test summary report is a testing work product that formally summarizes the results of all testing on an endeavor.
The typical objectives of a test summary report are to:
v Summarize all of the testing that was performed since the previous test summary report.
v Enable project management and the customer to know the status of project testing.
The typical objectives of a test summary report are to:
v Summarize all of the testing that was performed since the previous test summary report.
v Enable project management and the customer to know the status of project testing.
Error handling Testing
Error handling refers to the anticipation, detection, and resolution of programming, application, and communications errors. Specialized programs, called error handlers, are available for some applications. The best programs of this type forestall errors if possible, recover from them when they occur without terminating the application,
Locale
Locale is a set of parameters that defines the user's language, country and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier.
Wednesday, September 17, 2008
Pseudolocalization
Pseudolocalization is a software testing method to test internationalization aspects of software. Specifically, it brings to light potential difficulties with localization by replacing localizable text (particularly in a graphical user interface) with text that imitates the most problematic characteristics of text from a wide variety of languages.
Internationalization and localization
Internationalization and localization are means of adapting computer software to different languages and regional differences. Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes. Localization is the process of adapting software for a specific region or language by adding locale-specific components and translating text.
Monday, September 15, 2008
Parser
A parser is one of the components in an interpreter or compiler, which checks for correct syntax and builds a data structure (often some kind of parse tree, abstract syntax tree or other hierarchical structure) implicit in the input tokens. The parser often uses a separate lexical analyser to create tokens from the sequence of input characters. Parsers may be programmed by hand or may be semi-automatically generated (in some programming language) by a tool (such as Yacc)
Fault Injection
Fault injection is a technique for improving the coverage of a test by introducing faults in order to test code paths, in particular error handling code paths, that might otherwise rarely be followed. It is often used with stress testing and is widely considered to be an important part of developing robust software
Software brittleness
The term software brittleness refers to the increased difficulty in fixing older software that may appear reliable, but fails badly when presented with unusual data or altered in a seemingly minor way.
Types of prototyping
Throw Away Prototyping:
Also called close ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.
Evolutionary prototyping:
Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built
Incremental prototyping:
The final product is built as separate prototypes At the end the separate prototypes are being merged in an overall design
Extreme prototyping:
Extreme Prototyping as a development process is used for developing especially web applications. Basically, it breaks down web development into three phases, each one based on the preceding one
Advantages of prototyping:
Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers.
Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications
Also called close ended prototyping. Throwaway or Rapid Prototyping refers to the creation of a model that will eventually be discarded rather than becoming part of the finally delivered software. After preliminary requirements gathering is accomplished, a simple working model of the system is constructed to visually show the users what their requirements may look like when they are implemented into a finished system.
Evolutionary prototyping:
Evolutionary Prototyping (also known as breadboard prototyping) is quite different from Throwaway Prototyping. The main goal when using Evolutionary Prototyping is to build a very robust prototype in a structured manner and constantly refine it. "The reason for this is that the Evolutionary prototype, when built, forms the heart of the new system, and the improvements and further requirements will be built
Incremental prototyping:
The final product is built as separate prototypes At the end the separate prototypes are being merged in an overall design
Extreme prototyping:
Extreme Prototyping as a development process is used for developing especially web applications. Basically, it breaks down web development into three phases, each one based on the preceding one
Advantages of prototyping:
Reduced time and costs: Prototyping can improve the quality of requirements and specifications provided to developers.
Improved and increased user involvement: Prototyping requires user involvement and allows them to see and interact with a prototype allowing them to provide better and more complete feedback and specifications
Software prototyping
A possible activity during software development, is the creation of prototypes, i.e., incomplete versions of the software program being developed. A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.
Proof-of-Principle Prototype (Model)
This type of prototype is used to test some aspect of the intended design without attempting to exactly simulate the visual appearance, choice of materials or intended manufacturing process. Such prototypes can be used to “prove” out a potential design approach such as range of motion, mechanics, sensors, architecture, etc. These types of models are often used to identify which design options will not work, or where further development and testing is necessary..
Monday, August 25, 2008
Proof of Concept
A proof of concept can refer to a partial solution that involves a relatively small number of users acting in business roles to establish whether the system satisfies some aspect of the requirements
Concept Testing
Concept testing is the process of using quantitative methods and qualitative methods to evaluate consumer response to a product idea prior to the introduction of a product to the market. It can also be used to generate communication designed to alter consumer attitudes toward existing products..
Tuesday, August 19, 2008
Data flow analysis
It is a process for collecting run-time information about data in programs without actually executing them.
Hazard Analysis
A technique used to characterize the elements of risk. The result of a hazard analysis will drive the methods used for development and testing of a system.
Control flow analysis
A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.
Control flow analysis
A form of static analysis based on a representation of sequences of events (paths) in the execution through a component or system.
Dynamic analysis
The process of evaluating behavior, e.g. memory performance, CPU usage, of a system or component during execution.
Status accounting
An element of configuration management, consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of the approved changes.
Function Point Analysis (FPA)
A method aiming to measure the size of the functionality of an information system. The measurement is independent of the technology. This measurement may be used as a basis for the measurement of productivity, the estimation of the needed resources, and project control.
Mutation testing
Mutation testing (sometimes also called mutation analysis) is a method of software testing, which involves modifying program's source code in small ways. These, so-called mutations, are based on well-defined mutation operators that either mimic typical user mistakes (such as using the wrong operator or variable name) or force the creation of valuable tests (such as driving each expression to zero).
Monkey test
A monkey test is a unit test that runs with no specific test in mind. The monkey in this case is the producer of any input. For example, a monkey test can enter random strings into text boxes to ensure handling of all possible user input or provide garbage files to check for loading routines that have blind faith in their data
Stub
A routine that doesn't actually do anything other than declare itself and the parameters it accepts. Stubs are used commonly as placeholders for routines that still need to be developed. The stub contains just enough code to allow it to be compiled and linked with the rest of the program.
Heuristic evaluation
A static usability test technique to determine the compliance of a user interface with recognized usability principles (the so-called “heuristics”).
Testware
Artifacts produced during the test process required to plan, design, and execute tests, such as documentation, scripts, inputs, expected results, set-up and clear-up procedures, files, databases, environment, and any additional software or utilities used in testing.
Orthogonal array
A 2-dimensional array constructed with special mathematical properties, such that choosing any two columns in the array provides every pair combination of each number in the array.
Thread Testing
A version of component integration testing where the progressive integration of components follows the implementation of subsets of the requirements, as opposed to the integration of components by levels of a hierarchy
Wide Band Delphi
An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members
Security testing
The process to determine that an IS (Information System) protects data and maintains functionality as intended. The six basic security concepts that need to be covered by security testing are: confidentiality, integrity, authentication, authorisation, availability and non-repudiation.
Fault Tree Analysis
A technique used to analyze the causes of faults (defects). The technique visually models how logical relationships between failures, human errors, and external events can combine to cause specific faults to disclose.
Status Accounting
An element of configuration management, consisting of the recording and reporting of information needed to manage a configuration effectively. This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of the approved changes.
Tuesday, July 22, 2008
Difference Between Smoke and Sanity Tests
Software sanity tests are commonly conflated with smoke tests. A smoke test determines whether it is possible to continue testing, as opposed to whether it is reasonable. A software smoke test determines whether the program launches and whether its interfaces are accessible and responsive (for example, the responsiveness of a web page or an input button). If the smoke test fails, it is impossible to conduct a sanity test. In contrast, the ideal sanity test exercises the smallest subset of application functions needed to determine whether the application logic is generally functional and correct (for example, an interest rate calculation for a financial application). If the sanity test fails, it is not reasonable to attempt more rigorous testing. Both sanity tests and smoke tests are ways to avoid wasting time and effort by quickly determining whether an application is too flawed to merit any rigorous testing. Many companies run sanity tests on a weekly build as part of their development process.
Thursday, July 10, 2008
Build Verification test
What is BVT?
Build Verification test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly. Typically BVT process is automated. If BVT fails that build is again get assigned to developer for fix.
BVT is also called smoke testing or build acceptance testing (BAT)
Build Verification test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly. Typically BVT process is automated. If BVT fails that build is again get assigned to developer for fix.
BVT is also called smoke testing or build acceptance testing (BAT)
Use Case
A collection of possible scenarios between the system under discussion and external actors, characterized by the goal the primary actor has toward the system's declared responsibilities, showing how the primary actor's goal might be delivered or might fail.
Use cases are goals (use cases and goals are used interchangeably) that are made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal; each step in a scenario is a sub (or mini) goal of the use case. As such, each sub goal represents either another use case (subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition.
Use cases are goals (use cases and goals are used interchangeably) that are made up of scenarios. Scenarios consist of a sequence of steps to achieve the goal; each step in a scenario is a sub (or mini) goal of the use case. As such, each sub goal represents either another use case (subordinate use case) or an autonomous action that is at the lowest level desired by our use case decomposition.
State diagrams
It shows the dynamic behaviour of a system. The diagram shows the various states that an object can get into and the transitions that occur between the states.
State:
The state object is a snapshot of an object at a particular point in its life. A state may have an activity describing the function being performed.
Initial State:
The initial state is the starting state of the object with reference to the behaviour that the diagram explains. Each state diagram should have only one initial state.
Final State:
Each final state is the ending state of the object with reference to the behaviour that the diagram explains. There may be multiple final states for an object.
Transition:
The transition link represents the relationship between different states of an object. The transition guard is a condition which limits the cases in which a transition can occur. The transition action is performed during the transition and cannot be interrupted.
State:
The state object is a snapshot of an object at a particular point in its life. A state may have an activity describing the function being performed.
Initial State:
The initial state is the starting state of the object with reference to the behaviour that the diagram explains. Each state diagram should have only one initial state.
Final State:
Each final state is the ending state of the object with reference to the behaviour that the diagram explains. There may be multiple final states for an object.
Transition:
The transition link represents the relationship between different states of an object. The transition guard is a condition which limits the cases in which a transition can occur. The transition action is performed during the transition and cannot be interrupted.
Scripting language
A scripting language, script language or extension language is a programming language that controls a software application. "Scripts" are often treated as distinct from "programs", which execute independently from any other application. At the same time they are distinct from the core code of the application, which is usually written in a different language, and by being accessible to the end user they enable the behavior of the application to be adapted to the user's needs.
Robustness testing
It is defined as the degree to which a system operates correctly in the presence of exceptional inputs or stressful environmental conditions. The goal of robustness testing is to develop test cases and test environments where a system's robustness can be assessed. Many research projects worked on this topic, the two major approaches are:
Robustness testing approaches
Our robustness testing experiments of HA middleware
Robustness testing approaches
Our robustness testing experiments of HA middleware
Scribe
The person who records each defect mentioned and any suggestions for process improvement during a review meeting, on a logging form. The scribe has to ensure that the logging form is readable and understandable.
Configuration management
A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements.
Testing Process
The process for testing application blocks is outlined below. The steps listed should be performed regardless of the testing methodology that is used for the blocks.
Input
The following input is required to test an application block:
· Functional specifications
· Requirements
· Performance objectives
· Deployment scenarios
Steps
Figure shows the steps in the testing process for application blocks.
1. Create test plans. Create test plan documentation with a prioritized list of test cases and execution details.
2. Review the design. Review the design to ensure that it addresses all the deployment scenarios and the requirements. Also, ensure adherence to guidelines for performance, security, globalization, maintainability, and so on.
3. Review the implementation. Review the code to ensure that various best practices are followed.
4. Perform black box testing. Test the code from an end-user perspective by executing all the end-user scenarios.
5. Perform white box testing. Analyze the code for failure scenarios and simulate them by passing invalid data using custom test harnesses.
Input
The following input is required to test an application block:
· Functional specifications
· Requirements
· Performance objectives
· Deployment scenarios
Steps
Figure shows the steps in the testing process for application blocks.
1. Create test plans. Create test plan documentation with a prioritized list of test cases and execution details.
2. Review the design. Review the design to ensure that it addresses all the deployment scenarios and the requirements. Also, ensure adherence to guidelines for performance, security, globalization, maintainability, and so on.
3. Review the implementation. Review the code to ensure that various best practices are followed.
4. Perform black box testing. Test the code from an end-user perspective by executing all the end-user scenarios.
5. Perform white box testing. Analyze the code for failure scenarios and simulate them by passing invalid data using custom test harnesses.
Database Integrity Testing
Testing the methods and processes used to access and manage the data (base), to ensure access methods, processes and data rules function as expected and that during access to the database, data is not corrupted or unexpectedly deleted, updated or created.
Incremental development model
A development life cycle where a project is broken into a series of increments, each of which delivers a portion of the functionality in the overall project requirements. The requirements are prioritized and delivered in priority order in the appropriate increment. In some (but not all) versions of this life cycle model, each subproject follows a ‘mini V-model’ with its own design, coding and testing phases.
Usability Testing
It is defined as: "In System Testing, testing which attempts to find any human-factor problems". A better description is "testing the software from a user’s point of view". Essentially it means testing software to prove/ensure that it is 'user-friendly', as distinct from testing the functionality of the software. In practical terms it includes ergonomic considerations, screen design, standardisation etc.
Wednesday, July 9, 2008
Bug Life Cycle
Bug can be defined as the abnormal behavior of the software. No software exists without a bug. The elimination of bugs from the software depends upon the efficiency of testing done on the software.
In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle.
The life cycle of the bug can be shown diagrammatically as follows:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
In software development process, the bug has a life cycle. The bug should go through the life cycle to be closed. A specific life cycle ensures that the process is standardized. The bug attains different states in the life cycle.
The life cycle of the bug can be shown diagrammatically as follows:
1. New: When the bug is posted for the first time, its state will be “NEW”. This means that the bug is not yet approved.
2. Open: After a tester has posted a bug, the lead of the tester approves that the bug is genuine and he changes the state as “OPEN”.
3. Assign: Once the lead changes the state as “OPEN”, he assigns the bug to corresponding developer or developer team. The state of the bug now is changed to “ASSIGN”.
4. Test: Once the developer fixes the bug, he has to assign the bug to the testing team for next round of testing. Before he releases the software with bug fixed, he changes the state of bug to “TEST”. It specifies that the bug has been fixed and is released to testing team.
5. Deferred: The bug, changed to deferred state means the bug is expected to be fixed in next releases. The reasons for changing the bug to this state have many factors. Some of them are priority of the bug may be low, lack of time for the release or the bug may not have major effect on the software.
6. Rejected: If the developer feels that the bug is not genuine, he rejects the bug. Then the state of the bug is changed to “REJECTED”.
7. Duplicate: If the bug is repeated twice or the two bugs mention the same concept of the bug, then one bug status is changed to “DUPLICATE”.
8. Verified: Once the bug is fixed and the status is changed to “TEST”, the tester tests the bug. If the bug is not present in the software, he approves that the bug is fixed and changes the status to “VERIFIED”.
9. Reopened: If the bug still exists even after the bug is fixed by the developer, the tester changes the status to “REOPENED”. The bug traverses the life cycle once again.
10. Closed: Once the bug is fixed, it is tested by the tester. If the tester feels that the bug no longer exists in the software, he changes the status of the bug to “CLOSED”. This state means that the bug is fixed, tested and approved.
Thursday, July 3, 2008
Recovery testing
Recovery testing is a system test that focuses the software to fall in a variety of ways and verifies that recovery is properly performed. If it is automatic recovery then re-initialization, check pointing mechanisms, data recovery and restart should be evaluated for correctness. If recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated to determine whether it is within acceptable limits.
Stubs and Drivers
A software application is made up of a number of ‘Units’, where output of one ‘Unit’ goes as an ‘Input’ of another Unit. e.g. A ‘Sales Order Printing’ program takes a ‘Sales Order’ as an input, which is actually an output of ‘Sales Order Creation’ program.
Due to such interfaces, independent testing of a Unit becomes impossible. But that is what we want to do; we want to test a Unit in isolation! So here we use ‘Stub’ and ‘Driver.
A ‘Driver’ is a piece of software that drives (invokes) the Unit being tested. A driver creates necessary ‘Inputs’ required for the Unit and then invokes the Unit.
A Unit may reference another Unit in its logic. A ‘Stub’ takes place of such subordinate unit during the Unit Testing. A ‘Stub’ is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual unit. A Stub works as a ‘Stand-in’ for the subordinate unit and provides the minimum required behavior for that unit.
Programmer needs to create such ‘Drivers’ and ‘Stubs’ for carrying out Unit Testing.
Both the Driver and the Stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the Unit in question.
Example - For Unit Testing of ‘Sales Order Printing’ program, a ‘Driver’ program will have the code which will create Sales Order records using hard coded data and then call ‘Sales Order Printing’ program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a ‘Stub’, which will simply return fix discount data.
Due to such interfaces, independent testing of a Unit becomes impossible. But that is what we want to do; we want to test a Unit in isolation! So here we use ‘Stub’ and ‘Driver.
A ‘Driver’ is a piece of software that drives (invokes) the Unit being tested. A driver creates necessary ‘Inputs’ required for the Unit and then invokes the Unit.
A Unit may reference another Unit in its logic. A ‘Stub’ takes place of such subordinate unit during the Unit Testing. A ‘Stub’ is a piece of software that works similar to a unit which is referenced by the Unit being tested, but it is much simpler that the actual unit. A Stub works as a ‘Stand-in’ for the subordinate unit and provides the minimum required behavior for that unit.
Programmer needs to create such ‘Drivers’ and ‘Stubs’ for carrying out Unit Testing.
Both the Driver and the Stub are kept at a minimum level of complexity, so that they do not induce any errors while testing the Unit in question.
Example - For Unit Testing of ‘Sales Order Printing’ program, a ‘Driver’ program will have the code which will create Sales Order records using hard coded data and then call ‘Sales Order Printing’ program. Suppose this printing program uses another unit which calculates Sales discounts by some complex calculations. Then call to this unit will be replaced by a ‘Stub’, which will simply return fix discount data.
Monday, June 30, 2008
Test strategy
A test strategy must address the risks and present a process that can reduce those risks. The two components of Test strategy are:
Test Factor: The risk of issue that needs to be addressed as a part of the test strategy. Factors that are to be addressed in testing a specific application system will form the test factor.
Test phase: The phase of the systems development life cycle in which testing will occur.
Test Factor: The risk of issue that needs to be addressed as a part of the test strategy. Factors that are to be addressed in testing a specific application system will form the test factor.
Test phase: The phase of the systems development life cycle in which testing will occur.
Friday, June 27, 2008
Severity
It is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavior. The ’severity’ of a problem is defined in accordance to the customer’s risk assessment and recorded in their selected tracking tool.
Priority
It is associated with scheduling, and “severity” is associated with standards. “Priority” means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency).
Quality
Audit
An independent evaluation of software products or processes to ascertain compliance to standards, guidelines, specifications, and/or procedures based on objective criteria, including documents that specify:
(1) the form or content of the products to be produced
(2) the process by which the products shall be produced
(3) how compliance to standards or guidelines shall be measured. [IEEE 1028]
(1) the form or content of the products to be produced
(2) the process by which the products shall be produced
(3) how compliance to standards or guidelines shall be measured. [IEEE 1028]
Error Seeding
The process of adding known faults wantedly in a program for monitoring the rate of detection & removal and also to estimate the total number of faults remaining in the program.
Levels of the CMM
Level 1 - Ad hoc (Chaotic)
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.
Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. Projects establish their defined processes by applying the organization’s set of standard processes, tailored, if necessary, within similarly standardized guidelines.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 - Optimized
It is characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
It is characteristic of processes at this level that they are (typically) undocumented and in a state of dynamic change, tending to be driven in an ad hoc, uncontrolled and reactive manner by users or events. This provides a chaotic or unstable environment for the processes.
Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and used to establish consistency of process performance across the organization. Projects establish their defined processes by applying the organization’s set of standard processes, tailored, if necessary, within similarly standardized guidelines.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process (e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 - Optimized
It is characteristic of processes at this level that the focus is on continually improving process performance through both incremental and innovative technological changes/improvements.
Structure of CMM
Maturity Levels: A number of level continuums culminating in the discipline needed to engage in continuous process improvement and optimization.
Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.
Key Process Areas: A Key Process Area (KPA) identifies a cluster of related activities that, when performed collectively, achieve a set of goals considered important.
Goals: The goals of a key process area summarize the states that must exist for that key process area to have been implemented in an effective and lasting way. The extent to which the goals have been accomplished is an indicator of how much capability the organization has established at that maturity level. The goals signify the scope, boundaries, and intent of each key process area.
Common Features: Common features include practices that implement and institutionalize a key process area. There are five types of common features: Commitment to Perform, Ability to Perform, Activities Performed, Measurement and Analysis, and Verifying Implementation.
Key Practices: The key practices describe the elements of infrastructure and practice that contribute most effectively to the implementation and institutionalization of the KPAs.
Capability Maturity Model Integration (CMMI)
It is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.
LCSAJ
A Linear Code Sequence And Jump, consisting of the following three items (conventionally identified by line numbers in a source code listing): the start of the linear sequence of executable statements, the end of the linear sequence, and the target line to which control flow is transferred at the end of the linear sequence.
Traceability matrix
It is a table that correlates any two baselined documents that require a many to many relationship to determine the completeness of the relationship. It is often used with high-level requirements (sometimes known as marketing requirements) and detailed requirements of the software product to the matching parts of high-level design, detailed design, test plan, and test cases.
Defect
A flaw in a component or system that can cause the component or system perform its required function, e.g. an incorrect statement or data definition. A defect, encountered during execution, may cause a failure of the component or system.
Concurrency testing
Testing to determine how the occurrence of two or more activities within the same interval of time, achieved either by interleaving the activities or by simultaneous execution, is handled by the component or system.
Business process-based testing
The testing of the full business process, from the start of a transaction through to the completion. Its testing the full business process ensures that the system is really going to work.
Agile testing
It is practice for a project using agile methodologies, such as extreme programming (XP), treating development as the customer of testing and emphasizing the test-first design paradigm.
Accessibility testing
Accessibility testing for web sites is a service that can provide much more than the standard point-by-point testing techniques of most automated services
State transition testing
It focuses on the testing of transitions from one state (e.g., open, closed) of an object (e.g., an account) to another state.
Structured basis testing
A test case design technique in which test cases are derived from the code logic to achieve 100% branch coverage.
Test script
A test script in Software Testing is a set of instructions that will be performed on the System under Test to test that the system functions as expected. These steps can be executed manually or automatically.
Scenario testing
It is a software testing activity that uses scenario tests, or simply scenarios, which are based on a hypothetical story to help a person think through a complex problem or system. They can be as simple as a diagram for a testing environment or they could be a description written in prose. The ideal scenario has four key characteristics. It is a story that is motivating, credible, complex, and easy to evaluate.
Thursday, June 26, 2008
Test plan
A test plan is a systematic approach to testing a system such as a machine or software. The plan typically contains a detailed understanding of what the eventual workflow will be.
Error Guessing
It is a software testing design technique based on the ability of the tester to draw on his past experience, knowledge and intuition to predict where bugs will be found in the software under test. Some areas to guess are: empty or null strings, zero instances, occurrences, blank or null characters in strings, Negative numbers
Entity Life Cycle Testing
It is employed during System Testing where validation is done for an entity which undergone several processes’ before it reaches the current Scenario under focus. How this differs from Business Scenario Testing is that a Scenario Test Case talks about the end to end of particular cycle of the Entity, whereas Entity Life Cycle Testing talks about the entire Scenarios’ the entity Traveled/Undergone during its life, before it reaches the current Scenario.
Decision Testing
Decision tables offer a simple, visual aid, and they can be applied in knowledge-based systems to perform verification processes efficiently. In software development, decision tables help test teams manage complex logic in software applications
Boundary value analysis
It is a selection technique where test data are chosen to lie along "boundaries" of the input domain [or output range] classes, data structures, procedure parameters, etc. Choices often include maximum, minimum, and trivial values or parameters. This technique is often called stress testing.
Equivalence partitioning
It is a technique with the goal:
To reduce the number of test cases to a necessary minimum.
To select the right test cases to cover all possible scenarios.
Although in rare cases equivalence partitioning is also applied to outputs of a software component, typically it is applied to the inputs of a tested component. The equivalence partitions are usually derived from the specification of the component's behaviour.
Black Box Design Techniques
- Equivalence Partitioning
- Boundary Value Analysis
- Algorithm Test
- Decision Table Test
- Syntactic Test
- Semantic Test
- Elementary Comparison Test
- Data Cycle Test / Entity Life Cycle Test
- Process Cycle Test
- Program Interface Test
- Real-Life Test
- Error Guessing
- Random Test
- Idiot Proofing
White box test design techniques
- Line coverage
- Statement coverage
- Decision coverage
- Condition coverage
- Decision condition coverage
- Multiple condition coverage
- Determination condition coverage
White box test design techniques
Line Coverage:
Line coverage is the weakest coverage criteria. It requires execution of every line of code at least once.
Statement Coverage:
It requires the execution of all program statements. However, all the statements in a program could be executed without revealing errors even if the program as a whole may be riddles with errors.
Decision Coverage:
For decision coverage, the programmer can use case a. and any of the other three. For decision coverage, the programmer must test once when the condition (we must take the THEN and ELSE parts) is true and once when it is false. It should cover all lines as well as all branches of the program.
Condition Coverage:
It checks each of the ways the condition can be made True or False.
Decision/Condition Coverage:
In this type of coverage both decision as well as condition coverage must be satisfied.
Prototyping
Prototyping is the process of quickly putting together a working model (a prototype) in order to test various aspects of a design, illustrate ideas or features and gather early user feedback. Prototyping is often treated as an integral part of the system design process, where it is believed to reduce project risk and cost.
Software Development Lifecycle Models
1. SEQUENTIAL MODELS
a. Pure Waterfall
b. The “V” Model
2. INCREMENTAL MODELS
a. The Staged Delivery Model
b. The Parallel Development Model
3. EVOLUTIONARY MODELS
a. The Spiral Model
4. RELATED ASPECTS OF SOFTWARE ENGINEERING
a. Component-Based Software Engineering
b. Architecture Tradeoff Analysis
c. The Iterative Development Method
a. Pure Waterfall
b. The “V” Model
2. INCREMENTAL MODELS
a. The Staged Delivery Model
b. The Parallel Development Model
3. EVOLUTIONARY MODELS
a. The Spiral Model
4. RELATED ASPECTS OF SOFTWARE ENGINEERING
a. Component-Based Software Engineering
b. Architecture Tradeoff Analysis
c. The Iterative Development Method
Software life cycle model
A software life cycle model (SLCM) is a representation of the major components of software development work and their interrelationships in a graphical framework that can be easily understood and communicated.
Recovery Testing
Recovery testing is the activity of testing how well the software is able to recover from crashes, hardware failures and other similar problems. Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed.
Examples of recovery testing:
While the application running, suddenly restart the computer and after that check the validness of application's data integrity;
While application receives data from the network, unplug and then in some time plug-in the cable, and analyze the application ability to continue receiving of data from that point, when network connection disappeared;
To restart the system while the browser will have definite number of sessions and after rebooting check, that it is able to recover all of them.
Examples of recovery testing:
While the application running, suddenly restart the computer and after that check the validness of application's data integrity;
While application receives data from the network, unplug and then in some time plug-in the cable, and analyze the application ability to continue receiving of data from that point, when network connection disappeared;
To restart the system while the browser will have definite number of sessions and after rebooting check, that it is able to recover all of them.
Negative Test and Positive Test
Terms like "negative test" and "positive test" are more of a concept than a strict activity. In both instances you are dealing with an input, an action, and an output. The action acts upon the input to derive a certain output. So a test case (and thus a good test) is just one that deals with those three things. Both test cases can produce errors and, in fact, some say that the success of a test case is based upon the probability of it finding new errors in an application.
Fuzz testing
Fuzz testing or fuzzing is a software testing technique used to discover coding errors and security loopholes in software, operating systems or networks by inputting massive amounts of random data, called fuzz, to the system in an attempt to make it crash. If vulnerability is found, a tool called a fuzz tester (or fuzzer), indicates potential causes. Fuzz testing was originally developed by Barton Miller at the University of Wisconsin in 1989.
Test suite
A test suite, also known as a validation suite, is a collection of test cases that are intended to be used as input to a software program to show that it has some specified set of behaviors. Test suites are used to group similar test cases together. A system might e.g. have a smoke test suite that consists only of smoke tests or a test suite for some specific functionality in the system. A test suite often contains detailed instructions or goals for each collection of test cases and information on the system configuration to be used during testing. A group of test cases may also contain prerequisite states or steps, and descriptions of the following tests
Dynamic Testing
Dynamic Testing involves working with the software, giving input values and checking if the output is as expected. These are the Validation activities. Unit Tests, Integration Tests, System Tests and Acceptance Tests are few of the Dynamic Testing methodologies.
Static Testing
The Verification activities fall into the category of Static Testing. During static testing, you have a checklist to check whether the work you are doing is going as per the set standards of the organization. These standards can be for Coding, Integrating and Deployment. Reviews, Inspections and Walkthrough are static testing Methodologies
Bug
A software bug (or just "bug") is an error, flaw, mistake, "undocumented feature", failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy.
Test Scenario
A set of test cases that ensure that the business process flows are tested from end to end. They may be independent tests or a series of tests that follow each other, each dependent on the output of the previous one. The terms "test scenario" and "test case" are often used synonymously.
Test Case Format
Requirement Traceability:
A cross reference to the numbers of the requirements (in the system specification) which are being verified in this test.
Purpose:
Describe the features of the software to be tested, and the particular behavior being verified by this test.
Procedure:
Describe how to carry out the test (Sometimes this will be as simple as "Enter the data in the table below at the keyboard.") Where appropriate, you may omit redundant explanations by referring to procedures you described in previous portions of the document.
Test Data:
Write the actual input data to be provided and the expected output for your actual working product. You must provide the actual input data values, not just a description. For example, "Enter a new wholesale price" is wrong. "Enter a wholesale price of $23.50" is correct. For the expected results you must provide the actual values not just a description. For example, "The updated retail price is displayed" is wrong. "The retail price of $49.99 is displayed" is correct. Be sure to include any manual calculations necessary to determine the expected outputs. (For example, if the program converts Fahrenheit temperature to Celsius, show the hand computations you did using the conversion formulas to arrive at the expected results).
Often the test data can be shown in tabular form, with a column of input items and the corresponding column of expected outputs. If the test input is contained in an external data file, you can provide the file name and have the file contents listed on a separate page.
A cross reference to the numbers of the requirements (in the system specification) which are being verified in this test.
Purpose:
Describe the features of the software to be tested, and the particular behavior being verified by this test.
Procedure:
Describe how to carry out the test (Sometimes this will be as simple as "Enter the data in the table below at the keyboard.") Where appropriate, you may omit redundant explanations by referring to procedures you described in previous portions of the document.
Test Data:
Write the actual input data to be provided and the expected output for your actual working product. You must provide the actual input data values, not just a description. For example, "Enter a new wholesale price" is wrong. "Enter a wholesale price of $23.50" is correct. For the expected results you must provide the actual values not just a description. For example, "The updated retail price is displayed" is wrong. "The retail price of $49.99 is displayed" is correct. Be sure to include any manual calculations necessary to determine the expected outputs. (For example, if the program converts Fahrenheit temperature to Celsius, show the hand computations you did using the conversion formulas to arrive at the expected results).
Often the test data can be shown in tabular form, with a column of input items and the corresponding column of expected outputs. If the test input is contained in an external data file, you can provide the file name and have the file contents listed on a separate page.
Test Case
A test case in software engineering is a set of conditions or variables under which a tester will determine if a requirement or use case upon an application is partially or fully satisfied. It may take many test cases to determine that a requirement is fully satisfied.
Automation Testing
Automation is defined as developing and executing tests that can run unattended, comparing the actual to expected results and logging status. In simple words, it is automating the manual testing process currently in use.
Ad Hoc Testing
Ad hoc testing is a commonly used term for software testing performed without planning and documentation. The tests are intended to be run only once, unless a defect is discovered. Ad hoc testing is a part of exploratory testing, being the least formal of test methods. In this view, ad hoc testing has been criticized because it isn't structured, but this can also be strength: important things can be found quickly.
Smoke Testing
A smoke test generally consists of a collection of tests that can be applied to a newly created or repaired computer program. Sometimes the tests are performed by the automated system that builds the final software. In this sense a smoke test is the process of validating code changes before the changes are checked into the larger product’s official source code collection. Next after code reviews, smoke testing is the most cost effective method for identifying and fixing defects in software; some even believe that it is the most effective of all.
Functional Testing
Functional Testing is testing software based on its functional requirements. It ensures that the program physically works the way it was intended and all required menu options are present. It also ensures that the program conforms to the industry standards relevant to that environment; for example, in a Windows program, pressing F1 brings up help.
Performance Testing
Performance testing is performed, to determine how fast some aspect of a 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. Performance testing is a subset of Performance engineering, an emerging computer science practice which strives to build performance into the design and architecture of a system, prior to the onset of actual coding effort.
Beta
A beta version is the first version released outside the organization or community that develops the software, for the purpose of evaluation or real-world black/grey-box testing. The process of delivering a beta version to the users is called beta release. Beta level software generally includes all features, but may also include known issues and bugs of a less serious variety.
Alpha
The alpha build of the software is the build delivered to the software testers, which is persons different from the software engineers, but usually internal to the organization or community that develops the software. In a rush to market, more and more companies are engaging external customers or value-chain partners in their alpha testing phase. This allows more extensive usability testing during the alpha phase.
In the first phase of testing, developers generally test the software using white box techniques. Additional validation is then performed using black box or grey box techniques, by another dedicated testing team, sometimes concurrently. Moving to black box testing inside the organization is known as alpha release
In the first phase of testing, developers generally test the software using white box techniques. Additional validation is then performed using black box or grey box techniques, by another dedicated testing team, sometimes concurrently. Moving to black box testing inside the organization is known as alpha release
Pre-alpha
Sometimes a build known as pre-alpha is issued, before the release of an alpha or beta. In contrast to alpha and beta versions, the pre-alpha is not "feature complete". When it is used, it refers to all activities performed during the software project prior to software testing. These activities can include requirements analysis, software design, software development and unit testing.
Regression testing
Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes. Regression testing is a normal part of the program development process and, in larger companies, is done by code testing specialists. Test department coders develop code test scenarios and exercises that will test new units of code after they have been written.
Integration testing
Integration testing is a logical extension of unit testing. In its simplest form, two units that have already been tested are combined into a component and the interface between them is tested. A component, in this sense, refers to an integrated aggregate of more than one unit. In a realistic scenario, many units are combined into components, which are in turn aggregated into even larger parts of the program. The idea is to test combinations of pieces and eventually expand the process to test your modules with those of other groups. Eventually all the modules making up a process are tested together. Beyond that, if the program is composed of more than one process, they should be tested in pairs rather than all at once.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
Integration testing identifies problems that occur when units are combined. By using a test plan that requires you to test each unit and ensure the viability of each before combining units, you know that any errors discovered when combining units are likely related to the interface between units. This method reduces the number of possibilities to a far simpler level of analysis.
Unit testing
Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing is often automated but it can also be done manually. The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict, written contract that the piece of code must satisfy. As a result, it affords several benefits. This testing mode is a component of Extreme Programming (XP), a pragmatic method of software development that takes a meticulous approach to building a product by means of continual testing and revision.
Wednesday, June 25, 2008
User Acceptance Testing or System Validation
In this type of testing, the developed product is handed over to the user/paid testers in order to test it in real time scenario. The product is validated to find out if it works according to the system specifications and satisfies all the user requirements. As the user/paid testers use the software, it may happen that bugs that are yet undiscovered, come up, which are communicated to the developers to be fixed. This helps in improvement of the final product.
Functional Validation/Testing
This type of testing is carried out in order to find if the system meets the functional requirements. In this type of testing, the system is validated for its functional behavior. Functional testing does not deal with internal coding of the project, in stead, it checks if the system behaves as per the expectations.
Integration Validation/Testing
Integration testing is carried out in order to find out if different (two or more) units/modules co-ordinate properly. This test helps in finding out if there is any defect in the interface between different modules.
Buddy Checks
This is the simplest type of review activity used to find out bugs in a work product during the verification. In buddy check, one person goes through the documents prepared by another person in order to find out if that person has made mistake(s) i.e. to find out bugs which the author couldn’t find previously. The activities involved in Verification process are: Requirement Specification verification, Functional design verification, internal/system design verification and code verification (these phases can also subdivided further). Each activity makes it sure that the product is developed right way and every requirement; every specification, design code etc. is verified!
Code Validation/Testing
Developers as well as testers do the code validation. Unit Code Validation or Unit Testing is a type of testing, which the developers conduct in order to find out any bug in the code unit/module developed by them. Code testing other than Unit Testing can be done by testers or developers
Walkthrough
Walkthrough can be considered same as inspection without formal preparation (of any presentation or documentations). During the walkthrough meeting, the presenter/author introduces the material to all the participants in order to make them familiar with it. Even when the walkthroughs can help in finding potential bugs, they are used for knowledge sharing or communication purpose.
Inspection
Inspection involves a team of about 3-6 people, led by a leader, which formally reviews the documents and work product during various phases of the product development life cycle. The work product and related documents are presented in front of the inspection team, the member of which carry different interpretations of the presentation. The bugs that are detected during the inspection are communicated to the next level in order to take care of them
Validation
Validation is a process of finding out if the product being built is right? i.e. whatever the software product is being developed; it should do what the user expects it to do. The software product should functionally do what it is supposed to, it should satisfy all the functional requirements set by the user. Validation is done during or at the end of the development process in order to determine whether the product satisfies specified requirements.
Verification
The standard definition of Verification goes like this: "Are we building the product RIGHT?" i.e. Verification is a process that makes it sure that the software product is developed the right way. The software should confirm to its predefined specifications, as the product development goes through different stages, an analysis is done to ensure that all required specifications are met.
Black Box and White Box Testing
Black Box Testing is testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs.
Glass Box Testing is a technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs.
Glass Box Testing is a technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs.
Testing Tips
Black Box Testing is testing without knowledge of the internal workings of the item being tested. For example, when black box testing is applied to software engineering, the tester would only know the "legal" inputs and what the expected outputs should be, but not how the program actually arrives at those outputs.
Glass Box Testing is a technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs.
Glass Box Testing is a technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs.
Friday, June 20, 2008
Comparison between the human brain and a computer
Similarities between human brain and computer
There are huge differences between brain physiology and computer processing. But there also exist few
- The similarities are
Both are used for storage of information, to process information and to run tasks.
Both play extremely important roles in society, commerce, entertainment and science.
Both work by combining the processes of several components and parts to perform their tasks.
Both can change with time. (The brain evolves, while the computer upgrades with technological advances)
Both work by transmitting "logic signals" to each of their parts. Signals are both electrical
Both can increase their memory storage capacity.
Both can degrade. (Computers break down and brain cells deteriorate)
The differences are
Brain cells signal each other electrochemically and enzymatically while computer components transmit stronger electrical signals through conductors.
Computers have no common sense or real intellect unlike the human brain.
The brain can evolve but it has hardly changed for the past 100,000 years. The computer is rapidly changing with technology.
Although both can increase their memory storage capacity, they use difference methods.
The brain can learn and understand better, while the computer can multitask and perform complex actions.
It is impossible for the brain to act without emotions while computers act only on logic.
Repairing a computer is relatively simple compared to brain surgery.
The computer can be turned off, but not the brain. (it works for 24 hours a day)
The computer can hardly innovate and invent new ideas unlike the brain.
The brain has 100 billion neurons which form billions of links is many times more complex than, the mere hundreds of millions of transistors and circuit in today's computers.
Conclusion
Counting all the similarities and differences of the brain and the computer, you would now see that the computer and the brain do have something’s in common, but in many more ways they are actually more different than they are similar.
Friday, June 13, 2008
Project Managment Basics
Bottom up estimating [Technique]
A method of estimating a component of work. The work is decomposed into more detail. An estimate is prepared of what is needed to meet the requirements of each of the lower, more detailed pieces of work, and these estimated are then aggregated into a total quantity for the component of work. The accuracy of bottom up estimating is driven by the size and complexity of the work identified at the lower levels
A method of estimating a component of work. The work is decomposed into more detail. An estimate is prepared of what is needed to meet the requirements of each of the lower, more detailed pieces of work, and these estimated are then aggregated into a total quantity for the component of work. The accuracy of bottom up estimating is driven by the size and complexity of the work identified at the lower levels
Project managment
What is Analogous Estimation?
An estimating technique that uses the values of parameters, such as scope, cost, budget and duration or measures of scale such as size , weight , and complexity from a previous, similar activity as the basis for estimating the same parameter or measure for a future activity. It is frequently used to estimate a parameter when there is a limited amount of detailed information about the project. Analogous estimating is form of Expert judgment. Analogous estimating is the most reliable when the previous activities are similar in fact and not just in appearance and the project team members preparing the estimates have the needed expertise
An estimating technique that uses the values of parameters, such as scope, cost, budget and duration or measures of scale such as size , weight , and complexity from a previous, similar activity as the basis for estimating the same parameter or measure for a future activity. It is frequently used to estimate a parameter when there is a limited amount of detailed information about the project. Analogous estimating is form of Expert judgment. Analogous estimating is the most reliable when the previous activities are similar in fact and not just in appearance and the project team members preparing the estimates have the needed expertise
Thursday, June 12, 2008
Estimation Techniques
Software projects are typically controlled by four major variables; time, requirements, resources (people, infrastructure/materials, and money), and risks. Unexpected changes in any of these variables will have an impact on a project. Hence, making good estimates of time and resources required for a project is crucial. Underestimating project needs can cause major problems because there may not be enough time, money, infrastructure/materials, or people to complete the project. Overestimating needs can be very expensive for the organization because a decision may be made to defer the project because it is too expensive or the project is approved but other projects are "starved" because there is less to go around.
Estimates can be roughly divided into three types:
Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value.
Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value.
Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value.
Deciding which of these three different estimates you can provide is crucial. Fair estimates are possible when you are very familiar with what needs to be done and you have done it many times before. This sort of estimate is possible when doing maintenance type work where the fixes are known, or one is adding well-understood functionality that has been done before. Rough estimates are possible when working with well-understood needs and one is familiar with domain and technology issues. In all other cases, the best we can hope for before we begin is order of magnitude estimates. Some may quibble than order of magnitude estimates are close to no estimate at all! However, they are very valuable because they give the organization and project team some idea of what the project is going to need in terms of time, resources, and money. It is better to know that something is going to take between two and six months to do rather than have no idea how much time it will take. In many cases, we may be able to give more detailed estimates for some items rather than others. For example, we may be able to provide a rough estimate of the infrastructure we need but only an order of magnitude estimate of the people and time needed.
Order of magnitude estimate
This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the best estimate we can provide.Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks.
Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.
Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on.
Estimates can be roughly divided into three types:
Ballpark or order of magnitude: Here the estimate is probably an order of magnitude from the final figure. Ideally, it would fall within two or three times the actual value.
Rough estimates: Here the estimate is closer to the actual value. Ideally it will be about 50% to 100% off the actual value.
Fair estimates: This is a very good estimate. Ideally it will be about 25% to 50% off the actual value.
Deciding which of these three different estimates you can provide is crucial. Fair estimates are possible when you are very familiar with what needs to be done and you have done it many times before. This sort of estimate is possible when doing maintenance type work where the fixes are known, or one is adding well-understood functionality that has been done before. Rough estimates are possible when working with well-understood needs and one is familiar with domain and technology issues. In all other cases, the best we can hope for before we begin is order of magnitude estimates. Some may quibble than order of magnitude estimates are close to no estimate at all! However, they are very valuable because they give the organization and project team some idea of what the project is going to need in terms of time, resources, and money. It is better to know that something is going to take between two and six months to do rather than have no idea how much time it will take. In many cases, we may be able to give more detailed estimates for some items rather than others. For example, we may be able to provide a rough estimate of the infrastructure we need but only an order of magnitude estimate of the people and time needed.
Order of magnitude estimate
This is what most of us face when starting off a new project. New technology, teams unfamiliar with the technology or domain, or unclear requirements ensure that this will probably be the best estimate we can provide.Break the project down into the different tasks needed. Try to get as many tasks as possible. A useful way to break down tasks is to consider typical software activities such as analysis, design, build, demo, test, fix, document, deploy, and support and see if they are required for each task and whether they need to be broken out into new tasks.
Evaluate each task on two scales: complexity (high, medium, low) and size of work (large, medium, small). A less complex task may still involve a large amount of work; for example, loading a database with information from paper forms may take several weeks. A very complex task may not involve much actual work but can still take a lot of time, as in tuning a database for optimum performance. Complex tasks are usually hard to split between many people/teams while large-size, less complex tasks can usually be split up between many people/teams.
Tasks effectively fall into one of nine combinations of complexity and size. For each combination, define an expected amount of time and resources required. For example, we could say that low complexity and small-size tasks will take one week at most, medium complexity and small-size tasks will take three weeks, and so on.
Wednesday, June 11, 2008
Defect Finding Techniques
- Static techniques
–Deliverable is examined (manually or by a tool) for defects
–Examples: reviews, walkthroughs, inspections - Dynamic techniques
–A deliverable is used to discover defects
–Example: testing - Operational techniques
–An operational system contains a defect found by users, customers, or control personnel.
–Found as a result of a failure
What is Triple constraints in Project Managment
Scope, Time and cost together called as Triple constraint, A delta change in any of the three other two will have impact. ie: we have to revisit the other 2 factors for accomplishing the project with in dead lines and cost. if Qulaity is added to these constraints then it is known as Extended triple constraint
What is Project Management
Project Managment is the application of Knowledge, skills, tools and techniques to project activities to meet project requirments.Project managment in accomplished with the managment process of Initiation, planning, execution,, monitoring , Control and Closing.
Difference btw Project and operations
Project:
A project will be of temporary in nature, with a end date and will have a uniqueness.
operations:
Operations are which will occur on a periodicity basis[ Daily, monthly] for example railway reservations and bank day to day activities with computers are called operations
A project will be of temporary in nature, with a end date and will have a uniqueness.
operations:
Operations are which will occur on a periodicity basis[ Daily, monthly] for example railway reservations and bank day to day activities with computers are called operations
Subscribe to:
Posts (Atom)