Is spreadsheet syntax better than numeric indexing for cell selection?

Dirk Riehle; Georg-Daniel Schwarz; Philip Heltweg

REVIEW 2 major objections 4 minor 26 references

Is spreadsheet syntax better than numeric indexing for cell selection?

T0 review · 2 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read Spreadsheet-style cell references beat numeric indexing in a 93-person experiment.

desk verdict A careful crossover experiment with a real confound: the authors' own DSL got five course exercises while Pandas was self-taught, so the causal claim is weaker than the p-values suggest. read the letter →

arxiv 2505.23296 v1 pith:V6RYBISQ submitted 2025-05-29 cs.PL

Philip Heltweg , Dirk Riehle , Georg-Daniel Schwarz This is my paper

classification cs.PL

keywords domain-specificlanguagesdataengineeringprogrammingsyntaxcontrolledexperimentempiricalstudyspreadsheetnumericindexingcellselection

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper asks whether spreadsheet-style cell references—letters for columns and one-based numbers for rows, as in A1:B10—help people who work with data but are not professional programmers, compared with the zero-based numeric indexing found in general-purpose languages like df.iloc[0, 1]. It reports a controlled experiment in which 93 master's students completed cell-selection tasks in both syntaxes. When reading code, participants made fewer mistakes with spreadsheet syntax (p≈0.019, small effect), but were not faster. When writing code, they were faster (p≈4.8e-13, large effect) and more correct (p≈3e-6, medium effect) with spreadsheet syntax. The authors take this as evidence that a domain-specific spreadsheet syntax is a promising choice for data engineering tools aimed at practitioners without a software-engineering background.

What carries the argument

The machinery is the contrast between two cell-address notations in otherwise matched tasks: numeric indexing (e.g., df.iloc[6:10, 0:3], zero-based, rows and columns distinguished only by position) and spreadsheet-style references (e.g., A1:B10, columns as letters, rows as one-based numbers, with * meaning the last row or column). The experiment carries the argument through a crossover design that cancels individual differences: every participant did both treatments on four comprehension and four creation tasks, with an untracked pseudocode warm-up task and randomly assigned AB/BA sequences to limit carryover. Outcomes were measured programmatically—time to submission and Jaccard-index correctness between the highlighted cells and the selected set—and analyzed with paired nonparametric tests because the distributions were non-normal.

What would settle it

Re-run the experiment as a between-subjects design with a pre-test of each participant's skill in each syntax, or include self-reported prior hours with spreadsheets and with pandas as a covariate; if the spreadsheet advantage drops below statistical significance, the effect is explained by differential practice rather than by the syntax itself.

Watch

Extended reading notes

Core claim

The central claim is that for selecting cells from unstructured two-dimensional data, spreadsheet-style syntax reduces errors and saves time relative to numeric indexing, at least for users whose mental model of tables comes from spreadsheet software. Of the four measured outcomes, three favored spreadsheet syntax: reading comprehension correctness, code-creation correctness, and code-creation speed; reading speed showed no statistically significant difference (p≈0.147). The design was a crossover experiment: each participant used both syntaxes on parallel tasks, correctness was scored with the Jaccard index between selected and target cells, and times were measured from task start to submission. The authors explain the advantage through the two mental models: numeric indexing provides no syntactic distinction between rows and columns and forces users to remember zero-based, end-exclusive ranges, whereas spreadsheet syntax labels each dimension differently and matches the visual labels people already know from spreadsheet programs.

Load-bearing premise

The experiment assumes participants were roughly equally practiced in both syntaxes; there was no baseline measure of prior proficiency, so the measured advantage could partly be a training artifact if the spreadsheet-style DSL received more course time than pandas.

Editorial extensions

If this is right

