Organizational Patterns between Developers and Testers

Investigating Testers’ Autonomy and Role Identity

Michal Doležel

and Michael Felderer

2,3

Department of Information Technologies, University of Economics, Prague, Czech Republic

Institute of Computer Science, University of Innsbruck, Innsbruck, Austria

Department of Software Engineering, Blekinge Institute of Technology, Karlskrona, Sweden

Keywords: Software Testing, Agile Testing, Conflict, Profession, Role Identity, Social Identity Theory, Organizational

Structure, Combined Software Engineering, Software Engineering Management.

Abstract: This paper deals with organizational patterns (configurations, set-ups) between developers/programmers and

testers. We firstly discuss the key differences between these two Information Systems Development (ISD)

occupations. Highlighting the origin of inevitable disagreements between them, we reflect on the nature of

the software testing field that currently undergoes an essential change under the increasing influence of agile

ISD approaches and methods. We also deal with the ongoing professionalization of software testing. More

specifically, we propose that the concept of role identity anchored in (social) identity theory can be applied to

the profession of software testers, and their activities studied accordingly. Furthermore, we conceptualize

three organizational patterns (i.e. isolated testers, embedded testers, and eradicated testers) based on our

selective literature review of research and practice sources in Information Systems (IS) and Software

Engineering (SE) disciplines. After summarizing the key industrial challenges of these patterns, we conclude

the paper by calling for more research evidence that would demonstrate the viability of the recently introduced

novel organizational models. We also argue that especially the organizational model of “combined software

engineering”, where the roles of programmers and testers are reunited into a single role of “software

engineer”, deserves a closer attention of IS and SE researchers in the future.

1 INTRODUCTION

Information Systems Development (ISD) is a team

activity. Not even mentioning varying needs and

demanding expectations of future IS users, the nature

of the interplay among programmers, testers,

analysts, and other functional roles involved in the

execution of ISD activities influences outcomes of

ISD projects to a great extent (Walz et al., 1993).

Agile ISD is seen as an important step towards

improving this interplay by promoting values of

flexibility, cooperation, learning, and leanness

(Conboy, 2009). Compared to traditional (i.e.

sequential or phase-oriented) ISD methodologies, the

Agile ISD philosophy brings two principal changes

regarding the “human element” in ISD.

First, it assumes a less fragmented and little

formalized distribution of responsibilities across

different functional roles active in ISD, including

software testers (Cohn, 2010). Second, it puts forward

the view that software development is a complex

socio-technical process understandable through

studying people and their interactions (Balijepally et

al., 2006). These two changes motivate our paper.

Though systems/software testing is a vital part of

ISD activities, it has received scant attention in

previous Information Systems (IS) research (Hassan

and Mathiassen, 2018). Similarly, Software

Engineering (SE) research has focused on technical

challenges of software testing, and remains mostly

silent on the management ones (Garousi and Felderer,

2017). In particular, there is very little work available

that discusses the evolving role of testers in agile

teams from an organizational point of view based on

social science theories. This perspective is what we

aim for, but the present paper is just a first step in this

direction.

This paper concentrates on software testing

personnel (testers, test engineers, test analysts etc.)

and the changing nature of their role at present day.

Due to space constraints, however, we do not further

expand on how various sub-professions in software

336

Doležel, M. and Felderer, M.

Organizational Patterns between Developers and Testers.

DOI: 10.5220/0006783703360344

In Proceedings of the 20th International Conference on Enterprise Information Systems (ICEIS 2018), pages 336-344

ISBN: 978-989-758-298-1

testing (e.g., test managers) are exactly impacted. We

take a simplistic view that software tester or test

engineer has been the one who carries out the

majority of testing work in ISD.

Our aim here is to review relevant Information

Systems (IS) and Software Engineering (SE)

literature, identify gaps in it, and prepare the grounds

for presentation and interpretation of our results based

on an ongoing research project. In so doing, this paper

investigates the interconnected problems of testers’

role identity and organizational independence in ISD

activities. To understand the problem comprehensi-

vely, we use also literature from Management and

Organization Studies (MOS).

This paper proceeds as follows. Section 2 lays

conceptual foundations. Section 3 presents an over-

view of the organizational patterns suggested by us as

distinct. Section 4 indicates the further direction of

our research. Finally, Section 5 concludes the paper.

2 CONCEPTUAL BACKGROUND

The points of departure of our paper are discussed in

this section. Section 2.1 briefly highlights certain core

features of Agile ISD approaches. Section 2.2

discusses differences between programmers and

testers. Section 2.3 conceptualizes the problem of

testers’ independence. Finally, Section 2.4 concludes

by presenting some thoughts on the profession of

software testers.

2.1 Agile ISD

The popularity of agile IS development methods

(Agile) has been steadily growing over the last decade

