Black Box Testing

and

Agile Method of

SDLC

by

NAUMAN MITHANI

CF109 : Unit 1 : Assignment 1

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

1

T A B L E O F C O N T E N T S

BLACK BOX TESTING VERSUS WHITE BOX TESTING ... . . . . . . . . . 2 OVERVIEW ................................................................................................ 2

Black box testing ........................................................................................... 2 White box testing .......................................................................................... 2

COMPARISON OF BLACK AND WHITE BOX TESTING ...................................... 3 Black box testing: Advantages ...................................................................... 3 Black box testing: Disadvantages .................................................................. 3 White box testing: Advantages ..................................................................... 4 White box testing: Disadvantages ................................................................. 4

AGILE SOFTWARE DEVELOPMENT MODEL .. . . . . . . . . . . . . . . . . . . . . . . . . 5 OVERVIEW ................................................................................................ 5 FURTHER DESCRIPTION .............................................................................. 6 AGILE AND WATERFALL ............................................................................. 7 REFERENCES ............................................................................................. 8

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

2

B L A C K B O X T E S T I N G V E R S U S W H I T E B O X T E S T I N G

OVERVIEW

BLACK BOX TESTING

Black box Testing may be defined as front-end tests of the functionality of

the application under consideration. The testing of the internal structures,

mechanisms or code falls outside its domain.

Other names for this methodology are Specification-based technique,

Functional Testing and Behavioural Testing.

Typically, a set of input/response or input/outcome relationships is established

that encompasses the software’s requirements. A test suite is set-up based upon

this set of input/response relationships, and executed; the objective is to verify

the respective outcomes received against the expected outcomes.

A functional Black box test would be testing the ON/OFF functions of a

television by pressing the power button and noting whether the television turns

ON from OFF or vice versa. A non-functional test would be the time taken by

the television in turning ON/OFF.

It is mostly applicable to higher levels of testing such as Acceptance and System

Testing.

WHITE BOX TESTING

White box testing may be defined as the utilisation of the knowledge of the

internal structure and its code to test it and its implementation. It thus stands in

stark contrast to Black box testing , which tests the external/output functions,

where knowledge of internal structure or code is not required nor used.

White box testing is also known as Clear box testing, Glass box testing,

Transparent box testing and Structural testing.

This method of testing is similar to the testing of nodes in a circuit or the various

paths of a maze where the appropriate outputs are determined based on the

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

3

inputs. The test is the mechanism or the path of the code that leads to its

respective output.

Determination of all valid and invalid inputs for a software may be considered

White box testing as it requires knowledge of the implementation of the

underlying code.

In contrast to Black box’s predominant applicability, White box testing is

applicable mostly to lower levels such as Unit and Integration Testing.

COMPARISON OF BLACK AND WHITE BOX TESTING

BLACK BOX TESTING: ADVANTAGES

1. Absence of bias: The designer/programmer and tester are two

independent parties with independent objectives.

2. Quicker development (of tests): Knowledge and understanding of

internal structure is not required since only the external front-end

functions are tested.

3. Lower costs: Specific knowledge expertise is not required.

4. Simplicity: In the case of large or complex applications, the inherent

nature of Black box testing offers simplification by verifying the

appropriate outputs received based on the inputs.

BLACK BOX TESTING: DISADVANTAGES

1. Redundancy: Since there is no know-how of the implementation

of the code, the same paths of code can be tested multiple times

whilst others may never be tested at all

2. Finite input permutations: It is impossible to test all possible

inputs or input permutations in a reasonable amount of time; thus,

certain paths may never be tested.

3. Maintenance of scripts: Changes in applications may render a

test suite unsuitable since the tests rely on a specific GUI.

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

4

WHITE BOX TESTING: ADVANTAGES

1. Inherent eff iciency of automated tests: Unit tests may be

designed for different sections of the code and may be run

independently, and therefore simultaneously, thus saving time.

2. Swifter de-bugging: Since the tests are based upon the code,

less time and effort is required to locate bugs such as regression

errors.

3. Continuous Integration: Unit tests are a critical aspect of

continuous integration.

4. Test-driven development (TDD): This prominent Agile practice

is based upon the design of unit tests during the process of

development.

WHITE BOX TESTING: DISADVANTAGES

1. Validation of requirements: Since White box testing intrinsically

focuses on the internal paths and mechanisms (how), it is less suited

to validating requirements since Black box testing intrinsically

focuses on input-output and (front-end) functionality (why).

2. Misinterpretation of requirements: A mistake in the

understanding of the requirements could lead to an undesired

implementation of a requirement. A test would not identify this

since the fault would not lie in the programming code rather in the

design itself.

3. User behaviour: Since this testing does not focus on front-end or

end-user functionality, it is less able to account for any error that

arises depending upon an unexpected permutation of user actions.

In reality, Grey box testing methods, a combination of both, are commonly

