Upload
nauman-mithani
View
226
Download
12
Embed Size (px)
Citation preview
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.