Language designers for data engineering should treat spreadsheet-style cell selection as a serious option when the target users are not professional programmers.
Fewer cell-selection errors in pipeline code should lead to fewer bugs in downstream datasets, since wrong subsets propagate into cleaning and transformation steps.
The large speed advantage in code writing suggests the syntax lowers the technical barrier for subject-matter experts to contribute directly to data pipelines.
The paper's own discussion notes the advantage may shrink on very wide tables, where multi-letter column references like AA make spreadsheet syntax longer.
Improved comprehension of cell selection code should let practitioners verify and trust existing scripts more confidently before modifying them.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the mechanism is familiarity rather than notation per se, the same effect should appear for any DSL that reuses an audience's existing notation—date formats, units, or field names—which would make the result a general design principle, not a spreadsheet-specific finding.
A direct extension would test spreadsheet syntax against named-column selection and against direct visual manipulation; either might outperform both text syntaxes on realistic dirty data.
The speed gap may partly reflect that pandas offers many ways to select cells, so participants spent time verifying which syntax was allowed; a study with autocomplete or a single-documented API variant could separate intuitiveness from syntactic simplicity.
The authors expect the results not to generalize to professional programmers; a replication with industry data engineers with strong programming backgrounds would map where the syntax advantage ends.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Bottom line: this is a useful empirical artifact, and the large code-creation effects are probably not noise. But the paper's central causal conclusion—spreadsheet syntax is better for data practitioners—rests on a comparison that is not apples-to-apples. The same authors designed, taught, and gave students five exercises in the Jayvee DSL; Pandas was used in a self-directed project with no measured proficiency baseline. That confound is real and load-bearing, even if the effect sizes are large.

What is genuinely new: this is the first controlled experiment comparing spreadsheet-style versus numeric syntax specifically for cell selection in data engineering. That is a narrow but legitimate gap, and the study fills it carefully. The crossover design, random assignment, automatic measurement, paired nonparametric tests, effect sizes with CLES, and public data release all show good methodological discipline. They report the null result on reading speed instead of hiding it, and they discuss several plausible mechanisms without overclaiming.

Where it gets soft: first, the practice asymmetry is not just a footnote. Section 3.7 reports two lectures, five exercises in the DSL, and a self-directed Python project with no prior proficiency measure. The authors acknowledge in Section 6.1 that they are the DSL's creators, but they do not confront the more specific threat that differential training, not syntax, explains the advantage. That is the main thing standing between "spreadsheet syntax helps" and "the authors' DSL was overpracticed." Second, the reading-correctness result (p≈0.019, CLES 0.54) is small and would not survive a Bonferroni correction across the four hypotheses. The authors themselves call it small, which is honest, but the conclusion still leans on it. Third, the DSL's selection syntax is more constrained than iloc, so part of the code-creation advantage may come from fewer ways to make mistakes, not from the spreadsheet metaphor per se. The discussion touches on this but does not treat it as a competing explanation.

Who should read this: people designing DSLs or evaluating syntax choices for non-programmer audiences. It is an empirical data point, not a settled answer. As a referee, I would ask for a preregistered replication with a neutral control treatment, a baseline proficiency measure, and multiple-comparison-corrected analysis. The paper deserves peer review; it should not be desk rejected, but it needs revision before acceptance.

Referee Report

2 major / 4 minor

