• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 364
  • Last Modified:

Developing new system

Hi guys: Can any one please explain testing strategies or detailed plan during the analysis of new project development? Also is it ok to use live or simulated data?

  • 2
  • 2
1 Solution
btanExec ConsultantCommented:
depends on the nature of the system as the prime driver is the objective for the test which broadly covers functional, system component, security, user acceptance, and final integration aspects. It can be a run (or walk) through as well as detailed test plan checklist as either means there must be signed off by the customer and the provider. That is in general idea for testing.

Specifically, I tend to see different strategies may be adopted depending on the type of system to be tested and the development process used. The testing strategies are

1. Top-down testing
Where testing starts with the most abstract component and works downwards.

2. Bottom-up testing
Where testing starts with the fundamental components and works upwards.

3. Thread testing
Which is used for systems with multiple processes where the processing of a transaction threads its way through these processes.

4. Stress testing
Which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations.

5. Back-to-back testing
Which is used when versions of a system are available. The systems are tested together and their outputs are compared.

6. Performance testing.
This is used to test the run-time performance of software.

7. Security testing.
This attempts to verify that protection mechanisms built into system will protect it from improper penetration.

8. Recovery testing.
This forces software to fail in a variety ways and verifies that recovery is properly performed.

Large systems are usually tested using a mixture of these strategies rather than any single approach. Different strategies may be needed for different parts of the system and at different stages in the testing process.

Whatever testing strategy is adopted, it is always sensible to adopt an incremental approach to sub-system and system testing. Rather than integrate all components into a system and then start testing, the system should be tested incrementally. Each increment should be tested before the next increment is added to the system. This process should continue until all modules have been incorporated into the system.

When a module is introduced at some stage in this process, tests, which were previously unsuccessful, may now, detect defects. These defects are probably due to interactions with the new module. The source of the problem is localized to some extent, thus simplifying defect location and repair.

Do also factor QA process such that minimally covers
1. Enforcement of Standards (Customer imposed standards or management imposed standards)
2. Control of Change (Assess the need for change, document the change)
3. Measurement (Software Metrics to measure the quality, quantifiable)
4. Records Keeping and Recording (Documentation, reviewed, change control etc. i.e. benefits of docs).

On the part of test data, really depends on
1. static testing (no execution needed, proper assurance of codes void of backdoor/trapdoors etc)
2. dynamic testing (execution needed, interactive testing to sieve out actual response against expected or known flaws pertaining to such platform etc)
3. whitebox (details is shared and sort of "open book", scrutinise anymore lacking or missing areas)
4. blackbox (third party view, external party to have "blind" test" to single out low hanging fruits, where are the potential penetration points or hidden cracks)

Eventually really depends if there are any constraint and ideally all should be performed in staging segregated from production. It will be simulated as closely where possible but dependency such as eService is hard to simulated hence no matter how much you test, the final verdict is still at the production site with all actual service interactions.

Be realistic on the scope of testing :)
Go for small wins and chart the "SMART" milestone goals
mustish1Author Commented:
ok thanks. Can you also please tell me the most important security issues normall y face companies now a days. Is there any changes made security wise since last 5 years? In case if there will be a security issue how should comapnies prepare themselves for the problems in future?
btanExec ConsultantCommented:
Scope creep as the question is the security an afterthought or has already been embedded at the very requirement design phase. If it is not, prepare that the testing will be wide and open - know the critical asset and below are principle we can check within porject team

- Implement security controls when and where they make sense and provide real value
- Aim to reduce complexity of your network environment when implementing new solutions, not increase them
- Solicit help from third party network architects to obtain an outsider’s view on where your organization’s blind spots may be

Nothing changes much in security (threats always evolved, just look at the raise of APT, critical infra been exploited, OWASP 2013, cyber intelligence - from compliance (checklist) to detection (control based) to prevention (risk/process based) to analytical (value based).

Have the security clause template embedded into the tender or requirement, engage the security SME team very early, know the business is the driver and security is the supporting vertical - strike a consensus to balance cost effective outcome, lastly Always TRUST but VERIFY...(test scope). Regular pentest (and not just vulnerability test) will help to profile the security posture of the new system before commission and thereafter regular checks (just like "human" doing health check regularly)....Establish network with security community to get intelligence on new evolution of tech as well as the gaps ...

NIST has a nice paper for security testing
e.g. Technical Guide to Information Security Testing and Assessment (NIST Special Publication 800-115)

also another document from NIST also covers measuring security in an organization. The Guide for Assessing the Security Controls in Federal Information Systems, Special Publication 800-534, is much more high-level than SP 800-115, however it still gives some useful and important tips for planning security assessments.
mustish1Author Commented:
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get Certified for a Job in Cybersecurity

Want an exciting career in an emerging field? Earn your MS in Cybersecurity and get certified in ethical hacking or computer forensic investigation. WGU’s MSCSIA degree program was designed to meet the most recent U.S. Department of Homeland Security (DHS) and NSA guidelines.  

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now