ISQT Process & Consulting Services Pvt. Ltd., Bangalore, INDIA
ISQT's SOFTWARE TESTING WORLD
Definitive and Authoritative Knowledge . .
We TRAIN and ADVISE YOU to Excel in SOFTWARE TESTING
 
About Us   |   Our Clients   |   Contact Us   |   Our Partners
Follow Us: Facebook Twitter LinkedIn Email Us
 
  Home
 
 
  Dated: 26th April 2012
  Software Testing Objective towards Fulfilling Requirements (PART I)
  Author: Arunkumar Khannur | email: khannur@isqtinternational.com
   
 
Addressing Objective 1: “To provide information on how well the software is fulfilling its requirements so as to build the confidence that the software is working as required and is ready for release”
   
  This objective revolves around “requirements”. We need to understand the meaning of requirements as applicable in the context of software. We also need to list out the aspects that we shall cover while testing.
  ‘Requirements’ means mandatory aspects that shall be addressed when we undertake any work. These requirements when are defined, documented, reviewed, and approved statements then are referred to as ‘specifications’. Thus, ‘requirements specification’ means defined, documented, reviewed, and approved statements on expectations among stake-holders and more specifically between development organization and client. In other words, they are approved and agreed upon terms of reference between development organization and client. As such, it is a formal document which becomes the basis for business and technical aspects in the project. However most of the errors in software have origin in requirements.
  While doing testing, we focus on following:
  • While doing testing, we focus on following:
  • Addressing errors in requirements specification itself
  • Using requirements as the basis, deriving all activities related to software testing which include planning, designing, executing test cases so as to provide information on how well agreed requirements are realised in the form of a software.
Following sections will discuss on these points in length.
  Addressing Errors in Requirements Specification Itself
  Requirements expressed by client and user are captured by requirements study team and then they are segregated, documented, reviewed, and approved so as to formalise into a requirements specification. Each requirement appearing in the specification has many features that need to be implemented in the project to produce software. Following sections provide some insight into:
  • Requirements And Specification Related Bugs
  • Features Related Bugs
  • Feature Interaction Related Bugs

  Following section will detail on each one of them.

Requirements and Specification related Bugs
The bugs in requirements are a contributing cause to the failure of many projects. Ambiguous, unclear or incomplete requirements are serious problems but they are not the sole source of requirements bugs. Even when there are no bugs like ambiguous, unclear or incomplete requirements, we may expect new type of bugs because of changing features are new change requests.
No we shall understand each of these bugs.
 
  • Bugs Of Conception
  • Bugs Of Specification
  • Bugs Of Implementation
  No we shall understand each of these bugs.
  Bugs of Conception
  Requirements specifications is a "representational" perceptual model that is built based on inner "ideas", "impressions' or "sense data" of an observer (requirements study team member) and his inferences. As such what is real and what is represented always differ. We can see that there will be differences between what is expressed and what is represented. If we find a way to directly establish a link between the observer's inner world and external object, we can have better representation of requirements. However, major hurdle to achieve this is unreliability of our perceptions.
  Bugs of Specification
  Bugs in specification may appear in requirements because of high level, formal specification languages to specify requirements like -declarative (or traditional) approaches, scenario-based approaches, model-based approaches, prototyping-based approaches, testing-based approaches, or backlog-based approaches. Each one of these types of bugs has separate symptoms and causes, and each must be solved in a different way.
  Bugs of Implementation
  While implementing software, we move from problem specification to conceptual/logical specification to system implementation to system integration and release. This approach is basically is a problem solving approach using deductive logic by using a principle of stepwise refinement with the help of software development life cycle (SDLC). While doing so Bugs of Implementation may occur in each phase in the form of logical errors, documentation errors, missing documentation, translation errors, violation of standards, interface errors, cosmetic errors, etc.
  Feature Bugs
  Each requirement is made up of many features. Whenever there are specification related bugs, corresponding to that there will be feature related bugs. Corresponding to bugs related to requirement specification, there will be feature related bugs like wrong feature, missing feature, or extra feature. In case of missing feature, it is relatively easy to identify and also, to include the feature to address. In case of wrong feature, based on the phase where we detect that the particular feature is wrongly implemented, the implications may be deep. In order to address wrong features, one needs to change all earlier documents till that phase where wrong feature is detected and also, may include changes in design and code. As such these are very costly and cause delay in project completion. Extra features may have long reaching implications. When we provide extra features, many a times they may affect performance, maintainability, reliability, efficiency etc. Also, since development organization spends effort, time, and money in providing these extra features, there will negative impact on return on investment. Thus, providing extra features is also may not be acceptable.
  Feature Interaction Bugs
  Required functionality in software is because of interaction of many features. Each feature is not independent but interdependent. Though many a times feature specification is clear, correct, unambiguous, implementable, traceable, and testable the system may not be showing required functionality. The possible reasons may be because of incorrect interaction among features that are grouped together or because of incorrect interaction between feature in a particular group with another feature in the other group or because of incorrect interaction between features in a particular application with feature in some other external application. Such feature interaction related bugs are hard to detect and difficult to correct. However, as software systems are increasingly using computers, connectivity, content, and communication and also, ever increasing heterogeneity of platforms the possibility of interaction bugs is ever increasing. Thus as days pass by there is an increasing demand to come-out with appropriate test strategy and test cases to detect and address these bugs.
 
  Specification and Feature Bug Remedies
  Software development is a team effort by involving many stake holders with different roles and responsibility. While developing software, there is a continuous communication among these roles. However in majority of cases such communication is not effective.
Less than one-third of companies are well-equipped to do a good job on business and software requirements. Also, most organizations are not well set up to be successful in getting business requirements. Right-over 50% of them do not have even basic pieces in place to be successful at business and software requirements and 70% of organizations do not have the fundamental competencies within business requirements discovery to consistently bring in projects on time and on budget. This would result in requirements bugs.
Other than building competencies, there is a continuous look-out for high-level, formal specification languages. However such specification languages or approaches may provide short term solution but long term solution is still evading.
Short-term Support: High level, formal specification languages to specify requirements like -declarative (or traditional) approaches, scenario-based approaches, model-based approaches, prototyping-based approaches, testing-based approaches, or backlog-based approaches facilitate formalization of requirements. Using these languages, requirements become clear, complete, unambiguous, and testable. These approaches are found to be effective in short term and also, are very cost-effective.
Long-term Support: Specification languages though seems to be effective in short-term, they have major in-built limitations. These limitations have origin in lack of fundamental competencies that leave far reaching impact. This would cause types of bugs like bugs of conception, bugs of specification, bugs of implementation that may appear as tougher residual specification bugs that are difficult to detect and eliminate. Each one of these types of bugs has separate symptoms and causes, and each must be solved in a different way.
  Testing Techniques
  Requirements, Features, and Functionality Bugs can be detected by using functional testing techniques, namely, transaction flow testing, syntax testing, domain testing, logic testing, and state testing. Also, formal technical reviews which are part of static testing are capable of finding bugs in requirements and also, traceability related issues.
 
Previous Articles
Date: 23rd April, 2011
Primary and Secondary Qualities
 
ISQT Process & Consulting Services Private Limited 732, 1st Floor, 12th Main, 3rd Block, Rajajinagar, Bangalore - 560 010, INDIA
Phone:+ 91- 80 - 23012501-15 | Fax: + 91 80 23142425