2. WHAT IS DEVBOX TESTING?
Dev Box is an abridged version of ‘Developer Machine’. In Dev Box testing, a quality engineer validates,
tests, and verifies a feature in scope on the developer’s machine. It’s as simple as that. A basic approach
through which one ensures the quality of a feature.
3. WHY? WHAT IS THE R.O.I ??
Advantages
● Quality engineer’s technical grasp of the
product
● Upskilling quality engineer
● Failure quickly gives the team more input
● Enhance vertical testing
● Ensure trivial issues are not passed on, later
to be found by the integration or end to end
tests
● Enhance team communication and create
confidence
Trade Offs
● Every team member might take time to
synchronize
● If the team does not follow TDD (Test Driven
Development), it might be challenging or
pointless
● At least two quality engineers should be part
of the team (Dev Box is quality-centric,
hence, would require enough QEs to
accommodate all tasks)
4. WHAT SHOULD BE PREPARED ?!
The process of successful Dev Box testing starts early in the development cycle, when the feature is being discussed
between the Product, Dev, and QA teams. While a story is being groomed, a quality engineer ensures the following
are in place:
● Acceptance criteria (acts as verification points for the test)
● In scope and out of scope features (sets the scope of testing)
● Pre-conditions, if any
5. HOW IT SHOULD BE DONE ??
There is no formalized technique to accomplish it so that the team is the greatest.
● The developer shows the features introduced and modifications made, which influence BA & QA, which
accepted responsibility for this failure or history, on other functional fields. In this phase developer also must
show the features before and after the feature flag sets.
● Developers prepare the Staging Environment to traverse situations, usually in a good trajectory, and ensure the
objective of the work is fulfilled.
● The time used should be 10 to 15 minutes or more, depending on the intricacy of the story or defect.