Just taken from the following plan:
http://www.saros-project.org/ReleaseProcess
Before 12:00: RM creates a new release branch from master
<http://www.saros-project.org/w/SE/DPPReleaseProcess#HowToBranch>, runs
the JUnit test cases
<http://www.saros-project.org/w/SE/DPPTesting#HowToRunTheJUnitTestCases>
and the STF tests.
1. Please discard: runs the JUnit test cases
<http://www.saros-project.org/w/SE/DPPTesting#HowToRunTheJUnitTestCases>
and the STF tests if you do not push something to the main branch in the
last minute,
or it was commited after 6 A.M o clock (this is the time where the last
STF Regression currently started)
Check the CI logs, if there were any change after 6. AM, login to the CI
server and trigger the 2 CI STF manually after the Saros plugins were build.
If step 1 was not necessary do not bother the team with Junit / STF
results because the CI already may did this (was not occuring during
this release cycle)
Step 2: Before 16:00: both of the following tasks have to be done.
Attention: The second tasks depends on the first one!
"Try to sort items by importance and write in a language which
*<b>users</b>* can understand "
This was not done for many releases now. It is very polite to present
your testing crew a patch log, written in "developer style"
so they may guess what they should try to test. It is part of the RMs to
write this down, maybe gathering detailed feedback from
the developer who commited this code change / patch to figure out the
behaviour and describe it in a human understandable way.
Yes Franz, you ask me, but AFTER Sebastian posted the change log.
10:00-16:00 - Run the Testlink test suite
<http://www.saros-project.org/w/SE/DPPTesting#HowToTest> (TM & ATM,
assisted by RM & ARM)
* Test managers *must* close bugs in the bug tracker that are verified
as fixed
we still have open bugs that are mark as fixed for month now (they were
and are still present between the dummy release in may and july and after)
16:00-17:00 - TM sends to the mailing-list
* ...a list of critical bugs and regression
* ...a list of comments on the change-log. In particular whether a
|[FIX]| or actually worked
* ...all log files generated during the test as one big archive
log files only from Norman which made the whole testing worthless to
some points.
Oh btw, the XYZ times ... wait this time I square it ... post you damn
Eclipse log files, without
nobody may retrieve errors that occurs in the GUI code base
You may wasting your testing time, saying button XYZ pressing ZYX times
does nothing, because the developer has no clue what is really going on.
Posting "weird" testlink results:
In the Test for the [FIX] NPE in the IncomingProjectNegotiation, we
could see that the cancellation during an initial
project-transfer from ALICE to BOB doesn't work. The Session stays, and
the transmitted project is marked as shared.
(Take a look to
https://sourceforge.net/tracker/?func=detail&atid=843359&aid=3539670&group_id=167540
)
That's an important bug. We set the Priority to 8 (It's important, that
we find the reason for this bug and fix it for this release).
Summary was:
*Tests the cancellation during an initial invitation. *
*Use the STF-Test InviteAndLeaveStressTest. During the test, there
shouldn't be NullPointer-Exceptions. *
*Take a look to the log-files to see if there exists
NullPointer-Expetions with lines like that:*
at
de.fu_berlin.inf.dpp.invitation.IncomingProjectNegotiation.executeCancellation(IncomingProjectNegotiation.java:567)
at
de.fu_berlin.inf.dpp.invitation.IncomingProjectNegotiation.processException(IncomingProjectNegotiation.java:553)
at
de.fu_berlin.inf.dpp.invitation.IncomingProjectNegotiation.accept(IncomingProjectNegotiation.java:217)
at
de.fu_berlin.inf.dpp.ui.wizards.AddProjectToSessionWizard$2.run(AddProjectToSessionWizard.java:260)
???? Refacoring code in those closes make the summary become absolute.
Result should be:
3
ALICE cancel the project-transmission.
Session ends. Users get the information that the invitation was cancelled.
Least but not least, execution is "automated" ... THE TestLink Job from
Jenkins currently does not work (ever tried to use it ? Nobody complains
= no fix, why fixing things that are
not used), this test could never have been run in an automated
environment as there is not NO STF test case that is testing that behaviour.
Wednesday, Thursday
* The whole team fixes critical bugs on the branch
Und ich bin Jesus, oder Gott ... garantiert beides nicht und das mit
100% Wahrscheinlichkeit.
Also: Test backwards-compatibility. In a test session, one person should
use the branch version, the other uses the previous Saros version. This
information is important in the releasing process that follows.
I do not think that this is tested. (low prio)
Please take this process seriously, it should be fun and not a waste of
your time (If you think it is wasting your time or is boring, sleep
about it ... ). And please do not test until you are asleep. You may
make faults. It will not matter if we delay a release for a couple of days.
Regards,
Stefan
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dpp-devel mailing list
Dpp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dpp-devel
