How are Discussions Associated with Bug Reworking? An Empirical Study on Open Source Projects

Aug 29, 2018Download as pptx, pdf0 likes58 views

1) Initial bug fix discussions with more comments and more developers participating are more likely to experience later bug reworking through re-opening or re-patching of the bug. 2) Manual analysis found that defective initial fixes and failure to reach consensus in discussions contributed to later reworking. 3) For re-opened bugs, initial discussions focused on addressing a particular problem through a burst of comments, while re-patched bugs lacked thorough code review and testing during the initial fix period.

How Are Discussions Associated with Bug
Reworking? An Empirical Study on Open
Source Projects
Feng
Zhang
Ying Zou Ahmed
E.Hassan
Emad
Shihab
Yu Zhao

Bug Reworking
2
Bug fixing Bug reworking
Incomplet
e
Bug Re-
opening
Bug Re-
patching

Motivating Example
3
“All in all, I am not convinced that
these shortcuts been discussed enough
and this issue should not be closed”
“Reopening. Unfortunately, the
current implementation isn’t quite
right”
During the bug fixing, developers discuss like this
Does the discussion impact bug
reworking?

Dataset
4
Project LOC # Fixed
Linux 17.6M 8,410
Firefox 7.0M 27,759
PDE 472K 8,510
Ant 136K 2704
HTTP 510K 2,333

Research Questions
• RQ1: (Quantitative) How do the
initial-fix discussions impact the
likelihood of experiencing bug
reworking?
• RQ2: (Qualitative) Do initial-fix
discussions raise different topics in
the reworked bug fixes as compared
to the bug fixes without reworking?
5

Our Approach
6
Extract
Bug
Reports
RQ1
RQ2
Bugzilla
Histories of
Bug Report
s
Bug Report
s
Compute
Metrics
Extract
Topics

Computing Discussion Metrics
and Topics
7

Discussion Metrics
• Duration
• Number of Comments
• Dispersion
• Frequency
• Number of Developers
• Experience
8

RQ1:How do the initial-fix discussions
impact the likelihood of experiencing
bug reworking?
9
Control
Group
Bug Report
Use Fisher’s
Exact Test to
Evaluate the
Hypothesis
Experiment
al Group
the proportion of reworked bug fixes in the
experimental group and the control group has no
difference.

RQ1: Results
10
Initial-fix discussions with more
comments, more developers are more
likely to experience bug re-opening and
re-patching.
0
0.5
1
1.5
2
OddsRatio
Bug Re-opening
0
0.5
1
1.5
2
2.5
Duration #
Comments
Dispersion #
Developer
OddsRatio
Bug Re-patching

RQ1: Manual Analysis Results
11
Initial-fix discussions with more
comments, more developers are more
likely to experience bug re-opening and
re-patching.
0
0.5
1
1.5
2
OddsRatio
Bug Re-opening
0
0.5
1
1.5
2
2.5
Duration #
Comments
Dispersion #
Developer
OddsRatio
Bug Re-patching
a)Defective Fixes: Approaches are
not fully discussed
b)Incorrect Categorization of
Duplicated Bugs.

RQ1: Manual Analysis Results
12
Initial-fix discussions with more
comments, more developers are more
likely to experience bug re-opening and
re-patching.
0
0.5
1
1.5
2
OddsRatio
Bug Re-opening
0
0.5
1
1.5
2
2.5
Duration #
Comments
Dispersion #
Developer
OddsRatio
Bug Re-patching

RQ1: Manual Analysis Results
13
Initial-fix discussions with more
comments, more developers are more
likely to experience bug re-opening and
re-patching.
0
0.5
1
1.5
2
OddsRatio
Bug Re-opening
0
0.5
1
1.5
2
2.5
Duration #
Comments
Dispersion #
Developer
OddsRatio
Bug Re-patching
Did not reach a consens

RQ1: Manual Analysis Results
14
Initial-fix discussions with more
comments, more developers are more
likely to experience bug re-opening and
re-patching.
0
0.5
1
1.5
2
OddsRatio
Bug Re-opening
0
0.5
1
1.5
2
2.5
Duration #
Comments
Dispersion #
Developer
OddsRatio
Bug Re-patching
a)Burst of Discussion: Address a
particular problem
b)Throughout the initial-fix period: lack
of code review and testing

