Cause of Software Bugs

Incorrect communication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements)
Software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity
Programming errors - programmers, like anyone else, can make mistakes
Changing requirements - the customer may not understand the effects of changes, or may understand and request them anyway - redesign rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of keeping track of changes may result in errors. Enthusiasm of engineering staff may be affected. In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control
Time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.
Poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it
Software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs

Configuration Management

Configuration management covers the processes used to control, coordinate, and track: code, requirements, documentation, problems, change requests, designs, tools/compilers/libraries/patches, changes made to them, and who makes the changes

Verification and Validation

Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walk through, and inspection meetings. Validation typically involves actual testing and takes place after verifications are completed

Bug Life Cycle

1. New: When bug rises then it is in the New State
2. Open: Developer Check the Bug Then it is in the Open state
3. Fixed: Developer Fixes the Bug, Then State is fixed
4. Closed: Tester Checks again, if bug is not raised then it is Closed State
5. Reopen: Again It is raised then it is in Reopen State

Difference between Bug and Error

Bug
If the software does not meet the below criteria then it is bug

• Any thing which is not defined by the client
• If Excess Things are added in the software
• Software does not produce a expected result
• it is not user friendly

Error
An Error is a programming mistake, if the function is not responding with expected result then it is error, Bug is any thing which is not added or excess added in to software or it is functionally not well defined and it is not user friendly software. Then errors are also comes under bug

Difference between User Acceptance Testing and System Testing

User acceptance Testing is performed by the Client of the application to determine whether the application is developed as per the requirements specified by him/her. It is performed within the development of the organization or at the client site. Alpha testing and Beta testing are the examples of Acceptance Testing
System testing is performed by the Testers to determine whether the application is satisfying the requirements as specified in SRS

Testing Techniques

White Box Testing

• Aims to establish that the code works as designed
• Examines the internal structure and implementation of the program
• Target specific paths through the program
• Needs accurate knowledge of the design, implementation and code

Black box testing

• Aims to establish that the code meets the requirements
• Tends to be applied later in the life cycle
• Mainly aimed at finding deviations in behavior from the specification or requirement
• Causes are inputs, effects are observable outputs

Different Types of Testing

