What are test scenarios based on?

Question

Project management

Good afternoon!
The essence of the question - on the basis of what are test scenarios compiled?
I understand that in essence according to the specification, but the implementation may include many details that may be implicitly described in the specification or not described at all.
At the previous place of work, the testing department was combined with the analytics department - they immediately prepared an analysis according to the technical requirements and covered it with test scenarios. Now there is no such luxury - a whole department for these needs, but there is a need to test ready-made applications.
What is the best way to organize the process of writing test scenarios? Who should approve them? Project Manager?
The company is small, there are different projects - mobile/desktop applications.
Tell me what to read on the topic :)
Thank you!

Answer 1

I believe that test scripts are written according to the TOR if the goal is acceptance testing. If the goal is Quality Assurance, then test scenarios are written based on the experience of the test engineer himself, and he, in turn, builds on his personal preferences and best practices in the market or segment. For example, the TOR may not describe validation errors for POST requests, and a good QA can come up with them himself already at the level of cases, while throwing work to developers but also increasing the quality of the product in the end. Here I see these two ways. Acceptance and Quality Assurance.

Answer 2

The answer to this question depends on the responsibility of the software. In general, scenarios are written based on requirements. Not abstract slogans that are usually written in the TOR, but requirements with unambiguous technical characteristics. If the project is responsible, requiring certification (transport software, for example), this issue is regulated by the relevant standards, according to which certification is carried out. In particular for civil aviation, there is a document DO-178 (Russian translation - KT-178 and a less demanding analogue of GOST-51904), which determines, for example, that based on the requirements for the system, top-level requirements for software are developed (in parallel - for hardware), on the basis of which the design and requirements of the lower level are created, on the basis of which the code, and testers write top-level tests according to the requirements of the upper level (checking the functionality of the entire application) and lower-level tests according to the requirements of the lower level (unit tests). It turns out the implementation and independent verification on the basis of common initial data for the programmer and the tester. And here you do not need to rely on the experience and sophistication of the tester, he simply achieves the goal according to explicit criteria, this is transparent and manageable. But it is very expensive and time consuming.
In your case, of course, development processes will be much simpler, but here you must understand that strengthening the verification process will inevitably require costs. Miracles do not happen, as well as testers who, without documentation, are covered like gods. Here, more formalization is clearly required, which means at least one more level of detail after the TK. How much to detail - depends on how much you are willing to spend on it. The percentage of removing bugs will be appropriate.