(Conboy, 2009). More specifically, aside from small

teams and start-up businesses, Agile gradually

penetrates also traditional enterprises. In some

organizations, the observed growth of Agile

development initiatives can be, at least partly,

attributed to the general popularity of the concept.

Managers and executives have been always paying

attention to emerging management trends, and Agile

ISD approaches may be seen as one among their

present day favourites (Cram and Newell, 2016).

Cautiously stated, true efforts to introduce a

revolutionary, people-centric management

philosophy into the world of corporate organizing

may drive the remaining efforts (Laloux, 2014).

Considering the nature of the shift from

traditional to Agile ISD methods, it is essential to

recognize that agile software development consists of

socio-technical activities. This understanding

contrasts with the predominantly technical,

mechanistic understanding of software processes at

earlier times (Balijepally et al., 2006), even though

the socio-technical nature of software processes

obviously did not emerge over-night (Fuggetta and

Nitto, 2014). Indeed, ISD personnel is in the centre of

research on ISD and software processes nowadays.

Another important change introduced by Agile

directly influences the terminology adopted in this

paper: Instead of the previously common term

“developer”, we use a less-frequent term

“programmer” to avoid confusion with the Agile

terminology. Specifically, the concept of cross-

functional development team promoted by Agile has

a significant organizational impact: “the

[development] team needs to include everyone [e.g.,

programmers, testers, analysts, and business

representatives] necessary to go from idea to

implementation” (Cohn, 2010, p. 152).

2.2 Two Different Software Species

The mind-set of programmers and testers is

considered as different (Pettichord, 2000). A tester is

the one who empirically proves the system under test

to investigate whether the system is able to stand its

future operational mission. Examining system’s

behaviour, he or she is driven by the ideal of

protecting future end users and mitigation as many

risks as possible. By breaking the system, the tester

pursues to improve it.

By contrast, programmers are the builders.

“[F]lexing their intellectual muscles” (Cohen et al.,

2004, p. 78), they may look for creative, technically-

sound solutions irrespectively of potential negative

implications for end-users. Differently put, while

many programmers quite narrowly focus on technical

aspects of ISD by prioritizing solution efficiency in

technical terms, testers look primarily for solution

effectiveness and fit-for-future-use. These

differences are summarized in Table 1. Naturally, this

table presents a sort of black/white, simplistic

perspective.

Table 1: Characteristic differences between programmers

and testers. Adapted from Zhang et al (2018).

Dimension Programmers Testers

Work mindset Build Break

Key value

Technical

excellence

Customer

advocacy

Thinking focus Theory Practice

Project goal Efficiency Effectiveness

Job knowledge Depth Breadth

Organizational Patterns between Developers and Testers

337

It should come as no surprise that this dichotomy

frequently results in conflicts between the two groups.

Importantly, previous research indicates that this

conflict is inherent to software development activities

(Cohen et al., 2004). In principle, there are many

sources of the conflict. From their rich research data,

Zhang et al. (2014) identified five major categories,

focusing on three common elements: process, people,

and communication. Conflict management strategies

differ accordingly (Cohen et al., 2004).

However, our knowledge that the conflict is

inevitable little helps with avoiding organizational

misalignments between programmers and testers in

real organizations (Onita and Dhaliwal, 2011). This

also brings us to the point that the observed conflict

has not been comprehensively studied in traditional

ISD approaches with respect to the V-model. This

ISD concept (Boehm, 1984) portrays segmented test

levels (i.e., unit, integration, system, and user

acceptance), and assumes different expectations and

testing tasks distribution at each of the levels. But

most importantly, the V-model indicates that there

will be a specific dynamics between programmers

and testers at each of the levels.

Another walkable approach might be to radically

change the rules of the ISD game. Going this route,

Agile practitioners argue that Agile ISD methods help

to reduce the tensions between programmers and

testers by redefining the role of testers (Cohn, 2010).

Aside from other factors, this redefinition is

associated with the elimination of testers’

independence from programmers. Yet another group

of Agile practitioners calls for removing testers from

ISD processes entirely (Anderson, 2003). In general,

Agile ISD does not conceptualize software testing

using the V-model, because all necessary test

activities must be executed iteratively (Cohn, 2010).

We discuss the mentioned organizational

strategies in Section 3. Prior doing so, we explain the

historical role of testers’ independence in ISD, and

the ongoing professionalization of software testing.

2.3 The Cost of Testers’ Independence

In general, testers’ independence is codified by

various practitioner sources by postulating a

“common wisdom” that

A certain degree of independence (avoiding the

author bias) often makes the tester more effective

at finding defects and failures.

(ISTQB, 2011, p. 18)

The above thesis says that to prevent the

“contamination” of their perspective, testers need to

enjoy a certain level of organizational autonomy.

