pcb-rnd knowledge pool

 

Testing guide for the test sprint

testsprint by Tibor 'Igor2' Palinkas on 2016-07-16	Tags: howto, test, testing, contributing, cuntrobutor, user, test sprint, sprint
node source

 

Abstract: Mini-howto on joining the project as an user on a test sprint.

  Please start 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 (preferably 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 oddities 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 the tests
  • 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.