There is a dependency relationship between RefApp release Vs Implementing and running these tests. Implementing and running these tests ideally mean that the specific functionality they are testing are safe to be used by the end system users before the next version is released for our implementers. For-example in the Vitals and Triaging test workflow one of the user stories validates user input when the entered value of the vital is above the maximum value use case: the system should not save temperature above 43 Celsius and should alert to the data entry clerk until he/she records a value that is within the range (25-43) Celsius.
On the other hand having these tests running in master is a means of maintaining our 2.x RefApp in the long run putting in mind that the future product which we are eyeing at as a community is 3.x RefApp. Since we will have two versions being used concurrently (we won’t get rid of 2.x RefApp based on what I grasped from our recent virtual conference) so these automated tests will help us provide maintenance support for 2.x RefApp version. And perhaps some implementers may opt to remain using 2.x while others will choose 3.x version so we need to cater for ALL!
Not really!
However, based on the test implementation it asserts(confirms) that the entered data is truly saved in the vitals table. And if so then the test passes otherwise it should fail the run.
BTW it would be nice to have the vital results show up and this functionality(button) is provided by the system to end user where he/she just clicks on the button and the vitals are displayed(some where besides the vitals table), however since this is a test running behind the seen the assertion mechanism have mentioned above is good enough for the test since the test will fail the run when the vitals are not saved in the system.
Ideally the major goal of this particular test is not vital results showing up but to confirm ;
-
when normal vitals are entered, the system should be able to save them into the vitals table, and as well
-
validate that if a user enters a vital value which is below or above the acceptable range of that given vital, then the system should not save such data but rather display an alert to the user to comply until the entered value is within the acceptable range of that given vital in context.
Well, both are very good ideas! @sharif may as well have more ideas too though I think we need to think about this as QA team to see how far we can go along with it.
@dkayiwa’s comment here about feature files is a good start for us as we think through the idea on how best we can handle it with reference to business-level people!