Summary. The paper reports a controlled crossover experiment with 93 students comparing spreadsheet-style cell-range syntax (in the authors' Jayvee DSL) with numeric iloc indexing in Pandas/Python for reading and writing cell-selection code. It finds a statistically significant improvement in code-creation time (p≈4.8e-13) and correctness (p≈3e-6) and a smaller improvement in comprehension correctness (p≈0.019), with no significant difference in comprehension speed. The authors conclude that spreadsheet-style syntax is a promising alternative for data engineering tools aimed at practitioners without a software engineering background.

Significance. If the effect is causal, the result is practically relevant and provides a useful data point for DSL design in data engineering. The experiment has notable strengths: a crossover design with random assignment, two distinct real-world datasets, two task types, automated measurement and scoring, nonparametric paired tests, effect sizes (CLES and RBC), outlier checks, a public data release on Zenodo, and a detailed description of the instrument that enables replication. The large code-creation effects are likely robust. However, the reading-correctness effect is small and fragile, and the differential training between treatments is a serious confound that has not been addressed. These issues affect the strength of the paper's central causal claim.

major comments (2)

[§3.7, §3.3] The instrumentation section (3.7) states that participants were introduced to the DSL in two lectures and completed five exercises with it, whereas Pandas/Python was used mainly in a self-directed project, with only some participants having prior knowledge (§3.5). No baseline measure of proficiency in either syntax is reported. Because the paper's central claim is causal ('spreadsheet syntax is better'), the large code-creation advantages (Table 5, p≈4.8e-13 for time, CLES≈0.84) could be an artifact of differential practice with the authors' own DSL rather than a property of spreadsheet-style selection. This is a load-bearing threat that the current §6.1 discussion of dual role does not control for. I ask the authors to either provide additional evidence ruling out a practice effect (e.g., using task-order or event-log analyses, or a subgroup with comparable prior exposure) or to substantially temper the causal conclusions to refer to the DSL as taught in this course.
[§4.1, Table 4] The reading-correctness result H1b has p≈0.019 with CLES≈0.54. With four hypotheses tested (H1a, H1b, H2a, H2b), a Bonferroni correction would set the threshold at 0.0125, so this finding would not survive correction. The abstract's statement that 'when reading code, participants make less mistakes using spreadsheet-style syntax' is therefore too strong without a multiple-comparison correction or an explicit exploratory label. Please either apply a correction (e.g., Bonferroni or FDR) and adjust the conclusions, or clearly mark H1b as a tentative finding requiring replication.

minor comments (4)

[§3.7] There is a typo: 'I preparation for the experiment' should be 'In preparation for the experiment'.
[Abstract, §1] 'make less mistakes' should be 'make fewer mistakes'; consider also noting that the comprehension-speed result (H1a) was not significant, to avoid overstating the reading benefits in the abstract.
[Tables 4 and 5] Use a consistent format for p-values (e.g., 4.78e-13, 3.0e-6) and for H2b report the exact p-value; also specify how many outliers were removed for each hypothesis.
[§3.9] The sentence 'The more rigid structure of the DSL leads to slightly lower correctness values for code creation in the spreadsheet syntax for rare edge cases' is unclear; please specify which edge cases are meant and how often they occurred.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: the syntax-comparison conclusion is based on direct experimental measurements, not on a fitted parameter, a uniqueness theorem, or a definitional identity. The only self-involvement is the authors' own Jayvee DSL serving as one treatment arm, which is disclosed and is a validity threat rather than a circular reduction.

full rationale

The paper's central claim — that spreadsheet-style syntax improves program-comprehension correctness and code-creation speed and correctness versus numeric indexing — rests on a within-subjects controlled experiment that measures task time and Jaccard-index correctness directly (§3.4, §3.6, §3.9, §4). No parameter is fitted to a subset of the data and then relabeled as a prediction; the Wilcoxon signed-rank tests and CLES/RBC effect sizes are computed from the raw measurements and are not derived from the hypotheses they test. The two treatment syntaxes are not defined in terms of the outcome: spreadsheet syntax is operationalized as A1:B2-style column-character/one-indexed-row references and numeric syntax as Python/Pandas iloc, with surrounding code supplied to participants (§3.6). No uniqueness theorem or ansatz is imported from prior work. The only material self-citation is [5], the authors' own open-source Jayvee DSL, which implements the spreadsheet treatment and appears in the background discussion; it does not by itself justify the empirical conclusion, and the authors explicitly disclose their dual role as DSL creators in §6.1. The most serious concern is the training asymmetry reported in §3.7 (two introduction lectures plus five course exercises with the DSL, versus a largely self-directed Python/Pandas project with no baseline proficiency measurement): the large code-creation advantages could reflect differential practice rather than syntax per se. That is a threat to conclusion/internal validity, not circularity, because the conclusion does not reduce to its inputs by construction — the paper even disclaims causal interpretation in §7 ('we can not draw clear causal explanations from them'). The study is self-contained against its own measured data, so the circularity score is low despite the self-involvement.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no mathematical free parameters or new entities. Its central claim rests on domain assumptions about participant representativeness, balanced prior training, crossover validity, and the chosen correctness metric.

assumptions (4)

domain assumption Master's students in data science and AI are a valid proxy for data practitioners without a professional programming background.
Section 3.3 and Section 6.4 justify this by prior work, but it is unverified for the specific skill measured.
domain assumption Participants had comparable prior training and familiarity with both syntaxes.
Sections 3.5 and 3.7 describe training in both, but no proficiency baseline is measured; this is the main load-bearing internal-validity assumption.
domain assumption There are no differential carryover effects between treatment periods in the crossover design.
Sections 3.4.2 and 6.2 acknowledge carryover cannot be ruled out; random ordering mitigates but does not eliminate it.
domain assumption The Jaccard index of selected cells is an adequate operationalization of correctness.
Sections 3.4.1 and 6.3 note that competing definitions of correctness are possible.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Is spreadsheet syntax better than numeric indexing for cell selection?." pith.science (2026). https://pith.science/paper/V6RYBISQ

@misc{pith2026250523296,
  author       = {Pith},
  title        = {Pith review of: Is spreadsheet syntax better than numeric indexing for cell selection?},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/V6RYBISQ}},
  note         = {Machine review of arXiv:2505.23296}
}

