Black Box Testing

Black Box Testing(Black Box Testing is not a type of testing; it instead is a testing strategy) is also known as "Functional/Behavioural Testing", "Opaque Testing" and "Closed Box Testing". It is a technique whereby the internal workings of the item being tested are not known by the tester. The tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement specifications of the system and as a user, should know, how the system should behave in response to the particular action.

Advantages of Black Box Testing

- Tester can be non-technical.
- Used to verify contradictions in actual system and the specifications.
- Test cases can be designed as soon as the functional specifications are complete.

Disadvantage of Black Box Testing

- The test inputs needs to be from large sample space.
- It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
- Chances of having unidentified paths during this testing

Different Testing Types Under Black Box Testing

These testing types are again divided in two groups:

a) User is not required.

b) Testing in which user plays a role of tester

Testing type where user is not required:

- FUNCTIONAL TESTING: Functionality testing of software is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. Since Functionality testing falls within the scope of black box testing, require no knowledge of the inner design of the code or logic.

- STRESS TESTING:

- LOAD TESTING:

- Ad- hoc TESTING:

- EXPLANATORY TESTING:

- USABILITY TESTING:

- SMOKE TESTING:

- RECOVERY TESTING:

- VOLUME TESTING:

- DOMAIN TESTING:

- SCENARIO TESTING:

- REGRESSION TESTING:

- USER ACCEPTANCE TESTING:

- ALPHA TESTING:

- BETA TESTING:

Testing Methods

Different Testing Methods

1) Black Box Testing
2) White Box Testing
3) Grey Box Testing

Black Box Testing:

Black Box Testing is also known as Functional Testing. It is a technique whereby the internal workings of the item being tested are not known by the tester. The tester only knows the inputs and what the expected outcomes should be and not how the program arrives at those outputs. The tester does not ever examine the programming code and does not need any further knowledge of the program other than its specifications.

Advantages of Black Box Testing

- Tester can be non-technical.
- Used to verify contradictions in actual system and the specifications.
- Test cases can be designed as soon as the functional specifications are complete.

Disadvantage of Black Box Testing

- The test inputs needs to be from large sample space.
- It is difficult to identify all possible inputs in limited testing time. So writing test cases is slow and difficult
- Chances of having unidentified paths during this testing

White Box Testing:

White box testing involves looking at the structure of the core. When you know the internal structure of a product, test can be conducted to ensure that the internal operations performed according to the specification. And all internal components have been adequately exercised.

Advantages of White Box Testing

- More code coverage.

- It can start in the early phase along with software development hence more error can be found earlier during the process of development.

- As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type of input/data can help in testing the application effectively.

- It helps in optimizing the code and giving more stable build.

- It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of White Box Testing

- As the Knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this type of testing, which increases the cost.

- It is nearly impossible to look into every bit of code to find out hidden errors, which may create problems, resulting in failure of the application.

- There is no way to detect missing paths and data-sensitive errors.

Grey Box Testing:

Gray box testing is a combination of black box testing and white box testing. Gray box testing is not black box testing, because the tester does know some of the internal workings of the software under test. In gray box testing, the tester applies a limited number of test cases to the internal workings of the software under test. In the remaining part of the gray box testing, one takes a black box approach in applying inputs to the software under test and observing the outputs.

Gray box testing is a powerful idea. The concept is simple; if one knows something about how the product works on the inside, one can test it better, even from the outside. Gray box testing is not to be confused with white box testing; i.e. a testing approach that attempts to cover the internals of the product in detail. Gray box testing is a testing strategy based partly on internals. The testing approach is known as gray box testing, when one does have some knowledge, but not the full knowledge of the internals of the product one is testing.

In gray box testing, just as in black box testing, you test from outside of a product, just as you do with block box, but you make better-informed testing choices because you're better informed; because you know how the underlying software components operate and interact.

Defect Tracking Life Cycle

[Click on the image for better view]

1) Create Defect: Defect created by the developer while coding.
2) Discover Defect: Defect discovered by the tester while testing.
3) Enter Defect: Reporting the defect using any defect tracking tool.
4) Triage defect: Defect to be assigned to the developer.
5) Debug Defect: If the reported bug is a valid bug it is fixed by the developer.
6) Verify Defect: If the defect is invalid or if it is fixed by the developer then it is once again verified by the tester.
7) If the tester is satisfied by the fix the defect is closed.
8) After verifying if the tester is not satisfied the bug is reassigned and the cycle begins from step 4.
9) The closed bugs are retested during regression testing, if the defect is found again the bug is reopened and the cycle begins from step 4.

Basic fields entered while reporting a defect:

1) Defect ID: Unique ID assigned to the defect(System generated).
2) Defect Summary: Summary of the defect. A one line description that best represents the defect.
3) Assigned to: Assigning the defect to the developer to whom it is concern. This is set by the test lead generally. However if the tester is provided with the module wise developers list, then the tester could update the “assigned to” with the developer names.
4) Severity: Severity of the defect: critical, high, medium and low. This field is set by the testing team based on how sever the defect is and how quickly it need to solved.
5) Status: new, open, fixed, deferred, rejected, reopen, retest, closed, closed – rejected, closed – deferred, closed - duplicate.
6) Module/components: The component or module where the defect is found.
7) Build # / version #: Specify in which build the defect was detected.
8) Priority: Possible values –high, medium, low to be set by the business / development lead for the development team to prioritize the work for the defects added.
9) Attachments: For better understanding of the bugs tester need to attach the screen shot of the defect.
10) Description: Detailed description of the defect. It should provide defect description, reference data, prerequisites (if applicable ), steps to recreate, expected result, actual result, note to refer the attachment section if attachments are enclosed.
11) Fixed reason: The change made to fix the defect. This is done by the developer.
12) Rejected reason and closed – rejected reason: The reasons for rejecting the defect: non reproducible, work as designed, acceptable as it is, test error – not a defect, change / discrepancies in spec. This is also entered by the developer.

Software Development Life Cycle (SDLC): Waterfall Model

The Software Development Life Cycle is the cycle in which the business analysts, the software developers, the database designers and/or the database developers, the QA developers and end users collaborate to build the application software. Basically, it involves designing the application from scratch, documenting everything, adding the improvements and fixing the bugs that occur in the SDLC. It is the lifecycle of Software from concept to obsolescence.

It is divided into following stages:

1) Requirement Specification
2) System Design and Software Design
3) Implementation and Unit Testing
4) Integration and System Testing
5) Operation and Maintenance