Among the most well-known tests then the unit tests that test each class of the system individually, the integration tests testing two distinct parts of the system, such as a DAO, and the database. But what about the system test? What is it, how is it done and what is its purpose?
Is it even testing the system's view?
The system test aims to test the system completely. It is common to call this test black box, because the system is tested with everything connected: batch jobs, database, web services, etc. This test tests the system completely.
In practice they run under conditions similar to those that the user will use. This test checks if the components are compatible, if they interact correctly, if they transfer the right data at the right time, etc.
To answer your question "Is it even testing the system's interface?", see this #, it shows a summary of the tests:
Aswecansee,theanswertoyourquestionisYes.Itisatthisstagethatthesysteminterfaceistested.
Therearealsoacceptancetestsandregressiontests.Theacceptancetestisintendedtoverifycompliancewithbusinessanduserrequirementsinthelaststageofthedevelopmentcycle,validatingtheproductfordelivery.Theyareusuallyperformedbyarestrictedgroupofsystemendusers.Theregressiontestisappliedwhenlaunchinganewversionofthesoftwareorwhenthereisaneedtorunanewtestcycleduringthedevelopmentprocess.Itisnotconsideredatestlevel,butitisanimportantstrategyforreducingsideeffects.
Referencesandrelatedlinks:
In practice I see that the test should be done for any test that becomes expensive to do manually.
No test will be as up-to-date as a person-made test, so I see that in practice, you should create tests for code stability and scalability, ensuring that the solution is mature and has not impacted new implementations.
Testing without the deployed solution is ripe most of the time causes the test to be rewritten.
Thinking this way, it does not matter if the test is by UI (screen-by-screen) or by code, but whether it is honorable to do manually or if it is already a use case (solution) mature enough to make it viable the writing of the test, at that moment.Finally, in practice, you should balance the effort to implement the automated test (and its changes) with the manual test effort.
My opinion is that yes, it is testing the system interface, making sure that all the resources available to users are working before putting the system into production. But beyond that, the timing of the project and the context in which it applies may require a battery of regression tests, for example, which involves testing each feature and ensuring that client-specific rules are working as expected. Testing whether a button is working, whether the system is responsive or running across multiple browsers may not seem as important as other tests to those with technical knowledge, or participate in the project, however to system end users or by whom paid for it can add a very large value, so it is necessary to test the interface of a system, just like so many others.