Two examples follow. A high level of independence

is when testers work in isolation and use formal ISD

documentation as the primary source of information

about tested applications. In theory, the testers should

be better prepared to discover programmers’ lapses.

In practice, they may find themselves isolated and

disconnected from project activities. In addition, such

organizational set-up may strengthen adversarial

relationships between programmers and testers

(Grechanik et al., 2010).

An extreme case of testers’ independence

typically occurs when contractual relationships are

involved. First and foremost, an external test factory

run by a third party may be contracted (Andrade et al.,

2017). Second, as a tool of vendor management, a

special client unit might be designated to perform

quality verification of vendor’s IS development and

testing activities. In such case, another psychological

factor may drive vendor personnel’s behaviour. That

is the angst of defects that escaped detection at vendor

premises (Shah and Harrold, 2013).

Despite the fact that some organizations decided

against the organizational set-up with a high level of

independence for testers, practitioner literature

frequently promotes it (McKay, 2007). In addition,

the existence of an independent testing unit in

organizations was previously institutionalized as an

important criteria of test maturity; for example, it is

suggested by a popular test management guideline

(TMMi Foundation, 2012).

2.4 The Profession of Software Tester

In a broad sense, professions are vocations that carry

out professional activities in a given area of practice

(Hughes, 1958). The execution of professional

activities might be conditioned by a previous formal

training, length of practice, or entirely open to a

loosely defined group of people who claim to belong

among the professionals. The former two criteria

apply, for example, to medical professions, whereas

the latter one to software programmers and testers.

Aside from formal regulations that might be in place,

many professions informally or semi-formally (e.g.,

through optional certifications) postulate certain

behavioural norms that are then expected to be

followed by the profession’s members.

Using the language of social sciences, this process

is related to the social construction of “self-identity”

of professions. Through the formation of shared

meanings, members of a profession gradually reach

consensus what the professional norms are. In the

following, we use the term “professional identity” to

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

338

label distinct “goals, values, beliefs, norms, [and]

interaction styles” (Ashfort, 2001, p. 6) settled in a

profession. In young fields like software

development, the above formative processes are

naturally different from the processes in well-

established, formally regulated professions like law

or medicine (Evetts, 2014).

For a number of years, testers were socialized in

ISD environments where they were to become quality

advocates (a rather soft version of the metaphor),

quality gatekeepers (a mild version of the metaphor),

or quality police/enforcers (an extreme version of the

metaphor) (Charrett, 2012). Not long ago, managers of

testing teams were instructed to build their unit as “The

Perfect Beast” (McKay, 2007 n.p.), by metaphorically

combining qualities of several animal predators to fight

with software bugs (and possibly also with

programmers). And Software Quality Assurance

departments seen as quality watchdogs were

encouraged to “bite if necessary” (Chemuturi, 2011, p.

65). Interestingly, people from industry routinely (but

incorrectly) mix the role of software quality assurance

and the one of software testing (Koch, 2000).

Often mentioned during trainings, conferences, or

in books, all these metaphors and labels may be seen

as part of testers’ professional identity built through

the past decades. The metaphors also somehow relate

to the level of testers’ independence and their main

mission as explicitly formulated or tacitly expected

by an organization. Sadly enough, little guidance

grounded in empirical research is available to the

practitioners who struggle with whether one of the

mentioned modes is fit-for-purpose in their company.

Differently put, the role models that describe

expected or ideal professional behaviour in software

testing are often anecdotal, based on the personal

experience of trainers, mentors, or various testing

school gurus. And as a profession, software testing

heavily relies on personal experience, which is not

always shared with a wider community (Beer and

Ramler, 2008).

3 TYPICAL ORGANIZATIONAL

CONFIGURATIONS

In this section, we review three typical organizational

patterns that can be encountered in software

companies and IT units/divisions nowadays.

Organizational configuration implemented in a

particular company results from perceptions held by

the company regarding the role of software testers in

the company’s ISD processes (Charrett, 2012). Note

that we do not discuss various sourcing options (e.g.,

offshore, onshore, nearshore), but we focus on

programmers and testers in the sense of their

standings and organizational relationships.

3.1 Traditional Testing: Testers as

Gatekeepers

3.1.1 Grounding

Originating in a late-1970s vision of Barry Boehm

(1979), software testing has been traditionally

perceived as a distinct, separate ISD phase. The

concept of separate test levels with dedicated testing

responsibilities codified by the V-model (i.e., unit,

integration, system and user acceptance test levels)

has been traditionally presented as a form of test

maturity ideal. According the V-model, somewhat

exaggeratedly put, the more test levels exist in the

organization and the higher number of diverse groups

involved in software testing, the more mature test

process the organization exercises.

3.1.2 Key Industrial Challenges

Though the dilemma “What level of independence