read the original abstract

Selecting a subset of cells is a common task in data engineering, for example, to remove errors or select only specific parts of a table. Multiple approaches to express this selection exist. One option is numeric indexing, commonly found in general programming languages, where a tuple of numbers identifies the cell. Alternatively, the separate dimensions can be referred to using different enumeration schemes like "A1" for the first cell, commonly found in software such as spreadsheet systems. In a large-scale controlled experiment with student participants as proxy for data practitioners, we compare the two options with respect to speed and correctness of reading and writing code. The results show that, when reading code, participants make less mistakes using spreadsheet-style syntax. Additionally, when writing code, they make fewer mistakes and are faster when using spreadsheet syntax compared to numeric syntax. From this, a domain-specific syntax, such as spreadsheet syntax for data engineering, appears to be a promising alternative to explore in future tools to support practitioners without a software engineering background.

Figures

Figures reproduced from arXiv: 2505.23296 by the authors.

**Figure 2.** Program comprehension task in the experiment tool. [PITH_FULL_IMAGE:figures/full_fig_p009_2.png] view at source ↗

**Figure 3.** Kernel density plot for the results of H1a, time, program comprehension [PITH_FULL_IMAGE:figures/full_fig_p011_3.png] view at source ↗

Figures from the paper (3 more)

**Figure 4.** Figure 4: Kernel density plot for the results of H1b, correctness, program comprehension 5 Discussion In this chapter, we move beyond the quantitative results and discuss potential reasons for the effects that were measured in the experiment. Our goal is to provide additional in…

**Figure 5.** Figure 5: Kernel density plot for the results of H2a, time, code creation 5.2 On Code Creation When participants had to write code, they could complete the tasks in less time and with higher correctness when using the spreadsheet-style syntax compared to the numeric syntax. A fa…

**Figure 6.** Figure 6: Kernel density plot for the results of H2b, correctness, code creation 5.3 Potential Reasons for Improved Correctness A potential factor for improved correctness, both when reading code and when writing it, is the fact that spreadsheet syntax uses two different numberi…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

26 extracted references · 26 canonical work pages

[1]

The TAME project: towards improvement-oriented software environments

V R Basili and H D Rombach. The TAME project: towards improvement-oriented software environments. IEEE Transactions on Software Engineering, 14(6):758–773, June 1988

work page 1988
[2]

Benefits and barriers of user evaluation in software engineering research

Raymond P L Buse, Caitlin Sadowski, and Westley Weimer. Benefits and barriers of user evaluation in software engineering research. In Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications , New York, NY , USA, October 2011. ACM

work page 2011
[3]

Empirical software engineering experts on the use of students and professionals in experiments.Empirical Software Engineering, 23(1):452–489, February 2018

Davide Falessi, Natalia Juristo, Claes Wohlin, Burak Turhan, Jürgen Münch, Andreas Jedlitschka, and Markku Oivo. Empirical software engineering experts on the use of students and professionals in experiments.Empirical Software Engineering, 23(1):452–489, February 2018

work page 2018
[4]

A systematic analysis of problems in open collaborative data engineering.Trans

Philip Heltweg and Dirk Riehle. A systematic analysis of problems in open collaborative data engineering.Trans. Soc. Comput., 6(3-4):1–30, December 2023

work page 2023
[5]

An empirical study on the effects of jayvee, a domain-specific language for data engineering, on understanding data pipeline architectures

Philip Heltweg, Georg-Daniel Schwarz, Riehle Dirk, and Quast Felix. An empirical study on the effects of jayvee, a domain-specific language for data engineering, on understanding data pipeline architectures. Software: Practice & Experience, 2025

