Hi All,
Kjetil from fleten.net and I just had an X2Go QA brain storming
session. The context is a school project with a 2 months duration
about the general topic QA. The teachers at that school addressed
Kjetil in the search for possible QA projects. We arranged for an X2Go
QA project with that school, starting in two weeks' time (or so) from
now.
Being aware of several approaches one could take for software QA, we
chose a very simple and feasible approach (considering the short
period of preparation time).
X2Go currently offers two clients (X2Go Client, PyHoca-GUI).
These two clients run on various Linux distributions, MS Windows and
Mac OS X (X2Go Client only).
These two clients connect to Linux servers running X2Go.
The possible scenarios on X2Go Servers are so versatile, that we
definitely need to exclude many possible scenarios from testing and
only focus on some. As this project is supported by Kjetil's company
as a non-profit project, we will as a first step focus on testing
current X2Go features that are provided to customer's at fleten.net.
So the gain for fleten.net is intensive testing of a setup similar to
what they provide to their customers.
The gain for the X2Go project is a matrix / a scheme for testing
current X2Go features in various contexts. The idea is that others
jump in and enhance the methodology, increase the number of tests and
automize parts of the tests, as well. The final goal is that someone
comes in who really knows how software QA works and set up a proper QA
scheme for X2Go. Not now, but as a final goal.
For X2Go QA, Kjetil and I were of the same opinion, that never any
X2Go component should ever "call home" if an error occurs. This is
about respecting people's privacy when using X2Go software in the
first place. Also, a potential "calling-home" feature should
definitely be optional (the user gets asked, if a bug report is to be
sent...). However, from experiences with MS Windows and also with
recent Ubuntu versions, this extra bit of requiring a certain user
interaction is not something we want the user to burden with.
What we will work on during this week: Provide a(n incomplete) list of
X2Go features and compile information about which of the two clients
supports what feature. Months back, I already started such a list (but
got distracted by other stuff). Kjetil will fill in more features and
rework that list, whereas I will review and edit that list later-on.
We work on this list via the X2Go wiki [1].
Potential subprojects for the student project could then be:
(1)
o Create a general remote desktop computing feature list (what would I expect from a remote desktop computing software) o Create a list of X2Go features o see how these two list match...
(2)
o Create a matrix for X2Go feature testing
o Not all features can be tested, as this maybe goes beyond the
scope of this student
project
(3)
o Some students could work on jenkins based package installation
tests (after new
nightly build packages are available)
(4)
o Students can focus on X2Go Server / X2Go Client / PyHoca-GUI
debug messages and see
if there are log messages that are:
- useless (and should be silenced)
- really helpful for debugging
- are useful for heavy debugging, but obfuscate log message output
-> change log levels of certain debug messageso Basically, the debug output of X2Go Server / Client / Python X2Go
should provide
easy-to-read information on what the actual problem of the user is.
(5)
o Translate better between server-side errors and reporting them on
the client-side
(big task!!!)
(6)
o The QA testers need to be able to use the X2Go bug tracker, so
that they can provide
information to the X2Go BTS if tests fail.
(7)
o ... (??? any input from others ???)
So far to the summary of what we are currently working on. If people
have input on this and that or ideas, please feel free to enhance our
discussion.
For next week, we will schedule a meeting with the QA teacher of the
school that we are about to cooperate with. Part of the project will
be that I (Mike#1) will come to Denmark and visit that class of
students and provide support at critical points of the project
(integration).
light+love, Mike
[1] http://wiki.x2go.org/doku.php/wiki:development:x2go-qa
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...