Asset management and test status - NextensArelB/SwaggerGenerationTool GitHub Wiki

[[TOC]]

##Introduction This US/task has all to do with how we fill the Asset management database with test state and test coverage percentage per component level that has been put in the Access database*.
= Let teats automation team member know if you need the shortcut to this database, it cannot be included in this document A component in this database is a piece of software that is part of the Nextens product. This database is used to generate reports for management on the status of the Nextens products.

##Current situation Ben (van Tol) and Monica agreed that we will use Yoge's excel sheet with detailed test descriptions for the Naslag product and see if we can fill this component database with the test coverage like described in the next chapter.

##How test coverage could be measured

#Test coverage for the Unittests This could be automatically measured by components included in the CICD pipleine. Will have to find out what components can measure code coverage for unit tests This way the team can see what the coverage is and monitor the trends. At some point you can make sure the pullrequest does not get through when the test coverage is below a certain amount.

Test coverage measurement Unit tests Test coverage is measured by the Release process in the CICD pipeline and comes with an exact measure.

#Test coverage for API tests This could be measured by making sure all calls are coveraged by an API and all of the following conditions are met. The test coverage for an API is 100% when:

  1. All API calls (all calls of all Controllers) are covered by an test
  2. All parameters of all calls are tested (if the call has parameters): 2.1 Test if parameter handles null value correct for object parameters. if there are more than one parameter you test one at the time for null handling and all parameters with null value. 2.2 Test if the parameters have correct value's the call returns the expected result(s) 2.3 Test if the parameters have incorrect value's the call handles the error in a correct and secure fashion. You can think of data type checking, check for ranges, check for special characters (in the code a white list should be implemented).
  3. If applicable test for security: 3.1 If applicable test the API key is checked

Test coverage measurement API tests If all end points are covered by all criteria described above we have an 100% coverage. Or else coverage can be calculated as follows: Amount of end points / 6 criteria (1, 2, 2.1, 2.2, 2.3, 3.1) * matched criteria

Time estimation For an average API call having 4 parameters estimate is 2 hours per call.

#Test coverage for UI tests To measure the test coverage for UI pages is not so easy. What we can do is take the amount of controlls on a page and see how many are tested by an UI test and then come up with a percentage. Test coverage is 100% when: For all pages that belong to an (sub) part of the Nextens product:

  1. For all these pages go trough the controls on this page and test: 1.1 Test if the control exists (in the DOM) 1.2 Check if the control has the right status: (visible, enabled, has the right styling attributes etc) 1.3 Check if the control accepts correct input 1.4 Test the behaviour when you enter incorrect input. You can think of checking for data type (text, valid date time value), syntax check, valid ranges check. 1.5 If applicable: check the flow when the page has links to other pages

Test coverage measurement UI tests If for all pages all criteria points above are matched the test coverage is 100%. Or else the coverage can be calculated as follows: Amount of all controlls of the pages / 4 or 5 criteria (1.1, 1.2, 1.3, 1.4, 1.5) * matched criteria

  • Test coverage for E2E tests [new, added by monica]

Time estimation For UI pages it is difficult to come up with an average estimate because there are page with 200+ controlls and pages with just some of them. Also when a page contains a grid with it's functionalities (Sort, order, find etc) it is time consuming to create an test. For an average page having 30 controls estimate is 4 hours.

##The Access Assets database When you have the shortcut on your local system you can start the database you can open the database locally by double clicking it. Here you have a view and open the database tables.

The Access database contains the Assets database that has data for all assets managed by our company. There are two tables most interesting for us: Assets and Components. These two tables have 1-n relation: one Asset has one or more Components.

You can open the tables by right click on the tabel and select: Openen: image.png

##Test (automation) status per Component The are some fields with respect to testing that can be filled to give overview about the test status. Example are: APITestToBe, APITestActual, UITestToBe etc. These fields have dropdown lists for the status, like None, Manual, Manual/Automated etc. We can fill these fields with the current status. If we like we are also free to extent the list of the dropdown by updateing the 'TestLevels' table with a new status.

⚠️ **GitHub.com Fallback** ⚠️