SOFTWARE TESTING.docx (Size: 684.96 KB / Downloads: 22)
Software Engineering is an engineering discipline, which is concerned with all aspects of software production from the early stages of system specification through to maintaining the system after it has gone into use. In this definition, there are two key phrases:
1. ‘Engineering discipline’ Engineer makes things work. They apply theories, methods and tools where these are appropriate but they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods to support them. Engineers also recognize that they must work to organizational and financial constraints, so they look for solutions within these constraints.
2. ‘All aspects of software production’ Software Engineering is not just concerned with the technical processes of Software development but also with activities such as software project management and with the development of tools, methods and theories to support software production.
DIFFERENCE BETWEEN SOFTWARE ENGINEERING & COMPUTER SCIENCE:-
Essentially, computer science is concerned with the theories and methods, which underline computers and software systems where as software engineering is concerned with the practical problems of producing software. Some knowledge of computer science is essential for software engineers in the same way that some knowledge of physics is essential for electrical engineers.
Ideally, all of software engineering should be under pinned by theories of computer science but in reality this not the case. Software Engineers must often use ad hoc approaches to develop the software. Elegant theories of computer science cannot always be applied to real, complex problems, which require a software solution.
WHAT IS SOFTWARE TESTING?
Software testing is a process of verifying and validating that a software application or program. Software testing
1. Meets the business and technical requirements that guided its design and development, and
2. Works as expected.
Software testing also identifies important defects, flaws, or errors in the application code that must be fixed. The modifier “important” in the previous sentence is, well, important because defects must be categorized by severity.
During test planning we decide what an important defect is by reviewing the requirements and design documents with an eye towards answering the question “Important to whom?” Generally speaking, an important defect is one that from the customer’s perspective affects the usability or functionality of the application. Using colors for a traffic lighting scheme in a desktop dashboard may be a no-brainer during requirements definition and easily implemented during development but in fact may not be entirely workable if during testing we discover that the primary business sponsor is color blind. Suddenly, it becomes an important defect. (About 8% of men and .4% of women have some form of color blindness.)
WHAT DO WE TEST?
First, test what’s important. Focus on the core functionality—the parts that are critical or popular—before looking at the ‘nice to have’ features. Concentrate on the application’s capabilities in common usage situations before going on to unlikely situations. For example, if the application retrieves data and performance is important, test reasonable queries with a normal load on the server before going on to unlikely ones at peak usage times. It’s worth saying again: focus on what’s important. Good business requirements will tell you what’s important.
The value of software testing is that it goes far beyond testing the underlying code. It also examines the functional behavior of the application. Behavior is a function of the code, but it doesn’t always follow that if the behavior is “bad” then the code is bad. It’s entirely possible that the code is solid but the requirements were inaccurately or incompletely collected and communicated. It’s entirely possible that the application can be doing exactly what we’re telling it to do but we’re not telling it to do the right thing.
A comprehensive testing regime examines all components associated with the application. Even more, testing provides an opportunity to validate and verify things like the assumptions that went into the requirements, the appropriateness of the systems that the application is to run on, and the manuals and documentation that accompany the application. More likely though, unless your organization does true “software engineering” (think of Lockheed- Martin, IBM, or SAS Institute) the focus will be on the functionality and reliability of application itself.