Black Box Approach:

Functional testing approach focuses on application externals. We can call it as Requirements-based or Specifications-based.

Characteristics:

1. Functionality
2. Requirements, use, standards Correctness
3. Business forms, Documents
4. Does system meet business requirements

Type of Test during Black Box Approach:

1. System Testing: System test demonstrates that all programs function and work together as designed. This test is performed when all the individual component objects for a release have been integrated into a single system. Documented non-functional requirements such as performance, volume, stress, capacity and security are also verified. Particular attention is paid to regression testing during this phase.
2. User Acceptance Testing: The testing performed for or by user is called user acceptance testing or UAT. The purpose is to ensure that end users are satisfied with the functionality and performance of the system.

Techniques & Tools:

1. Equivalence partitioning – Develop program code to perform tests
2. Boundary value analysis – Develop program code to perform tests
3. Cause-effect graphing – Flow graphing tools
4. Random testing – GUI test tools
5. Error Guessing – GUI test tools
6. Regression testing – GUI / Server test tools
7. Stress testing – Load test tools
8. Replication testing - Load test tools
9. Data Integrity testing – Data analysis tools
10. Backup and recoverable testing – Load test tools / Server test tools / GUI test tools
11. Configuration testing – Multi platform test tools
12. Performance Testing – Load test tools
13. Functional testing – Load test tools / GUI test tools / Server test tools
14. Security testing – Security test tools
15. Operational Readiness Testing – Load test tools / server / GUI tools
16. User Acceptance testing – GUI test tools
17. Compatibility / conversion testing – Load / GUI / Server test tools
18. Benchmark Testing – Benchmarking tools
19. Usability testing – Usability measurement tools
20. Alpha / Beta testing – Load / Server / GUI test tools

White Box Approach:

Structural testing approach focuses on application internals. We can call it as Program-based.

Characteristics:

1. Module design
2. Implementation
3. Do modules / functions meet functional and design specifications?
4. Do program structures meet functional and design specifications?
5. How does the program work?

Type of Test during White Box Approach:

1. Unit Testing: To verify the pieces of code against the design, to remove problems from the code, and to ensure that each component of the code executes according to functional and design specifications. Generally, developers do unit testing.
2. Integration Testing: To verify that each software unit interfaces correctly with other software units. Developers, also testers perform integration testing.

Techniques & Tools:

1. Fault insertion – Coding tools
2. String Test – GUI and Server test tools
3. Error handling – Error handling Tools
4. Statement coverage – Static and Dynamic Analyzers
5. Decision coverage - Static and Dynamic Analyzers, Coverage analysis Tools
6. Condition coverage - Static and Dynamic Analyzers, Coverage analysis tools
7. Path coverage - Static and Dynamic Analyzers, Coverage analysis tools
8. Data flow coverage – Data modeling tools, Flow diagram editors
9. Memory leak – Memory usage tools
10. Cyclomatic complexity – Cyclomatic complexity Analyzers

Why does software have bugs?

1. Miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements).

2. 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. And the use of object-oriented techniques can complicate instead of simplify a project unless it is well engineered.

3. Programming errors - programmers, like anyone else, can make mistakes.

4. 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.

· Egos - people prefer to say things like:

·           'no problem' 

·           'piece of cake'

·           'I can whip that out in a few hours'

·           'it should be easy to update that old code'

·          

·          instead of:

·           'that adds a lot of complexity and we could end up

·              making a lot of mistakes'

·           'we have no idea if we can do that; we'll wing it'

·           'I can't estimate how long it will take, until I

·              take a close look at it'

·           'we can't figure out what that old spaghetti code

·              did in the first place'

·          

·          If there are too many unrealistic 'no problem's', the

·          Result is bugs.

·          

5. 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 ('if it was hard to write, it should be hard to read').

6. Software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs.

Software Development Life Cycle (SDLC)

Water Fall Model:

There are seven stages of the software development life cycle:

1. Initiate the project – The users identify their Business requirements.

2. Define the project – The software development team translates the business requirements into system specifications and put together into System Specification Document.

