FacebookTwitterDiggStumbleuponGoogle BookmarksRedditTechnoratiLinkedin


So you want to really help get the fire started?
Frustrated that you have so much to offer the project?
This is your home. Here you will soon find a range of projects related to the MFMP. Each mini project will have a defined goal and the mode of working will be live and open.

How do I take part?

  • Set up a Gmail account
  • Register on the QuantumHeat forum and using your Gmail address
  • Put yourself forward for a particular project giving an overview of the skills you have relevant to the project by sending us a mail using the green "+" to the right or from within the document itself at the top upper right (include your Gmail address in both cases).

You will then be given access to the LIVE linked google docs associated with the mini project and be able to start collaborating.

People who are not actively working on the mini project can still watch the projects documents evolve and do research and post contributions in the comments.

Help Define the Ultimate Black Box Test

Geschrieben von Ryan Hunt am .

There have been some suggestions about us facilitating validation tests for various parties.  Last week at ICCF, I ran into an excellent fellow who had already put a lot of thought into this.  Using some notes he sent me, I started a document flesh out the process.  My hope is that if we are asked to do a validation of device without being able to see inside the device everyone including the inventor, our team, and the general public will know what to expect and be able to trust the results.  Furthermore, I hope this helps to set the bar for anyone doing a validation test or public demo.

Please help us refine this into a comprehensive, well articulated document.  You can review it here and make suggestions, or request to get editing access to the original document.


0 #2 SE 2017-07-20 18:29
As document you should create a test plan which is a project plan for testing. Maybe there a templates for test plans especially for energy devices. I do software testing personally but the main principles should be the same.

* introduction with background information / define why do you want test your device
* describe test object and list all documents related to the test object
* what should be tested / what shouldn't been tested (what can be tested see https://en.wikipedia.org/wiki/ISO/IEC_9126)
* prioritise your the features you want to test. do a risk analysis for this. test the features with a higher prio more extensive.
* list requirement documents (do you want to evaluate against some standards? )
* draft your test strategy (helicopter view). for black box testing you need a good documentation basis. but decide the right test method for every feature independently.
* test environment (plan test environment like you have done it already in your draft, keep the environment parameter under control is a good thing. knowing all your input data and environment parameters makes your test reproducible. keep them constant and stable.)
* plan the test driver for test automation. plan what is done manually.
* calculate what you need - human resources and all test ware. (make or buy decision)
* describe when a test run is assumed as failed or passed
* describe how to proceed when a test run is interrupted - in this case it is important to proof that the test object is still in a defined state.
* plan the execution of the test run itself step by step
* plan all tasks you have to do to prepare the test environment, test run, etc.
* what are the deliverables out of the test activities (documents, etc.)
0 #1 Randall Reviere 2014-01-08 23:45
Just to let you know that as of 1/8/14 your catch is not working on the new account creation page. I'd like to create an account but can't at this point.

Add comment