RQ2: Do initial-fix discussions raise different
topics in the reworked bug fixes as compared
to the bug fixes without reworking?
15
There is no difference in the distribution of topics
between bugs that are never reworked and ones that
are reworked.
Apply LDA to
Extract Topics
Perform
Wilcoxon
Rank-Sum
Test
Bug
Reports
Reworked
Never
Reworked

RQ2: Results
16
Bug Re-opening
Bug Re-patching
Topic
Code Inspection <
Customization Settings >
Patch Creation <
Topic
Content
Misunderstanding
>
Solution Implementation >
Code Testing <
Among all the
extracted topics,
there are several
topics showing a
consistent
association with
bug re-opening
and bug re-
patching.

Continuous testing tools like Auto-test and InfiniTest can help developers write better code faster by running tests automatically after each code change. A study found developers using continuous testing were three times more likely to complete programming tasks by the deadline and most participants believed it helped them work more efficiently. InfiniTest is recommended for use within IDEs like Eclipse due to its ability to provide test results within the same environment, while Auto-test may be better for non-IDE users.

TDD: Facts and FallaciesStephen Rylander

TddAlexander Zaidel

The document discusses Test Driven Development (TDD). TDD is a software development process where test cases are written before implementation code to specify requirements, with code only written to pass newly created tests. The TDD cycle involves writing a test, running the test which fails with no code, writing minimum code to pass the test, running all tests which should now pass, and refactoring code before repeating. Examples like calculating prime number sums and FizzBuzz are provided. Benefits of TDD include improved code quality, reduced bugs, and faster development through continuous testing and feedback. Best practices include pair programming, test planning, and using testing frameworks.

Test driven development(tdd)Omar Youssef Shiha

Test Driven Development (TDD) is a software testing methodology where developers write automated test cases before writing any code. It involves writing a failing test case for new functionality, then writing the minimum amount of code to pass that test, and refactoring the code. Key steps are to add a test, run all tests and see the new one fail, write code to pass the test, run tests to succeed, and refactor code while maintaining tests. Benefits include instant feedback, better code quality, and lower rework effort. Limitations include difficulty testing certain types of code like GUIs. Unit testing tests individual units of code in isolation through mocking of external dependencies.

Test driven development vs Behavior driven developmentGallop Solutions

TDD - Test Driven DevelopmentLim Chanmann

This document provides an overview of test-driven development (TDD), including why it is important, perspectives on TDD, how to implement TDD, and recommended TDD tools. TDD involves writing tests before code to ensure requirements are met and drive the development process through repeated short cycles. Tests should be small, focused, repeatable, and independent to avoid side effects and keep code clean and working. Implementing TDD helps focus on required behaviors, improves quality, provides documentation, and allows for more confident changes and early defect identification.

Tdd com JavaRafael Miceli

TDD CrashCourse Part2: TDDDavid Rodenas

TddCristina Carstea

This document discusses test driven development (TDD). It begins by explaining the basic TDD process of writing a failing test, getting it to compile, making it pass without changing existing code, and then refactoring. It outlines some benefits of TDD like improved code quality and confidence in changes. It also notes some challenges like additional overhead and keeping test code clean. Overall, it argues that while TDD requires proper implementation, it can help produce higher quality code with fewer bugs.

Tdd practicesaxykim00

This document discusses test-driven development (TDD) practices. It covers the characteristics of good tests, what TDD is and why it is used, the TDD development cycle of red-green-refactor, best practices for TDD, anti-patterns to avoid, and practices for writing testable code. The key aspects of TDD outlined are writing tests before code, running tests after each small code change, and refactoring code between test cycles.

TDD with RSpecRachid Calazans

This document provides an overview of test driven development (TDD) and the RSpec testing framework in Ruby. It defines TDD as a software development process that was created in the 1990s to practice test-first design. RSpec is introduced as a popular testing framework for Ruby that supports behavior driven development (BDD). The basics of RSpec are explained, including the describe, context, and it methods for organizing tests and defining examples. Hooks and expectations are also summarized.