should testers enjoy?” is one among “test management

classics” for ISD managers, little research effort has

been devoted to explore it scholarly so far (Garousi and

Mäntylä, 2016; Sunyaev and Basten, 2015). Not

surprisingly, the extreme cases when testers and

programmers are geographically separated with no

mechanisms to facilitate effective communication

between them are typically found dysfunctional

(Grechanik et al., 2010). However, quite little is known

about the real effects of having testers reporting back

to a manager who supervises both programmers and

testers in a co-located environment. This single-point-

of-responsibility configuration is established in many

companies and supported by the way how a typical ISD

project is managed (Atkinson, 1999). Though the

problem of conflicting goals of the project manager or

development manager is quite evident, there is no

simple remedy.

This case is represented by the full independence

scenario (Figure 1, type A). Importantly, the character

of the metaphorical wall (“Who reports to whom?”)

and its “permeability” (“How testers interact with

programmers?”) should be of interest to further

research efforts exploring this area. Similarly, the

conflicting goals dilemma should be explored from

the viewpoint of software testers and their everyday

activities.

Organizational Patterns between Developers and Testers

339

Programmers

Testers

Programmers Testers

Software

Engineers

Type A: Separate

functional teams

Type B: Single

development team with

embedded testers

Type C: Team with

eradicated functional

specializations

“ISOLATED TESTERS”

“EMBEDDED TESTERS”

“ERADICATED TESTERS”

Figure 1: Typical organizational patterns between programmers and testers.

3.2 Agile Testing: Removing the Wall

3.2.1 Grounding

To solve the challenge of conflicting ISD priorities,

Agile ISD approaches understand software testing as

part of whole-team responsibility (Cohn, 2010;

Crispin and Gregory, 2009). SCRUM, a well-known

agile framework, explicitly states that testers are

integral part of the development team. In other words,

testers are “embedded” into the development team,

and their responsibilities overlap with programmers

to some extent (Figure 1, type B). Blending the

responsibilities of programmers, testers, and analysts

by creating a “cross-functional team”, SCRUM aims

to remove unnecessary organizational boundaries.

Scrum recognizes no sub-teams in the

Development Team, regardless of particular

domains that need to be addressed like testing or

business analysis; there are no exceptions to this

rule; ...

(Scrum.org, n.d.)

In theory, the inherent conflict between

programmers and testers should be solved. In

practice, research shows that some testers still report

problematic relationships with programmers (see

below). This could be partly attributed to the fact that

there is no single way of “doing Agile ISD”; the same

label “Agile” may represent quite diverse ISD

strategies in reality. Aside from pure Agile ISD

approaches, many companies follow the way of

tailoring or even dabbling the original Agile ISD

philosophy (Cram and Newell, 2016). The latter two

approaches indicate that in present days some

companies tend to hybridize software processes rather

than fundamentally transform their nature

(Kuhrmann et al., 2017).

3.2.2 Key Industrial Challenges

Practitioner literature suggests that moving from

waterfall to agile environment may be a challenging

task for testers (Crispin and Gregory, 2009). The

main reason behind this challenge is the nature of

expected change in testers’ mind-set towards frequent

direct communication and participative behaviours

(Cohn, 2010).

The fact that transitioning to Agile does not assure

happiness of testers was explicated by Deak et al.

(2016). From their work, however, it is not entirely

clear why “more agile [than waterfall] testers were

unhappy about their relationship with the

developers”. Their research indicates that “removing

the wall” might be not enough if subsequent coaching

strategies for both programmers and testers are not

implemented in order to increase “group maturity” of

the ISD team (Gren et al., 2017).

Based on these challenges, the essence of future

research efforts could lay in (i) understanding

effective coaching mechanisms to help programmers

and testers transitioning from waterfall to agile, and

(ii) the creation of guidelines to help these groups

working in hybrid environments where not all agile

principles are applicable in a pure form.

3.3 Combined Software Engineering:

Eradication of Testers

3.3.1 Grounding

“Combined software engineering” is a term

popularized by Microsoft (Dobrigkeit et al., 2016).

The notion implies that there had been traditionally at

least two broad functional responsibilities and career

paths in ISD: programming and testing. (In this

discussion, for the sake of simplicity, we ignore

distinct career paths of software architects/analysts

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

340

and development managers.) They may had been

given titles such as “Software (Development)

Engineer” and “Software (Development) Engineer in

Test” (Page et al., 2009) . Note that Google, among

others, is known to differentiate between “Software

Engineers in Test” and “Test Engineers” more

precisely (see Whittaker et al., 2012).

The original organizational situation of having

some dedicated testing roles clearly differs from

having no testers at all historically. The latter may be

typical in smaller or “less mature” – according the

traditional worldview – companies (Prechelt, 2016).

Speaking about the former, some companies recently

