Black Box Testing and Agile Method of SDLC

by

NAUMAN MITHANI CF109 : Unit 1 : Assignment 1

CF 109 : Unit 1 : Assignment 1b

TABLE OF CONTENTS BLACK BO X TESTING VERSUS W HITE BO X 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 SOFTW ARE DEVELOPM ENT M ODEL .......................... 5 OVERVIEW ................................................................................................ 5 FURTHER DESCRIPTION .............................................................................. 6 AGILE AND WATERFALL ............................................................................. 7 REFERENCES ............................................................................................. 8

Nauman Mithani

CF 109 : Unit 1 : Assignment 1b

BLACK BOX TESTING VERSUS WHITE BOX TESTING

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 softwares 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 Nauman Mithani

CF 109 : Unit 1 : Assignment 1b 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 boxs 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.

Nauman Mithani

CF 109 : Unit 1 : Assignment 1b

WHITE BOX TESTING: ADVANTAGES

1. Inherent efficiency 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. 4. Continuous Integration: Unit tests are a critical aspect of continuous integration. 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.

Nauman Mithani

CF 109 : Unit 1 : Assignment 1b

AGILE SOFTWARE DEVELOPMENT MODEL

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

Nauman Mithani

CF 109 : Unit 1 : Assignment 1b

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 Nauman Mithani

CF 109 : Unit 1 : Assignment 1b 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.

Nauman Mithani

CF 109 : Unit 1 : Assignment 1b

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):4756. Available from: http://dx.doi.org/10.1109/MC.2003.1204375.

Nauman Mithani