Remember that all models are wrong; the practical question is how wrong do they have to be to not be useful.
The most that can be expected from any model is that it can supply a useful approximation to reality: All models are wrong; some models are useful
With that well known disclaimer, here's presenting a hopefully useful model for addressing your software development project's quality assurance needs.
It starts at the root Test and Quality Assurance Documentation entity which is an aggregation of the following 3 top level header entities of
- Planning - Test Strategy and Test Management Plan
- Doing - Test Cases
- Reporting - Test Reports
The main goal of the model is to help kick start the thought process for a software project's new quality assurance development via software testing. The model identifies many entities in the software testing domain and draws relationships between them.
This approximate model could perhaps be further extended for your specific project's needs for quality assurance and software testing.
Your inputs are welcome!
Feel there are more core basic entities that can be added to this model?
Any extension entities or new relationships between entities?
Please, write in the comments section below.
 |
| A Model for Quality Assurance via Software Testing |
Very verbose & lucid model which perfectly depicts paradigms of testing. Just one suggestion can this model also depict the how part of Test Execution wherein "Automation" of test cases can be an entity & may be different tools linked to it, so that the model also cover automation as one dimension
ReplyDeleteThought over CI /CD linked with test automation & how it can be portrayed in the present model can be also given.
Thanks for the feedback!
DeleteDefinitely, I will add the extension entities you mention add to the upgraded version of the model.
Another key feedback I got on another channel from a friend Ajay Dass (https://www.linkedin.com/in/ajaydass/) was that testing must satisfy the perceivable quality of the target users of the software. Therefore the key is to know what your end user perceives as high quality and test according to that.
His feedback summary was that - test strategy, planning and test cases must strongly tie back to requirements and specifications of customer and this strong association is missing in the version of this model on 29.0.1.2019.
In some way, or rather a round about way, his thought was captured in the part where the defects are mentioned, the defects have a severity and priority that are associated with the same for the requirement it is also with.
But I agree with him that this is more an `after the fact association` between requirements and the QA strategy, need to think of an earlier association with requirements since during the testing process the test team can have defects that are not exactly a requirement. Solving these defects need to be de-prioritized.
So basing on this and other feedback I will get over the next days, I will continue to upgrade this to a next version.
I meant an earlier point in the diagram to depict the association between the QA Strategy and the Requirements.
Delete