introduced certain organizational changes in order to

stop differentiating between their programmers and

testers in terms of their professional status. Simply

put, these companies have combined the two

previously independent ISD functions (Figure 1, type

C). These organizational changes are implemented

consistently with the companies’ hiring, firing, and

compensation & benefits policies. Recently the expert

public paid quite a lot of attention to the case of

Microsoft in which testers played an important role

(Thonangi, 2014).

3.3.2 Key Industrial Challenges

The idea of “combined software engineering” is quite

new and unproven. Though there are some interesting

blog posts (e.g. Jensen, 2016), there is not a lot of

information in printed literature to date. We see two

important goals on which further research should

concentrate: (i) to understand organizational enablers

of combined software engineering models, and (ii) to

help organizations with solving possible side effects

and people problems in the area of motivation when

such a model is introduced to the organization. In our

opinion, the first area can be elegantly studied using

cultural lens in order to understand nuances of

organizational life culturally (Smircich, 1983). The

latter one calls for more research on the motivation of

programming and testing specialists under the

mentioned organizational conditions (Beecham et al.,

2008; Deak et al., 2016).

4 RESEARCH DIRECTION AND

DISCUSSION

In this section, we briefly explain our open-ended

research idea. Our overall goal is to understand which

of the configurations explained above real

organizations use, and what the reasons behind their

decisions are. By exploring this problem, we hope to

provide a conceptual guideline to organizations

transitioning from traditional ISD approaches to

Agile ISD. Specifically, we believe that this

endeavour might help practitioners with forming and

managing cross-functional agile teams in enterprise

environment. Similarly, the new theory we aim to

develop will hopefully contribute to a better

theoretical understanding of this area. Overall,

regarding the theorizing which follows, we are

roughly guided by data from our ongoing research

projects.

It is our argument that the body of knowledge on

role identity (RI) accumulated in MOS can help with

further directing our research. The RI work is

informed predominantly by concepts originating in

social psychology and microsociology (or

sociological social psychology), in particular by

Social Identity Theory (SIT, see Tajfel and Turner,

1986) and Identity Theory (IDT, see Stryker and

Burke, 2000) respectively.

Role identities [or role-based identities] are

socially constructed definitions of self-in-role

(this is who a role occupant is). Role identities

anchor or ground self-conceptions in social

domains. To switch roles is to switch social

identities.

(Ashfort, 2001, p. 27)

A specific type of role identity is professional role

identity (or simply professional identity), which is the

term we have introduced in Section 2.4 without

providing much theoretical background. Differently

from personal identity, social, role, and professional

identities are based on group membership. With

regards to the problem studied by the present paper, it

is important to understand the concept of group very

broadly. In our case, the first group (a macro group)

might be that of the professional community of

software testers (where exists and its influence is

salient). The second group (a micro group) is that of

a particular ISD team where the tester works. An

additional group membership (a meso group) may be

introduced when the company centralizes software

testing activities under one tent of enterprise test

organization or test centre. These centralized entities

can form an additional organizational layer across the

existing landscape of ISD teams that have been

previously constituted in the company (Doležel,

2017). And naturally, these two or three social group

memberships can collide.

We thus propose that one needs to understand not

only the micro organizational context, but also more

abstract, high-level layers that contribute to forming

of the professional identity (i.e. the meso and macro

Organizational Patterns between Developers and Testers

341

levels). In this sense, one needs to identify the

influence of “institutional forces” (a term borrowed

from sociology). This need stems from the fact that

“professionals act as bridges between the institutional

forces of their professions and their respective

organizations” (Daudigeos, 2013, p. 725).

Our key thesis is thus provocative. We argue that

the macro social forces that drive the ongoing

professionalization of software testers may

significantly conflict with the core Agile principles

implemented in a purist (i.e. crusader) way at the

micro level. Crusader organizations are “employing

a highly prescriptive adoption of agile techniques,

alongside an avoidance of traditional approaches

entirely” (Cram and Newell, 2016, p. 9). By contrast,

dedicated software testers typically work in

traditional, larger, and “more mature” organizations.

When such a traditional organization wants to

suddenly become a crusader, software testers as a

profession may feel jeopardized by the ideas

presented by the Agile community, and react

defensively. An excellent example supporting our

view is presented by Larman and Vodde (2010) in

their book. Book sections titled “Avoid… Test

department”, “Avoid… TMM, TPI, and other [test]

‘maturity’ models”, and “Avoid… ISTQB and other

tester certification” (!) speak for themselves. It seems

not exaggerated to expect that if their advices are

followed by ISD managers literally, the relevant

organizational changes must result in a professional

identity crisis of software testers working for those

managers. Everything the testers learned in the past

is gone, and the world is not the same as it was. A

piece of anecdotal evidence describing testers’