employed.

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

5

A G I L E S O F T W A R E D E V E L O P M E N T M O D E L

OVERVIEW

The Agile Software Development Model (approach or methodology) is

one where software development is iterative, incremental and evolutionary. This

term was introduced in 2001 in the Agile Manifesto by its lead proponents.

Under this approach, software developers are (self-)organised into cross-

functional teams which then focus on their respective modules. It promotes a

time-boxed iterative approach and evolutionary development. This approach

dynamically accommodates changes in the user requirements and changes are

made as the development progresses/evolves. The Manifesto cites the following

points as its core philosophy:

• Organisation and interactions: Self-organisation and motivation

are key aspects, and where the environment promotes interactions such

as co-location (in-person conversation) and pair programming.

• Working software: In meetings or presentations to the client, working

software is far more practically useful and welcome measure of progress.

• Client collaboration: not all requirements of the client may be

collected at the start of the software development AND/OR

requirements may change (evolve) over the course of the development;

therefore, involvement of and cooperation with the client is crucial.

• Rapid response to change and continuous development are key

features of the Agile approach.

• Increments and iterations: further functioning modules are added

and delivered frequently.

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

6

FURTHER DESCRIPTION

The Agile methodology functions by dividing the software development project

into smaller tasks and accomplishes them in an incremental manner. Planning is

short-term where the iteration time-boxes are of 1 to 4 weeks in duration with

the objective of implementing or adding certain new functions (increments) or

correcting existing ones. Such an iteration time-box is thus also known as

“Sprint”.

During each sprint, cross-functional teams work simultaneously on all aspects

such as planning, analysis of requirements, design, coding and testing (unit and

acceptance). At the conclusion of each sprint, the software that has incorporated

the incremental change is demonstrated to the client. This way, the project can

adapt better to desired changes or corrections.

During the planning stages of the project, the Product Backlog list is created,

comprising all requirements known at the time. The requirements are then

prioritised and the required resources estimated. The Product Backlog is

dynamic and is subject to new items and details, as well as revisions or updates

of priorities and estimations of required resources. The Backlog is reviewed by

the development team at every sprint.

Communication under the Agile method involves routine daily in-person

meetings. The meetings are conducted at the same time and place everyday

and involve the participants remaining standing for the duration; this ensures the

meetings are brief (15 min. maximum). Thus, the routine and brief nature of

these meetings have lent it the term “(daily) scrum meetings”. During the

scrum meetings, the team members discuss their accomplishments over the last

day, their objectives for the current day and their challenges.

A characteristic feature of the Agile daily scrum is the inclusion of two types of

personnel: (1) Scrum Master and (2) customer representative. The Scrum

Master is the facilitator of the scrum meetings who ensures it is productive and

flows smoothly. He does not assign tasks to the members of the team as that is a

team responsibility, rather assist the team members in tackling their challenges.

The Customer Representative is the liaison between the customer and the

development team. It is his role to maintain focus on the requirements and

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

7

serves as a source of reference in that capacity. He is also the keeper of the

Product Backlog.

AGILE AND WATERFALL

The Agile methodology rose to prominence due to the limitations presented by

the strict, regimented Waterfall methodology.

Under the Agile method, software is developed by concurrent development of

constituent modules that are combined incrementally to yield the finished

product. Waterfall is linear and sequential, where progress is perceived as a

steady cascade through the various phases of conception, initiation, design,

development and testing.

Agile is considered a “lightweight”, flexible method that allows for frequent

changes and testing alongside the construction of the product. It is thus suited

to situations that are fluid e.g. when the customer requirements are vague or the

business environment is uncertain. One risk that arises from this flexible nature,

which is accommodating to frequent changes/updates, is the possibility the

project may lose direction.

In cases where the environment is stable and where there is no room for

deviation from the predetermined design, Waterfall is apt. It is also better suited

to cases where frequent interactions with the customer is not possible or when

possibility exists that developers may quit the project midway.

Waterfall is also prominent in safety-critical, documentation-heavy and

modelling-dependant environments. Since the Waterfall model places its stress

on the end-product vs. the process, it has maintained its presence in

environments where safety and quality are paramount over speed.

It must be ever borne in mind that neither model is perfect; both are sensitive to

the developers that practise it and the contexts in which they are deployed.

CF 109 : Unit 1 : Assignment 1b

Nauman Mithani

8

REFERENCES

• Abrahamsson P. “Agile software development methods : review and

analysis”. VTT; 2002. Available from:

http://www.worldcat.org/isbn/9513860108.

• Beck, Kent. “Manifesto for Agile Software Development”; 2001.

• Ambler SW. “Examining the Agile Manifesto”; 2011.

• Larman C, Basili VR. “Iterative and incremental developments. a brief

history”. Computer. 2003 Jun;36(6):47–56. Available from:

http://dx.doi.org/10.1109/MC.2003.1204375.