How to successfully grow a code review cultureNina Zakharenko
As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.
In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.
https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/
Peer code review is one of the most effective ways to find defects – but is it agile? Because agile teams loathe heavy process, code review practices can easily fail. However, lightweight peer code review aligns well with the central tenets of agile—keeping feedback close to the point of creation, increasing team velocity by finding defects faster, and improving collective code ownership through frequent collaboration. Gregg Sporar shares recent research on code review practices and describes an agile code review approach—how much time to spend, which code to review, how much code to review at a time, how to set goals, the value of annotation, and more. After comparing four styles of code review—pair programming, over-the-shoulder, email, and tool-assisted—Gregg gives specific advice for creating review checklists and dealing with the social effects of code review in an agile environment.
How to successfully grow a code review cultureNina Zakharenko
As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.
In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.
https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/
Peer code review is one of the most effective ways to find defects – but is it agile? Because agile teams loathe heavy process, code review practices can easily fail. However, lightweight peer code review aligns well with the central tenets of agile—keeping feedback close to the point of creation, increasing team velocity by finding defects faster, and improving collective code ownership through frequent collaboration. Gregg Sporar shares recent research on code review practices and describes an agile code review approach—how much time to spend, which code to review, how much code to review at a time, how to set goals, the value of annotation, and more. After comparing four styles of code review—pair programming, over-the-shoulder, email, and tool-assisted—Gregg gives specific advice for creating review checklists and dealing with the social effects of code review in an agile environment.
Synthesizing Continuous Deployment Practices in Software DevelopmentAkond Rahman
Continuous deployment speeds up the process of existing agile methods, such as Scrum, and Extreme Programming (XP) through the automatic deployment of software changes to end-users upon passing of automated tests. Continuous deployment has become an emerging software engineering process amongst numerous software companies, such as Facebook, Github, Netflix, and Rally Software. A systematic analysis of software practices used in continuous deployment can facilitate a better understanding of continuous deployment as a software engineering process. Such analysis can also help software practitioners in having a shared vocabulary of practices and in choosing the software practices that they can use to implement continuous deployment. The goal of this paper is to aid software practitioners in implementing continuous deployment through a systematic analysis of software practices that are used by software companies. We studied the continuous deployment practices of 19 software companies by performing a qualitative analysis of Internet artifacts and by conducting follow-up inquiries. In total, we found 11 software practices that are used by 19 software companies. We also found that in terms of use, eight of the 11 software practices are common across 14 software companies. We observe that continuous deployment necessitates the consistent use of sound software engineering practices such as automated testing, automated deployment, and code review.
This is the presentation used during the session "Lessons Learned in Software Quality 1" conducted in Amman, PSUT (15, Dec, 2010). Presented by Belal Raslan (Director at Quality Partners) & Rayya Abu Ghosh (Quality Manager at Yahoo! Middle east).
With Agile adoption many things have changed in quality assurance and tester role. Ourdays the whole team is responsible for product quality. But not so many people understand how such high level approaches work in practice, how developer interacts with tester, what stages each task passes on the way from requirements specification to customer acceptance, who is doing what at each stage.
I have met only few teams, where developer and tester work closely together on a daily basis. Some projects try to same money on developer's time, others try to have independent testing team without influence from developers side. Developers also don't understad how tester could help them in practice. But this pair is able to significantly improve product quality and avoid many common issues.
In this talk we will cover motivation behind pair work of develoeper and tester, concrete practices and approaches at different stages, and advantages that both sides could achieve from such work style.
This research is presented at the 12th Working Conference on Mining Software Repositories (MSR2015)
Abstract: Software code review is a well-established software quality practice. Recently, Modern Code Review (MCR) has been widely adopted in both open source and industrial projects. To evaluate the impact that characteristics of MCR practices have on software quality, this paper comparatively studies MCR practices in defective and clean source code files. We investigate defective files along two perspectives: 1) files that will eventually have defects (i.e., future-defective files) and 2) files that have historically been defective (i.e., risky files). Through an empirical study of 11,736 reviews of changes to 24,486 files from the Qt open source system, we find that both future-defective files and risky files tend to be reviewed less rigorously than their clean counterparts. We also find that the concerns addressed during the code reviews of both defective and clean files tend to enhance evolvability, i.e., ease future maintenance (like documentation), rather than focus on functional issues (like incorrect program logic). Our findings suggest that although functionality concerns are rarely addressed during code review, the rigor of the reviewing process that is applied to a source code file throughout a development cycle shares a link with its defect proneness.
Who Should Review My Code? A file-location based code-reviewer recommendation approach for modern code review.
This research study is presented at the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER2015)
Find more information and preprint at patanamon.com
Code review is one of the crucial software activities where developers and stakeholders collaborate with each other in order to assess software changes. Since code review processes act as a final gate for new software changes to be integrated into the software product, an intense collaboration is necessary in order to prevent defects and produce a high quality of software products. Recently, code review analytics has been implemented in projects (for example, StackAnalytics4 of the OpenStack project) to monitor the collaboration activities between developers and stakeholders in the code review processes. Yet, due to the large volume of software data, code review analytics can only report a static summary (e.g., counting), while neither insights nor instant suggestions are provided. Hence, to better gain valuable insights from software data and help software projects make a better decision, we conduct an empirical investigation using statistical approaches. In particular, we use the large-scale data of 196,712 reviews spread across the Android, Qt, and OpenStack open source projects to train a prediction model in order to uncover the relationship between the characteristics of software changes and the likelihood of having poor code review collaborations. We extract 20 patch characteristics which are grouped along five dimensions, i.e., software changes properties, review participation history, past involvement of a code author, past involvement of reviewers, and review environment dimensions. To validate our findings, we use the bootstrap technique which repeats the experiment 1,000 times. Due to the large volume of studied data, and an intensive computation of characteristic extraction and find- ing validation, the use of the High-Performance-Computing (HPC) re- sources is mandatory to expedite the analysis and generate insights in a timely manner. Through our case study, we find that the amount of review participation in the past and the description length of software changes are a significant indicator that new software changes will suffer from poor code review collaborations [2017]. Moreover, we find that the purpose of introducing new features can increase the likelihood that new software changes will receive late collaboration from reviewers. Our findings highlight the need for the policies of software change submission that monitor these characteristics in order to help software projects improve the quality of code reviews processes. Moreover, based on our findings, future work should develop real-time code review analytics implemented on HPC resources in order to instantly provide insights and suggestions to software projects
Review Participation in Modern Code Review: An Empirical Study of the Android...The University of Adelaide
This work empirically investigates the factors influence review participation in the MCR process. Through a case study of the Android, Qt, and OpenStack open source projects, we find that the amount of review participation in the past is a significant indicator of patches that will suffer from poor review participation. Moreover, the description length of a patch and the purpose of introducing new features also share a relationship with the likelihood of receiving poor review participation.
This full article of this work is published in the Empirical Software Engineering journal. Available online at http://dx.doi.org/10.1007/s10664-016-9452-6
We know that software is important to our lives. Today, software was applied to diverse applications, but there are still many problems. Software Engineering was established to find solutions to various problems. About Software Development I expect that this presentation will be the one that keeps pushing, as a starting point or inspires you to interested in learning further about software engineering.
Speculative analysis for comment quality assessmentPooja Rani
Previous studies have shown that high-quality code comments assist developers in program comprehension and maintenance tasks. However, the semi-structured nature of comments, unclear conventions for writing good comments, and the lack of quality assessment tools for all aspects of comments make their evaluation and maintenance a non-trivial problem.
To achieve high-quality comments, we need a deeper understanding of code comment characteristics and the practices developers follow. Our preliminary findings show that developers embed various kinds of information in class comments across programming languages. Still, they face problems in locating relevant guidelines to write consistent and informative comments, verifying the adherence of their comments to the guidelines, and evaluating the overall state of comment quality.
To help developers and researchers in building comment quality assessment tools, we provide: (i) an empirically validated taxonomy of comment convention-related questions from various community forums, (ii) an empirically validated taxonomy of comment information types from various programming languages, (iii) a language independent approach to automatically identify the information types, and (iv) a comment quality taxonomy prepared from a systematic literature review.
PTAQ L - Adam Makarowicz - The quality, or there and back againAdam Makarowicz
Let’s take a look how the process of quality assurance has evolved in Cognifide. I would like to take you on a journey through the transformation of quality assurance process in our company from the dinosaurs to the electrically driven car sent into space. The short history from script approach to exploratory testing, from Testers to Quality Assurance Engineers, from manual to automated approach, from Quality Assurance to Quality Assistance, from Continuous Integration to Continuous Delivery and many other elements of our software quality path. Have we found an ideal and bulletproof Quality Assurance process? Has the evolution finished? If not, what’s next?
Synthesizing Continuous Deployment Practices in Software DevelopmentAkond Rahman
Continuous deployment speeds up the process of existing agile methods, such as Scrum, and Extreme Programming (XP) through the automatic deployment of software changes to end-users upon passing of automated tests. Continuous deployment has become an emerging software engineering process amongst numerous software companies, such as Facebook, Github, Netflix, and Rally Software. A systematic analysis of software practices used in continuous deployment can facilitate a better understanding of continuous deployment as a software engineering process. Such analysis can also help software practitioners in having a shared vocabulary of practices and in choosing the software practices that they can use to implement continuous deployment. The goal of this paper is to aid software practitioners in implementing continuous deployment through a systematic analysis of software practices that are used by software companies. We studied the continuous deployment practices of 19 software companies by performing a qualitative analysis of Internet artifacts and by conducting follow-up inquiries. In total, we found 11 software practices that are used by 19 software companies. We also found that in terms of use, eight of the 11 software practices are common across 14 software companies. We observe that continuous deployment necessitates the consistent use of sound software engineering practices such as automated testing, automated deployment, and code review.
This is the presentation used during the session "Lessons Learned in Software Quality 1" conducted in Amman, PSUT (15, Dec, 2010). Presented by Belal Raslan (Director at Quality Partners) & Rayya Abu Ghosh (Quality Manager at Yahoo! Middle east).
With Agile adoption many things have changed in quality assurance and tester role. Ourdays the whole team is responsible for product quality. But not so many people understand how such high level approaches work in practice, how developer interacts with tester, what stages each task passes on the way from requirements specification to customer acceptance, who is doing what at each stage.
I have met only few teams, where developer and tester work closely together on a daily basis. Some projects try to same money on developer's time, others try to have independent testing team without influence from developers side. Developers also don't understad how tester could help them in practice. But this pair is able to significantly improve product quality and avoid many common issues.
In this talk we will cover motivation behind pair work of develoeper and tester, concrete practices and approaches at different stages, and advantages that both sides could achieve from such work style.
This research is presented at the 12th Working Conference on Mining Software Repositories (MSR2015)
Abstract: Software code review is a well-established software quality practice. Recently, Modern Code Review (MCR) has been widely adopted in both open source and industrial projects. To evaluate the impact that characteristics of MCR practices have on software quality, this paper comparatively studies MCR practices in defective and clean source code files. We investigate defective files along two perspectives: 1) files that will eventually have defects (i.e., future-defective files) and 2) files that have historically been defective (i.e., risky files). Through an empirical study of 11,736 reviews of changes to 24,486 files from the Qt open source system, we find that both future-defective files and risky files tend to be reviewed less rigorously than their clean counterparts. We also find that the concerns addressed during the code reviews of both defective and clean files tend to enhance evolvability, i.e., ease future maintenance (like documentation), rather than focus on functional issues (like incorrect program logic). Our findings suggest that although functionality concerns are rarely addressed during code review, the rigor of the reviewing process that is applied to a source code file throughout a development cycle shares a link with its defect proneness.
Who Should Review My Code? A file-location based code-reviewer recommendation approach for modern code review.
This research study is presented at the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER2015)
Find more information and preprint at patanamon.com
Code review is one of the crucial software activities where developers and stakeholders collaborate with each other in order to assess software changes. Since code review processes act as a final gate for new software changes to be integrated into the software product, an intense collaboration is necessary in order to prevent defects and produce a high quality of software products. Recently, code review analytics has been implemented in projects (for example, StackAnalytics4 of the OpenStack project) to monitor the collaboration activities between developers and stakeholders in the code review processes. Yet, due to the large volume of software data, code review analytics can only report a static summary (e.g., counting), while neither insights nor instant suggestions are provided. Hence, to better gain valuable insights from software data and help software projects make a better decision, we conduct an empirical investigation using statistical approaches. In particular, we use the large-scale data of 196,712 reviews spread across the Android, Qt, and OpenStack open source projects to train a prediction model in order to uncover the relationship between the characteristics of software changes and the likelihood of having poor code review collaborations. We extract 20 patch characteristics which are grouped along five dimensions, i.e., software changes properties, review participation history, past involvement of a code author, past involvement of reviewers, and review environment dimensions. To validate our findings, we use the bootstrap technique which repeats the experiment 1,000 times. Due to the large volume of studied data, and an intensive computation of characteristic extraction and find- ing validation, the use of the High-Performance-Computing (HPC) re- sources is mandatory to expedite the analysis and generate insights in a timely manner. Through our case study, we find that the amount of review participation in the past and the description length of software changes are a significant indicator that new software changes will suffer from poor code review collaborations [2017]. Moreover, we find that the purpose of introducing new features can increase the likelihood that new software changes will receive late collaboration from reviewers. Our findings highlight the need for the policies of software change submission that monitor these characteristics in order to help software projects improve the quality of code reviews processes. Moreover, based on our findings, future work should develop real-time code review analytics implemented on HPC resources in order to instantly provide insights and suggestions to software projects
Review Participation in Modern Code Review: An Empirical Study of the Android...The University of Adelaide
This work empirically investigates the factors influence review participation in the MCR process. Through a case study of the Android, Qt, and OpenStack open source projects, we find that the amount of review participation in the past is a significant indicator of patches that will suffer from poor review participation. Moreover, the description length of a patch and the purpose of introducing new features also share a relationship with the likelihood of receiving poor review participation.
This full article of this work is published in the Empirical Software Engineering journal. Available online at http://dx.doi.org/10.1007/s10664-016-9452-6
We know that software is important to our lives. Today, software was applied to diverse applications, but there are still many problems. Software Engineering was established to find solutions to various problems. About Software Development I expect that this presentation will be the one that keeps pushing, as a starting point or inspires you to interested in learning further about software engineering.
Speculative analysis for comment quality assessmentPooja Rani
Previous studies have shown that high-quality code comments assist developers in program comprehension and maintenance tasks. However, the semi-structured nature of comments, unclear conventions for writing good comments, and the lack of quality assessment tools for all aspects of comments make their evaluation and maintenance a non-trivial problem.
To achieve high-quality comments, we need a deeper understanding of code comment characteristics and the practices developers follow. Our preliminary findings show that developers embed various kinds of information in class comments across programming languages. Still, they face problems in locating relevant guidelines to write consistent and informative comments, verifying the adherence of their comments to the guidelines, and evaluating the overall state of comment quality.
To help developers and researchers in building comment quality assessment tools, we provide: (i) an empirically validated taxonomy of comment convention-related questions from various community forums, (ii) an empirically validated taxonomy of comment information types from various programming languages, (iii) a language independent approach to automatically identify the information types, and (iv) a comment quality taxonomy prepared from a systematic literature review.
PTAQ L - Adam Makarowicz - The quality, or there and back againAdam Makarowicz
Let’s take a look how the process of quality assurance has evolved in Cognifide. I would like to take you on a journey through the transformation of quality assurance process in our company from the dinosaurs to the electrically driven car sent into space. The short history from script approach to exploratory testing, from Testers to Quality Assurance Engineers, from manual to automated approach, from Quality Assurance to Quality Assistance, from Continuous Integration to Continuous Delivery and many other elements of our software quality path. Have we found an ideal and bulletproof Quality Assurance process? Has the evolution finished? If not, what’s next?
This presentation is about unit tests, integration tests, REST tests, code coverage and analysis tools, code reviews and other tools that help achieve high-level results.
This presentation by Ilya Tsvetkov (Associate Manager, GlobalLogic) was delivered at GlobalLogic Java Conference in Krakow on December 12, 2015.
Making the Unstable Stable - An Intro To TestingCameron Presley
Does it always seem like bugs you've fixed keep coming back? Does it seem like when you fix one bug, two more crop up? What if I were to tell you there's a better way?
In this presentation, we're going to explore how to make a code base more stable by using automated testing. To start, we'll explore the business case of why you should be writing tests by looking at industry studies and personal experience. From there, we'll look at the fundamentals of testing by talking about the pros/cons of unit, integration, and UI testing. Finally, we'll look at some resources to learn how to write tests.
Intended for developers who are new to testing, by the end of this presentation, you will understand why you should write tests, and will have the concepts and tools to get started.
Prerequisites
Some knowledge with an Object-Oriented language would be beneficial, but not required.
DevLabs Alliance Top 20 Software Testing Interview Questions for SDET - by De...DevLabs Alliance
DevLabs Alliance Software Testing Interview Questions for SDET will help SDETs to prepare for their interviews. Learn top 20 questions with their answers for Software Testing which are majorly asked in interview for SDET role.
DevLabs Alliance Top 20 Software Testing Interview Questions for SDET - by De...DevLabs Alliance
DevLabs Alliance Software Testing Interview Questions for SDET will help SDETs to prepare for their interviews. Learn top 20 questions with their answers for Software Testing which are majorly asked in interview for SDET role.
What Do Developers Discuss about Code Comments?Pooja Rani
Code comments are important for program compre- hension, development, and maintenance tasks. Given the varying standards for code comments, and their unstructured or semi- structured nature, developers get easily confused (especially novice developers) about which convention(s) to follow, or what tools to use while writing code documentation. Thus, they post related questions on external online sources to seek better commenting practices. In this paper, we analyze code comment discussions on online sources such as Stack Overflow (SO) and Quora to shed some light on the questions developers ask about commenting practices. We apply Latent Dirichlet Allocation (LDA) to identify emerging topics concerning code comments. Then we manually analyze a statistically significant sample set of posts to derive a taxonomy that provides an overview of the developer questions about commenting practices.
Our results highlight that on SO nearly 40% of the questions mention how to write or process comments in documentation tools and environments, and nearly 20% of the questions are about potential limitations and possibilities of documentation tools to add automatically and consistently more information in comments. On the other hand, on Quora, developer questions focus more on background information (35% of the questions) or asking opinions (16% of the questions) about code comments. We found that (i) not all aspects of comments are covered in coding style guidelines, e.g., how to add a specific type of information, (ii) developers need support in learning the syntax and format conventions to add various types of information in comments, and (iii) developers are interested in various automated strategies for comments such as detection of bad comments, or verify comment style automatically, but lack tool support to do that.
PDF: https://arxiv.org/abs/2108.07648
Video: https://youtu.be/EUQINZ38ziU
Replication package: https://doi.org/10.5281/zenodo.5044270
Presentation of the paper "Investigating Severity Thresholds for Test Smells" published at MSR 2020.
Authors:
Davide Spadini, Martin Schvarcbacher, Ana-Maria Oprescu, Magiel Bruntink, Alberto Bacchelli
Link to the preprint: https://research.tudelft.nl/en/publications/investigating-severity-thresholds-for-test-smells
Presentation of the paper "Primers or Reminders? The Effects of Existing Review Comments on Code Review" published at ICSE 2020.
Authors:
Davide Spadini, Gül Calikli, Alberto Bacchelli
Link to the paper: https://research.tudelft.nl/en/publications/primers-or-reminders-the-effects-of-existing-review-comments-on-c
Immunizing Image Classifiers Against Localized Adversary Attacksgerogepatton
This paper addresses the vulnerability of deep learning models, particularly convolutional neural networks
(CNN)s, to adversarial attacks and presents a proactive training technique designed to counter them. We
introduce a novel volumization algorithm, which transforms 2D images into 3D volumetric representations.
When combined with 3D convolution and deep curriculum learning optimization (CLO), itsignificantly improves
the immunity of models against localized universal attacks by up to 40%. We evaluate our proposed approach
using contemporary CNN architectures and the modified Canadian Institute for Advanced Research (CIFAR-10
and CIFAR-100) and ImageNet Large Scale Visual Recognition Challenge (ILSVRC12) datasets, showcasing
accuracy improvements over previous techniques. The results indicate that the combination of the volumetric
input and curriculum learning holds significant promise for mitigating adversarial attacks without necessitating
adversary training.
Hierarchical Digital Twin of a Naval Power SystemKerry Sado
A hierarchical digital twin of a Naval DC power system has been developed and experimentally verified. Similar to other state-of-the-art digital twins, this technology creates a digital replica of the physical system executed in real-time or faster, which can modify hardware controls. However, its advantage stems from distributing computational efforts by utilizing a hierarchical structure composed of lower-level digital twin blocks and a higher-level system digital twin. Each digital twin block is associated with a physical subsystem of the hardware and communicates with a singular system digital twin, which creates a system-level response. By extracting information from each level of the hierarchy, power system controls of the hardware were reconfigured autonomously. This hierarchical digital twin development offers several advantages over other digital twins, particularly in the field of naval power systems. The hierarchical structure allows for greater computational efficiency and scalability while the ability to autonomously reconfigure hardware controls offers increased flexibility and responsiveness. The hierarchical decomposition and models utilized were well aligned with the physical twin, as indicated by the maximum deviations between the developed digital twin hierarchy and the hardware.
Explore the innovative world of trenchless pipe repair with our comprehensive guide, "The Benefits and Techniques of Trenchless Pipe Repair." This document delves into the modern methods of repairing underground pipes without the need for extensive excavation, highlighting the numerous advantages and the latest techniques used in the industry.
Learn about the cost savings, reduced environmental impact, and minimal disruption associated with trenchless technology. Discover detailed explanations of popular techniques such as pipe bursting, cured-in-place pipe (CIPP) lining, and directional drilling. Understand how these methods can be applied to various types of infrastructure, from residential plumbing to large-scale municipal systems.
Ideal for homeowners, contractors, engineers, and anyone interested in modern plumbing solutions, this guide provides valuable insights into why trenchless pipe repair is becoming the preferred choice for pipe rehabilitation. Stay informed about the latest advancements and best practices in the field.
Hybrid optimization of pumped hydro system and solar- Engr. Abdul-Azeez.pdffxintegritypublishin
Advancements in technology unveil a myriad of electrical and electronic breakthroughs geared towards efficiently harnessing limited resources to meet human energy demands. The optimization of hybrid solar PV panels and pumped hydro energy supply systems plays a pivotal role in utilizing natural resources effectively. This initiative not only benefits humanity but also fosters environmental sustainability. The study investigated the design optimization of these hybrid systems, focusing on understanding solar radiation patterns, identifying geographical influences on solar radiation, formulating a mathematical model for system optimization, and determining the optimal configuration of PV panels and pumped hydro storage. Through a comparative analysis approach and eight weeks of data collection, the study addressed key research questions related to solar radiation patterns and optimal system design. The findings highlighted regions with heightened solar radiation levels, showcasing substantial potential for power generation and emphasizing the system's efficiency. Optimizing system design significantly boosted power generation, promoted renewable energy utilization, and enhanced energy storage capacity. The study underscored the benefits of optimizing hybrid solar PV panels and pumped hydro energy supply systems for sustainable energy usage. Optimizing the design of solar PV panels and pumped hydro energy supply systems as examined across diverse climatic conditions in a developing country, not only enhances power generation but also improves the integration of renewable energy sources and boosts energy storage capacities, particularly beneficial for less economically prosperous regions. Additionally, the study provides valuable insights for advancing energy research in economically viable areas. Recommendations included conducting site-specific assessments, utilizing advanced modeling tools, implementing regular maintenance protocols, and enhancing communication among system components.
Welcome to WIPAC Monthly the magazine brought to you by the LinkedIn Group Water Industry Process Automation & Control.
In this month's edition, along with this month's industry news to celebrate the 13 years since the group was created we have articles including
A case study of the used of Advanced Process Control at the Wastewater Treatment works at Lleida in Spain
A look back on an article on smart wastewater networks in order to see how the industry has measured up in the interim around the adoption of Digital Transformation in the Water Industry.
5. Research Questions
RQ1: How rigorously is test code reviewed?
RQ2: What do reviewers discuss in test
code reviews?
RQ3: Which practices do reviewers follow
for test files?
RQ4: What problems and challenges do
developers face when reviewing tests?
We collected Code Reviews
from Gerrit
3 OSS: Eclipse, Qt, OpenStack
12 interviews
6. Research Questions
RQ1: How rigorously is test code reviewed?
RQ2: What do reviewers discuss in test
code reviews?
RQ3: Which practices do reviewers follow
for test files?
RQ4: What problems and challenges do
developers face when reviewing tests?
We collected Code Reviews
from Gerrit
3 OSS: Eclipse, Qt, OpenStack
12 interviews
7. RQ1: How rigorously is test code reviewed? — Method
# of
prod. files
# of
test files
# of code
reviews
# of
reviewers
# of
comments
Eclipse 215k 19k 60k 1k 95k
Openstack 75k 48k 199k 9k 894k
Qt 158k 8k 114k 1k 19k
Total 450k 77k 374k 12k 1,010k
8. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
9. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
10. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java ATest.java
11. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java
12. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Test alone
A.java ATest.java
Production alone
A.java
13. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java
Test alone
ATest.java
14. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java
Test alone
ATest.java
0
15
30
45
60
75
% of files with review comments
15. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java
Test alone
ATest.java
0
15
30
45
60
75
% of files with review comments
16. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java
Test alone
ATest.java
0
15
30
45
60
75
% of files with review comments
17. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java
Test alone
ATest.java
0
15
30
45
60
75
% of files with review comments
When together,
production code is 1.9
more likely do be discussed
18. RQ1: How rigorously is test code reviewed? — Results
Together
A.java ATest.java
Production alone
A.java
Test alone
ATest.java
0
15
30
45
60
75
% of files with review comments
When together,
production code is 1.9
more likely do be discussed
When taken separately,
test code is 1.16
more likely to be discussed
19. Avg # of comments
per file
Avg # of reviewers
Avg length of
comments
Together
Production
Test
3.00
1.27
5.49
19.09
15.32
Production alone 1.64 3.95 18.13
Test alone 2.30 5.15 17.01
RQ1: How rigorously is test code reviewed? — Results
20. # of comments,
avg length,
avg # reviewers
Prod. files are
2 times more likely
to be discussed
than test files
Test files are
discussed more
when alone
RQ1: How rigorously is test code reviewed? — Summary
21. Research Questions
RQ1: How rigorously is test code reviewed?
RQ2: What do reviewers discuss in test
code reviews?
RQ3: Which practices do reviewers follow
for test files?
RQ4: What problems and challenges do
developers face when reviewing tests?
We collected Code Reviews
from Gerrit
3 OSS: Eclipse, Qt, OpenStack
12 interviews
22. RQ2: What do reviewers discuss in test code reviews? — Method
> 1,000,000
comments
600
comments
1st round:
6 categories*
2nd round:
for each category,
more fine-grained
*Bacchelli & Bird. Expectations, Outcomes, and Challenges of Modern Code Review. ICSE 2013
23. RQ2: What do reviewers discuss in test code reviews? — Results
0% 10% 20% 30% 40%
production reviews (Bacchelli & Bird, ICSE 2013)
test reviews (this study)
Code improvements
Understanding
Social communication
Defects
Knowledge transfer
24. 0
10
20
30
40
Testing practices Code styling Un/Tested paths Better naming Unnecessary code Assertion handling
Code improvements
RQ2: What do reviewers discuss in test code reviews? — Results
25. RQ2: What do reviewers discuss in test code reviews? — Results
0% 10% 20% 30% 40%
production reviews (Bacchelli & Bird, ICSE 2013)
test reviews (this study)
Understanding
Social communication
Defects
Knowledge transfer
Code improvements
26. 0
10
20
30
40
50
Severe issues Less severe issues Wrong assertions
Defects
RQ2: What do reviewers discuss in test code reviews? — Results
“You need to instantiate
LttngKernelTrace here
otherwise you will get a
class cast exception” —
Severe issue
“This isnt being used, hence
pep8 error.” —
Less severe issue
27. RQ2: What do reviewers discuss in test code reviews? — Results
0% 10% 20% 30% 40%
production reviews (Bacchelli & Bird, ICSE 2013)
test reviews (this study)
Code improvements
Understanding
Social communication
Knowledge transfer
Defects
28. 0
15
30
45
60
Link to external documentation How-to
Knowledge transfer
RQ2: What do reviewers discuss in test code reviews? — Results
29. RQ2: What do reviewers discuss in test code reviews? — Summary
Testing practices,
tested paths and
assertions
Defects are not
among the most
discussed topics
Developers often
comment with
how-to or ext.
documentation
30. Research Questions
RQ1: How rigorously is test code reviewed?
RQ2: What do reviewers discuss in test
code reviews?
RQ3: Which practices do reviewers follow
for test files?
RQ4: What problems and challenges do
developers face when reviewing tests?
We collected Code Reviews
from Gerrit
3 OSS: Eclipse, Qt, OpenStack
12 interviews
32. 1 Openstack
1 Qt
1 Eclipse
1 Microsoft
1 Ericsson
2 Alura
5 OSS
12 interviews
RQ3: Which practices do reviewers follow for test files? — Method
33. RQ3: Which practices do reviewers follow for test files? — Summary
Checking out the
change and run
the tests
Understanding if
all paths are
covered
Test
Driven
Review
34. Research questions
RQ1: How rigorously is test code reviewed?
RQ2: What do reviewers discuss in test
code reviews?
RQ3: Which practices do reviewers follow
for test files?
RQ4: What problems and challenges do
developers face when reviewing tests?
We collected Code Reviews
from Gerrit
3 OSS: Eclipse, Qt, OpenStack
12 interviews
35. Management
policies prioritize
strongly
production code
Novice developers
do not know the
effect of poor
testing
Lack of navigation
support and in-
depth code
coverage info
Reviewing tests
requires context on
both tests and
production
RQ4: What problems and challenges do developers face when reviewing tests?
36. Management
policies prioritize
strongly
production code
Novice developers
do not know the
effect of poor
testing
Lack of navigation
support and in-
depth code
coverage info
Reviewing tests
requires context on
both tests and
production
RQ4: What problems and challenges do developers face when reviewing tests?
Provide the
context for
reviewing test
Plan enough
time for test
review
Educate on test
reviewing and
writing
Detailed code
coverage
information
Implications and recommendations
37.
38. Code Review
•Developers have limited time to do
code review
•Should test files be reviewed?
•If production files are more prone
to contain bugs…reviewer should
focus on production!
39. Should test files be reviewed?
• We conducted a preliminary investigation to see whether test and production
code files are equally associated with defects
• We built a statistical model and used as an explanatory variable “being a
test”
40. Should test files be reviewed?
• 3 OSS projects: Qt, Eclipse and Openstack
• Dependent variable: post-release defects
• Explanatory variables: metrics well related to defect proneness: product metrics,
process metrics and human factors.
‣ Plus, our variable: isTest
41. Metrics in order of importance
Attribute Average merit Average Rank
Churn 0.753 1
Author ownership 0.599 2.2 ± 0.4
Cumulative churn 0.588 2.8 ± 0.4
Total authors 0.521 4
Major authors 0.506 5
Size 0.411 6
Prior defects 0.293 7
Minor authors 0.149 8
Is test 0.085 9
Should test files be reviewed?
• Yes!
• The decision to review a file
should not be based on whether
the file contains production or test
code, as this has no association
with defects.