What is a regression test library? What are the main entities and components of an RTL? How is it created during the testing process? Does testing of small scaled projects also require a regression test library?
...but I still haven't found what I'm looking for.
A set of tests - automated or manual, or both, that are applied as needed to the intended application(s) and/or system(s)-under-test.
"As-needed" can be determined by release of new versions with new functionality, making sure what used to work - still does. Or fixes to defects will trigger a round of regression testing.
Main entities are scripts with a focus on functional testing of logical pieces/parts of the app or system-under-test. The script may be modeled in many ways to prove that it functions as intended. Workflow modeling may have been employed to prove that the system or app will allow the user to perform the intended work through the happy paths and/or not-so-happy paths.
Other entities may be:
1) common tests that are callable by others - such as login, logout, parameterized tests that can be multi-purpose, and so on.
2) Documentation of your tests.
How is it created? The answer to this can be lengthy. I'll stick with the basis and that is by posing a question or two.
What documents, specifications, use-cases or other sources tell you how it is to behave? It is from these sources that you set out to prove compliance with those sources. The act of proving requires the development of tests. These tests can probably live for many versions of the app-under-test, albeit with maintenance. It is these tests that become regression tests. These you deploy as needed.
What is small-scale to you? Your questions would seem to indicate that it probably requires a regression test suite.
A regression test library is often synonymous with a regression test repository. In other words, a centralized location where you store your tests and information associated with those tests.
In a sophisticated shop, this may consist of automated libraries with links to test data and other documentation (such as plans, business requirements, reports). In other shops, it may be as simple as a shared file containing word documents. Having an RTL is not based on size or sophistication. It's more of an ease of use and organization issue. It's just easier to access stuff stored in one central location.
This is generally my "formal, large" project repository setup:
Test Requirements (linked to business requirements)
Test Cases (linked to test requirements)
Test Scripts (automated, linked to test cases)
Test Documents (Strategy, Plan, Schedule, etc.)
Test Data (usually links to other files)
If you are working on a small project, you may only have a small subset of these.