Index: doc-rnd/devlog/20160716_sprint.html
===================================================================
--- doc-rnd/devlog/20160716_sprint.html (nonexistent)
+++ doc-rnd/devlog/20160716_sprint.html (revision 2271)
@@ -0,0 +1,81 @@
+
+
+
+
+ Testing guide for the test sprint
+
+Please step with procedure I and proceed to procedure II then to procedure III.
+You can postpone or stop any time, even partial results are useful.
+
+The most important procedures are I. and II., which together are estimated
+to take something between 40 and 90 minutes.
+
+No installation, no root privileges required. No interference expected with
+your pcb mainline installation. What you'll need is about the same you would
+need for compiling mainline or a random application:
+
+ - an svn client (e.g. apt-get install subversion)
+
- a C compiler (e.g. apt-get install gcc - anything that supports C99 should work)
+
- the normal development libs (e.g. libc)
+
- extra libs depending on your desired setup (e.g. libgtk2-0-dev)
+
- make
+
+
+ I. Setup [10..30 minutes]
+
+ - Objective: get a running pcb-rnd.
+
- steps:
+
+ - 1. check out the code in a new directory: svn checkout svn://repo.hu/pcb-rnd/trunk
+
- 2. configure: cd trunk; ./configure
+
- 3. check the summary the last step produced; if you don't like it or anything is suspicious, consult Igor2 on IRC
+
- 4. compile: cd trunk; make
+
- 5. check if the compilation terminated with error (->Igor2 on IRC)
+
- 6. dry run: cd trunk/src; ./pcb-rnd
+
- 7. check if it generally runs as expected (note: there's no opengl, the menu layout and some default settings are slightly different)
+
- 8. please report even if everything worked: it's for the record/statistics; please include, in your report:
+
+ - a. your system: uname -a
+
- b. whether you used the gtk HID or the lesstif HID or both
+
+
+
+
+ II. Test drive [30..60 minutes]
+
+
+ - Objective: find random bugs and make suggestions via a simulated production test drive.
+
- steps:
+
+ - 1. take on of your existing .pcb (preferrably one that you can share in case of a bugreport is needed)
+
- 2. copy the .pcb to trunk/src as foo.pcb
+
- 3. run cd trunk/src; ./pcb-rnd foo.pcb
+
- 4. pretend carrying out a real modification; e.g. replace one of the ICs with a footprint of the same pin count but different dimensions (e.g. so8 -> ssop8 or sot23->to220). Pretend you really want to do this modification and pretend that the board will go in production. Do your usual routine (e.g. check gerbers).
+
- 5. if you see anything strange, find bugs, have suggestions:
+
+ - a. consult Igor2 on IRC
+
- b. if there are files to be "attached" or your observation/question can only be stated in a medium sized novel, please send an email to pcb-rnd (at) igor2.repo.hu (and then we can still discuss it on IRC)
+
- c. it is sometimes worth checking the behavior of a recent mainline pcb; there are bugs and strangenesses present in both current mainline and pcb-rnd (because of the common ancestor)
+
+
+
+
+ III. Systematic testing [60..90]
+
+ - Objective: systematic testing of specific features that are affected
+ by recent code rewrite/development.
+
- steps:
+
+ - 1. contact Igor2 on IRC to get a chunk of a testing chunk
+
- 2. understand the subsystem in question (from user perspective)
+
- 3. use your fantasy to invent test methods to see whether the
+ subsystem works in common or normal use cases
+
- 4. use your fantasy to invent test methods to see whether the
+ subsystem works in corner cases
+
- 5. report anything that seems like a bug or undesired behavior or regression
+
- 6. please do report if there's no bug and the given subsystem
+ worked as expected; positive results are just as important as negative ones
+
- 7. start over from step III/1.
+
+
+