From kde-edu Wed Apr 25 12:00:41 2007 From: Anne-Marie Mahfouf Date: Wed, 25 Apr 2007 12:00:41 +0000 To: kde-edu Subject: Re: [kde-edu]: Unmaintained apps in kdeedu Message-Id: <200704251200.41682.annemarie.mahfouf () free ! fr> X-MARC-Message: https://marc.info/?l=kde-edu&m=117751790113647 On Tuesday 24 April 2007 20:23:54 Jason Harris wrote: > Anne-Marie Mahfouf wrote: > > Jason: If you explain me how to do a "QA audit" maybe we could do a > > week-end or a day on IRC and get people to help. Maybe even they'll find > > maintainers. > > Sure, here's what I meant in detail: > > First, compile a list of the program's expected behaviors. Every single > action the user can take while interacting with the program should be > included. For example, the behaviors list for KAnagram might look like > the following: > > 1. Menu functions > + Quit program > + About KAnagram > + About KDE > _ KAnagram Handbook > _ Configure Kanagram opens the dialog > _ Next word presents the next puzzle > > 2. General gameplay > _ Correct answer flashes green in edit line, presents a new puzzle > _ Incorrect answer flashes red in edit line > _ Clicking "Hint" shows a hint (for a short period?) > _ Clicking "reveal word" shows the correct answer > _ Clicking on the category name switches to the next category > _ leading and trailing whitespace is ignored when checking for a > correct answer > _ An answer is submitted by pressing the Enter key, or by clicking on > the "Up arrow" button next to the line edit. > B Mouse cursor changes to the "click hand" over all active elements > X Gameplay sounds work > > 3. Configuration Window > B When opening the configure window for the first time, all options are > synced to the actual settings being used by the program > _ Selecting a different language works > X Installing chalk font works > ? Switching to chalk font works > ? Toggling sound works > _ Create new vocabulary works > _ Edit existing vocabulary works > _ Delete existing vocabulary works > X Download new vocabularies works > _ Default options button works > > > Once you have compiled the list, you go through each one and check > whether it works properly in the program (and under a variety of > conditions, if applicable). Then, you indicate whether it passed or > not. I use the following characters: > > + = correct behavior > _ = not yet tested > B = Buggy behavior (perhaps it works under some conditions, but not always) > X = Broken feature > C = causes a crash > ? = Could not test > > So, for example, I found that sound did not work, I could not install > the chalk font, and I could not install a new vocabulary using Get New > Stuff (each of these may be due to the fact that I only have > kdelibs+kdeedu on this machine). Because sound and installing the chalk > font didn't work, I was unable to test their toggles (hence the "?"). > Finally, the mouse-cursor item gets a "B" because the cursor doesn't > change when you mouse over the KAanagram title graphic, even though it > is clickable (it reveals the About dialog), and the initial options sync > gets a "B" because the program initially auto-hides hints, but the > Configure window shows "Do Not Auto-Hide Hints" for this option when it > is first opened. > > It may be tempting to skip "obvious" behaviors in compiling the QA list > (such as "Quit program", or pressing enter to submit a guess), but it is > important to include *all* of the program's behaviors that you can think > of. It's amazing how often some long-overlooked bug is exposed by this > process. > > In general, I try to restrict myself to the set of expected behaviors, > as described in the handbook or implied by the GUI. Enumerating the > behaviors like this will inevitably reveal issues, such as usability > issues, that could be considered outside the scope of this QA survey. > However, we may still want to note these. > > For example, in KAnagram, it would be nice if the category name in the > upper right revealed a listbox when clicking, so that any category could > be selected. If this is inconsistent with the kid-friendly GUI, then at > least providing a "previous" arrow in addition to "next" would be nice. > > Also, when the solution is shown with "reveal word", it would make sense > to provide some visual cue for proceeding to the next puzzle. As it is, > you either press the regular "Next word" button, or type in the revealed > solution. I was thinking of something like a next arrow drawn on the > chalkboard itself, to the right of the revealed word. > > Again, issues like this are *not* the expected KAnagram behaviors, they > are new ideas. So they don't really belong in the QA list. > > regards, > Jason Thanks a lot for the nice explanations. It would be a good idea indeed to audit all KDE-Edu programs at some point using that procedure. In the meantime I'll work a bit on Kanagram fixinfg the obvious maybe I'll start on Saturday if nothing else comes up. Cheers, Anne-Marie _______________________________________________ kde-edu mailing list kde-edu@mail.kde.org https://mail.kde.org/mailman/listinfo/kde-edu