Test-Driven Developmentadrianmitev

Test-driven development (TDD) is a software development process that relies on the repetition of a short development cycle of requirements, design, and coding. It promotes writing tests before writing code (test-first design) and helps improve code quality by reducing defects. The TDD cycle involves writing an automated test, running the test and seeing it fail, writing the minimum amount of code to pass the test, and refactoring the code as needed. TDD brings benefits like clarifying requirements, adding executable documentation, and detecting errors early. Acceptance TDD involves automating acceptance tests to define and validate requirements. It helps establish a definition of done and improves team collaboration.

TDD refresherKerry Buckley

The document discusses test-driven development (TDD) and provides guidance on how to implement TDD. It outlines the progression from manual testing to automated testing to test-first development. The benefits of TDD include less manual testing, faster feedback, safer code changes, and improved design. Good tests express intent, isolate areas under test, and provide clear failures. When starting TDD, automate tests for important features and bug-prone areas first, and use TDD for new features.

Test driven development - Zombie proof your codePascal Larocque

This document discusses test driven development and how to write testable code. It recommends writing tests before writing code to prevent "zombie code" that is hard to maintain and change. Specific tips provided include using dependency injection, following SOLID principles to separate concerns, and writing fast, isolated tests using tools like PHPUnit and PHPSpec. Continuous integration is also recommended to prevent technical debt from accumulating.

PVS-Studio confesses its love for LinuxPVS-Studio

Test driven development_continuous_integrationhaochenglee

This document discusses test-driven development (TDD) and continuous integration (CI). It explains that TDD involves writing tests before code to drive the design. The key steps of TDD are design, test, implement, and test again. CI involves integrating code changes frequently, usually daily, to catch errors early. TDD and CI work well together as the tests from TDD can be run automatically through CI to provide rapid feedback. The document provides an overview of how to implement TDD and CI using tools like Jenkins.

Test driven development and react js application go hand in handKaty Slemon

Test-driven development (TDD) is an important approach for React application development. TDD involves writing tests before writing code to ensure features are well-specified and code works as intended. Some key benefits of TDD for React include high test coverage, exceptional code quality, reduced costs from fewer bugs, and convenient debugging. Popular tools for TDD with React are Jest for tests, Enzyme for mounting components, and Cypress for end-to-end testing. Developers should follow best practices like single responsibility components and maximizing code reuse. Overall, TDD helps produce robust, maintainable React applications.

Tddmahmoud ramadan

TDD is a software development process that relies on writing test cases before code to validate requirements and ensure code works as intended. The TDD cycle involves writing a failing test case, then code to pass the test, and refactoring the code. TDD results in cleaner, higher quality code that is easier to maintain and modify through automated regression testing and producing more modular code. Junit is a testing framework for writing unit tests in Java, and mocking is used to isolate dependencies.

DockerCon US 2016 - Scaling Open Source operationsArnaud Porterie

This document discusses scaling open source operations at Docker. It covers three main areas: the people involved in open source projects including users, contributors and maintainers; the processes for code reviews, design decisions, and managing documentation; and the tooling for measuring activity and automating processes. Maintainers play a key role in reviewing contributions and improving infrastructure. Culture is important for a healthy community. Processes aim to balance contributor experience and code quality. Metrics and automation tools like webhooks help scale projects.

Test driven development in meteorMichael Lazarski

This document discusses test-driven development (TDD) and its benefits. It recommends using TDD to check that software functions as required, allow for quick code changes, and help understand code design. TDD helps determine when to stop coding, can document what code should do, and leads to decreased costs and faster time to market. The document provides examples of TDD frameworks for Meteor projects and outlines a sample rock-paper-scissors API requirement and test.

Agile testing overviewraianup

This document discusses testing approaches in Agile development. It notes that Agile methods require discipline and sustainable practices. Agile teams value continuous testing to ensure continuous progress, with testing seen as a way of life rather than a phase. Shortening feedback loops through automated testing allows teams to detect problems quickly. The document emphasizes that testing moves the project forward by providing ongoing feedback, rather than acting as a gatekeeper. It also highlights practices like keeping code clean, using lightweight documentation, and considering work "done" only after it is implemented and tested.