3. Design the system – The System Architecture Team designs the system and writes Functional Design Document. During design phase general solutions re hypothesized and data and process structures are organized.

4. Build the system – The System Specifications and design documents are given to the development team code the modules by following the Requirements and Design document.

5. Test the system - The test team develops the test plan following the requirements. The software is build and installed on the test platform after developers have completed development and Unit Testing. The testers test the software by following the test plan.

6. Deploy the system – After the user-acceptance testing and certification of the software, it is installed on the production platform. Demos and training are given to the users.

7. Support the system - After the software is in production, the maintenance phase of the life begins. During this phase the development team works with the development document staff to modify and enhance the application and the test team works with the test documentation staff to verify and validate the changes and enhancement to the application software.

QA process starts from the second phase of the Software Development Life Cycle i.e. Define the Project. Actual Product testing will be done on Test the system phase (Phase-5). During this phase test team will verify the actual results against expected results.

Very Important concepts of Software Testing:

Software Quality Assurance:

Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

Quality Assurance measures the quality of processes used to create a quality product.
1. It is a system of management activities.
2. It is a preventive process.
3. It applies for entire life cycle.
4. Deals with Process.

It is very important for a tester to know difference between Quality Assurance and Quality Assurance.

Quality control:
Quality control measures the quality of a product
1.It is a specific part of the Quality Assurance procedure.
2. It is a corrective process.
3. It applies for particular product.
4. Deals with the product.

Severity and priority will be assigned for a particular bug to know the importance of the bug.
Severity: How severely the bug is effecting the application.
Priority: Informing to the developer which bug to be fix first.

Defect: While executing the test case if u found any mismatch, the u will report
it to the development team that is called defect.
Bug: Once the developer accepts your defect, then it is called as a bug.

Test case

Test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly.

Test condition The condition required to test a feature.(pre condition)

Test script
A. Test script is the script which is generated by an automation tool while recording a application features.

Test data
A. Test data means the input data (valid, invalid data) giving to check the feature
of an application is working correctly.

Test bed

Test bed means under what test environment (Hardware, software set up) the
application will run smoothly.

Baseline document
The review and approved document is called as baseline document (i.e) Test plan,SRS(Software requirement Specification).

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:
Verification typically involves reviews and meetings to evaluate documents, plans, code, requirements, and specifications. This can be done with checklists, issues lists, walkthroughs, and inspection meetings

Validation: Validation typically involves actual testing and takes place after verifications are completed.

The term 'IV & V' refers to Independent Verification and Validation.

Walkthrough:

A 'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.

Inspection:
An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything. Attendees should prepare for this type of meeting by reading through the document; most problems will be found during this preparation. The result of the inspection meeting should be a written report. Thorough preparation for inspections is difficult, painstaking work, but is one of the most cost effective methods of ensuring quality.

Black Box Testing Classifications

Classifications of Black Box Testing:

FUNCTIONAL TESTING:

• FUNCTIONAL testing validates functional requirements of an application.It covers how well the system executes the functions it is supposed to execute including user commands, data manipulation, searches and business processes, user screens, and integrations.

SYSTEM TESTING:

• SYSTEM testing is done on overall requirements specifications.This testing covers all combined parts of a system.
  

USABILITY TESTING:

• USABILITY Testing is done to test User-Friendliness of the system.It is done to uncover the areas where user feels uncomfortable in using the software.It leverage areas of strength for maximum usability.It is done by working the end users to asses how the end users are interacting with the software.User interviews, surveys, video recording of user sessions, and other techniques can be used.

SMOKE TESTING:

• SMOKE testing is non-exhaustive software testing that deals with major functionalities of the software and testing the most crucial functions of a program,but not bothering with finer details.This is done for every new build and is done only with valid inputs.This testing is also called build verification test.

SANITY TESTING:

• SANITY testing is done in order to check if the application is ready for further major testing and is working properly without failing up to least expected level.It is 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.

REGRESSION TESTING:

• REGRESSION testing focuses on retesting the software after changes are made for extension or correction to ensure that no defects have been introduced.Some changes done to the software may introduce new bugs or unfix the old bugs,or a change that is done to fix a bug is failed.So to mitigate those risks regression test.Automated testing tools can be especially useful for this type of testing.

