Testing Requirements Aug 29, 2024

Подробнее о видео

Testing Requirements E34 2024 08 29
A Bit of Security for August 29, 2024
Philip Crosby wrote that quality is conformance to requirements. Testing (software testing is in my background) is simply validating that the product meets its stated goals.
The software development process consists of stepwise refinement from a business requirement to a body of code. The subsequent integration of code into modules, applications, and full business processes mirrors that stepwise refinement, which gives us a “V” shaped pattern from business requirements on the top left, down to code at the bottom, and then up the other leg with unit test, function/component, test system test, and so on. The content of the test phase consists of scripts and inputs that demonstrate the product reflects the intent of the corresponding step on the way down. So the final test is, does the product accurately reflect the original requirement and specification?
This simple process isn’t merely waterfall, although waterfall was built around that model. And, although some mischaracterize it a rigid and inflexible, there was always plenty of feedback from one step to the prior step. Architects took feedback from Designers, and Designers from Developers, and everyone was involved in the code walkthrough – which started long before any code was created.
This model V not only has direction, but it incorporates feedback. The results of a test demonstrate that the refinement was correct, and the product performs as intended every step of the way.
Testing depends on adequate requirements. The process of writing code occupies only a small fraction of the total development time. Typically, the ratio is 8::4::1::2 between high level design, low level design, code, and unit test. That means over a 15-month cycle, the first year is all pre-code. Any organization that insists one-third of the code be done at the 5-month mark guarantees two things: first, the project will be at least six months late, and second, the bugs will be much harder to detect and correct that otherwise.
When an organization ships code with an obvious defect it usually means that the development team leadership consciously decided to shorten the cycle – skipping design reviews, or omitting test activities, in favor of meeting an arbitrary schedule. If you want to know how well the test went, start by asking how clear are the product requirements? What problem is the business trying to solve? Understanding these fundamentals points both forward to the code development process and back to the rigor and thoroughness of the business strategy. The cost of development should be recouped through the revenue that the new product generates. Revenue projections and market sizings are inputs to the development process, and should be include in the discussion to build the product in-house or use a third party solution. The business case can be tested, too. One final note – the product requirements include both functional requirements: what it’s supposed to do – and non-functional requirements: how it behaves in its environment. How fast is it? How easy to debug? How easy to tune? And most importantly, how well does it preserve privacy, trustworthiness, and security?
Testing Requirements
A Bit of Security for August 29, 2024
How do you test software? It’s easy – you see if the code does what the requirements say. Listen to this -
Let me know what you think in the comments below or at wjmalik@noc.social
#cybersecuritytips #softwaretest #codequality #SDLC #QA #BitofSec