Agile and test driven developmentAhmed El-Deeb

The document provides an overview of agile and test-driven development. It begins by comparing waterfall and agile approaches, noting that agile uses short iterative cycles. It then defines agile as iterative and incremental, with continual revisiting of requirements and design. Common agile methodologies like Scrum and extreme programming are discussed. Test-driven development is introduced as writing tests before code to ensure requirements are met and prevent bugs. The benefits of agile and TDD for developers are more code proven to meet requirements and less time spent debugging.

Test Driven DevelopmentSoftware Infrastructure

Test Driven Development (TDD) is a technique where tests are written before code to validate functionality. It promotes writing small testable units through the "red-green-refactor" process of writing a failing test, passing code, and refactoring. Popular unit testing frameworks for .NET like MSTest, NUnit, and xUnit allow automating tests that are fast, independent, repeatable, self-validating, and timely. Mocking frameworks like Moq and FakeItEasy generate stubs and fakes to isolate dependencies during testing. TDD helps reduce bugs and technical debt when refactoring legacy codebases lacking tests.

Automatically Generated Patches as Debugging Aids: A Human Study (FSE 2014)Sung Kim

The document reports on a human study that investigated the usefulness of automatically generated patches as debugging aids. The study found that high-quality patches significantly improved debugging correctness, with 71% of patches being correct, while low-quality patches slightly undermined correctness. High-quality patches were also more useful for difficult bugs. The type of debugging aid did not affect debugging time. Participants considered high-quality patches much more helpful than low-quality patches. The study suggests that automatically generated patches can be useful debugging aids if they are of sufficient quality.

Cje demonoyenmaih

This document provides information about exam dumps for the Certified Jenkins Engineer (CJE) exam, including 129 questions and answers with explanations, access to future updates for 3 months, and a money-back guarantee if the exam is failed. It includes sample questions covering topics like Jenkins build executors, version control software (SCM), branching strategies, and notification integrations. The full exam dumps are available for purchase from the listed website.

Test Driven Development (TDD) & Continuous Integration (CI)Fatkul Amri

Continuous integrationBoris Dominic

Continuous integration (CI) aims to improve software quality and reduce delivery time by implementing continuous quality control processes like running automated unit, integration, and acceptance tests. CI helps teams be more efficient by quickly identifying issues and getting feedback. Key principles of CI include having a single code repository, automating builds and testing, publishing the latest build daily, and getting builds into production to enable fast feedback. Automating builds is important to ensure consistency across environments and allow issues to be identified and addressed early during development rather than in production.

Bug best practicegaoliang641

The document provides guidance on best practices for bug filing and management. It discusses how to write high-quality bug reports that are reproducible by developers. It emphasizes the importance of thoroughly documenting steps to reproduce issues and providing all relevant information. The document also covers defect tracking metrics and how they can be used to assess testing progress and product quality.

Characterizing and predicting which bugs get fixedThomas Zimmermann

This document discusses factors that affect whether software bugs get fixed. It analyzes bug report data from Microsoft and surveys Microsoft employees. The analysis found that bugs with one reassignment are more likely to be fixed, but too many reassignments decrease likelihood. Bugs opened by people with high reputations and handled within single teams and locations are more likely to be fixed. The survey revealed social factors like seniority, reputation, relationships, and trust also impact the bug fixing process.

More Related Content

What's hot (20)

TDD CrashCourse Part2: TDDDavid Rodenas

TddCristina Carstea

Tdd practicesaxykim00

TDD with RSpecRachid Calazans

Test-Driven Developmentadrianmitev

TDD refresherKerry Buckley

Test driven development - Zombie proof your codePascal Larocque

PVS-Studio confesses its love for LinuxPVS-Studio

Test driven development_continuous_integrationhaochenglee

Test driven development and react js application go hand in handKaty Slemon

Tddmahmoud ramadan

