Jump to content

User:J-at-ywalters-dot-net/sandbox

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by J-at-ywalters-dot-net (talk | contribs) at 02:50, 29 August 2020. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

J-at-ywalters-dot-net (j@ywalters.net) sandbox page


Open box testing

Illustration of Open Box Testing discipline

Open box testing (also known as white box testing, clear box testing, glass box testing, transparent box testing, and structural testing) describes a software validation and verification discipline that is typically performed by the application engineers that have directly contributed to a project's source code. Individuals that have direct access to source code are considered to be able to see within the box and have with that ability their significant understanding of the computer programming within the project enables certain activities but also creates some bias challenges.

The following, commonly referenced types of testing activities often comprise open box testing disciplines within organizations that are following modern software engineering practices:

  • Unit testing
    • smallest piece of code that can be logically isolated
  • Component testing
    • also known as program or module testing individual components separately without integrating with other components done after unit testing
  • Integration testing
    • individual software modules are combined and tested as a group
  • System testing
    • verification of a completely integrated system

Practitioners of open box testing disciplines are subject to various cognitive biases, particularly confirmation bias, as it is impractical to have people objectively evaluate the quality of work that they have done. Third party, unprejudiced validations of the work of others is a long determined best practice throughout many industries.

We suck at testing our own code. We suck so badly at it that it has led to entire professions like as Quality Assurance analysts and test engineers. We're not necessarily bad at coding, but we're notoriously bad at finding our own bugs.
Confirmation Bias: How your brain wants to wreck your code [1]

Open box testing activities are typically performed prior to an official, fully integrated installation of a piece of software and the start of an official, objective testing cycle begins. Post-installation, a wide variety of closed box testing disciplines are performed by a variety of different types of software testing professionals.

Illustration of Closed Box Testing discipline

The Shift-left testing approach to software development has the open box testing disciplines as central tenet. As part of this "test early and often" modern and progressive testing approach, developers are being incorporated into the testing cycle earlier than ever before. Focusing on finding and remediating software defects as early as possible within the Software Development Life Cycle (SDLC) has profound benefits in that testing is involved from the very beginning and that quality is a shared responsibility for all involved within the project.

In an Agile software development enabled world, teams are being asked to reduce the length of time of software delivery while continuously improving quality of each release of the software. At the same time, there is typically an increased pressure to reduce testing costs.

Illustration of Open Box and Closed Box Testing disciplines
Illustration of Closed Box and Open Box Testing disciplines
  1. ^ Eland, Matt. "Confirmation Bias: How your brain wants to wreck your code". Retrieved 12 September 2019.