In our process our developers run Unit Tests and Integration Tests before they check in their code for it to be built and deployed to UAT where the testers and product owners can perform their test fixtures and acceptance tests.

Once the unit tests and integration tests have successfully completed, the developer where possible will demonstrate to the tester the working functionality to ensure that the acceptance criteria is satisfied before checking the code in. This test is performed on the development environments by the developer. This begs the question

How do we refer to a non automated test run on the development environment?

I like the sound of Development acceptance testing

Other suggestions could be Pre Check in Review or perhaps Development Sanity Checking

Is there a more standard moniker for this activity doing the rounds in the agile community that I haven't heard of as yet?

  • 3
    Is this the most useful thing you could be doing right now? Naming this? More than that, why are you trying to create a process to describe something that is clearly just people using their best judgement/ normal development stuff, does anyone need a cup of tea made or something?
    – Nathan
    Commented Oct 21, 2015 at 14:52
  • Ah! Hi Nathan. You speak with great wisdom. However; I have to document process for those without your clarity of though and sound sense of judgement. The process guide I'm putting in place is mostly for the benefit of the legacy staff I have inherited who have had little experience of any sound development practice over the past 25 years. The new hires and more agile of the existing staff need little hand holding. Now, does anyone fancy a cup of tea ;) Commented Oct 21, 2015 at 15:27
  • If it is just for documenting the process, just describe it as you did to us: The developers give an (informal) demonstration of the feature. Commented Oct 25, 2015 at 20:01
  • Since this is an informal demonstration you should call it exactly that: a demonstration. (calling it developer acceptance testing seems like an oxymoron to me) - presumably not running any formal test case, or not any formal test case that has not already run.
    – asoundmove
    Commented Nov 18, 2015 at 0:38
  • Also I would check against ISTQB, seems like a growing standard practice these days.
    – asoundmove
    Commented Nov 18, 2015 at 0:42

2 Answers 2


Have a look on this Wikipedia page to check if your process is providing the appropriate test coverage according to SDLC and correlate whatever you call your test coverage with how the industry calls it.

Again, you can call it whatever you want, as long as it provides the appropriate test coverage.

The developer doesn't need to convince anyone that his code works. Test cases should be written based on requirements, and the executed against the code RELEASED for testing. Defects captured during tests are fed back to development to be fixed and then retested.


  • Based on my experience, "System Test" is broadly accepted as a test to be done before UAT. +1.
    – Tiago Cardoso
    Commented Nov 22, 2015 at 23:48

I agree with the others in that it sounds like you want to document formal and prescribed processes, which should be avoided in agile IMO. One key thing though, is that you mention it's going to UAT and going to the tester, but hopefully they've been testing all along and this is really about acceptance. If your organization requires that level of documentation, I'd recommend:

"Ready for Acceptance" - the story is ready for acceptance by the responsible party, typically the Product Owner. In some cases, the developer or QA representative will walk through it with the Product Owner if this was not done throughout the iteration/sprint.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.