https://github.com/kiwitcms/black-boxes
black box hardware for testing
https://github.com/kiwitcms/black-boxes
Last synced: 9 months ago
JSON representation
black box hardware for testing
- Host: GitHub
- URL: https://github.com/kiwitcms/black-boxes
- Owner: kiwitcms
- License: gpl-3.0
- Created: 2020-07-11T20:19:32.000Z (almost 6 years ago)
- Default Branch: master
- Last Pushed: 2021-01-25T08:53:57.000Z (over 5 years ago)
- Last Synced: 2024-10-30T05:42:01.404Z (over 1 year ago)
- Language: C++
- Homepage: https://kiwitcms.org/blog/kiwi-tcms-team/2020/10/10/progress-update-on-open-source-hardware-for-black-box-testing/
- Size: 5.32 MB
- Stars: 1
- Watchers: 5
- Forks: 1
- Open Issues: 13
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Hardware for teaching exploratory testing
The original idea comes from
[James Lyndsay](http://exercises.workroomprds.com/) with more recent
implementation from
[Claudiu Draghia](http://blog.brainforit.com/2017/02/06/black-boxes-for-black-box-testing/).
The premise of these exercises is that when analyzing/exploring a complex
system under test (SUT) it is not very easy to be exercising the system and
observing what happens and analyzing your own actions to figure out if you are
missing something or not. The goal of all exercises is to figure out how each
of them works, e.g. how each box works.
The term [black-box testing](https://en.wikipedia.org/wiki/Black-box_testing)
is used when we have to deal with a SUT whose internals are unknown to the observer.
The only way we can interact with SUT is by input values and the only feedback that
we get is observing if/how SUT changes its final state. All of the examples here are
designed with this in mind, hence the boxes are black in color.
The opposite term also exists:
[white box testing](https://en.wikipedia.org/wiki/White-box_testing) -
this is when SUT internals are known to us, either via documentation or source code
or schematics, something else and/or all of the above.