DockerCon US 2016 - Scaling Open Source operationsArnaud Porterie

Test driven development in meteorMichael Lazarski

Agile testing overviewraianup

Agile and test driven developmentAhmed El-Deeb

Test Driven DevelopmentSoftware Infrastructure

Automatically Generated Patches as Debugging Aids: A Human Study (FSE 2014)Sung Kim

Cje demonoyenmaih

Test Driven Development (TDD) & Continuous Integration (CI)Fatkul Amri

Continuous integrationBoris Dominic

TDD CrashCourse Part2: TDDDavid Rodenas

TddCristina Carstea

Tdd practicesaxykim00

TDD with RSpecRachid Calazans

Test-Driven Developmentadrianmitev

TDD refresherKerry Buckley

Test driven development - Zombie proof your codePascal Larocque

PVS-Studio confesses its love for LinuxPVS-Studio

Test driven development_continuous_integrationhaochenglee

Test driven development and react js application go hand in handKaty Slemon

Tddmahmoud ramadan

DockerCon US 2016 - Scaling Open Source operationsArnaud Porterie

Test driven development in meteorMichael Lazarski

Agile testing overviewraianup

Agile and test driven developmentAhmed El-Deeb

Test Driven DevelopmentSoftware Infrastructure

Automatically Generated Patches as Debugging Aids: A Human Study (FSE 2014)Sung Kim

Cje demonoyenmaih

Test Driven Development (TDD) & Continuous Integration (CI)Fatkul Amri

Continuous integrationBoris Dominic

Similar to How are Discussions Associated with Bug Reworking? An Empirical Study on Open Source Projects (11)

Bug best practicegaoliang641

Characterizing and predicting which bugs get fixedThomas Zimmermann

Characterizing and Predicting Which Bugs Get ReopenedThomas Zimmermann

This document summarizes a study characterizing and predicting which software bugs get reopened. Through a qualitative survey, researchers identified six main causes of bug reopens: bugs being difficult to reproduce, misunderstood root causes, insufficient bug information, increased bug priority later on, regression bugs, and process-related issues. A quantitative analysis using logistic regression found that bugs found through code analysis tools or human review were less likely to reopen, while bugs found through system or customer testing were more likely to reopen. The analysis also found that bugs opened by people with higher reputations based on past bugs were less likely to reopen.

Software bug prediction Muthukumaran Kasinathan

The document presents a software bug prediction model. It aims to build a resilient bug prediction model through simulation on open source issue trackers like Jira and Bugzilla. It also aims to conduct a comparative study of the new model against existing competitive models. The model will make use of data from software repositories, bug reports, and code artifacts to predict bugs. Open source projects like Eclipse, Mozilla and Android will be used for simulations. Data mining tools like WEKA and RAPID MINER will be utilized extensively. The model also aims to facilitate code refactoring to improve software maintenance activities like modification and enhancement. Literature in the areas of bug prediction and code refactoring will be surveyed. The research will be conducted in

Patterns for Cleaning Up Bug DataRodrigo Rocha

Predicting Faults from Cached HistorySung Kim

bug-advocacyKALYAN Chakravarthy

The document discusses techniques for software testers to advocate for bugs they have found to get them prioritized and fixed. It recommends testers think of bug reports as tools to convince programmers to spend time fixing issues. Effective bug reports motivate programmers by highlighting impact and addressing objections. Testers should research failure conditions thoroughly by varying their own behavior, program options/settings, and software/hardware environments to prove bugs are more serious or widespread than initially found. The goal is to provide compelling arguments to prioritize and fix bugs.

Xen Project Contributor Training - Part 1 introduction v1.0The Linux Foundation

The document discusses factors that impact the effectiveness of code contributions to open source projects. It identifies tensions that can arise between contributors wanting quick approval of their code and reviewers having other considerations around code quality and maintainability. It recommends good planning, preparation, communication and following community workflows and conventions to help contributions be reviewed efficiently with minimal iterations.

Empircal Studies of Performance Bugs & Performance Analysis Approaches for La...SAIL_QU

