TL;DR
Classifying testing or security as non-functional requirements may or may not be appropriate for your project. Regardless, all work related to a project's expected outcomes can and should be decomposed into estimable work items that are either "done" or "not done" when evaluating progress or deliverables.
How to Manage Outcome-Based Delivery for Testing, Security, and Other Activities
Even if they are classified as "non-functional" requirements because they are not product features in the way that many product or project managers typically think about these things from a development-focused perspective, they are still work and should be tracked accordingly. All of the things you mentioned should have measurable PKIs and OKRs, or at the very least desired outcomes for each activity. If they don't, then you're either not involving the correct subject matter experts in planning, or your project is doing things that were not (and perhaps still are not) appropriately defined at the strategic or tactical levels for the project.
For example:
- For "performance testing" to be successful, what components will be measured, how will the measurements be evaluated, and what is the minimum level of performance that must be met?
- If "anomaly testing" is performed, what methodologies will be used and how many anomalies (or classifications of anomalies) will determine of the overall result is satisfactory or not?
- If "security testing" is performed, what are the standards or other baselines that need to be met to report success?
If these things are gating criteria for the project, then they should be part of the "Definition of Done" and tracked as work items. If they aren't, then this would appear to be some sort of post facto scope creep. In the former case, these items should have been part of your project initiation and planning; in the latter case, the work items should be treated as new requirements within whatever change control processes have been established for the project.
Involve Subject Matter Experts
In either case, you clearly need to involve subject matter experts (SMEs) for the activities that are not accurately reflected in the current plan. The SMEs should ideally be the people who will actually be doing the work, or you risk a mismatch between abstract estimates and the knowledge and skill sets of the actual task performers. The SMEs can help:
- define the work required to meet each outcome or objective,
- identify how the work will be tracked and measured, and
- estimate the level of effort or time it would likely take to perform each activity within a clearly-defined set of assumptions.
In other words, these things should be planned, estimated, scheduled, and tracked the same way you would track any other project-related requirements. The only difference is that it seems like the project currently lacks the required expertise within the team as presently constituted. That means you'll either need to add those people and skills to the team, or leverage outside resources to help the project fill any gaps.