!!! Ronald van Maanen - Profession Test Engineer

!! [Test Page|RVM_TEST_PAGE]

!! Links
# [New Bugs|NewBug]
# [Open Bugs|OpenBug]
# [Closed Bugs|ClosedBug]

!! Platforms
The platform I am specialised in is Windows.

!! Found Incidents
|1|List Locks Plugin|[Bug Page Lock Is Displayed While Page Is No Longer Being Edited]|Closed|2.4.102|5.5
|2|Referred Pages Plugin|[Bug Refered Pages Plugin Does Not Recognize Links In Table Construct]|New|2.4.102|5.5

!! Things to test
If you are a developer and like to have your contribution tested feel free to edit this page to add your contribution to it or the link to the page describing your contribution.

|001|[Calendar Plugin ] | Testing if it works correct on XP as it is described| Done | No errors found.|(1)|2.4.102|5.5
(1) I downloaded the version contained in the binary distribution. I Could find a version number so I hope this description will do.

Ronald, this would be a lot more helpful if you were to provide information on which versions of the code you were testing, and also details of your build and test environment. Otherwise it's not a lot of use to anyone except yourself. Thanks! -- MurrayAltheim, 21-May-2007

My apologies for being incomplete. I added as much information as I could find about the version of the Callender Plugin I tested, if you are refering to that plug-in, I hope it is enough. If not let me know..\\
Regards Ronald van Maanen. (21-May-2007)

Thanks, Ronald, I was really meaning more generally, i.e., publishing test results only really helps when the information includes relatively complete details about the test environment, the versions of the code being tested, otherwise there's no way to apply that information anywhere — nobody else can use it. The version of the CalendarPlugin could be ascertained on where you got it, say from a specific CVS version or from a specific release version. That way developers can figure out the rest. But what we're really aiming for is to not require humans to do __any__ testing, it just takes too much time and with CVS changing often daily manually run tests can fail to become relevant after a single day. Ideally there'd be a JUnit test written for each bit of code that was considered in need of testing, that way you'd just run the test suite rather than having to go over each thing every time there was a new build. I'm sure Janne would be overjoyed to have people write more JUnit tests for JSPWiki, which would then be ran each time there was a build. -- MurrayAltheim

I understand your comments. Therefore I would like to propose the following.\\
If an developer has developed a plugin and tested it on his system (i.e. Unix or Solaris) with build in Unit testing I can test by trying to install the plugin according to her/his instructions and test it like a normal user but also try to see how the plugin reacts when I try to for example in combinations with other plugins or try to use it incorrectly and see how it behaves.\\
To make this work there should be mail contact or Wiki Page contact between developer and the tester to make sure that the latest version of the plugin is tested and test results can be returned.\\

Ronald van Maanen - 28-May-2007\\



That's a very generous offer. One problem with this would be that it would require all plugin developers to contact one person, who then becomes a single point of failure (SPF). In software teams it's best to avoid any SPFs if at all possible. People changes jobs, companies, etc. all the time, and on an open source project nobody is even being paid so this becomes even more of an issue.

Because of the nature of JSPWiki being a Tomcat application, which build and test environment (linux, unix, windows, ~MacOS, etc.) shouldn't make very much difference, particularly with things like plugins that generally function entirely within the web application. Probably the greatest benefit for anyone to add to the JSPWiki project in terms of testing would be to learn (if they didn't already) how to create __[JUnit|http://www.junit.org/index.htm]__ tests, which are just little bits of Java code that when run test specific __assertions__ (expected results) for a given run of some code. For example, if the result of running a plugin with a given set of parameters is a specific fragment of XHTML markup, a JUnit test would succeed or fail based on seeing that expected output. There's good documentation on the JUnit website, or you could look at the existing CVS distribution's {{tests}} directory to see the existing JUnit tests, which could serve as an easy way to get started writing your own.

Learning JUnit is also a very good skill to have if you're interested in Java-based testing, as it's probably the most popular testing environment for Java. Each JUnit test that is written is then added to an overall test suite, such that when the JSPWiki code is built, the test harness can be run and see if there if everything is still working. Tests can be written to see if specific combinations of plugins produce expectable results, basically anything that can be written in Java code can be written as a test (e.g., a SQL call, an XSLT transformation, whatever).

If you were to begin writing JUnit tests these could be added to the project and run each time JSPWiki is built. Janne has repeatedly asked all of the development team to contribute JUnit tests for the code we produce, but like any project there's only so much time and we don't (like in a professional organisation with a QA/testing budget) have any people devoted to testing. Testing and QA people are always extremely valuable and very much appreciated, so if you wanted to do this I'd suggest emailing Janne and asking which are the sections of code most critically in need of testing.




The problem is that I am a hobby programmer. I understand VB6 and VB scripting and also some reasonable Perl.\\
However my Java knowledge is at max at beginners level. I can read the code and understand the basics of inhereting. But real programming in Java is not my cup of tea as the english use to say.\\
But testing (and writing parts for user manuals) is my strongest point.\\
Ronald - 07 august 2007.
!! Beta testing version 2.5

I've been testing JSPWiki 2.5.139.\\
I've seen that the sortable table functionality now part of the standard package has become, which I think is aan good idea.\\
What I miss is the grpahical Edit modus that is present in the 2.4 versions.\\
''It's still there.  You just turn it on in the UserPreferences instead of editor page.''

How do I set it then. I searched the site very thouroughly but could not find any information on how to do it via the UserPreferences.\\
I think it has to do with Wki Words but I have no further clue. Something like "Editor=Plain" or maybe "<editor>plain</editor>" \\
Ronald van Maanen
Select Wikiwizard in the UserPreferences' __Editor__ dropdown. --[DF|DirkFrederickx]

The UserPreferences page was populated when visited it later.