This document summarizes three empirical studies on software performance bugs: 1. A quantitative study found performance bugs have different characteristics than other bugs, such as taking longer to fix, but findings were not consistent across projects. 2. A qualitative study of bug reports found performance bugs have a higher impact, more context in reports, and require more collaborative fixing. 3. A user-centric performance analysis study found examining performance from users' perspectives provided a complementary view to traditional scenario-centric analyses. Considering individual users revealed different performance trends and consistency than aggregate analyses.

Open Bugs & Development StagesNicolò Paternoster

This document summarizes an empirical study on software measurement that investigated whether there are more issues reported in the early stage or late stage of a software project's lifecycle. The study analyzed 11 open source projects and found that in the early stage, the number of new bugs is significantly greater than in the late stage. Additionally, while the increment of new issues over time interacts differently for each project, it generally does not significantly impact the difference between early and late stages. This implies that software reliability increases as projects mature and more effort should be focused on debugging in the early stages of development.

The Bug Backlog - An Evergrowing MountainJohan Hoberg

If you are part of a development team working on a game, and you are working in some kind of Agile way, you most likely have a bug backlog, or at least bugs as part of some kind of backlog. The bug backlog looks very different during different stages of the game development cycle - it starts out empty, and then as features and complexity is added, it grows. And in most cases it never stops growing.

Bug best practicegaoliang641

Characterizing and predicting which bugs get fixedThomas Zimmermann

Characterizing and Predicting Which Bugs Get ReopenedThomas Zimmermann

Software bug prediction Muthukumaran Kasinathan

Patterns for Cleaning Up Bug DataRodrigo Rocha

Predicting Faults from Cached HistorySung Kim

bug-advocacyKALYAN Chakravarthy

Xen Project Contributor Training - Part 1 introduction v1.0The Linux Foundation

Empircal Studies of Performance Bugs & Performance Analysis Approaches for La...SAIL_QU

Open Bugs & Development StagesNicolò Paternoster

The Bug Backlog - An Evergrowing MountainJohan Hoberg

More from SAIL_QU (20)

Studying the Integration Practices and the Evolution of Ad Libraries in the G...SAIL_QU

In-app advertisements have become a major revenue for app developers in the mobile app economy. Ad libraries play an integral part in this ecosystem as app developers integrate these libraries into their apps to display ads. However, little is known about how app developers integrate these libraries with their apps and how these libraries have evolved over time. In this thesis, we study the ad library integration practices and the evolution of such libraries. To understand the integration practices of ad libraries, we manually study apps and derive a set of rules to automatically identify four strategies for integrating multiple ad libraries. We observe that integrating multiple ad libraries commonly occurs in apps with a large number of downloads and ones in categories with a high percentage of apps that display ads. We also observe that app developers prefer to manage their own integrations instead of using off the shelf features of ad libraries for integrating multiple ad libraries. To study the evolution of ad libraries, we conduct a longitudinal study of the 8 most popular ad libraries. In particular, we look at their evolution in terms of size, the main drivers for releasing a new ad library version, and their architecture. We observe that ad libraries are continuously evolving with a median release interval of 34 days. Some ad libraries have grown exponentially in size (e.g., Facebook Audience Network ad library), while other libraries have worked to reduce their size. To study the main drivers for releasing an ad library version, we manually study the release notes of the eight studied ad libraries. We observe that ad library developers continuously update their ad libraries to support a wider range of Android versions (i.e., to ensure that more devices can use the libraries without errors). Finally, we derive a reference architecture for ad libraries and study how the studied ad libraries diverged from this architecture during our study period. Our findings can assist ad library developers to understand the challenges for developing ad libraries and the desired features of these libraries.

Studying the Dialogue Between Users and Developers of Free Apps in the Google...SAIL_QU

Improving the testing efficiency of selenium-based load testsSAIL_QU

