Demo Data from EDBT 2026 / reviewers in the wild / expert
Ronivaldo Ferreira
dblp:345/0309
· DBLP profile ↗
1ranked-venue papers
0as first author
1since 2021 · last 2023
0000-0002-5812-8707ORCID · reported
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Software testing · 87% Empirical software engineering · 13% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Software testing
flaky test |
0.7 | 1 | 2023 | Test Flakiness Across Programming Languages · IEEE Trans. Software Eng. 2023 |
Software testing
regression testing |
0.7 | 1 | 2023 | Test Flakiness Across Programming Languages · IEEE Trans. Software Eng. 2023 |
Empirical software engineering
mining software repositories |
0.2 | 1 | 2023 | Test Flakiness Across Programming Languages · IEEE Trans. Software Eng. 2023 |
Methods — techniques the papers use, named apart from their topics
empirical study · 0.7
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2023 | Test Flakiness Across Programming LanguagesabstractRegression Testing (RT) is a quality-assurance practice commonly adopted in the software industry to check if functionality remains intact after code changes. Test flakiness is a serious problem for RT. A test is said to be flaky when it non-deterministically passes or fails on a fixed environment. Prior work studied test flakiness primarily on Java programs. It is unclear, however, how problematic is test flakiness for software written in other programming languages. This paper reports on a study focusing on three central aspects of test flakiness: concentration, similarity, and cost. Considering concentration, our results show that, for any given programming language that we studied (C, Go, Java, JS, and Python), most issues could be explained by a small fraction of root causes (5/13 root causes cover 78.07% of the issues) and could be fixed by a relatively small fraction of fix strategies (10/23 fix strategies cover 85.20% of the issues). Considering similarity, although there were commonalities in root causes and fixes across languages (e.g., concurrency and async wait are common causes of flakiness in most languages), we also found important differences (e.g., flakiness due to improper release of resources are more common in C), suggesting that there is opportunity to fine tuning analysis tools. Considering cost, we found that issues related to flaky tests are resolved either very early once they are posted ($< $10 days), suggesting relevance, or very late ($>$100 days), suggesting irrelevance. Keila Barbosa Costa, Ronivaldo Ferreira, Gustavo Pinto 0001, Marcelo d'Amorim, Breno Miranda |
IEEE Trans. Software Eng. | 2 |