reactions during a training run by Larman and Vodde

is presented in the same source.

Inversely, people in crusader organizations

typically believe that Agile is “a better, more rational

approach compared to traditional methods” (Cram

and Newell, 2016, p. 6). In other words, relevant

socio-psychological forces are aligned with the

organizational culture of such companies and people

happily work there while adoring the mentioned

principles of agility. As indicated above, this

balanced, positive state may significantly differ from

a situation, when an organization had institutionalized

different working patterns and interaction styles in the

past years, and suddenly decided to change them

overnight. In such cases, the psychological safety of

members of certain professional groups may be

significantly harmed. The previous work patterns and

interaction styles are suddenly out-dated, and the new

ones still to be created. More importantly, unless the

impacted groups feel safe and comfortable with the

new reality, the implemented change won’t be

successful (Burnes, 2004).

Though the above ideas are mostly speculative,

we present them in this paper because we believe that

they are quite important and promising for ISD

practice. It is also our hope that they may guide

further theory building efforts carried out by both IS

and SE researchers. Interestingly, though similar

interests were originally inherent mostly to research

in the sociology of professions, it is argued that this

discipline gradually “came to an intellectual

standstill” (Gorman and Sandefur, 2011, p. 290).

Instead of occupational sociologists, increasingly

often scholars who educate knowledge workers

dominate the field research on “their” professions,

focusing on everyday activities of “their”

professionals (ibid.).

5 CONCLUSION

This paper has discussed the topic of organizational

patterns between programmers and testers, and how

these patterns evolve in Agile ISD. Drawing on the

problem of testers’ independence (Sunyaev and

Basten, 2015), and extending the problem to the Agile

world, the paper has summarized existing knowledge

and indicated the further research direction. We have

taken a critical stance to pinpoint some problems we

see when “Agile ideals” are blindly followed and

used as a rhetorical tool and salvation device (Case,

1999).

Our position articulated in this paper is that the

previous IS and SE research indicates that

programmers and testers form distinct groups with

distinct social and professional identities. These

groups execute their work activities in a different

manner. We support the view that agile ISD must be

philosophically based on a new set of fundamental

principles (Cohn, 2010). However, based only on

anecdotal evidence, we remain undecided whether

transformation to a “combined software engineering”

model in a traditional company can be successful. If

it can, it will be imperative to understand situational

factors that contribute to this success (Clarke and

O’Connor, 2012).

We indeed agree that ISD teams may function

very well without dedicated testers (Prechelt, 2016).

We, however, cautiously note that before going this

route, a “traditional” company where software testers

are a well-established profession should carefully

analyse the impact of such decision, and propose

sound risk mitigating strategies. The history teaches

us that simply jumping on the bandwagon of the latest

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

342

management fad hardly ever paves the way towards

the success of the intended change (Case, 1999).

We are eager to hear about further independent

research efforts that probe into organizations who

deployed such models. We propose that success or

failure of the change initiative should be understood

in terms of the following criteria (though not

necessarily all adopted in a single case study): (i)

objective, measurable quality metrics demonstrate

that software quality is not degraded under the new

conditions; (ii) fulfilling all tasks of the former ISD

actors, new ISD teams have a high level of group

maturity (Gren et al., 2017); (iii) previous

programming and testing personnel is still motivated

and happily working in the new setting (Deak et al.,

2016), proud of their newly acquired identity. Based

on anecdotal evidence and our own work-in-progress

research data, we are concerned about, especially

with regards to the last criteria. We have noticed that

effects on the morale and motivation of both the

unique software species seem to devastating when the

changes are introduced insensitively, and people do

not understand reasons behind them (see also Jensen,

2016).

Our research continues to concentrate mostly on

the standing of testers in hybridized ISD settings

(Cram and Newell, 2016; Kuhrmann et al., 2017). We

work on an empirical study that uses the lens of SIT

and IDT to understand the challenges introduced by

blending the roles and responsibilities of

programmers and testers in agile ISD processes. In

parallel, we also explore the growing influence of

DevOps on software testing concepts, as exemplified

by the concept of “testing in production”.

REFERENCES

Anderson, D. J. (2003), Agile Management for Software

Engineering, Pearson Education, Upper Saddle River,

NJ.

Andrade, R., Santos, I., Lelli, V., Oliveira, K. and Rocha,

A. (2017), “Software Testing Process in a Test Factory:

From Ad hoc Activities to an Organizational Standard”,

International Conference on Enterprise Information

Systems, pp. 132–143.

Ashfort, B. E. (2001), Role Transitions in Organizational

Life: An Identity-Based Perspective, Lawrence

Erlbaum Associates, Inc., Mahwah, NJ.

Atkinson, R. (1999), “Project management: cost, time, and

quality, two best guesses and a phenomenon, it’s time

