Interactive, visual fault localization support for end-user programmers

Ruthruff, Joseph R.; Prabhakararao, S.; Reichwein, James; Cook, Curtis R.; Creswick, Eugene R.; Burnett, Margaret

doi:10.1016/j.jvlc.2004.07.001

Cited by 31 publications

(46 citation statements)

References 32 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Complicating the situation is the interactive nature of end-user debugging: when end users observe a failure they often begin debugging immediately -not after running several tests -at which time the system may have little information with which to provide feedback. Thus, a fault localization tech-nique that requires large amounts of data (e.g., [15]) may be inappropriate for end users. Fourth, evidence shows that end users often make mistakes when performing interactive testing and debugging tasks [27]. (Professional programmers err too, of course, but their understanding of testing processes may render them less error-prone than end users.)…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

An empirical study of fault localization for end-user programmers

Ruthruff

Burnett

Rothermel

2005

Proceedings of the 27th International Conference on Software Engineering - ICSE '05

Self Cite

View full text Add to dashboard Cite

End users develop more software than any other group of programmers, using software authoring devices such as e-mail filtering editors, by-demonstration macro builders, and spreadsheet environments. Despite this, there has been little research on finding ways to help these programmers with the dependability of their software. We have been addressing this problem in several ways, one of which includes supporting end-user debugging activities through fault localization techniques. This paper presents the results of an empirical study conducted in an end-user programming environment to examine the impact of two separate factors in fault localization techniques that affect technique effectiveness. Our results shed new insights into fault localization techniques for end-user programmers and the factors that affect them, with significant implications for the evaluation of those techniques.

show abstract

Section: Introductionmentioning

confidence: 99%

“…Our previous work [26,27] shows that this support can help end users find faults by leading them to employ more effective debugging strategies. However, our results also show that, at times, some [25], which we briefly describe here.…”

Section: Introductionmentioning

confidence: 99%

An empirical study of fault localization for end-user programmers

Ruthruff

Burnett

Rothermel

2005

Proceedings of the 27th International Conference on Software Engineering - ICSE '05

Self Cite

View full text Add to dashboard Cite

show abstract

“…For example, static checkers [Bush et al 2000;Cole et al 2006] could provide cues about which dependency chains have the most potential problems, leading the user to fault-prone code. Another more interactive approach would be to allow the user to explicitly validate values as in the WYSIWYT testing and the fault localization approach [Ruthruff et al 2005]. These annotations of correct and incorrect values could be propagated through the dynamic slice, highlighting contributors to incorrect values.…”

Section: Integration With Other Techniquesmentioning

confidence: 99%

Extracting and answering why and why not questions about Java program output

Myers

2010

ACM Trans. Softw. Eng. Methodol.

View full text Add to dashboard Cite

When software developers want to understand the reason for a program's behavior, they must translate their questions about the behavior into a series of questions about code, speculating about the causes in the process. The Whyline is a new kind of debugging tool that avoids such speculation by instead enabling developers to select a question about program output from a set of "why did and why didn't" questions extracted from the program's code and execution. The tool then finds one or more possible explanations for the output in question. These explanations are derived using a static and dynamic slicing, precise call graphs, reachability analyses, and new algorithms for determining potential sources of values. Evaluations of the tool on two debugging tasks showed that developers with the Whyline were three times more successful and twice as fast at debugging, compared to developers with traditional breakpoint debuggers. The tool has the potential to simplify debugging and program understanding in many software development contexts.

show abstract

“…For example, Microsoft Excel 2003 will show the cells on which the current cell depends. Forms/3 goes further in providing visualizations that try to focus the user's attention on from where faulty values may have come [21]. Production systems, such as ACT-R, have long had the ability to ask why productions did or did not fire [3], and the Whyline [11] generalizes this to any output statement in the program.…”

Section: Related Workmentioning

confidence: 99%

“…When the user hits F1, the system should return all objects under the mouse, including individual objects, groups, and background ("master") objects, and put these into the first-level menu. An implementation for spreadsheets might combine the techniques described here with techniques discussed elsewhere [21] [1] that explain how the values were calculated.…”

Section: Other Kinds Of Applicationsmentioning

confidence: 99%

Answering why and why not questions in user interfaces

Myers

Weitzman

et al. 2006

Proceedings of the SIGCHI Conference on Human Factors in Computing Systems

View full text Add to dashboard Cite

Modern applications such as Microsoft Word have many automatic features and hidden dependencies that are frequently helpful but can be mysterious to both novice and expert users. The "Crystal" application framework provides an architecture and interaction techniques that allow programmers to create applications that let the user ask a wide variety of questions about why things did and did not happen, and how to use the related features of the application without using natural language. A user can point to an object or a blank space and get a popup list of questions about it, or the user can ask about recent actions from a temporal list. Parts of a text editor were implemented to show that these techniques are feasible, and a user test suggests that they are helpful and well-liked.

show abstract

Interactive, visual fault localization support for end-user programmers

Cited by 31 publications

References 32 publications

An empirical study of fault localization for end-user programmers

An empirical study of fault localization for end-user programmers

Extracting and answering why and why not questions about Java program output

Answering why and why not questions in user interfaces

Contact Info

Product

Resources

About