Demonstration venue · read-only. Every page can be browsed; the buttons that would change it are switched off. Create an account to run TaxoReview on your own data. A simulation from public publication records: the people listed were not invited and did not agree to review.
? Tutorial for this page

Ronivaldo Ferreira

dblp:345/0309 · DBLP profile ↗
← Back
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

TopicWeightPapersLastEvidence papers
Software testing
flaky test
0.712023
Test Flakiness Across Programming Languages · IEEE Trans. Software Eng. 2023
Software testing
regression testing
0.712023
Test Flakiness Across Programming Languages · IEEE Trans. Software Eng. 2023
Empirical software engineering
mining software repositories
0.212023
Test Flakiness Across Programming Languages · IEEE Trans. Software Eng. 2023

Methods — techniques the papers use, named apart from their topics

empirical study · 0.7
YearPublicationVenuePosition
2023 Test Flakiness Across Programming Languages
abstract
Regression 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