work page 2025
[6]

Comparing three notations for defining scenario-based model tests: A controlled experiment

Bernhard Hoisl, Stefan Sobernig, and Mark Strembeck. Comparing three notations for defining scenario-based model tests: A controlled experiment. In 2014 9th International Conference on the Quality of Information and Communications Technology, pages 180–189. IEEE, September 2014

work page 2014
[7]

Is business domain language support beneficial for creating test case specifications: A controlled experiment

Florian Häser, Michael Felderer, and Ruth Breu. Is business domain language support beneficial for creating test case specifications: A controlled experiment. Information and software technology, 79:52–62, November 2016

work page 2016
[8]

Étude comparative de la distribution florale dans une portion des alpes et des jura

P Jaccard. Étude comparative de la distribution florale dans une portion des alpes et des jura. Bull Soc V audoise Sci Nat, 37:547–579, 1901

work page 1901

Show all 26 references

[9]

Reporting guidelines for controlled experiments in software engineering

A Jedlitschka and D Pfahl. Reporting guidelines for controlled experiments in software engineering. In 2005 International Symposium on Empirical Software Engineering, 2005. , page 10 pp. Ieee, 2005

2005
[10]

Effectiveness and efficiency of a domain-specific language for high- performance marine ecosystem simulation: a controlled experiment

Arne N Johanson and Wilhelm Hasselbring. Effectiveness and efficiency of a domain-specific language for high- performance marine ecosystem simulation: a controlled experiment. Empirical Software Engineering, 22:2206– 2236, 2017

2017
[11]

The simple difference formula: An approach to teaching nonparametric correlation

Dave S Kerby. The simple difference formula: An approach to teaching nonparametric correlation. Comprehen- sive psychology, 3:11.IT.3.1, January 2014

2014
[12]

Robust statistical methods for empirical software engineering.Empirical Software Engineering, 22(2):579–630, April 2017

Barbara Kitchenham, Lech Madeyski, David Budgen, Jacky Keung, Pearl Brereton, Stuart Charters, Shirley Gibbs, and Amnart Pohthong. Robust statistical methods for empirical software engineering.Empirical Software Engineering, 22(2):579–630, April 2017

2017
[13]

Readability of domain-specific languages: A controlled experiment comparing (declarative) inference rules with (imperative) java source code in programming language design

Kai Klanten, Stefan Hanenberg, Stefan Gries, and V olker Gruhn. Readability of domain-specific languages: A controlled experiment comparing (declarative) inference rules with (imperative) java source code in programming language design. In Proceedings of the 19th International...

2024
[14]

A practical guide to controlled experiments of software engineering tools with human participants

Amy J Ko, Thomas D LaToza, and Margaret M Burnett. A practical guide to controlled experiments of software engineering tools with human participants. Empirical Software Engineering, 20(1):110–141, February 2015

2015
[15]

Comparing general-purpose domain specific languages: empirical study

T Kosar, N Oliveira, M Mernik, M João, M Pereira, M Repinåek, D Cruz, and P Rangel Henriques. Comparing general-purpose domain specific languages: empirical study. Computer Science Information Systems , 2010

2010
[16]

Program comprehension of domain-specific and general-purpose languages: replication of a family of experiments using integrated development environ- ments

Tomaž Kosar, Sašo Gaberc, Jeffrey C Carver, and Marjan Mernik. Program comprehension of domain-specific and general-purpose languages: replication of a family of experiments using integrated development environ- ments. Empirical Software Engineering, 23(5):2734–2763, October 2...

2018
[17]

Program comprehension of domain-specific and general- purpose languages: comparison using a family of experiments

Tomaž Kosar, Marjan Mernik, and Jeffrey C Carver. Program comprehension of domain-specific and general- purpose languages: comparison using a family of experiments. Empirical software engineering , 17:276–304, 2012

2012
[18]

A common language effect size statistic.Psychological bulletin, 111(2):361– 365, March 1992

Kenneth O McGraw and S P Wong. A common language effect size statistic.Psychological bulletin, 111(2):361– 365, March 1992

1992
[19]

An analysis of variance test for normality (complete samples)

S S Shapiro and M B Wilk. An analysis of variance test for normality (complete samples). Biometrika, 52(3/4):591–611, 1965