to accept other success criteria”, International Journal

of Project Management, Vol. 17 No. 6, pp. 337–342.

Balijepally, V., Mahapatra, R. and Nerur, S. (2006),

“Assessing Personality Profiles of Software Developers

in Agile Development”, Communications of the

Association for Information Systems, Vol. 18 No. 1, p.

Article 4.

Beecham, S., Baddoo, N., Hall, T., Robinson, H. and Sharp,

H. (2008), “Motivation in Software Engineering: A

systematic literature review”, Information and Software

Technology, Vol. 50 No. 9–10, pp. 860–878.

Beer, A. and Ramler, R. (2008), “The Role of Experience

in Software Testing Practice”, Software Engineering

and Advanced Applications, pp. 258–265.

Boehm, B. (1984), “Verifying and validating software

requirements and design specifications”, IEEE

Software, Vol. 1 No. 1, pp. 75–88.

Burnes, B. (2004), “Kurt Lewin and the planned approach

to change: A re-appraisal”, Journal of Management

Studies, Vol. 41 No. 6, pp. 977–1002.

Case, P. (1999), “Remember re-engineering? The rhetorical

appeal of a managerial salvation device”, Journal of

Management Studies, Vol. 36 No. 4, pp. 419–441.

Clarke, P. and O’Connor, R. V. (2012), “The situational

factors that affect the software development process:

Towards a comprehensive reference framework”,

Information and Software Technology, Vol. 54 No. 5,

pp. 433–447.

Cohen, C. F., Birkin, S.J., Garfield, M.J. and Webb, H.W.

(2004), “Managing conflict in software testing”,

Communications of the ACM, Vol. 47 No. 1, pp. 76–81.

Cohn, M. (2010), Succeding with Agile, Addison Wesley,

Upper Saddle River, NJ.

Conboy, K. (2009), “Agility from first principles:

Reconstructing the concept of agility in information

systems development”, Information Systems Research,

Vol. 20 No. 3, pp. 329–354.

Cram, W.A. and Newell, S. (2016), “Mindful revolution or

mindless trend? Examining agile development as a

management fashion”, European Journal of

Information Systems, Vol. 25 No. 2, pp. 154–169.

Crispin, L. and Gregory, J. (2009), Agile Testing: A

Practical Guide for Testers and Agile Teams, Addison-

Wesley, Upper Saddle River.

Daudigeos, T. (2013), “In Their profession’s service: How

staff professionals exert influence in their

organization”, Journal of Management Studies, Vol. 50

No. 5, pp. 722–749.

Deak, A., Stålhane, T. and Sindre, G. (2016), “Challenges

and strategies for motivating software testing

personnel”, Information and Software Technology, Vol.

73, pp. 1–15.

Dobrigkeit, F., Meyer, S. and Uflacker, M. (2016), “Case

Studies on End-User Engagement and Prototyping

during Software Development”, Design Thinking

Research: Taking Breakthrough Innovation Home, pp.

183–213.

Doležel, M. (2017), “Images of Enterprise Test

Organizations: Factory, Center of Excellence, or

Community?”, Software Quality Days, Vienna.

Evetts, J. (2014), “The concept of professionalism:

Professional work, professional practice and learning”,

Organizational Patterns between Developers and Testers

343

International Handbook of Research in Professional

and Practice-Based Learning, pp. 29–57.

Fuggetta, A. and Nitto, E. Di. (2014), “Software Process”,

Proceedings of the on Future of Software Engineering,

pp. 1–12.

Garousi, V. and Felderer, M. (2017), “Worlds Apart:

Industrial and Academic Focus Areas in Software

Testing”, IEEE Software, Vol. 34 No. 5, pp. 38–45.

Garousi, V. and Mäntylä, M. V. (2016), “A systematic

literature review of literature reviews in software

testing”, Information and Software Technology, Vol.

80, pp. 1339–1351.

Gorman, E. H. and Sandefur, R. L. (2011), “‘Golden Age,’

Quiescence, and Revival”, Work and Occupations, Vol.

38 No. 3, pp. 275–302.

Grechanik, M., Jones, J. A., Orso, A. and Van Der Hoek, A.

(2010), “Bridging gaps between developers and testers

in globally-distributed software development”, FoSER,

Santa Fe, New Mexico, pp. 149–153.

Gren, L., Torkar, R. and Feldt, R. (2017), “Group

development and group maturity when building agile

teams: A qualitative and quantitative investigation at

eight large companies”, Journal of Systems and

Software, Vol. 124, pp. 104–119.

Hassan, N. R. and Mathiassen, L. (2018), “Distilling a body

of knowledge for information systems development”,

Information Systems Journal, Vol. 28 No. 1, pp. 175–

226.

Hughes, E.C. (1958), Men and Their Work, Free Press,

