Strategy for testing UI specific elements


(Klaudia Pałkowska) #1

Hi all,

In order to define a strategy for testing UI specific elements, I have reviewed our manual test cases with the UI component. During the review, I found that some of the test cases were executed 1-2 times a long time ago (i.e. Sprint 25), which suggest that the test case isn’t valuable. Moreover, I found a few test cases with ~140 steps. According to the Testing Guide, a test case should contain up to 40 steps which I think is reasonable and we should avoid adding such long TCs.

Below you can see the improvements which may reduce the time spent on the release testing and increase the quality. All of the mentioned UI elements are currently tested manually.

My suggestions:

  1. Filter buttons should be checked by functional tests (no need to test alignment in a separate ticket).
  2. Sort buttons should be checked by functional tests (no need to test alignment in a separate ticket).
  3. We should include checking some component, like the filter button, in the functional test for the specific screen rather than create a specific manual test case for all occurrences.
  4. Checking whether the given screen is accessible for a user with or without proper rights should be checked by functional tests.
  5. Dropdown placing shouldn’t be tested.
  6. Resizing input boxes shouldn’t be tested.
  7. The colors of the rows in the tables shouldn’t be tested.
  8. Redirecting to the login form after token expiration should be checked by functional tests.
  9. Product grid error messages (validations) should be checked by functional tests.
  10. Toggle on View Shipment should be checked by a functional test.
  11. There is no need to have a test case for the background of the application.
  12. The order of the items in the navigation bar should be checked by a functional test.
  13. Offline actions (power icon, initiate, submit, authorize) should be checked by functional tests.
  14. Filter button’s color should be checked by a functional test.
  15. The pagination component shouldn’t be checked separately because it is checked in the other functional tests (i.e. submitting requisition).
  16. The order of facilities within drop-downs has a unit test, so there is no need to check it manually.
  17. Auto-save the requisition should be checked by a functional test.

The UI elements which should be tested manually:

  1. Table horizontal scrollbar
  2. Sticky columns
  3. Sticky headers
  4. Breadcrumbs
  5. Datepickers

I would appreciate your feedback very much.

Best,
Klaudia


(Sebastian Brudziński) #2

Thanks for looking into this, Klaudia!

Those suggestions sound good to me. I think it would be most valuable to get our testers opinion on this. They can probably weigh in more and confirm where they are seeing regressions on the UI and where they don’t and whether that matches with what we want/don’t want to test.

Best,
Sebastian.


(Sammie Im) #3

Thanks for gathering this list Klaudia. I would love for all of this to be handled by functional tests. Here are some other scenarios that I’ve seen when testing that I’d like to be handled in functional tests, if they aren’t already:

  1. Facilities with long names bug: https://openlmis.atlassian.net/browse/OLMIS-5488
  2. Printing
  3. Pagination
  4. Translations
  5. Requisition template validations before saving
  6. Stock Management error validations
  7. Navigation using back button or refresh

Thanks,
Sam


#4

Hi Klaudia,
I agree with all your suggestions but two:

Ad. 6 - I think resizing input boxes should still be tested because there were some regressions related to it.
Ad. 16 - I wonder whether this unit test works correctly, as for some reason, the following regressions occurred:

Best,
Joanna


(Klaudia Pałkowska) #5

Thank you both for your replies.

Joanna, we can add a functional test for resizing input boxes. As for the second issue, We never had that sorting on the UI but displayed facilities in the order returned by the backend. It is probably broken because of login refactor and saving (minimal) facilities in the database. Although, you are right; we should have a functional test for it.

Thanks,
Klaudia


#6

Hi, Klaudia,

I think that these are interesting observations and should be implemented if we want to improve the release testing. Overall, I agree with your suggestions.

Thanks,
Joanna