The life cycle begins when an application is first conceived and ends when it is no longer in use. It includes aspects such as initial concept, requirements analysis, functional design, internal design, documentation planning, test planning, coding, document preparation, integration, testing, maintenance, updates, retesting, phase-out, and other aspects.
Poor requirements - if requirements are unclear, incomplete, too general, or not testable, there will be problems.
Unrealistic schedule - if too much work is crammed in too little time, problems are inevitable.
Inadequate testing - no one will know whether or not the program is any good until the customer complains or systems crash.
Featuritis - requests to pile on new features after development is underway; extremely common.
- Miscommunication - if developers don't know what's needed or customer's have erroneous expectations, problems are guaranteed.
Solid requirements - clear, complete, detailed, cohesive, attainable, testable requirements that are agreed to by all players. Use prototypes to help nail down requirements.
Realistic schedules - allow adequate time for planning, design, testing, bug fixing, re-testing, changes, and documentation; personnel should be able to complete the project without burning out.
Adequate testing - start testing early on, re-test after fixes or changes, plan for adequate time for testing and bug-fixing.
Stick to initial requirements as much as possible - be prepared to defend against changes and additions once development has begun, and be prepared to explain consequences. If changes are necessary, they should be adequately reflected in related schedule changes. If possible, use rapid prototyping during the design phase so that customers can see what to expect. This will provide them a higher comfort level with their requirements decisions and minimize changes later on.
- Communication - require walkthroughs and inspections when appropriate; make extensive use of group communication tools - e-mail, groupware, networked bug-tracking tools and change management tools, intranet capabilities, etc.; insure that documentation is available and up-to-date - preferably electronic, not paper; promote teamwork and cooperation; use protoypes early on so that customers' expectations are clarified.
Throughout the entire lifecycle, neither development nor verification is s straight line activity. Modifications or corrections to a structure at one phase will require modifications or re-verification of structures produced during previous phases.
SOFTWARE QUALITY AND COST ASPECT
STABLE PROCESS OF SOFTWARE TESTING
STABLE PROCESS OF SOFTWARE TESTING PART TWO
DEFECTS IN SOFTWARE TESTING
REDUCTION OF DEFECTS IN SOFTWARE TESTING
SOFTWARE TESTING AND EFFECTING FACTORS
SCOPE OF SOFTWARE TESTING
TESTING LIFE CYCLE PART ONE
TESTING LIFE CYCLE PART TWO
TESTING LIFE CYCLE PART THREE
SOFTWARE TESTING AND CONSTRAINTS WITH IN IT
TESTING CONSTRAINTS PART TWO
LIFE CYCLE TESTING
Independent Software Testing
Testing verification and validation
Functional and structural testing
Static and dynamic testing
V model testing
Eleven steps of V model testing
Execution testing technique
Recovery Testing technique
Operation testing technique
Compliance software testing technique
Security testing technique