1965
[20]

Hints for reviewing empirical work in software engineering

W F Tichy. Hints for reviewing empirical work in software engineering. Empirical Software Engineering , 5(4):309–312, 2000

2000
[21]

Pingouin: statistics in python

Raphael Vallat. Pingouin: statistics in python. The Journal of Open Source Software , 3(31):1026, November 2018

2018
[22]

A critique and improvement of the CL common language effect size statis- tics of McGraw and wong

András Vargha and Harold D Delaney. A critique and improvement of the CL common language effect size statis- tics of McGraw and wong. Journal of educational and behavioral statistics: a quarterly publication sponsored by the American Educational Research Association and the Am...

2000
[23]

Crossover designs in software engineering experiments: Benefits and perils

Sira Vegas, Cecilia Apa, and Natalia Juristo. Crossover designs in software engineering experiments: Benefits and perils. IEEE Transactions on Software Engineering, 42(2):120–135, February 2016

2016
[24]

Individual comparisons by ranking methods

Frank Wilcoxon. Individual comparisons by ranking methods. Biometrics bulletin, 1(6):80, December 1945

1945
[25]

Experimen- tation in Software Engineering

Claes Wohlin, Per Runeson, Martin Höst, Magnus C Ohlsson, Björn Regnell, and Anders Wesslén. Experimen- tation in Software Engineering. Springer Science + Business Media, 2012

2012
[26]

40 years of designing code comprehension experiments: A systematic mapping study

Marvin Wyrich, Justus Bogner, and Stefan Wagner. 40 years of designing code comprehension experiments: A systematic mapping study. ACM Comput. Surv., October 2023. 18

2023

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.

[1] [1]

The TAME project: towards improvement-oriented software environments

V R Basili and H D Rombach. The TAME project: towards improvement-oriented software environments. IEEE Transactions on Software Engineering, 14(6):758–773, June 1988

work page 1988

[2] [2]

Benefits and barriers of user evaluation in software engineering research

Raymond P L Buse, Caitlin Sadowski, and Westley Weimer. Benefits and barriers of user evaluation in software engineering research. In Proceedings of the 2011 ACM international conference on Object oriented programming systems languages and applications , New York, NY , USA, October 2011. ACM

work page 2011

[3] [3]

Empirical software engineering experts on the use of students and professionals in experiments.Empirical Software Engineering, 23(1):452–489, February 2018

Davide Falessi, Natalia Juristo, Claes Wohlin, Burak Turhan, Jürgen Münch, Andreas Jedlitschka, and Markku Oivo. Empirical software engineering experts on the use of students and professionals in experiments.Empirical Software Engineering, 23(1):452–489, February 2018

work page 2018

[4] [4]

A systematic analysis of problems in open collaborative data engineering.Trans

Philip Heltweg and Dirk Riehle. A systematic analysis of problems in open collaborative data engineering.Trans. Soc. Comput., 6(3-4):1–30, December 2023

work page 2023

[5] [5]

An empirical study on the effects of jayvee, a domain-specific language for data engineering, on understanding data pipeline architectures

Philip Heltweg, Georg-Daniel Schwarz, Riehle Dirk, and Quast Felix. An empirical study on the effects of jayvee, a domain-specific language for data engineering, on understanding data pipeline architectures. Software: Practice & Experience, 2025

work page 2025

[6] [6]

Comparing three notations for defining scenario-based model tests: A controlled experiment

Bernhard Hoisl, Stefan Sobernig, and Mark Strembeck. Comparing three notations for defining scenario-based model tests: A controlled experiment. In 2014 9th International Conference on the Quality of Information and Communications Technology, pages 180–189. IEEE, September 2014

work page 2014

[7] [7]

Is business domain language support beneficial for creating test case specifications: A controlled experiment

Florian Häser, Michael Felderer, and Ruth Breu. Is business domain language support beneficial for creating test case specifications: A controlled experiment. Information and software technology, 79:52–62, November 2016

work page 2016

[8] [8]

Étude comparative de la distribution florale dans une portion des alpes et des jura

P Jaccard. Étude comparative de la distribution florale dans une portion des alpes et des jura. Bull Soc V audoise Sci Nat, 37:547–579, 1901

work page 1901