Performance testing
a. Performance testing is designed to test run time performance of software within the context of an integrated system. It is not until all systems elements are fully integrated and certified as free of defects the true performance of a system can be ascertained
b. Performance tests are often coupled with stress testing and often require both hardware and software infrastructure. That is, it is necessary to measure resource utilization in an exacting fashion. External instrumentation can monitor intervals, log events. By instrument the system, the tester can uncover situations that lead to degradations and possible system failure
Security testing
If your site requires firewalls, encryption, user authentication, financial transactions, or access to databases with sensitive data, you may need to test these and also test your site's overall protection against unauthorized internal or external access
Exploratory Testing
Often taken to mean a creative, internal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it
Benefits Realization tests
With the increased focus on the value of Business returns obtained from investments in information technology, this type of test or analysis is becoming more critical. The benefits realization test is a test or analysis conducted after an application is moved into production in order to determine whether the application is likely to deliver the original projected benefits. The analysis is usually conducted by the business user or client group who requested the project and results are reported back to executive management
Mutation Testing
Mutation testing is a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources
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
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
Build Acceptance Tests
Build Acceptance Tests should take less than 2-3 hours to complete (15 minutes is typical). These test cases simply ensure that the application can be built and installed successfully. Other related test cases ensure that Testing received the proper Development Release Document plus other build related information (drop point, etc.). The objective is to determine if further testing is possible. If any Level 1 test case fails, the build is returned to developers un-tested
Smoke Tests
Smoke Tests should be automated and take less than 2-3 hours (20 minutes is typical). These tests cases verify the major functionality a high level. The objective is to determine if further testing is possible. These test cases should emphasize breadth more than depth. All components should be touched, and every major feature should be tested briefly by the Smoke Test. If any Level 2 test case fails, the build is returned to developers un-tested
Bug Regression Testing
Every bug that was “Open” during the previous build, but marked as “Fixed, Needs Re-Testing” for the current build under test, will need to be regressed, or re-tested. Once the smoke test is completed, all resolved bugs need to be regressed. It should take between 5 minutes to 1 hour to regress most bugs
Database Testing
Database testing done manually in real time, it check the data flow between front end back ends. Observing that operations, which are operated on front-end is effected on back-end or not.
The approach is as follows:
While adding a record there' front-end check back-end that addition of record is effected or not. So same for delete, update, Some other database testing checking for mandatory fields, checking for constraints and rules applied on the table , some time check the procedure using SQL Query analyzer
Functional Testing (or) Business functional testing
All the functions in the applications should be tested against the requirements document to ensure that the product conforms with what was specified.(They meet functional requirements)Verifies the crucial business functions are working in the application. Business functions are generally defined in the requirements Document. Each business function has certain rules, which can’t be broken. Whether they applied to the user interface behavior or data behind the applications. Both levels need to be verified. Business functions may span several windows (or) several menu options, so simply testing that all windows and menus can be used is not enough to verify the business functions. You must verify the business functions as discrete units of your testing
* Study SRS
* Identify Unit Functions
* For each unit function
* Take each input function
* Identify Equivalence class
* Form Test cases
* Form Test cases for boundary values
* From Test cases for Error Guessing
* Form Unit function v/s Test cases, Cross Reference Matrix
User Interface Testing (or) structural testing
It verifies whether all the objects of user interface design specifications are met. It examines the spelling of button test, window title test and label test. Checks for the consistency or duplication of accelerator key letters and examines the positions and alignments of window objects
Volume Testing
Testing the applications with voluminous amount of data and see whether the application produces the anticipated results (Boundary value analysis)
Stress Testing
Testing the applications response when there is a scarcity for system resources
Load Testing
It verifies the performance of the server under stress of many clients requesting data at the same time
Installation testing
The tester should install the systems to determine whether installation process is viable or not based on the installation guide
Configuration Testing
The system should be tested to determine it works correctly with appropriate software and hardware configurations
Compatibility Testing
The system should be tested to determine whether it is compatible with other systems (applications) that it needs to interface with
Documentation Testing
It is performed to verify the accuracy and completeness of user documentation
1. This testing is done to verify whether the documented functionality matches the software functionality
2. The documentation is easy to follow, comprehensive and well edited
If the application under test has context sensitive help, it must be verified as part of documentation testing
Recovery/Error Testing
Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems
Comparison Testing
Testing that compares software weaknesses and strengths to competing products
Acceptance Testing
Acceptance testing, which black box is testing, will give the client the opportunity to verify the system functionality and usability prior to the system being moved to production. The acceptance test will be the responsibility of the client; however, it will be conducted with full support from the project team. The Test Team will work with the client to develop the acceptance criteria
Alpha Testing
Testing of an application when development is nearing completion, Minor design changes may still be made as a result of such testing. Alpha Testing is typically performed by end-users or others, not by programmers or testers
Beta Testing
Testing when development and testing are essentially completed and final bugs, problems need to be found before the final release. Beta Testing is typically done by end-users or others, not by programmers or testers
Regression Testing
The objective of regression testing is to ensure software remains intact. A baseline set of data and scripts will be maintained and executed to verify changes introduced during the release have not “undone” any previous code. Expected results from the baseline are compared to results of the software being regression tested. All discrepancies will be highlighted and accounted for, before testing proceeds to the next level
Incremental Integration Testing
Continuous testing of an application as new functionality is recommended. This may require various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers are developed as needed. This type of testing may be performed by programmers or by testers
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
Integration Testing
Upon completion of unit testing, integration testing, which is black box testing, will begin. The purpose is to ensure distinct components of the application still work in accordance to customer requirements. Test sets will be developed with the express purpose of exercising the interfaces between the components. This activity is to be carried out by the Test Team. Integration test will be termed complete when actual results and expected results are either in line or differences are explainable/acceptable based on client input
System Testing
Upon completion of integration testing, the Test Team will begin system testing. During system testing, which is a black box test, the complete system is configured in a controlled environment to validate its accuracy and completeness in performing the functions as designed. The system test will simulate production in that it will occur in the “production-like” test environment and test all of the functions of the system that will be required in production. The Test Team will complete the system test. Prior to the system test, the unit and integration test results will be reviewed by SQA to ensure all problems have been resolved. It is important for higher level testing efforts to understand unresolved problems from the lower testing levels. System testing is deemed complete when actual results and expected results are either in line or differences are explainable/acceptable based on client input
Parallel/Audit Testing
Testing where the user reconciles the output of the new system to the output of the current system to verify the new

Project Roles and Responsibilities

Testers & Test Lead
Testing, is the core competence of any Testing Organization

• Understand the Application Under Test
• Prepare test strategy
• Assist with preparation of test plan
• Design high-level conditions
• Develop test scripts
• Understand the data involved
• Execute all assigned test cases
• Record defects in the defect tracking system
• Retest fixed defects
• Assist the test leader with his/her duties
• Provide feedback in defect triage
• Automate test scripts
• Understanding of SRS

QA Manager

• Preparation of System Test Plan
• Formation of Test Team
• Schedule Preparation
• Module Allocation
• Reviews on Test Process
• Client Interaction
• Verify Status Reports

Project Manager

• Preparation of Software Requirements Specification (SRS)
• Formation Development Team,Test Team
• Management of requirements through out the project life cycle activities
• Preparation of Detailed Design Document
• Unit Test cases and Integration Test cases
• Guidance on programming and related coding conventions / standards

Software Requirements Specification (SRS) Contents

1. Introduction

• Purpose
• Scope
• Major Constraints and References

2. Functional Requirements

• Context Diagram
• Functional Decomposition Diagram
• System Functions
• Database Requirements
• User Interface Requirements
• External Software Interface / Compatibility Requirements
• Reports Requirements
• Security Requirements

3. Use Case Specifications

• Acceptance Criteria

Software Development Process

