Dormant bug v2
•Download as PPTX, PDF•
0 likes•375 views
This document presents an empirical study of dormant bugs. The study analyzed over 20 open-source systems to understand dormant bugs. The key findings are: 1) Approximately 29% of bugs are dormant bugs that remain undetected for long periods. 2) Dormant bugs are fixed faster (median of 5 days) and with larger fixes (median of 19 lines of code) than non-dormant bugs. 3) Developers who fix dormant bugs tend to be more experienced than those who fix non-dormant bugs.
Report
Share
Report
Share
Recommended
Sonybmg Rootkit
The SonyBMG rootkit was a program installed on Sony music CDs that was intended to prevent copying but ended up opening security holes that allowed viruses to infect computers more easily. It affected around 500,000 networks and took 3 months for Sony to release a removal tool. The rootkit altered the way Windows operating systems read CDs and allowed easier virus infections by opening security holes, though its creator intended it only as anti-copying software. To remove the rootkit, the Sony utility would need to be used.
Msr2011 zaman
This document summarizes a study comparing how security bugs, performance bugs, and other bugs are handled in the Firefox browser. The study found that:
1) Security bugs are triaged and fixed faster than other types of bugs.
2) Security bug fixes are performed by more experienced developers and tend to be more complex, involving changes to more files.
3) Security bugs are tossed (reassigned) and reopened more often during the fixing process than other bugs.
Qsic2010 shihab
This document describes a study that evaluates different heuristics for prioritizing which functions in a legacy system should have unit tests written for them first under a test-driven maintenance (TDM) approach. The study used historical modification and bug fix data from a legacy system to simulate writing unit tests over time according to various heuristics like "most frequently modified", "largest fixed", and "change risk". The results showed that heuristics focused on modification frequency and past fixes performed best in terms of usefulness of the unit tests and optimal test coverage within resource constraints.
Icsme14danieletal 150722141344-lva1-app6891
The study analyzed delays in integrating addressed issues into software releases. It found that 34-60% of addressed issues in traditional release cycles were delayed, while 98% were delayed in rapid release cycles. The study built prediction models using random forests to predict integration delays. Integration workload was the most influential variable in the models. The models performed better than random guessing with precisions of 0.59-0.88 and ROC areas above 0.74.
Wcre2010 shihab
This study examined attributes of bug reports in the Eclipse project to predict which bugs would be re-opened. The researchers found that comment text, description text, and component were the best indicators. Using these and other attributes, their prediction model achieved 63% precision and 85% recall in identifying re-opened bugs. Month, time to resolve, and fixer/reporter names were also important attributes. The researchers concluded that comments are important for predicting re-opened bugs and that bug reports contained the most useful attributes.
Detecting Occurrences of Refactoring with Heuristic Search
This document describes a technique for detecting refactorings between two versions of a program using heuristic search. Refactorings are detected by generating intermediate program states through applying refactorings, and finding a path from the original to modified program that minimizes differences. Structural differences are used to identify likely refactorings. Candidate refactorings are evaluated and applied to generate new states, with the search terminating when the state matches the modified program. A supporting tool was developed and a case study found the technique could correctly detect an actual series of refactorings between program versions.
Leveraging performance counters and execution logs to diagnose memory related...
This document discusses an approach to diagnosing memory-related performance issues in systems by leveraging performance counters and execution logs. The approach involves:
1) Generating signatures each time memory is sampled from counters and combining them with abstracted events from logs.
2) Counting the events and calculating memory usage to identify outliers.
3) Inspecting the outliers to diagnose issues like memory bloat, leaks or spikes.
The results showed the approach could flag problematic events with over 99.98% precision and reduce diagnostic effort by over 99.98%, helping experts efficiently analyze memory performance problems.
Why You Should Be Fixing Bugs
The document discusses fixing bugs in software. It lists 4 bugs that have been fixed or are currently being worked on. It provides reasons for fixing bugs such as working on real software used by millions, impressing others, and learning valuable skills. Tips are given for getting started with bug fixing, including resources on the Mozilla hacking page and source code review site. Contact information is also listed for asking any questions.
Recommended
Sonybmg Rootkit
The SonyBMG rootkit was a program installed on Sony music CDs that was intended to prevent copying but ended up opening security holes that allowed viruses to infect computers more easily. It affected around 500,000 networks and took 3 months for Sony to release a removal tool. The rootkit altered the way Windows operating systems read CDs and allowed easier virus infections by opening security holes, though its creator intended it only as anti-copying software. To remove the rootkit, the Sony utility would need to be used.
Msr2011 zaman
This document summarizes a study comparing how security bugs, performance bugs, and other bugs are handled in the Firefox browser. The study found that:
1) Security bugs are triaged and fixed faster than other types of bugs.
2) Security bug fixes are performed by more experienced developers and tend to be more complex, involving changes to more files.
3) Security bugs are tossed (reassigned) and reopened more often during the fixing process than other bugs.
Qsic2010 shihab
This document describes a study that evaluates different heuristics for prioritizing which functions in a legacy system should have unit tests written for them first under a test-driven maintenance (TDM) approach. The study used historical modification and bug fix data from a legacy system to simulate writing unit tests over time according to various heuristics like "most frequently modified", "largest fixed", and "change risk". The results showed that heuristics focused on modification frequency and past fixes performed best in terms of usefulness of the unit tests and optimal test coverage within resource constraints.
Icsme14danieletal 150722141344-lva1-app6891
The study analyzed delays in integrating addressed issues into software releases. It found that 34-60% of addressed issues in traditional release cycles were delayed, while 98% were delayed in rapid release cycles. The study built prediction models using random forests to predict integration delays. Integration workload was the most influential variable in the models. The models performed better than random guessing with precisions of 0.59-0.88 and ROC areas above 0.74.
Wcre2010 shihab
This study examined attributes of bug reports in the Eclipse project to predict which bugs would be re-opened. The researchers found that comment text, description text, and component were the best indicators. Using these and other attributes, their prediction model achieved 63% precision and 85% recall in identifying re-opened bugs. Month, time to resolve, and fixer/reporter names were also important attributes. The researchers concluded that comments are important for predicting re-opened bugs and that bug reports contained the most useful attributes.
Detecting Occurrences of Refactoring with Heuristic Search
This document describes a technique for detecting refactorings between two versions of a program using heuristic search. Refactorings are detected by generating intermediate program states through applying refactorings, and finding a path from the original to modified program that minimizes differences. Structural differences are used to identify likely refactorings. Candidate refactorings are evaluated and applied to generate new states, with the search terminating when the state matches the modified program. A supporting tool was developed and a case study found the technique could correctly detect an actual series of refactorings between program versions.
Leveraging performance counters and execution logs to diagnose memory related...
This document discusses an approach to diagnosing memory-related performance issues in systems by leveraging performance counters and execution logs. The approach involves:
1) Generating signatures each time memory is sampled from counters and combining them with abstracted events from logs.
2) Counting the events and calculating memory usage to identify outliers.
3) Inspecting the outliers to diagnose issues like memory bloat, leaks or spikes.
The results showed the approach could flag problematic events with over 99.98% precision and reduce diagnostic effort by over 99.98%, helping experts efficiently analyze memory performance problems.
Why You Should Be Fixing Bugs
The document discusses fixing bugs in software. It lists 4 bugs that have been fixed or are currently being worked on. It provides reasons for fixing bugs such as working on real software used by millions, impressing others, and learning valuable skills. Tips are given for getting started with bug fixing, including resources on the Mozilla hacking page and source code review site. Contact information is also listed for asking any questions.
DevAppLB - PhoneGap Zombie App - Dani Arnaout
PhoneGap is a mobile development framework that allows developers to build applications for a variety of mobile platforms, using familiar web technologies such as HTML, CSS, and JavaScript.
The concept is that you can develop one application using the PhoneGap architecture, and then deploy to multiple mobile platforms — without the need to re-write any code!
In this tutorial, you’ll learn the basics of using PhoneGap to make a simple to-do app, with a twist – it’s an app to help you survive the Zombie Apocalypse!
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
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.
Failfast
The document discusses the concept of "fail fast" in software development. It advocates for failing immediately when errors are encountered rather than failing silently, which can lead to bugs appearing unexpectedly later on. It recommends using assertions to validate conditions and ensure failures occur early in development. Debugging is identified as the most annoying part of software work, and failing fast is presented as a solution to reduce debugging time by catching errors sooner.
Favourite technology
A speaking lesson for learners of English based on an authentic video. Level: Intermediate. Activities: listening (gist and decoding), modal verbs, linkers for listing, presenting favourite apps
Five Stages of Development - Nordic.js
The document discusses the five stages of grief (denial, anger, bargaining, depression, acceptance) according to the Kübler-Ross model. It relates these stages to the development of Firefox Developer Tools. It describes how Mozilla went through stages of denial, anger, and bargaining about the tools before reaching a stage of acceptance with a twist - deciding to improve the tools by soliciting feedback and implementing new features. This process led to increased usage of Firefox Developer Tools. The document advocates debugging apps across desktop, Android, and iOS using one tool - the Firefox Tools Adapter.
2016 - Daniel Lebrero - REPL driven development
New computers have more and more available memory which for us, programmers means we can use more memory in our applications.
However in JAVA (actually all JVM based languages) at some certain point things may get tricky, especially when we expect from our applications to be responsive all the time. This talk will focus on Garbage First collector (the new default in JDK9) which is the newest algorithm available in HotSpot JVM (not so new though) and the only one which can handle 32+GB heap size without blocking your application threads for longer than 200ms. After this talk you will have overview how G1 works, how to read the log, spot common problems and which gc settings you should avoid.
Source Control 101
My brief introductory training on using source control. SubVersion was used during the presentation but it applies to most source control systems.
Debugging Your Plone Site
Basic steps to debugging a website, specific place in Plone that will help you debug the site, and some examples of bugs I fixed recently.
6 easy bug tracking tips & tricks every developer should know!
When it comes to bug tracking there’s a lot of discipline required from everybody involved.
Tracking & solving bugs encourages everyone involved to stand to the rules. Especially in creative- & startup-driven industries it can be pretty hard to discourage any informal communication. Bug tracking isn't that much fun. But promise me: it can be super-fun.
I’d like to present you 6 simple bug tracking tips for your next bug tracking project, which will help you feel way more comfortable while tracking & fixing bugs.
According to Technopedia bug tracking is defined as:
"...a process used by quality assurance personnel and programmers to keep track of software problems and resolutions.”
Therefore a bug tracking tool stores all the information about reported bugs and keeps track of the status of each bug. You definitely see the need of extensive information while tracking bugs.
For further read, I recommend the following blog posts:
>> surprisingly easy bug tracking hacks: http://usersnap.com/blog/easy-bug-tracking-hacks-developers/
>> How to set up a bug-free environment: http://usersnap.com/blog/bug-free-development-environment/
Five stages of development - at Vaimo
This document discusses the five stages of development as they relate to the development of Firefox Developer Tools: denial, anger, bargaining, depression, and acceptance. It describes how the developer tools team went through these stages before deciding to accept the situation and make improvements. They did this by blogging, gathering community feedback, and shipping new features. This led to a 6% increase in the number of developers using Firefox Developer Tools as their primary toolset.
Version Control Systems - ArabNet Beirut 2014 - Dani Arnaout
This is the presentation that was given at ArabNet Beirut 2014. It cover some basic & intermediate info about Version Control Systems in a simple & special way.
It includes lots of images & just few text, so you won't be able to fully understand what's going on unless you watched the talk.
Will add a link to the talk once it becomes available.
SAD15 - Maintenance
This document discusses software maintenance in the context of a large multiplayer online game that has been in development since 1992. It describes the four main types of maintenance: corrective, adaptive, perfective, and preventative. Despite extensive bug tracking and fixing efforts by many developers, the game continues to accumulate new bug reports due to inconsistencies in coding standards, lack of formal developer training, and the political nature of coordinating volunteer work. Refactoring, optimization, and adapting to new requirements are ongoing maintenance challenges for the massive codebase.
Bug first Zero Defect
How could the concept of Zero Defect improve the quality of the software that is developed and deployed to customer.
Let's Make the PAIN Visible!
What if we could measure the indirect costs of pain building up on a software project? What if we could measure the effects of learning curves, collaboration pain, and problems building up in the code?
We could:
Identify the highest leverage opportunities for improvement
Make the case to management that budget should be allocated for a solution
Lead the organization in making better decisions with a data-driven feedback loop to guide the way
Several years ago, I stumbled into a solution for measuring the growing “friction” in developer experience. Visibility turned my world upside-down.
We've been trying to explain the pain of Technical Debt for generations, but we've never been able to measure it. Visibility introduces a whole new world of possibilities.
In this talk, I'll show you what I'm measuring, how exactly I'm measuring it, then we'll talk through the implications for our teams, our organizations, and our industry.
We can identify the highest leverage improvement opportunities and steer our projects with a data-driven feedback loop.
We can breakdown the "wall of ignorance" between developers and management by defining an explicit language for managing technical risk.
We can teach the art of software development with a data-driven feedback loop and codify our knowledge into sharable decision principles.
We can revolutionize our business accounting methods to take the pain of software development into account, so the costs and risks are visible at the highest levels of the organization.
We can conquer the challenges across the software industry by working together, learning together, and sharing our knowledge with the world.
With visibility, we can start a revolution in data-driven learning.
Improving Bug Tracking Systems
The document discusses improving bug tracking systems. It describes the current process of reporting bugs which involves users providing detailed steps to reproduce the issue. It envisions a future where conversational agents assist users in reporting bugs by asking targeted questions to gather key details. This helps identify the likely cause of the bug and location to fix it. The document also discusses building models to predict bug fixes using decision trees trained on historical bug report data.
React Apps at AirHelp. Lessons learned.
Over the last few years, in order to facilitate growth of our UI applications, we had to make a few architectural decisions like turning to monorepo approach, distributing private packages with npm or adjusting continuous integration setup. In this talk I'd like to share the pain points we've encountered throughout the way, as well as to present benefits of the approach we've worked out compared to more traditional alternatives.
Software testing and concolic execution LSE 2013
The document discusses software testing and concolic execution. It begins with an introduction to the author and their work in software testing. It then provides definitions and statistics related to software testing, and describes various methods for finding bugs such as white box testing, black box testing, dumb fuzzing, and in-memory fuzzing. The document introduces concolic execution as a technique that uses both symbolic and concrete execution to solve path constraints. It also discusses tools used for concolic execution like Valgrind, its VEX intermediate language, and the Z3 theorem prover.
Introducing BugBase 1.0
This document introduces BugBase, a simple PHP bug tracking system. It provides an overview of BugBase's features such as login/registration, dashboard, reporting bugs, and an administration system. The document also discusses why bug tracking is useful for sharing information, helping newcomers, and keeping records. It notes that the current version of BugBase has room for improvement with 98 commits in 7 days leaving quality issues and pending work. Developers are invited to fork and contribute to BugBase to help with its evolution.
Droidcon thessaloniki 2015
The talk is about the “Best Practices” after the mistakes we learnt from.
This is a series of the most interesting “epic fails” we did and hard lessons we learnt. In this session, we will share some stories on how the most unexpected tiny error had the biggest impact.
http://2015.droidcon.gr/session/raymond-chenon/
Middle Out Design
An approach to design from the middle out. Rather than starting at the beginning, what if you need to hit the ground running with a product that's already midway through development? Can you still address conceptual issues effectively? Can you still develop consistent standards? Developed while at Dubberly Design Office.
Studying the Integration Practices and the Evolution of Ad Libraries in the G...
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...
Presenting our paper "Studying the Dialogue Between Users and Developers of Free Apps in the Google Play Store" at ICSE 2018
More Related Content
Similar to Dormant bug v2
DevAppLB - PhoneGap Zombie App - Dani Arnaout
PhoneGap is a mobile development framework that allows developers to build applications for a variety of mobile platforms, using familiar web technologies such as HTML, CSS, and JavaScript.
The concept is that you can develop one application using the PhoneGap architecture, and then deploy to multiple mobile platforms — without the need to re-write any code!
In this tutorial, you’ll learn the basics of using PhoneGap to make a simple to-do app, with a twist – it’s an app to help you survive the Zombie Apocalypse!
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
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.
Failfast
The document discusses the concept of "fail fast" in software development. It advocates for failing immediately when errors are encountered rather than failing silently, which can lead to bugs appearing unexpectedly later on. It recommends using assertions to validate conditions and ensure failures occur early in development. Debugging is identified as the most annoying part of software work, and failing fast is presented as a solution to reduce debugging time by catching errors sooner.
Favourite technology
A speaking lesson for learners of English based on an authentic video. Level: Intermediate. Activities: listening (gist and decoding), modal verbs, linkers for listing, presenting favourite apps
Five Stages of Development - Nordic.js
The document discusses the five stages of grief (denial, anger, bargaining, depression, acceptance) according to the Kübler-Ross model. It relates these stages to the development of Firefox Developer Tools. It describes how Mozilla went through stages of denial, anger, and bargaining about the tools before reaching a stage of acceptance with a twist - deciding to improve the tools by soliciting feedback and implementing new features. This process led to increased usage of Firefox Developer Tools. The document advocates debugging apps across desktop, Android, and iOS using one tool - the Firefox Tools Adapter.
2016 - Daniel Lebrero - REPL driven development
New computers have more and more available memory which for us, programmers means we can use more memory in our applications.
However in JAVA (actually all JVM based languages) at some certain point things may get tricky, especially when we expect from our applications to be responsive all the time. This talk will focus on Garbage First collector (the new default in JDK9) which is the newest algorithm available in HotSpot JVM (not so new though) and the only one which can handle 32+GB heap size without blocking your application threads for longer than 200ms. After this talk you will have overview how G1 works, how to read the log, spot common problems and which gc settings you should avoid.
Source Control 101
My brief introductory training on using source control. SubVersion was used during the presentation but it applies to most source control systems.
Debugging Your Plone Site
Basic steps to debugging a website, specific place in Plone that will help you debug the site, and some examples of bugs I fixed recently.
6 easy bug tracking tips & tricks every developer should know!
When it comes to bug tracking there’s a lot of discipline required from everybody involved.
Tracking & solving bugs encourages everyone involved to stand to the rules. Especially in creative- & startup-driven industries it can be pretty hard to discourage any informal communication. Bug tracking isn't that much fun. But promise me: it can be super-fun.
I’d like to present you 6 simple bug tracking tips for your next bug tracking project, which will help you feel way more comfortable while tracking & fixing bugs.
According to Technopedia bug tracking is defined as:
"...a process used by quality assurance personnel and programmers to keep track of software problems and resolutions.”
Therefore a bug tracking tool stores all the information about reported bugs and keeps track of the status of each bug. You definitely see the need of extensive information while tracking bugs.
For further read, I recommend the following blog posts:
>> surprisingly easy bug tracking hacks: http://usersnap.com/blog/easy-bug-tracking-hacks-developers/
>> How to set up a bug-free environment: http://usersnap.com/blog/bug-free-development-environment/
Five stages of development - at Vaimo
This document discusses the five stages of development as they relate to the development of Firefox Developer Tools: denial, anger, bargaining, depression, and acceptance. It describes how the developer tools team went through these stages before deciding to accept the situation and make improvements. They did this by blogging, gathering community feedback, and shipping new features. This led to a 6% increase in the number of developers using Firefox Developer Tools as their primary toolset.
Version Control Systems - ArabNet Beirut 2014 - Dani Arnaout
This is the presentation that was given at ArabNet Beirut 2014. It cover some basic & intermediate info about Version Control Systems in a simple & special way.
It includes lots of images & just few text, so you won't be able to fully understand what's going on unless you watched the talk.
Will add a link to the talk once it becomes available.
SAD15 - Maintenance
This document discusses software maintenance in the context of a large multiplayer online game that has been in development since 1992. It describes the four main types of maintenance: corrective, adaptive, perfective, and preventative. Despite extensive bug tracking and fixing efforts by many developers, the game continues to accumulate new bug reports due to inconsistencies in coding standards, lack of formal developer training, and the political nature of coordinating volunteer work. Refactoring, optimization, and adapting to new requirements are ongoing maintenance challenges for the massive codebase.
Bug first Zero Defect
How could the concept of Zero Defect improve the quality of the software that is developed and deployed to customer.
Let's Make the PAIN Visible!
What if we could measure the indirect costs of pain building up on a software project? What if we could measure the effects of learning curves, collaboration pain, and problems building up in the code?
We could:
Identify the highest leverage opportunities for improvement
Make the case to management that budget should be allocated for a solution
Lead the organization in making better decisions with a data-driven feedback loop to guide the way
Several years ago, I stumbled into a solution for measuring the growing “friction” in developer experience. Visibility turned my world upside-down.
We've been trying to explain the pain of Technical Debt for generations, but we've never been able to measure it. Visibility introduces a whole new world of possibilities.
In this talk, I'll show you what I'm measuring, how exactly I'm measuring it, then we'll talk through the implications for our teams, our organizations, and our industry.
We can identify the highest leverage improvement opportunities and steer our projects with a data-driven feedback loop.
We can breakdown the "wall of ignorance" between developers and management by defining an explicit language for managing technical risk.
We can teach the art of software development with a data-driven feedback loop and codify our knowledge into sharable decision principles.
We can revolutionize our business accounting methods to take the pain of software development into account, so the costs and risks are visible at the highest levels of the organization.
We can conquer the challenges across the software industry by working together, learning together, and sharing our knowledge with the world.
With visibility, we can start a revolution in data-driven learning.
Improving Bug Tracking Systems
The document discusses improving bug tracking systems. It describes the current process of reporting bugs which involves users providing detailed steps to reproduce the issue. It envisions a future where conversational agents assist users in reporting bugs by asking targeted questions to gather key details. This helps identify the likely cause of the bug and location to fix it. The document also discusses building models to predict bug fixes using decision trees trained on historical bug report data.
React Apps at AirHelp. Lessons learned.
Over the last few years, in order to facilitate growth of our UI applications, we had to make a few architectural decisions like turning to monorepo approach, distributing private packages with npm or adjusting continuous integration setup. In this talk I'd like to share the pain points we've encountered throughout the way, as well as to present benefits of the approach we've worked out compared to more traditional alternatives.
Software testing and concolic execution LSE 2013
The document discusses software testing and concolic execution. It begins with an introduction to the author and their work in software testing. It then provides definitions and statistics related to software testing, and describes various methods for finding bugs such as white box testing, black box testing, dumb fuzzing, and in-memory fuzzing. The document introduces concolic execution as a technique that uses both symbolic and concrete execution to solve path constraints. It also discusses tools used for concolic execution like Valgrind, its VEX intermediate language, and the Z3 theorem prover.
Introducing BugBase 1.0
This document introduces BugBase, a simple PHP bug tracking system. It provides an overview of BugBase's features such as login/registration, dashboard, reporting bugs, and an administration system. The document also discusses why bug tracking is useful for sharing information, helping newcomers, and keeping records. It notes that the current version of BugBase has room for improvement with 98 commits in 7 days leaving quality issues and pending work. Developers are invited to fork and contribute to BugBase to help with its evolution.
Droidcon thessaloniki 2015
The talk is about the “Best Practices” after the mistakes we learnt from.
This is a series of the most interesting “epic fails” we did and hard lessons we learnt. In this session, we will share some stories on how the most unexpected tiny error had the biggest impact.
http://2015.droidcon.gr/session/raymond-chenon/
Middle Out Design
An approach to design from the middle out. Rather than starting at the beginning, what if you need to hit the ground running with a product that's already midway through development? Can you still address conceptual issues effectively? Can you still develop consistent standards? Developed while at Dubberly Design Office.
Similar to Dormant bug v2 (20)
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
How are Discussions Associated with Bug Reworking? An Empirical Study on Open...
6 easy bug tracking tips & tricks every developer should know!
6 easy bug tracking tips & tricks every developer should know!
Version Control Systems - ArabNet Beirut 2014 - Dani Arnaout
Version Control Systems - ArabNet Beirut 2014 - Dani Arnaout
More from SAIL_QU
Studying the Integration Practices and the Evolution of Ad Libraries in the G...
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...
Presenting our paper "Studying the Dialogue Between Users and Developers of Free Apps in the Google Play Store" at ICSE 2018
Improving the testing efficiency of selenium-based load tests
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...
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...
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...
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...
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...
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?
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 Changes
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 Analyses
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...
Presented by Daniel da Costa, Shane McIntosh, Weiyi (Ian) Shang, Uira Kulesza, Roberta Coelho, and Ahmed E. Hassan
A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...
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...
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...
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?
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 ...
Presented by Kazuhiro Yamashita, Changyun Huang, Meiyappan Nagappan, Yasutaka Kamei, Audris Mockus, Ahmed E. Hassan, and Naoyasu Ubayashi
Revisiting the Experimental Design Choices for Approaches for the Automated R...
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 Professionals
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 Data
- 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.
More from SAIL_QU (20)
Studying the Integration Practices and the Evolution of Ad Libraries in the G...
Studying the Integration Practices and the Evolution of Ad Libraries in the G...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
Improving the testing efficiency of selenium-based load tests
Improving the testing efficiency of selenium-based load tests
Studying User-Developer Interactions Through the Distribution and Reviewing M...
Studying User-Developer Interactions Through the Distribution and Reviewing M...
Studying online distribution platforms for games through the mining of data f...
Studying online distribution platforms for games through the mining of data f...
Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...
Understanding the Factors for Fast Answers in Technical Q&A Websites: An Empi...
Investigating the Challenges in Selenium Usage and Improving the Testing Effi...
Investigating the Challenges in Selenium Usage and Improving the Testing Effi...
Mining Development Knowledge to Understand and Support Software Logging Pract...
Mining Development Knowledge to Understand and Support Software Logging Pract...
Which Log Level Should Developers Choose For a New Logging Statement?
Which Log Level Should Developers Choose For a New Logging Statement?
The Impact of Task Granularity on Co-evolution Analyses
The Impact of Task Granularity on Co-evolution Analyses
A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...
A Framework for Evaluating the Results of the SZZ Approach for Identifying Bu...
A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...
A Study of the Relation of Mobile Device Attributes with the User-Perceived Q...
A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...
A Large-Scale Study of the Impact of Feature Selection Techniques on Defect C...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
Studying the Dialogue Between Users and Developers of Free Apps in the Google...
What Do Programmers Know about Software Energy Consumption?
What Do Programmers Know about Software Energy Consumption?
Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...
Threshold for Size and Complexity Metrics: A Case Study from the Perspective ...
Revisiting the Experimental Design Choices for Approaches for the Automated R...
Revisiting the Experimental Design Choices for Approaches for the Automated R...
Measuring Program Comprehension: A Large-Scale Field Study with Professionals
Measuring Program Comprehension: A Large-Scale Field Study with Professionals
Dormant bug v2
- 1. An Empirical Study of Dormant Bugs Tse-Hsun(Peter) Chen Meiyappan Nagappan Emad Shihab Ahmed E. Hassan 1
- 2. Most studies focus on post-release bugs 2 Version A Version B File A Bug 1 Bug 2 Bugs Discovered!Assign Bugs to File A
- 3. Some bugs may remain dormant for a long time 3 Version A Version CVersion B File A Bug is waken up, but is counted as post-release bug for Version B Zzz… Zzz…
- 4. What are dormant bugs? 4 Version BVersion A Version C Today File A Bug 1 File B Bug 2 Bug 3 Bugs introduced in Version A Not a dormant bug Bug 2 Dormant bug (discovered one version after it was introduced ) Dormant bug (discovered many versions after it was introduced ) Bug 1 … Zzz..Zzz.. Bug 3
- 5. Dormant bugs affect perceived software quality 5 VersionA Version B Version A has 5 bugs Version B has 10 bugs
- 6. Dormant bugs affect perceived software quality 6 VersionA Version B Version A has 5 bugs Version B has 10 bugs Version B has 8 dormant bugs! These dormant bugs were introduced in version A
- 7. Case study on 20 systems 7 Studied 20 open-source systems in the Apache Foundation Analyzed all versions System LOCs: 61K ~ 1.5M # dormant bugs 29% # non- dormant bugs 71%
- 8. Many bugs are actually dormant bugs 8 VersionA Version C Bug introduced in Version A 33% of bugs become dormant bugs! VersionA Bugs reported in Version A Many post-release bugs are actually introduced in MUCH EARLIER versions! 20% of bugs are dormant bugs from prior versions
- 9. RQ1: How quickly are dormant bugs fixed? Research questions 9 RQ2: What is the size of a dormant bug fix? RQ3: Who fixes dormant bugs? RQ4: What are the root causes of dormant bug fixes?
- 10. RQ1: How quickly are dormant bugs fixed? Research questions 10 RQ2: What is the size of a dormant bug fix? RQ3: Who fixes dormant bugs? RQ4: What are the root causes of dormant bug fixes?
- 11. Dormant bugs are fixed faster and the fixes are larger 11 Dormant Non-dormant Take 5 days to fix (median) Takes 60% more time to fix Dormant Non-dormant Fix size is 19 LOC (median) Fix size is 50% smaller
- 12. RQ1: How quickly are dormant bugs fixed? Research questions 12 RQ2: What is the size of a dormant bug fix? RQ3: Who fixes dormant bugs? RQ4: What are the root causes of dormant bug fixes?
- 13. RQ1: How quickly are dormant bugs fixed? Research questions 13 RQ2: What is the size of a dormant bug fix? RQ3: Who fixes dormant bugs? RQ4: What are the root causes of dormant bug fixes?
- 14. Dormant fixers are more experienced 14 Dormant Non-dormant #ofpriorcommitsofbugfixers
- 15. RQ1: How quickly are dormant bugs fixed? Research questions 15 RQ2: What is the size of a dormant bug fix? RQ3: Who fixes dormant bugs? RQ4: What are the root causes of dormant bug fixes?
- 16. RQ1: How quickly are dormant bugs fixed? Research questions 16 RQ2: What is the size of a dormant bug fix? RQ3: Who fixes dormant bugs? RQ4: What are the root causes of dormant bug fixes?
- 17. Manual study of the root causes 17 All bugs Randomly sampled 357 dormant bugs and 357 non-dormant bugs Manually classify the bugs
- 19. Dormant bugs are different from non- dormant bugs 19 We should consider dormant bugs in future studies to avoid bias They are different!
- 20. 20
- 21. 21
- 22. 22
- 23. 23
- 24. 24