Slides for a paper published at AST 2019: Shahnaz M. Shariff, Heng Li, Cor-Paul Bezemer, Ahmed E. Hassan, Thanh H. D. Nguyen, and Parminder Flora. 2019. Improving the testing efficiency of selenium-based load tests. In Proceedings of the 14th International Workshop on Automation of Software Test (AST '19). IEEE Press, Piscataway, NJ, USA, 14-20. DOI: https://doi.org/10.1109/AST.2019.00008

Studying User-Developer Interactions Through the Distribution and Reviewing M...SAIL_QU

This document discusses studying user-developer interactions through the distribution and reviewing mechanisms of the Google Play Store. It analyzes emergency updates made by developers to fix issues, the dialogue between users and developers through reviews and responses, and how the reviewing mechanism can help identify good and bad updates. The study found that responding to reviews is six times more likely to increase an app's rating, with 84% of rating increases going to four or five stars. Three common patterns of developer responses were identified: responding to negative or long reviews, only negative reviews, and reviews shortly after an update.

Studying online distribution platforms for games through the mining of data f...SAIL_QU

Our studies of Steam platform data provided insights into online game distribution: 1) Urgent game updates were used to fix crashes, balance issues, and functionality; frequent updaters released more 0-day patches. 2) The Early Access model attracted indie developers and increased game participation; reviews were more positive during Early Access. 3) Game reviews were typically short and in English; sales increased review volume more than new updates; negative reviews came after longer play.

Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...SAIL_QU

This study analyzed factors that impact the speed of questions receiving accepted answers on four popular Stack Exchange websites: Stack Overflow, Mathematics, Ask Ubuntu, and Super User. The researchers examined question, answerer, asker, and answer factors from over 150,000 questions. They built classification models and found that key factors for fast answers included the past speed of answerers, length of the question, and past speed of answers for the question's tags. The models achieved AUCs of 0.85-0.95. Fast answers relied heavily on answerers, especially frequent answerers. The study suggests improving incentives for non-frequent and more difficult questions to attract diverse answerers.

Investigating the Challenges in Selenium Usage and Improving the Testing Effi...SAIL_QU

Selenium is a popular tool for browser-based automation testing. The author analyzes challenges in using Selenium by mining Selenium questions on Stack Overflow. Programming language-related questions, especially for Java and Python, are most common and growing fastest. Less than half of questions receive accepted answers, and questions about browsers and components take longest. In the second part, the author develops an approach to improve efficiency of Selenium-based load testing by sharing browsers among user instances. This increases the number of error-free users by 20-22% while reducing memory usage.

Mining Development Knowledge to Understand and Support Software Logging Pract...SAIL_QU

This document summarizes Heng Li's PhD thesis on mining development knowledge to understand and support software logging practices. It discusses how logging code is used to record runtime information but can be difficult for developers to maintain. The thesis aims to understand current logging practices and develop tools by mining change history, source code, issue reports, and other development knowledge. It presents research that analyzes logging-related issues to identify developers' logging concerns, uses code topics and structure to predict where logging statements should be added, leverages code changes to suggest when logging code needs updating, and applies machine learning models to recommend appropriate log levels.

Which Log Level Should Developers Choose For a New Logging Statement?SAIL_QU

The document discusses choosing an appropriate log level when adding a new logging statement. It finds that an ordinal regression model can effectively model log levels, achieving an AUC of 0.76-0.81 in within-project evaluation and 0.71-0.8 in cross-project evaluation. The most influential factors for determining log levels vary between projects and include metrics related to the logging statement, containing code block, and file as well as code change and historical change metrics.

Towards Just-in-Time Suggestions for Log ChangesSAIL_QU

The document presents a study on providing just-in-time suggestions for log changes when developers make code changes. The researchers analyzed over 32,000 log changes from 4 systems. They found 20 reasons for log changes that fall into 4 categories: block changes, log improvements, dependence-driven changes, and logging issues. A random forest classifier using 25 software metrics related to code changes, history, and complexity achieved 0.84-0.91 AUC in predicting whether a log change is needed. Change metrics and product metrics were the most influential factors. The study aims to help developers make better logging decisions for failure diagnosis.

The Impact of Task Granularity on Co-evolution AnalysesSAIL_QU