Plan: Device a Plan
Define your objective and determine the strategy and support methods required to archive that objective
Do: Execute the plan
Create the conditions and perform the necessary training to execute the plan.Make sure every one thoroughly understands the objectives and the plan.
Check: Check the result
Check to determine whether work is progressing according to the plan and whether the expected results are obtained. Check for performance of the set procedures, changes in conditions, or abnormalities that may appear
Act: Take necessary action
If your checkup reveals that the work is not being performed according to plan or that results are not what was anticipated , devise measures for appropriate action.Testing only involves only check component of the plan-do-check-act(PDCA) cycle

Software Development Life Cycle (SDLC)

1. System Information/Engineering and Modeling
a.The initial proposal phase to understand and identify the project requirements and main features proposed in the application
b. By the end of the study the entire client systems, the team furnishes a document that holds specific recommendations for the candidate system. Out Put of this phase

• A rough estimation of efforts and prices for entire project
• A Rough Schedule for entire phase
• Initial business functions in the project

2. System Requirement Analysis & Specification
The objective of this phase to identify and document the user requirements for a proposed system.This phase contains complete information of function, information of the domain for the software,behavior,performance,Interfacing.Out put of this phase is

• An estimate for effort or price for remaining project phases(Design, Development, Testing Deployment, Support)
• Details Schedule of the remaining Phases(Design, Development, Testing, Deployment, Support)
• The final functional specification and analysis for other phases

3. System Analysis and Design
a. This process of designing exactly of the specifications are to be implemented
b. How the software to written, including object model with properties and methods, Database Designing,client server architecture. Out put of this Phase A Final Design Specification
4. Code Generation
a. Design Must be Formatted in to machine readable format
b. With respect of the application the right programming language is used,

• A Beta version of application
• Preliminary Manuals and user document
• Preliminary Technical Documents

5. Testing
Once code is generated Program testing begins.Different testing methodologies are available to unrevealed the bugs.Out put of this phage

• A Final version of complete application
• A Final Manual
• A Final Technical Document

6. Deployment & Maintenance
In This software ready to deploy in customer place, maintenance period starts for the application.Application should create accept the changes in this phase

Quality Control & Quality Assurance

Quality Assurance
All those planned and necessary ideas to provide adequate confidence that the product/service will satisfy the given requirements of quality
Quality Control
All those necessary steps taken for fulfilling the requirements of quality

Some Major Computer System Failures Caused by Bugs

1. In August of 2006 a U.S. government student loan service erroneously made public the personal data of as many as 21,000 borrowers on it's web site, due to a software error. The bug was fixed and the government department subsequently offered to arrange for free credit monitoring services for those affected
2. A September 2006 news report indicated problems with software utilized in a state government's primary election, resulting in periodic unexpected rebooting of voter checking machines, which were separate from the electronic voting machines, and resulted in confusion and delays at voting sites. The problem was reportedly due to insufficient testing
3. Software bugs in a Soviet early-warning monitoring system nearly brought on nuclear war in 1983, according to news reports in early 1999. The software was supposed to filter out false missile detections caused by Soviet satellites picking up sunlight reflections off cloud-tops, but failed to do so. Disaster was averted when a Soviet commander, based on what he said was a '...funny feeling in my gut', decided the apparent missile attack was a false alarm. The filtering software code was rewritten

When to Stop Testing

It's difficult to determine exactly when to stop Testing.The following are some of the cases which can help to decide when to reduce/stop Testing
1. Deadlines(Release/Test Deadlines etc)
2. Test cases completed with certain percentage passed
3. Test budget depleted
4. Coverage of code/functionality requirements reaches a specified point
5. Bug rate falls below a certain level
6. Beta or Alpha testing period ends

Inadequately Tested Software Negative Impacts

It is difficult to test software products, as evidenced by the problems we find in our software every day. The customer risks of not adequately testing software can be as minor as user inconvenience or as major as loss of life. Not only are there customer (end-user) risks for inadequately tested software, there are also corporate risks. Especially for mature products, an inadequately tested product can have serious negative consequences for a company

Software Testing Axioms

1. It is impossible to test a program completely
2. Software testing is risk based exercise
3. Testing cannot show that bugs don't exist
4. The more bugs you find, the more bugs there are
5. Not all the bugs you find will be fixed
6. Product specifications are never final

Software Testing

Intentionally finding errors from the software is called testing. Errors may be functional errors or usability errors or excess functionality which is not defined by client. Simply means testing the Software to find and report defects. It gives an assurance that the end product is as per customer requirement specification
Goal of Software Testing
Quality in software product in terms of functionality, user friendly
Testing Operators
Tester, Test Lead, QA Manager, Project Manager, Developer and Client
Test/QA Team Lead
Coordinates the testing activity, communicates testing status to management and manages the test team
Testers
Develops test script/case and data, script execution, metrics analysis, and evaluates results for system, integration and regression testing
Test Build Manager/System Administrator/Database Administrator

• Delivers current versions of software to the test environment
• Performs installations of application software, and applies patches (both application and operating system)
• Performs set-up, maintenance, and back up of test environment hardware.

Technical Analyst & Test Configuration Manager

• Performs testing assessment and validates system/functional test requirements
• Maintains the test environment, scripts, software, and test data