diff --git a/tests/testcases/Group3-RBAC/3-01-DB-user-manage-project-members.md b/tests/testcases/Group3-RBAC/3-01-DB-user-manage-project-members.md
new file mode 100644
index 000000000..fce0235cf
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-01-DB-user-manage-project-members.md
@@ -0,0 +1,74 @@
+Test 3-01 - Manage Project Members (DB Mode)
+=======
+
+# Purpose:
+
+To verify that a non system admin user can add members of various roles to a project when users are managed locally by Harbor (DB mode).
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
+* A linux host with Docker CLI installed (Docker client).
+* At least three non-admin users are in Harbor. 
+
+# Test Steps:
+
+**NOTE:**  
+* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
+* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. 
+* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
+
+1. Log in to UI as user A (non-admin).
+2. Create a new project X with publicity is off (default).
+3. Verify that user A cannot change his/her own role of project X.
+4. On a Docker client host, use `docker login <harbor_host>` to log in as user A. 
+5. Push an image to project X.
+6. On the Docker client host, log out user A and log in as user B.
+7. Use `docker pull` to pull the image from project X. (should fail)
+8. Use `docker push` to push an image to project X. (should fail)
+9. Keeps user A's UI session logging on, in a different browser log in as user B.
+10. User B views "My Projects", should not see project X.
+
+11. In user A's UI, add user B to project X as a guest.
+12. In user B's UI, check project X is in "My projects" and view members and images of project X.
+13. Verify that user B cannot change role of other members in project X.
+14. Verify that user B cannot add a new member to project X.
+15. On a Docker client host, user B again pulls the image from project X. 
+16. user B pushes a new image to project X. (should fail)
+17. In user A's UI, update user B to developer role of project X.
+18. In user B's UI, check project X is in "My projects" and view members and images of project X.
+19. Verify that user B cannot change role of other members in project X.
+20. Verify that user B cannot add a new member to project X.
+
+21. On a Docker client host, user B pushes a new image to project X. 
+22. In user A's UI, update user B to project admin role of project X.
+23. In user B's UI, check project X is in "My projects" and view members and images of project X.
+24. Verify that user B can add a new member user C to project X.
+25. Verify that user B can change role of user C in project X.
+26. On a Docker client host, user B pushes a new image to project X. 
+27. In user A's UI, remove user B from project X.
+28. On a Docker client host, user B pulls an image of project X. (should fail)
+29. On a Docker client host, log out user B and log in as user C. 
+30. User C pulls an image of project X. 
+
+# Expected Outcome:
+
+* Step 3, user B cannot change his/her own role, and cannot remove himself/herself from project X.
+* Step 7, user B should fail to pull image from project X. 
+* Step 8, user B should fail to push image to project X. 
+* Step 9, make sure to keep A's session while using another browser to log in as user B.
+* Step 10, user B should not see project X.
+* Step 12-14, as described.
+* Step 15, user B can pull the image of project X, 
+* Step 16, user B cannot push images to project X.
+* Step 18-20, as described.
+* Step 21, user B pushes an image successfully.
+* Step 23-25, as described.
+* Step 28, user B's pulling should fail
+* Step 30, user C's pulling should succeed.
+
+# Possible Problems:
+None
\ No newline at end of file
diff --git a/tests/testcases/Group3-RBAC/3-02-DB-user-manage-project-publicity.md b/tests/testcases/Group3-RBAC/3-02-DB-user-manage-project-publicity.md
new file mode 100644
index 000000000..40fd749ed
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-02-DB-user-manage-project-publicity.md
@@ -0,0 +1,49 @@
+Test 3-02 - Manage Project Publicity (DB Mode)
+=======
+
+# Purpose:
+
+To verify that a non system admin user can change project publicity of a project when users are managed locally by Harbor (DB mode).
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
+* A linux host with Docker CLI installed (Docker client).
+* At least three non-admin users are in Harbor. 
+
+# Test Steps:
+
+**NOTE:**  
+* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
+* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. 
+* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
+
+1. Log in to UI as user A (non-admin).
+2. Create a new project X with publicity is on.
+3. On a Docker client host, use `docker login <harbor_host>` to log in as user A. 
+4. Push an image to project X.
+5. On the Docker client host, log out user A and log in as user B. 
+6. User B pulls an image from project X.
+7. Keeps user A's UI session logging on, in a different browser log in as user B.
+8. User B views "My Projects", should not see project X.
+9. User B views "Public Projects", should see project X.
+10. In user A's UI, change publicity of project X to off.
+11. In user B's UI, user B checks "My Projects" and "Public Projects", should not see project X in both places.
+12. On the Docker client host, user B pulls an image from project X. (should fail)
+13. In user A's UI, change publicity of project X to on again.
+14. User B views "My Projects", should not see project X.
+15. User B views "Public Projects", should see project X.
+
+
+# Expected Outcome:
+* Step 6, user B's pulling image from project X should succeed. 
+* Step 7, make sure to keep A's session while using another browser to log in user B.
+* Step 8-11, as described.
+* Step 12, user B's pulling should fail.
+* Step 13-15, as described.
+
+# Possible Problems:
+None
\ No newline at end of file
diff --git a/tests/testcases/Group3-RBAC/3-03-DB-user-search-project-members.md b/tests/testcases/Group3-RBAC/3-03-DB-user-search-project-members.md
new file mode 100644
index 000000000..8c8bce185
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-03-DB-user-search-project-members.md
@@ -0,0 +1,40 @@
+Test 3-03 - Search Project Members (DB Mode)
+=======
+
+# Purpose:
+
+To verify that a non system admin user can search members of a project when users are managed locally by Harbor (DB mode).
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
+* A linux host with Docker CLI installed (Docker client).
+* At least five(5) non-admin users are in Harbor. 
+
+# Test Steps:
+
+**NOTE:**  
+* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
+* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. 
+* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
+
+1. Log in to UI as user A (non-admin).
+2. Create a new project X.
+3. Add user B as a project admin role of project X. 
+4. Add 3 more members to project X with various roles, such as developer, guest. 
+5. Keeps user A's UI session logging on, in a different browser log in as user B.
+6. In user B's UI, search members of project X using different criteria (keywords). 
+7. In user A's UI, change user B's role to developer of project X.
+8. In user B's UI, search members of project X using different criteria. 
+9. In user A's UI, change user B's role to guest of project X.
+10. In user B's UI, search members of project X using different criteria. 
+
+
+# Expected Outcome:
+* Step 6,8,10, user B should see results based on search keywords. 
+
+# Possible Problems:
+None
\ No newline at end of file
diff --git a/tests/testcases/Group3-RBAC/3-04-LDAP-user-manage-project-members.md b/tests/testcases/Group3-RBAC/3-04-LDAP-user-manage-project-members.md
new file mode 100644
index 000000000..e20a507a0
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-04-LDAP-user-manage-project-members.md
@@ -0,0 +1,31 @@
+Test 3-04 - Manage Project Members (LDAP Mode)
+=======
+
+# Purpose:
+
+To verify that a non system admin user can add members of various roles to a project in LDAP mode.
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
+* A linux host with Docker CLI installed (Docker client).
+* At least three non-admin users are in Harbor. 
+
+# Test Steps:
+
+**NOTE:**  
+* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
+* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. 
+* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
+
+Same as Test 3-01.
+
+# Expected Outcome:
+
+Same as Test 3-01.
+
+# Possible Problems:
+None
\ No newline at end of file
diff --git a/tests/testcases/Group3-RBAC/3-05-LDAP-user-manage-project-publicity.md b/tests/testcases/Group3-RBAC/3-05-LDAP-user-manage-project-publicity.md
new file mode 100644
index 000000000..9be70ca80
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-05-LDAP-user-manage-project-publicity.md
@@ -0,0 +1,31 @@
+Test 3-05 - Manage Project Publicity (LDAP Mode)
+=======
+
+# Purpose:
+
+To verify that a non system admin user can change project publicity of a project in LDAP mode.
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
+* A linux host with Docker CLI installed (Docker client).
+* At least three non-admin users are in Harbor. 
+
+# Test Steps:
+
+**NOTE:**  
+* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
+* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. 
+* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
+
+Same as Test 3-02.
+
+
+# Expected Outcome:
+Same as Test 3-02
+
+# Possible Problems:
+None
\ No newline at end of file
diff --git a/tests/testcases/Group3-RBAC/3-06-LDAP-user-search-project-members.md b/tests/testcases/Group3-RBAC/3-06-LDAP-user-search-project-members.md
new file mode 100644
index 000000000..bed13514a
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-06-LDAP-user-search-project-members.md
@@ -0,0 +1,26 @@
+Test 3-06 - Search Project Members (LDAP Mode)
+=======
+
+# Purpose:
+
+To verify that a non system admin user can search members of a project in LDAP mode.
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against an LDAP or AD server. ( auth_mode is set to **ldap_auth** .) The user data is stored in an LDAP or AD server.
+* A linux host with Docker CLI installed (Docker client).
+* At least five(5) non-admin users are in Harbor. 
+
+# Test Steps:
+
+Same as Test 3-03.
+
+
+# Expected Outcome:
+* Same as Test 3-03.
+
+# Possible Problems:
+None
\ No newline at end of file
diff --git a/tests/testcases/Group3-RBAC/3-11-DB-admin-user-manage-project-members.md b/tests/testcases/Group3-RBAC/3-11-DB-admin-user-manage-project-members.md
new file mode 100644
index 000000000..b1a86a9b6
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-11-DB-admin-user-manage-project-members.md
@@ -0,0 +1,78 @@
+Test 3-11 - Admin Manages Project Members (DB Mode)
+=======
+
+# Purpose:
+
+To verify that an admin user can add members of various roles to a project. Users are managed locally by Harbor (DB mode).
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
+* A linux host with Docker CLI installed (Docker client).
+* At least three non-admin users are in Harbor. 
+* At least one project that admin user is not a member of.
+
+# Test Steps:
+
+**NOTE:**  
+* In below test, user A, B and C are non system admin users. User A, B, C and project X should be replaced by longer and meaningful names.
+* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. 
+* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
+
+1. Log in to UI as admin user.
+2. Look for an existing project X that admin is not a member of. 
+3. Add user A to project X as project admin.
+4. Add user B to project X as developer.
+5. Add user C to project X as guest.
+6. On a Docker client host, use `docker login <harbor_host>` to log in as admin. 
+7. Use `docker push` to push an image to project X. 
+8. Use `docker pull` to pull the image from project X. 
+9. On a Docker client host, log out admin and log in as user A. 
+10. Use `docker push` to push an image to project X. 
+11. Use `docker pull` to pull the image from project X.
+ 
+12. On a Docker client host, log out user A and log in as user B. 
+13. Use `docker push` to push an image to project X. 
+14. Use `docker pull` to pull the image from project X. 
+15. On a Docker client host, log out user B and log in as user C. 
+16. Use `docker pull` to pull the image from project X. 
+17. Use `docker push` to push an image to project X. (should fail)
+
+18. Keeps admin's UI session logging on, in a different browser log in as user C.
+19. In user C's UI, verify his/her role is guest of project X. 
+20. In admin's UI, change user C's role to developer of project X.
+21. In user C's UI, verify his/her role is developer of project X. 
+22. On a Docker client host, log in as user C. 
+23. Use `docker pull` to pull the image from project X. 
+24. Use `docker push` to push an image to project X. 
+25. In admin's UI, change user C's role to project admin of project X.
+26. In user C's UI, verify his/her role is project admin of project X. 
+
+27. In admin's UI, remove user C's from project X.
+28. Set project X's publicity to on.
+29. On a Docker client host, log in as user C. 
+30. Use `docker pull` to pull the image from project X. 
+31. Use `docker push` to push an image to project X. (should fail)
+32. In admin's UI, remove user C's from project X.
+33. Set project X's publicity to off.
+34. On a Docker client host, log in as user C. 
+35. Use `docker pull` to pull the image from project X. (should fail) 
+36. Use `docker push` to push an image to project X. (should fail)
+
+
+# Expected Outcome:
+
+* Step 7,8,10,11,16 should succeed.
+* Step 17 should report errors.
+* Step 19,21, as described.
+* Step 23,24 should succeed.
+* Step 26 as described.
+* Step 30 should succeed.
+* Step 31 should fail.
+* Step 35-36 should fail.
+
+# Possible Problems:
+None
\ No newline at end of file
diff --git a/tests/testcases/Group3-RBAC/3-12-DB-admin-user-search-project-members.md b/tests/testcases/Group3-RBAC/3-12-DB-admin-user-search-project-members.md
new file mode 100644
index 000000000..df05ae4b4
--- /dev/null
+++ b/tests/testcases/Group3-RBAC/3-12-DB-admin-user-search-project-members.md
@@ -0,0 +1,34 @@
+Test 3-12 - Admin Search Project Members (DB Mode)
+=======
+
+# Purpose:
+
+To verify that an admin user can search members of a project when users are managed locally by Harbor (DB mode).
+
+# References:
+User guide
+
+# Environment:
+* This test requires that a Harbor instance is running and available.
+* Harbor is set to authenticate against a local database. ( auth_mode is set to **db_auth** .) The user data is stored in a local database.
+* A linux host with Docker CLI installed (Docker client).
+* At least five(5) non-admin users are in Harbor. 
+* At least 5 members in a project that admin user is not a member of.
+
+# Test Steps:
+
+**NOTE:**  
+* In below test, user A, B are non system admin users. User A, B and project X should be replaced by longer and meaningful names.
+* MUST use two kinds of browsers at the same time to ensure independent sessions. For example, use Chrome and Firefox, or Chrome and Safari. 
+* DO NOT use the same browser to log in two users at the same time in different windows(tabs).
+
+1. Log in to UI as admin.
+2. Look for an existing project X that admin is not a member of, project X should have at least 5 members. 
+3. Search members of project X using different criteria (keywords). 
+
+
+# Expected Outcome:
+* Step 3, admin should see results based on search keywords. 
+
+# Possible Problems:
+None
\ No newline at end of file