Software Development Life Cycle

Software Development Life Cycle

Software development approach and has a value proposition that includes faster turnaround times, trained pool of engineers with decent exposure to processes and best practices followed for the entire SDLC.

We have exposure on the following SDLC models :

• Waterfall
• V-Shaped
• Structured Evolutionary Prototyping Model
• Incremental
• Spiral
• Agile

A brief description of the various models mentioned above is given below. Along with the description, we have mentioned the strengths and discussed when a particular model is suited to you:

 

Identifying sqa issues

Software Quality Assurance is a good practice that every large scale business should employ. IT related businesses have never hesitated to use SQA to ensure that the application they will release for their users or sell to their customers will live up to their expectations.

Sponsored Links

On the other hand, there are companies that has opted to forgo with the usage of SQA and relied on application testers just to make sure the application will never have internal errors. The SDLC on the other hand, will ensure the development of the application will work as planned.

Like other development plans, there are issues why developers and companies do not use SQA.

 

IEEE SOFTWARE TEST DOCUMENTATION Std 829-1998 – TEST PLAN

Purpose
To describe the scope, approach, resources, and schedule of the testing activities. To identify the items being tested, the features to be tested, the testing tasks to be performed, the personnel responsible for each task, and the risks associated with this plan.

 

Software Testing Levels, Types, Terms and Definitions

Testing Levels and Types
There are basically three levels of testing i.e. Unit Testing, Integration Testing and System Testing. Various types of testing come under these levels.

Unit Testing:
To verify a single program or a section of a single program

Integration Testing:
To verify interaction between system components
Prerequisite: unit testing completed on all components that compose a system

System Testing:
To verify and validate behaviors of the entire system against the original system objectives
Software testing is a process that identifies the correctness, completeness, and quality of
software.

 

Most common software errors

Following are the most common software errors that aid you in software testing. This helps you
to identify errors systematically and increases the efficiency and productivity of software testing.
Types of errors with examples
• User Interface Errors: Missing/Wrong Functions, Doesn’t do what the user expects, Missing
information, Misleading, Confusing information, Wrong content in Help text, Inappropriate error
messages. Performance issues – Poor responsiveness, Can’t redirect output, Inappropriate use of
key board
• Error Handling: Inadequate – protection against corrupted data, tests of user input, version
control; Ignores – overflow, data comparison, Error recovery – aborting errors, recovery from
hardware problems.
• Boundary related errors: Boundaries in loop, space, time, memory, mishandling of cases
outside boundary.
• Calculation errors: Bad Logic, Bad Arithmetic, Outdated constants, Calculation errors,
Incorrect conversion from one data representation to another, Wrong formula, Incorrect
approximation.

 

Verification and Validation

 Verification and Validation.

• Testing is part of verification and validation.
• Verification: Are we building the product right?
• Validation Are we building the right product?
• V&V activities include a wide range of the SQA activities.

 

Some Important terminologies

Some Important terminologies

• Project :  If something is developed based on a particular user/users requirements, and is used exclusively by them, then it is known as project. The finance is arranged by the client to complete the project successfully.
• Product :  If something is developed based on company’s specification (after a general survey of the market requirements) and can be used by multiple set of masses, then it is known as a product. The company has to fund the entire development and usually expect to break even after a successful market launch.
• Defect v/s Defective: If the product is justifying partial requirements of a particular customer but is usable functionally, then we say that The product has a defect, But If the product is functionally non usable , then even if some requirements are satisfied, the product still will be tagged as Defective.
• Quality Assurance : Quality assurance is a process of monitoring and guiding each and every role in the organization in order to make them perform their tasks according to the company’s process guidelines.
  

 

Definitions of Black-box and White-box Testing

Black-box: This testing methodology looks at what are the

available inputs for an application and what the expected outputs are that should result from each input. It is not
concerned with the inner workings of the application, the process that the application undertakes to achieve a
particular output or any other internal aspect of the application that may be involved in the transformation of an
input into an output. Most black-box testing tools employ either coordinate based interaction with the applications graphical user interface (GUI) or image recognition. An example of a black-box system would be a search engine.You enter text that you want to search for in the search bar, press “Search” and results are returned to you. In such a case, you do not know or see the specific process that is being employed to obtain your search results, you simply see that you provide an input – a search term – and you receive an output – your search results.

 

Evaluating exit criteria and reporting

Evaluating exit criteria is the activity where test execution is assessed against the defined objectives. This should be done for each test level, as for each we need to know whether we have done enough testing. Based on our risk assessment, we’ll have set criteria against which we’ll measure ‘enough’. These criteria vary for each project and are known as exit criteria. They tell us whether we can declare a given testing activity or level complete. We may have a mix of coverage or completion criteria (which tell us about test cases that must be included, e.g. ‘the driving test must include an emergency stop’ or ‘the software test must include a response measurement’), acceptance criteria (which tell us how we know whether the software has passed or failed overall, e.g. ‘only pass the driver if they have completed the emergency stop correctly’ or ‘only pass the software for release if it meets the priority 1 requirements list’) and process exit criteria (which tell us whether we have completed all the tasks we need to do, e.g. ‘the examiner/tester has not finished until they have written and filed the end of test report’). Exit criteria should be set and evaluated for each test level. Evaluating exit criteria has the following major tasks:

 

Test Strategy Template

These are the most common sections:

1.Objectives
State the objectives of this document at a high-level.

2.Scope
State the scope of the testing strategy, what will the testing concentrate around, at high-level; leave details for the Testing Scope.

3.Test Deliverables
State the testing activities and what documents result from these activities; for example a testing activity is Test Planning and the document resulting is the Master Test Plan or Test Plan.

4.Testing Schedule
Give the timelines around which the project is planned and where testing fits in this schedule.
I find that a diagram has a high-impact on the user (a Georgia rule of thumb is that I use color and diagrams to break the boredom of the text).
Describe the diagram in words.

5.Test Scope
The Project Charter or Master Test Plan usually state all the items in scope, just copy and paste from these documents. Add anything that’s missing or has changed from the last review.
Then state any items that are Out of Scope.

6.Risk Analysis
State all the risk that you envision, the higher the risk – the higher the test priority.
When you start testing you will want to start with the high-priority items, then test medium-priority and if time permits test low-priority functionality.Risk Analysis is very important from this point of view because it drives the whole test strategy. When giving the risk state how to you plan to mitigate (to alleviate, to make less severe) and what is the contingency plan (back-up plan in case this happens).Additionally you may want to say what is the impact of each risk.