RECOVERY TESTING:

• RECOVERY testing is done to check how well the application can recover from crashes,hardware failures etc. Type or extent of recovery is specified in the requirement specifications .Recovery testing is the forced failure of the software in a variety of ways to verify that recovery is properly performed. For example,While the application running, suddenly restart the computer and after that check the validness of application's data integrity.

EXPLORATORY TESTING:

• EXPLORATORY testing is done in order to learn/explore the application.It is informal software test that is not based on formal test plans or test cases. Testers may be learning the software as they test it.

AD-HOC TESTING:

• AD-HOC testing is similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it. Ad hoc testing can find holes in your test strategy,it helps in deciding the scope and duration of the various other testing and it also helps testers in learning the application prior starting with any other testing. It is the least formal method of testing.
  

COMPATIBILITY TESTING:

• COMPATIBILITY testing is done to check how well the software performs in a particular hardware/software/operating system/network environment and different combinations of above.

COMPARISON TESTING:

• COMPARISON testing is done to compare the software strengths and weaknesses with competing products or previous versions and other similar products.

INSTALL/UNINSTALL TESTING:

• INSTALL/UNINSTALL testing is done to check full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.

STRESS TESTING:

• STRESS testing is done by giving stress to the system beyond its specifications to check how and when it fails. This testing is performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load. Stress testing is subjecting a system to an unreasonable load while denying it the resources (e.g., RAM, disc, mips, interrupts) needed to process that load.

LOAD TESTING:

• LOAD testing is done to determine the maximum sustainable load the system can handle.It is done in order to find out at what point the web-site/application fails or at what point its performance degrades. Its a performance testing to check system behavior under load. Load testing operates at a predefined load level, usually the highest load that the system can accept while still functioning properly..In load testing,extreme importance should be given of having large datasets available for testing.Automated testing tools can be useful for this type of testing to generate these large data sets.

ALPHA TESTING:

• ALPHA testing should be done in an in house virtual user environment . This Testing is done at the end of development.Here the users are invited at the development center where they use the application and the developers note every particular input or action carried out by the user.Any type of abnormal behavior of the system is noted and rectified by the developers.Still minor design changes may be made as a result of this testing.

BETA TESTING:

• BETA testing is done when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.Here the software is distributed as a beta version to the users and users test the application at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the developers.

SECURITY TESTING:

• SECURITY testing is done to check how well the system protects against unauthorized internal or external access.It checks if system, database is safe from external attacks.It may require sophisticated testing techniques.

What is Software Testing

Software Testing is the Process of running and executing the software and evaluating the results.It is done to identify error int he software.It is the process used to identify Quality,Correctness,Completeness of the Software product.Testing is done to verify and validate the software.Testing is the measure of Software's Quality and Reliability.

Quality:
A Software is said to be of good quality provided if it is reasonably bug free,developed with in the given date and budget,easily maintainable.
Testing should be done through out the Software Development Life Cycle to bring out quality product.

Life Cycle Testing: It aims at catching defects as early as possible and thus reduces the cost of fixing the bugs.
This can be done by continuously testing the system during all the phases of software development
Software Testing Process:




1.Requirements Analysis Phase:

• Verify whether the requirements are accurate,complete,meet all user needs.
  

2.Design Phase:

• Verify whether design is done to achieve the objectives of the specified requirements and is effective or not.
• Preparing the Test Plan.
  
• Verification is done through Walkthroughs and Inspections.
  

3.Construction Phase:

• Verify the code correctness,completeness and consistency.
• Verify whether the code is done as per standards or not.
• Preparing the Test Cases.
  
• Verification is done through Walkthroughs and Inspections.
• validation is done through Unit Testing and Integration Testing.
  

4. Testing Phase:

• Executing the Test cases.
• Recording the Defects and Tracking them Using Defect Tracking tools.
  

5. Operation and Maintenance Phase:

• After Software moved to Production, any Customizations or enhancements done to the software need to be thoroughly tested and care should be taken not to introduce regression issues.