London.

Charrett, A.-M. (2012), “Appendix D: Cost of Starting Up

a Test Team”, How to Reduce the Cost of Software

Testing, CRC Press, Boca Raton, FL.

Chemuturi, M. (2011), Mastering Software Quality

Assurance: Best Practices, Tools and Techniques for

Software Developers, J.Ross Publishing, Fort

Lauderdale, FL.

ISTQB. (2011), “ISTQB Foundation Level Syllabus”,

available at: https://www.istqb.org/downloads/.

Jensen, B. (2016), “The Combined Engineering Software

Model”, available at: https://testastic.wordpress.com/

2016/01/03/the-combined-engineering-software-

model/.

Koch, A. S. (2000), “‘A’ is for ‘Assurance’– A Broad View

of SQA”, Pacific Northwest Software Quality

Conference, Portland, OR, pp. 217–236.

Kuhrmann, M., Hanser, E., Prause, C.R., Diebold, P.,

Münch, J., Tell, P., Garousi, V., et al. (2017), “Hybrid

software and system development in practice: waterfall,

scrum, and beyond”, Proceedings of the 2017

International Conference on Software and System

Process, pp. 30–39.

Laloux, F. (2014), Reinventing Organizations: A Guide to

Creating Organizations Inspired by the Next Stage in

Human Consciousness, Nelson Parker, Brussels,

Belgium.

Larman, C. and Vodde, B. (2010), Practices for Scaling

Lean & Agile Development, Addison-Wesley, Upper

Saddle River, NJ.

McKay, J. (2007), Managing the Test People: A Guide to

Practical Technical Management, Rocky Nook, Santa

Barbara, CA.

Onita, C. and Dhaliwal, J. (2011), “Alignment within the

corporate IT unit : an analysis of software testing and

development”, European Journal of Information

Systems, Vol. 20 No. 1, pp. 48–68.

Page, A., Johnston, K. and Rollison, B. (2009), How We

Test Software in Microsoft, Microsoft Press, Redmond,

WA.

Pettichord, B. (2000), “Testers and Developers Think

Differently”, Software Testing and Quality Engineering

Magazine, Vol. Jan/Feb, pp. 42–46.

Prechelt, L. (2016), “Quality Experience : A Grounded

Theory of Successful Agile Projects Without Dedicated

Testers”, International Conference on Software

Engineering.

Scrum.org. (n.d.). “What is a Scrum Development Team?”,

available at: https://www.scrum.org/resources/what-is-

a-scrum-development-team.

Shah, H. and Harrold, M.J. (2013), “Culture and Testing:

What is the Relationship?”, 8th International

Conference on Global Software Engineering, IEEE, pp.

51–60.

Smircich, L. (1983), “Concepts of Culture and

Organizational Analysis”, Administrative Science

Quarterly, Vol. 28 No. 3, p. 339.

Stryker, S. and Burke, P.J. (2000), “The Past, Present, and

Future of an Identity Theory”, Social Psychology

Quarterly (Special Millenium Issue on the State of

Sociological Social Psychology), Vol. 63 No. 4.

Sunyaev, A. and Basten, D. (2015), “Truth and myth of

independent software testing”, Proceedings of the 30th

Annual ACM Symposium on Applied Computing, pp.

1722–1728.

Tajfel, H. and Turner, J.C. (1986), “The Social Identity

Theory of Intergroup Behavior”, Psychology of

Intergroup Relations, Nelson-Hall Publishers, Chicago,

IL, pp. 7–24.

Thonangi, U. (2014), “Why did Microsoft lay off

‘Programmatic testers’?”, available at: https://www.

linkedin.com/pulse/20140806183208-12100070-why-

did-microsoft-lay-off-programmatic-testers/.

TMMi Foundation. (2012), “Test Maturity Model

integration”, Ireland, available at: www.tmmi.org.

Walz, D. B., Elam, J. J. and Curtis, B. (1993), “Inside a

software design team: knowledge acquisition, sharing,

and integration”, Communications of the ACM, Vol. 36

No. 10, pp. 63–77.

Whittaker, J. A., Arbon, J. and Carollo, J. (2012), How

Google Tests Software, Addison-Wesley, Upper Saddle

River, NJ.

Zhang, X. “Paul”, Nickels, D., Poston, R. and Dhaliwal, J.

(2018), “One World, Two Realities: Perception Differen-

ces between Software Developers and Testers”, Journal

of Computer Information Systems, No. in press.

Zhang, X., Stafford, T. F., Dhaliwal, J. S., Gillenson, M. L.

and Moeller, G. (2014), “Sources of conflict between

developers and testers in software development”,

Information and Management, Vol. 51 No. 1,

pp. 13–26.

ICEIS 2018 - 20th International Conference on Enterprise Information Systems

344