Source-linked AI summary
Exploring Emotional Intelligence in Software Testing
Cristina Martinez Montes, Pushpamalar Rajendran, Grace Karuri, Felix Dobslaw
TL;DR
Most prior emotion research in software engineering has focused on developers, while testers deliver judgments about colleagues’ work under changing demands. This study uses interviews and reflexive thematic analysis to examine testers’ accounts of EI, finding themes in stress regulation, team communication, and responses to requirements change.
Problem
Most prior emotion research in software engineering studied developers, while testers’ work involves interpersonal judgments under testing demands.
Source: §6 · p. 17Method
The authors interviewed 16 testers in Sweden working in agile settings and analysed their accounts using reflexive thematic analysis informed by Goleman’s EI framework.
Source: §1 · p. 3, §2.2.1 · p. 5Results
Testers described regulating stress, sustaining trust while communicating critical findings, and responding to requirements changes through narrowed coverage, advocacy, or workarounds.
Source: §7 · p. 25Takeaways & Limitations
The paper recommends training managers and developers in basic EI practices to share responsibility for constructive feedback, trust, and psychological safety.
Source: §6.3 · p. 23EI was not measured with a valid instrument, so the self-reported findings cannot establish EI levels or causal influence on behaviour or software quality.
Source: §6.5 · p. 24
Abstract
from arXiv · showhide
Background: Emotional Intelligence (EI) is the ability to recognise, understand, and manage one's own and others' emotions. Software testers deliver judgements about colleagues' work under deadlines they do not control, and prior work on emotion in software engineering has mostly studied developers. Aims: To explore how software testers describe the part EI plays in their day-to-day work, in communication and conflict within the team, and in responding to requirements volatility. Method: Semi-structured interviews with 16 software testers in Sweden working in teams that use agile practices, across aviation, automotive, healthcare, IT services, administration, banking and pharmaceuticals, analysed with reflexive thematic analysis informed by Goleman's EI framework. Results: Three themes. Testers described regulating stress under deadline pressure and drawing motivation from recognition, clarity and autonomy; managing the daily delivery of critical findings to colleagues so that trust survives; and responding to requirements change with frustration that turned into decisions about what to leave untested, into advocacy for process change, or into workarounds. Read against developer-focused studies, the themes point to features of the testing role: the work product is a criticism of a colleague's work, success is invisible while failure is attributed, and the tester's window shrinks with every upstream delay. Conclusions: For testers, managing emotions is a constant job requirement. The results highlight that the importance of EI increases when the development process lacks an independent testing phase. The findings also inform implications for teams and, ultimately, for organisations and future research.
1 Introduction
Testers work across stakeholder and developer perspectives, amid ambiguous requirements, delivery pressure, and potential conflict. This study examines how emotional intelligence shapes their daily quality work, team communication, and responses to changing requirements.
1 Introduction
- Testers mediate between stakeholders and developers, while differing priorities and ambiguous requirements can produce misunderstandings and conflict.Testing centers on assuring desired behavior while developers implement it.Source: §1 · p. 2
- Requirements volatility and end-to-end testing complexity can trigger anger, anxiety, and fatigue while testers coordinate work under limited time.Tasks include keeping integrated testing information current and coordinating across development teams.Source: §1 · p. 2
- The study asks how EI relates to testers’ work practices, team communication and conflict, and decisions made in response to requirements volatility.It addresses a gap in research on EI’s role in software testing and quality assurance.Source: §1 · pp. 2–3
- The paper reports three themes, compares them with developer-focused emotion research, and discusses implications for testers, team leads, and organisations.It also considers why EI may carry more weight when development lacks a separate testing phase.Source: §1 · p. 3
- The authors interviewed 16 testers in Sweden working in agile settings across seven industries, including both manual testing and test automation.The industries included aviation, automotive, healthcare, IT services, administration, banking, and pharmaceuticals.Source: §1 · p. 3
2 Background
The background situates testing in collaborative, iterative development and introduces emotional intelligence as a workplace-relevant lens. It adopts Goleman’s framework to examine how emotions shape work and interactions.
2.1 Software Testing in Contemporary Development
- Testing is integrated throughout iterative development, and the study uses “agile practices” for short-cycle, cross-functional work regardless of the named process.The focus includes hybrid settings and is not tied to a particular process.Source: §2.1 · p. 4
- Agile testing brings time pressure, limited support, and difficulty establishing testers’ roles, while testers may be held responsible for undetected failures.The paper premises that removing the formal test-phase gate makes testers’ quality influence more relational, increasing the weight of interpersonal competence.Source: §2.1 · p. 4
2.2 Emotional Intelligence
- EI is presented through models that connect emotions with thought, behaviour, and workplace outcomes, and prior studies link it to team performance and conflict resolution.The background also notes findings relating leaders’ EI to team performance and work attitudes.Source: §2.2 · pp. 4–5
2.2.1 Goleman’s Emotional Intelligence Framework.
- The study selects Goleman’s performance-based EI framework because it directly addresses work and organisational effectiveness.Its four domains are self-awareness, self-management, social awareness, and relationship management.Source: §2.2.1 · p. 5
3 Related Work
Prior research connects emotion and EI with software work and team outcomes, but much of the emotion research has studied software engineers without distinguishing role-specific demands. The section also reviews factors relevant to testers’ motivation and stress.
3.1 Emotions and EI in Software Engineering
- Studies of software engineers associate emotional states with productivity and describe EI-related strategies for managing emotions, sustaining productivity, and achieving team goals.The reviewed work does not make much distinction between emotional demands across software roles.Source: §3.1 · p. 6
- Prior research links EI with collaboration, teamwork effectiveness, organisational commitment, stress mitigation, trust, empathy, and conflict resolution.The reviewed studies include software-development settings and broader organisational contexts.Source: §3.1 · pp. 6–7
3.2 Human Factors and EI in Software Testing
- Testers’ motivation and effectiveness relate to organisational, interpersonal, and intrapersonal factors; recognition and challenging work motivate, while limited influence and poor management can demotivate.The paper identifies a lack of in-depth research on EI as experienced by testers and presents its study as addressing that gap.Source: §3.2 · p. 7
4 Methodology
The study uses qualitative interviews and reflexive thematic analysis to examine testers’ accounts, with collaborative interpretation and reflexivity guiding analysis. The authors frame the findings as contextual rather than universal and report their ethical procedures.
4 Methodology
- The exploratory qualitative interview study sought rich accounts of EI in testers’ work within teams using agile practices.Open-ended semi-structured questions allowed follow-up while retaining consistency across participants.Source: §4 · p. 7
4.1 Target Population
- Participants were purposively recruited from agile or hybrid teams, with attention to age, experience, and company type and priority given to varied experience.The researchers invited people in software tester positions and sought a balance across participant characteristics.Source: §4.1 · p. 8
4.2 Interview as Data Collection Tool
- Interviews followed a guide aligned with the research questions, Goleman’s framework, and target emotions, and covered deadlines, changing requirements, and workplace emotions.The in-person interviews were conducted in English, lasted 22–56 minutes, and were recorded and transcribed.Source: §4.2 · p. 8
4.3 Data Analysis
- The researchers used framework-guided reflexive thematic analysis, coding close to participants’ words and developing themes iteratively from codes, memos, and transcripts.Two authors initially coded responses; the team discussed interpretations, refined themes against raw data, and selected illustrative quotations.Source: §4.3 · pp. 8–10
4.4 Rigour and Trustworthiness
- The analysis rejected coding consensus and quantitative intercoder reliability as inconsistent with RTA, while using a changing shared code list as an analytic record.Themes were also recursively reviewed for coherence and distinct boundaries.Source: §4.4 · pp. 10–11
4.4.1 Reflexivity
- The authors’ software-testing experience aided familiarity with participants’ context but risked projecting prior assumptions; reflexive discussion and a critical companion were used to challenge readings.The authors describe the final themes as interpretive constructions shaped by participant accounts, researcher subjectivities, and theoretical frameworks.Source: §4.4.1 · p. 12
4.5 Ethical Considerations
- Participants received an explanation of the study, gave written consent, and were anonymised; no formal ethical review was sought under the stated Swedish legal criteria.Transcripts were stored on a password-protected university server, and participants were not compensated.Source: §4.5 · p. 12
5 Results
Interviews with 16 Swedish testers yielded three themes: day-to-day emotional regulation and motivation, trust-preserving team communication, and responses to requirements volatility. Across them, testers described managing pressure while making decisions about quality, collaboration, and testing coverage.
5 Results
- The interview participants were 16 software testers working in Sweden across industries including aviation, automotive, healthcare, IT services, administration, banking, and pharmaceuticals.Participants worked in either manual testing or test automation.Source: §5 · p. 12
5.1 Insights from Interviews
- Testers described EI in three areas: daily work, communication and conflict, and responses to requirements volatility.The interviews yielded three themes, interpreted as EI in day-to-day practice, social interaction, and requirements-change responses.Source: §5.1 · p. 13, Sub-theme B: Positive drivers · p. 15, §5.1.2 · p. 16
- The three themes and their sub-themes were generated from 146 codes; Themes 2 and 3 were not divided into sub-themes.Source: Table 6 · p. 13
Sub-theme A: Self-regulation under pressure
- Under deadline pressure, testers used breaks, documentation, task sequencing, and objectivity; deadlines affected test quality, and maintaining quality increased workload.Some also chose when to approach colleagues based on their stress levels.Source: Sub-theme A: Self-regulation under… · p. 14
Sub-theme B: Positive drivers
- Clear goals, stable priorities, recognition, and autonomy supported focused testing, ownership, motivation, and persistence despite constraints.Autonomy included trusted latitude to challenge unsafe shortcuts, propose sequencing, or introduce lightweight tools.Source: Sub-theme B: Positive drivers · pp. 14–15
5.1.2 Theme 2: EI for Communication, Collaboration, and Conflict Management
- Testers described delivering critical findings, using documentation and reporting to coordinate work, and drawing on EI to de-escalate conflict and preserve trust.The accounts also show that individual EI has limits in hostile environments, prompting the authors to call for stronger team interactions.Source: §5.1.2 · pp. 15–16
5.1.3 Theme 3: Emotional Responses to Requirements Volatility
- Frustration at changing or unclear requirements narrowed some testing to must-pass cases, while others raised process concerns or used similar systems as workarounds.These responses shaped coverage and the balance between thoroughness and timeliness.Source: §5.1.3 · pp. 16–17
6 Discussion
The discussion interprets three interview themes as role-specific emotional work, from regulating pressure and preserving trust to making testing and process decisions under requirements change. It connects individual practices to team and organisational support while acknowledging limits on what the study establishes.
6 Discussion
- Testers described regulating emotional responses under pressure, using empathy and timing to manage conflict, and turning requirements frustration into adaptive strategies or process advocacy.The authors read these practices through Goleman’s EI domains.Source: §6 · p. 18
6.1 What Testers Add to Existing Accounts of Emotion in Software Engineering
- Testers’ motivation draws on recognition, clear goals, and autonomy, while repeatedly delivering critical findings makes emotional labour part of preserving colleagues’ trust.Unlike developer work, testing success can remain invisible while failure is attributed to the tester.Source: §6 · p. 17, §6.1 · pp. 18–19
- Requirements frustration can narrow coverage to must-pass tests, while testers often lack release authority and face higher emotional stakes in regulated domains.Participants described deferring exploratory work and edge cases when requirements changed late.Source: §6.1 · pp. 19–20
6.2 From Personal Coping to Systemic Capability
- Participants described emotion regulation scaling from individual practices to team trust and coordination, and organisational advocacy, though broader causal generalisation remains unestablished.The authors caution that larger samples are needed before proposing the pattern as a causal model.Source: §6.2 · pp. 20–21
6.3 Implications for Practice
- Practice proposals include recognising testers’ EI, making emotional bottlenecks visible, embedding change and conflict routines, recording deferred tests, and training managers and developers.The recommendations aim to share emotional responsibility rather than leave it with individual testers.Source: §6.3 · pp. 22–23
6.4 Implications for Research
- Future research should test the proposed process and coverage relationship, measure EI and observe responses, and compare testing types and contexts.Suggested approaches include experimental or longitudinal study of test prioritisation, exploratory testing, defect detection, and coverage.Source: §6.4 · pp. 23–24
6.5 Limitations
- Interpretation is bounded by self-selected Swedish interviews, potentially leading prompts, retrospective self-reports without EI measurement, and no analysis contrasting manual with automated testing.The authors do not claim the sample represents Swedish testers or that the findings establish EI levels, influence, or causality.Source: §6.5 · p. 24
7 Conclusion and Future Work
Interviews with 16 testers in Sweden yielded three themes about emotional intelligence in testing, including an emotional path from requirements change to decisions about what remains untested. The conclusion identifies limits the study could not test and questions for further research.
7 Conclusion and Future Work
- Testers linked frustration with requirements change to narrowed test coverage, a decision about what to leave unexamined that the authors consider most directly relevant to software quality.The interview guide raised this topic, and participants confirmed and elaborated on it.Source: §7 · p. 25
- The study could not test whether testers’ influence over quality decisions carries more weight without a separate test phase because it did not compare process models.The authors suggest comparing testers in phased and iterative delivery, or following a team through such a change.Source: §7 · p. 25
- Future work should investigate how often late change narrows coverage, what is dropped, whether making trade-offs explicit changes that, and which themes travel beyond Sweden.The authors also call for contrasting manual and automation testers and studying settings where speaking up carries a higher cost.Source: §7 · p. 25
8 Statements and Declarations
The authors disclose their contributions, funding status, data availability, and competing interests.
8 Statements and Declarations
- CMM, PR, and GK developed the paper’s main idea and concept; CMM, PR, GK, and FD performed formal analysis and investigation.CMM and FD wrote, reviewed, and edited the manuscript.Source: §8 · p. 25
- The authors report that they received no support from any organisation for the submitted work.Source: §8 · p. 25
- The dataset of codes and themes is publicly available on Zenodo, while interview transcripts are withheld to protect participant anonymity and confidentiality.Source: §8 · p. 25
- The authors disclose no relevant financial or non-financial interests.Source: §8 · p. 25