[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Short report from testing the WLUS 1.2-27



Short report from testing of WLUS 1.2-27

- The persistent password arrangement did work as expected

- The test-case 001 creating one new user did fail
   a auto-generated password was put after the common password
  http://developer.skolelinux.no/testing/wlus/001_create_one_new_user.txt
- The test-case 014 creating many users from file, did fail
   this you did not get a message that the users was created
   the ICT-person don't know the users password
   http://developer.skolelinux.no/testing/wlus/014_create_users_from_file.txt
- The test-case 015 with disable/enable users login was a success
   this was as expected
   http://developer.skolelinux.no/testing/wlus/015_disable_login.txt

I also found this receipt. It should be a "OK" here: 
http://developer.skolelinux.no/~knuty/testing/wlus/wlus_tc_016_add_group.png

Andreas writes in the error-fixing log for WLUS 1.2-17:  

* user password change reworked. now we have criteria 
 (configurable, even!) for password quality. 

This has to be shaped up in more than two ways. 

1. It should be possible for the ICT-person at a school to 
   save the automaticly generated password in a file.

2. The password-routine has to be eased up a lot because 
   it adds complexity to already good passwords. 

3. The pupils in 1-4 grade don't remember complex password. Remember
   that this is mainly a system for the lover grades, and until 10-th
   grade. The ICT-person at a school don't need university-level of
   password-handling yet. They can have that option, but not as
   default.

I will call this idea with complex password last minute changes.  I'm
not really sure if this is good or bad, but it produces a lot more
test-cases. If I had programmed this, I would fixed the problems
reported, and then add new features for testing. To do this in two
increments will help the testers and developer(s) to insulate the
error-fixing.

Then we could check the persistence password-thing, and after thats
cleared out of the way, then we could check the "to tight" password
regime. When doing things in more increments, a faulty new function
don't messes up testing of other things. Then we also makes regression-
testing more easy :-)

This was not a problem today, but it has been a problem for 
couple of days last week (with no running system) and could 
be in the future. I did not make to test group-handling either 
because of the new password-functionality ...
 http://developer.skolelinux.no/testing/wlus/004_add_to_group.txt

- K



Reply to: