And here's a small post scriptum related to the importance of log files. I observed an implicit misconception, I was taken in myself: "Log files are only needed for investigating weird problems. As soon as a failure is reproducible they're not needed anymore, because anyone who is interested might create the log files himself, just by following the steps of the bug description." Rather it's more economical to provide the log files either way, thus saving the effort of reproduction.
Franz -----Original Message----- From: Zieris, Franz [mailto:franz.zie...@fu-berlin.de] Sent: Monday, March 04, 2013 11:54 AM To: Stefan Rossbach Cc: dpp-devel@lists.sourceforge.net Subject: Re: [DPP-Devel] Results from TESTING Hi, I totally agree with these two points! Although I forgot to explicitly request the attachment of the log files, the prior creation of a "good enough" testing plan (e.g. no step-by-step descriptions where a simpler scenario description suffices) indeed was. And as far as I know, Arsenij and Patrick created and followed such a plan. However, at least we agree on the cornerstones of our Pre-Release Testing Procedure, so the re-writing of the according online description should be pretty painless. Best Regards, Franz -----Original Message----- From: Stefan Rossbach [mailto:srossb...@arcor.de] Sent: Monday, March 04, 2013 2:24 AM To: Zieris, Franz Cc: Arsenij Solovjev; dpp-devel@lists.sourceforge.net Subject: Re: [DPP-Devel] Results from TESTING Yes I know this side is outdated but: 1. Give us a detailed description about what you have tested (if you state that all went well ... well ... I will blame you if we will find defects in the "Akzeptanz Tests" 2. Log files ... I do no care where they will be uploaded but: I need the log files (best if you start with an STF configuration so the Log Level is changed to Trace and (not mentioned in this page) the normal Eclipse Log file. If you are testing the new release and do not provide the log files, your are testing for "free" ... a.k.a you can rerun the whole process again until you provide the log files (no log files = no further analysis = no release if something went wrong = you wasted hours of testing) BR, Stefan ----------- Am 03.03.2013 23:10, schrieb Zieris, Franz: Hi all, these "rules" are . special. The last time when logfiles were uploaded to our internal (!) subversion server was on November 9th, 2009. We'll discuss the content of this page after the next release. Arsenij and Patrick asked me personally about their actual tasks for testing and we talked face-to-face, because I knew this page was hopelessly outdated. Best Regards, Franz ----------- From: Stefan Rossbach [mailto:srossb...@arcor.de] Sent: Sunday, March 03, 2013 10:59 PM To: Arsenij Solovjev Cc: dpp-devel@lists.sourceforge.net Subject: Re: [DPP-Devel] Results from TESTING Please follow our rules for testing: http://www.saros-project.org/Testing You missed some things like: * Creating a Test Plan at the TestLink? home page 1. Go to "Test Plan Management" and click on the create button. Give a suitable name to the test plan. 2. Go to "Builds / Releases" and create a new build. We will probably only need a single build. 3. Go to "Add / Remove Test Cases". Choose the test cases you identified earlier. After the test: 1. All test participants store their log files in Subversion at https://svn.mi.fu-berlin.de/agse/sci/dpp/testing/logs/... and send an email to the list telling the others that they have done so 1. Alternatively if log files are small: Test participants send their logs to the list for the TM to upload to SVN. 2. All test participants search their log files for "FATAL", "ERROR" and "WARN". All of these should be collected into an email to be sent to the mailing-list. This should be done no later than 4pm on the test day. 3. ----------- Am 22.02.2013 17:16, schrieb Arsenij Solovjev: Hallo dear devs, There is one critical bug, no regressions and a few mildly irritating things. The critical bug: a) Session-6 doesn't work: the host always gets his favorite color, no matter which color it had in a previous session with the same contact. A few mildly irritating things: a) The colors in the SUC change to the Session colors as soon as a session is started, and revert to the old grey and cyan (which don't look pleasant anyway) when the session ends. b) We couldn't reproduce bug #3458952 on the old release. Both the new and the old release displayed the same kind of behaviour: - A invited B and B accepted and chose a project location. - While B was modifying a shared file the whole time, a session negotiation is started with C - B got restricted to read-only, and couldn't regain permissions (The grant write-access context menu item, was greyed out on the host's side) BR, Arsenij and the test team ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ DPP-Devel mailing list DPP-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dpp-devel
