Skip to main content
Topic: [tests] Which are the areas that need access testing? (Read 351 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[tests] Which are the areas that need access testing?

The recent issue with the search has clearly exposed the fact that we need more testing.
And the more we can automate the better.
But in any case, before starting building the tests (because some may be tricky) I would like to list all the areas that have a risk of exposing "confidential" informations and the risk level to prioritize the development of tests.
I'll start listing the most obvious, feel free to mention any other I may have missed.

arearisk levelrisk level reasonrequirements for testing
view an hidden board in board index/message indexMedium.The code is not particularly complex, and shared with many other areas, any bug would be evident quite early in the development.
Particular attention to the different possible configurations.
A forum with a basic setup and 1 hidden board.
direct access to a board a group is no allowed to accessMedium.The code is not particularly complex, and shared with many other areas, any bug would be evident quite early in the development.
Particular attention to the different possible configurations.
A forum with a basic setup and 1 hidden board.
direct access to a topic in a board a group is no allowed to accessMedium.The code is not particularly complex, and shared with many other areas, any bug would be evident quite early in the development.
Particular attention to the different possible configurations.
A forum with a basic setup and 1 hidden board.
Search results showing results from hidden boards.High.The code is quite complex and has a high number of combinations of settings (access, search indexes, groups permissions). A bug may not be immediately evident because the searches may not always lead to hidden content and different setup may give different resultsA forum with a basic setup, 1 hidden board with at least 1 topic and some unique test to simplify the search and pinpoint the bug.
Access to the admin area.Low.The code is very straight forward and easy to verify, potential issues should be easy to identify even at the pull request level.
Potential weak point all the different combination of permissions.
A normal install even without boards and a member without admin privileges. Maybe some other groups with different access levels.
Access to personal messagesMedium.Personal messages are somehow independent from everything and the access is defined though permissions, though the complexity of the code may result in shady situations where it's not always easy to spot changes that may affect access levels.A forum install with at least two members (maybe three), one of which is admin, and at least 1 PM for all members to test some different combinations. Even better if two different conversations between different members.
Access to the moderation area.Low.The code is very straight forward and easy to verify, potential issues should be easy to identify even at the pull request level.
Potential weak point all the different combination of permissions.
A normal install even without boards and a member without admin privileges. Maybe some other groups with different access levels.
Access to someone else drafts.Low.Again code rather straightforward and easy to follow. The permissions involved are mainly "own", so the risk is limited.A forum with two members (or three) and one draft.
Access to attachments in protected boards.Low.Again code rather straightforward and easy to follow. The permissions involved are based on board access, so if the board access is not affected this should work as well.A forum with two members (or three), two baords (one of which not accessible to at least one of the members) and at least one attachment.
Access to profile areasMedium.Indeed the permission system should be somehow easy to validate at PR level, though there are few oddities and considering one of the features to add at some point is a more granular control access, it may become pretty difficult to keep track of all the variations.A forum with at least two members and testing out all the different variation of permissions.
Access to the members list (and corresponding search).Medium.The permission system should be easy,but with custom fields and different level accesses it could become pretty messy (including also custom profile fields and the various permission settings).A forum with at least two members and testing out all the different variation of permissions.
In general visualization of "personal" details (IP address, email address, etc.) more or less at any level of the application (Display, who is online, etc.)Medium.All the functions are more or less centralized, so any issue should be spotted rather easily, though it's also true that there are seveal implication regarding permissions that are not entirely transparent (what permission gives access to view IPs? Which permission allows view emails? etc.), opening the path to potential misunderstanding.A forum with at least a couple of members with different roles and permissions.

At the moment, this is it.
Did I miss anything?
Bugs creator.
Features destroyer.
Template killer.

Re: [tests] Which are the areas that need access testing?

Reply #1
Access to profile info? (And related stuff like viewing/searching members.)

 

Re: [tests] Which are the areas that need access testing?

Reply #2
Added.

Of course this exercise is just the first step, the second one is to start picking cases one by one and build some tests.
Since I believe in unit testing, but I also like to see the final interaction to validate the whole procedure, these cases are IMO better covered by a "web test" on a full install of ElkArte.
In the unit tests we already have "web tests" running through Selenium, that cover:
1) the install procedure,
2) the "add group" admin interface,
3) the activate and delete of a member from the admin panel,
4) log in and log out,
5) the registration procedure and the delete.
Bugs creator.
Features destroyer.
Template killer.

Re: [tests] Which are the areas that need access testing?

Reply #3
Oook.
I think I finished my reworking of the search and now it should be somehow easier to understand (not that much) and test (probably quite a bit).

I think that for this test, what is needed are:
1) 3 users, one with full access to all the boards, one with partial access and one with no access,
2) 2 boards,
3) 1 topic per board with at least a common word.

The expected results should be:
  • user with full access => 2 results
  • user with partial access => 1 result
  • user with no access => 0 result

The tests should be repeated for any (feasible) API.
Bugs creator.
Features destroyer.
Template killer.

Re: [tests] Which are the areas that need access testing?

Reply #4
Seems like that would cover at least the basics ... I don't think we can test the Sphinx API, but for sure the basic, fulltext and custom API's can be covered.
Squish squish. squish, squish, squish.
Find a bug,
Make a wish.