The document discusses how task granularity at different levels (e.g. commits, pull requests, work items) can impact analyses of co-evolution in software projects. It finds that analyzing at the commit-level can overlook relationships between tasks that span multiple commits. Work item level analysis is recommended to provide a more complete view of co-evolution, as median of 29% of work items consist of multiple commits, and analyzing at the commit level would miss 24% of co-changed files and inability to group 83% of related commits.

A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...SAIL_QU

A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...SAIL_QU

This study examined the relationship between mobile device attributes and user-perceived quality of Android apps. The researchers analyzed 150,373 star ratings from Google Play across 30 devices and 280 apps. They found that the perceived quality of apps varies across devices, and having better characteristics of an attribute does not necessarily correlate with higher quality. Device OS version, resolution, and CPU showed significant relationships with ratings, as did some app attributes like lines of code and number of inputs. However, some device attributes had stronger relationships than app attributes.

A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...SAIL_QU

This document presents the results of a large-scale study on the impact of feature selection techniques on defect classification models. The study used expanded scopes including multiple datasets from NASA and PROMISE with different feature types, more classification techniques from different paradigms, and additional feature selection techniques. The results show that correlation-based feature subset selection techniques like FS1 and FS2 consistently appear in the top ranks across most of the datasets, projects within the datasets, and classification techniques. The document concludes that future defect classification studies should consider applying correlation-based feature selection techniques.

Studying the Dialogue Between Users and Developers of Free Apps in the Google...SAIL_QU

The study analyzes user-developer interactions through reviews and responses on the Google Play Store. It finds that responding to reviews has a significant positive impact, with 84% of rating increases due to the developer addressing the issue or providing guidance. Three common response patterns were identified: only negative reviews, negative or longer reviews, and reviews shortly after an update. Developers most often thank the user, ask for details, provide guidance, or ask for an endorsement. Guidance responses can address common issues through FAQs. The analysis considered over 2,000 apps, 355,000 review changes, 128,000 responses, and 4 million reviews.

What Do Programmers Know about Software Energy Consumption?SAIL_QU

This document summarizes the results of a survey of 122 programmers about their knowledge of software energy consumption. The survey found that programmers have limited awareness of energy consumption and how to reduce it. They were unaware of the main causes of high energy usage. Programmers lacked knowledge about how to properly rank the energy consumption of different hardware components and were unfamiliar with strategies to improve efficiency, such as minimizing I/O and avoiding polling. The study concludes that programmers would benefit from more education on software energy usage and its causes.

Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...SAIL_QU

Revisiting the Experimental Design Choices for Approaches for the Automated R...SAIL_QU

Prior research on automated duplicate issue report retrieval focused on improving performance metrics like recall rate. The author revisits experimental design choices from four perspectives: needed effort, data changes, data filtration, and evaluation process. The thesis contributions are: 1) Showing the importance of considering needed effort in performance measurement. 2) Proposing a "realistic evaluation" approach and analyzing prior findings with it. 3) Developing a genetic algorithm to filter old issue reports and improve performance. 4) Highlighting the impact of "just-in-time" features on evaluation. The findings help better understand benefits and limitations of prior work in this area.

Measuring Program Comprehension: A Large-Scale Field Study with ProfessionalsSAIL_QU

The document summarizes a large-scale field study that tracked the program comprehension activities of 78 professional developers over 3,148 hours. The study found that: 1) Program comprehension accounted for approximately 58% of developers' time on average, with navigation and editing making up the remaining portions. 2) Developers frequently used web browsers and document editors to aid comprehension beyond just IDEs. 3) Interviews and observations revealed that insufficient documentation, unclear code, and complex inheritance hierarchies contributed to long comprehension sessions.

On the Unreliability of Bug Severity DataSAIL_QU

- Machine learning models are negatively impacted by noisy or inconsistent labels in training data. This is a challenge for tasks like bug severity classification where labels can be subjective. - A new evaluation metric called Krippendorff's alpha is proposed to measure agreement between labels while accounting for inconsistencies. It is shown to better reflect performance than accuracy when labels are inconsistent. - Making "big data thick" by improving quality is an important future direction, but challenging at scale. Lightweight methods are needed to reduce noise without extensive manual labelling. Performance measures also need to account for noise inherent in some real-world problems.