This free survey is powered by
  1. Surveys
  2. 2015
  3. May
  4. D
  5. Defect Managemnt in Agile
0%
Exit Survey
 
 
The world of software development has evolved with agile practices that aim to build and ship good quality software frequently with improved functionality every time. The agile philosophy advocates removal of defects at the point of discovery. As the industry has spent practising agile for more than a decade, this is the time to understand the defects/issues/problems faced by the agile development teams, their perception about the causes of those issues and the information used by them for managing those issues. The present research study needs the responses from the agile practitioners to the questions related to the same.

It is an academic work aims to add knowledge to the discipline of agile software development and so, you candid and honest answers will be invaluable contribution.
 
 
 
Name:
   
 
 
Age in Years:
   
 
 
 
Years of Experience in Software Development:
   
 
 
Years of Experience in Agile Based Software Development:
   
 
 
Frequently Played Role in Agile Teams:
   
 
 
Please complete the following statements by choosing the right frequency of occurrence of certain problem you face.

The frequency of occurrence of the problem/defect/issue can be identified by underlining one of the following criteria given below:
Always (occurs in every iteration – 100%, i.e., in 10 of 10 iterations)
Frequently (occurs in 50 to 100% iterations, i.e., in 5 to 9 of 10 iterations) Sometimes (occurs in less than 50% of iterations, i.e., less than 5 of 10 iterations) Never (does not occur in any iteration) I don’t know/remember
I don’t know/remember
Always Frequently Sometimes Never Don't Know
Poor/incomplete coverage of code and functionality in unit testing
Poor/incomplete coverage of code and functionality integration testing
Poor/incomplete coverage of code and functionality load and stress testing
Poor/incomplete coverage of code and functionality Regression Testing
Poor/incomplete coverage of code and functionality System Testing
Lack of technical compatibility with previous release (like import/export of files)
Incomplete information in new version of release document (like addition, enhancement or removal of product features with respect to the old version)
Incorrect/irrelevant/incomplete error messages in trace log
Dependency on third party components and drivers affecting connectivity and compatibility adversely
Insufficient impact analysis of enhancement
Always Frequently Sometimes Never Don't Know
Insufficient library documentation
Incorrect assignment to variables including initialization
Exceptional deviation from desired functionality
Unclear Objectives of project
Requirements and their dependencies are unclear to the team
Frequent changes in architecture and design
Poor management of technical debt
Poor management of code growth
Unclear definition of done for the story, sprint or release
Lack of connect between requirements and testing
Always Frequently Sometimes Never Don't Know
Lack of customer communication/involvement/presence
Quick/hasty submission of poor quality code
Less importance given to good quality coding
Lack of interactions between the developers and testers
Poor quality process and culture of programming
Incongruent and ineffective tools of testing
High dependence on other teams that have different priorities
Lack of common language/standards in tagging the issues/defects/problems
 
 
 
Please add some more adverse experiences related to defects, which have been different from the ones stated above:
   
 
 
What types/pieces of information is used by you in managing defect effectively?

The frequency of use of the specific piece of information can be identified by     Always (used in every iteration – 100%, i.e., in 10 of 10 iterations)
Frequently (used in 50 to 100% iterations, i.e., in 5 to 9 of 10 iterations)
Sometimes (used in less than 50% of iterations, i.e., less than 5 of 10 iterations) Never (is not used in any iteration)
I don’t know/remember
Always Frequently Sometimes Never Don't Know
Types of defects like assignment, interface and algorithm
Attributes of defects like severity, priority and missing/incorrect
The activity while doing which the defect has been discovered
The sub-activity/trigger that brought the trigger to surface(like side effects, specific test case and concurrency)
The phase responsible for inserting a defect
The role responsible for inserting a defect
The time taken in closing defects
Rate at which different types of defects are closed
Rate at which different types of defects are discovered
Rate at which test points/cases are covered
Sources of defects like internal components, releases, build, third party or outsourced components
Fix release schedule
Analysis of impact of Fix Release Schedule on Customer
 
 
 
Please mention any other piece of information that you use or think, could be used for effective management of defects:
   
 
Share This Survey:          Surveys Powered by  QuestionPro Survey Software