1. The testers evolution to a mobile app tester.
Nowadays mobile apps are part of everyday life. Think a minute, how many apps did you use today? I
guess it's somewhere between 10 and 20 on a daily bases. We use them to keep in touch with our
friends and family, read or watch news,
have insight in our financial situation of
just for fun, shooting little birds around
with big catapults. This is a huge
difference with a few years ago. You
where glad to synchronize your calendar
and email with your mobile device and
that's that.
Within this fast or even extremely fast
changing software development world,
how did we as testers adapt to this? Did
we change just as fast? Have we become a new breed of testers? I think not, because we humans
aren't capable of adjusting to these changes with the same speed. But still, we need to do so,
because mobile apps and there for the testing of mobile apps will become part of our testing
experience.
Let's take a look on how testing and there for the tester evolved over the last 50 years as described in
the concept evolution of software testing using the testing process model proposed by Gelperin and
Hetzel from their study “The Growth of Software Testing” [ Communications of the ACM, Volume 31
Issue 6, June 1988, pp. 687-695]. In their study they speak of 5 phases:
- 1956 The debugging-oriented period
1957 - 1978 The demonstration-oriented period
1979 - 1982 The destruction-oriented period
1983 -1987 The evaluation-oriented period
1988 - The prevention-oriented period.
Each of these periods needed another kind of tester. So let's take a look at the pre historic age of
software testing, the debugging-oriented period.
The tester in the debugging-oriented period
During this period the testing focus was more on hardware
than it was on software, the systems where huge mainframe
systems and testing was more part of programming than
something on its own. Some state that testing was part of the
debugging activities. So what would your skills as a tester be
in this prehistoric age of testing? My guess is that you would
be more a developer/programmer than a tester. And part of
your tasks was to prove that something you build actually did
what you expected to do based on a requirement.
The first one to describe an actual operational test was Turing in his article "Computing Machinery
and Intelligence"[Mind 59, Oct. 1950, pp. 433-460]. The operational test Turing defined
required the behavior of the program and a reference system (a human) to be indistinguishable to an
interrogator (tester). This could be considered the birth of functional testing.

2. The tester in the demonstration-oriented period
The ancient history of testing is the second phase, the demonstration-orientated period. During this
period, the meaning of testing and debugging both included efforts to detect, locate, identify and
correct faults.
The systems or applications that needed to be 'tested' during this period were mainly standalone
applications or 'computer programs' as they were called.
In 1957, Charles Baker pointed out that “program checkout” was seen to have two goals:
“Make sure the program runs” and “Make sure the program solves the problem.” The latter goal was
viewed as the focus of testing, since “make sure” was often translated into the testing goal of
satisfying requirements. During this period
definitions stress the purpose of testing into
demonstrate correctness. And during this
period, where more and complex applications
were build it became clear to business that
testing should be improved. They demanded
better testing.
If we take this in account, we see an evolution
of the tester. No longer a
developer/programmer, but someone who can
read a requirement and derive some sort of
positive test out of it, to proof that the
software works correct. He or she does this
with common sense, but also the first test technique, path coverage, is introduced. After designing
the test, the tester could execute the test and analyze the result. If it failed the tester would point
this out to the programmer and he would resolve this issue, so the tester could test it again.
The tester in the destruction-oriented period
Now we arrive in the middle ages of software testing, the destruction-oriented period. There are
two important things in this period. The First important thing was the difference between testing
and debugging. From now on, testing was the art of finding faults and debugging is locating,
identifying and correcting these faults.
Secondly, this period set a whole new mindset on testing. In Myers 1979 book, The Art of Software
testing, software testing was described as " The process of executing a program with the intent of
finding errors ". He also stated that test cases or tests were of much greater value if an error was
found. In the demonstration-orientated phase, proofing the correctness of software could lead to
selecting test data which had a low probability in causing failures.
If the main goal of software testing is proofing that there is a fault in the software, we will create
different test cases with a higher probability to detect them. There for testing is more successful. This
also led to other test related activities like verification/validation activities, but also to better analysis
and review techniques. Even the first steps were made on describing combined fault detection
approaches.
So the tester now faces new challenges, because he or she has to be trained in reviewing techniques,
know more about verification and validation and learns new analysis techniques. Testing techniques
changed and new design techniques lure on the horizon. The destruction-oriented period tester
becomes more and more a serious player in the field of software development. He develops new
skills and will evolve in to the next phase tester, the evaluation-oriented period tester.

3. The tester in the evaluation-oriented period
This is next phase as described by Gelperin and Hetzel, the evaluation-oriented period or as I refer to
it as the early modern period of software testing. During this period a methodology that integrates
analysis, review, and test activities to provide product evaluation during the software lifecycle, was
described in " Guideline for Lifecycle Validation, Verification, and Testing of Computer Software" by
The Institute for Computer Sciences and Technology of the National Bureau of Standards .
The tester needed to adapt to this guideline,
because the guideline described three sets of
evaluation techniques; the basic, the comprehensive
and the critical.
It also states that; "No single VV&T technique can
guarantee correct, error-free software. However, a
carefully chosen set of techniques for a specific
project can help to ensure the development and
maintenance of quality software for that project".
Now, the tester does not only needs to have
knowledge of different techniques, he also needs to
know how to combine them to suit his needs. The
tester in this period had a focus on software
requirements and design, but relied heavily on
analysis and reviewing techniques.
But still, the tester needed to evolve further, because testing evolved further. This takes us to the
modern age tester in the prevention-oriented period.
The tester in the prevention-oriented period
During this period, different experts have written books on the subject. One of the significant books
was "Software testing techniques"[ Beizer, Second Edition, Van Nostrand Reinhold Company Limited,
1990, ISBN 0-442-20672-0]. Beizer stated that “the act of designing tests is one of the most effective
bug preventers known". This extended the definition of testing with error prevention and
empowered early testing to lower costs [Boehm].
Beizer and Hetzel both contributed ideas that created the mindset that early test design was of great
importance throughout the entire software life cycle. And here is the big difference between the
prevention-oriented period and the evaluation-oriented period. Where the evaluation-oriented
period relied mainly on analysis and reviewing other than testing, the prevention-oriented period
sees test planning, test analysis and test design as a major role.
So the tester becomes more of an all-round test consultant, who has knowledge of planning, analysis,
design, building, executing, maintaining. We define more functions, not only a tester, but test
engineers, test designers, test managers etc. You have specialists in test automation, performance
testing etc. And all of them are highly skilled professionals, not only hard skills but also soft skills. But
is this the last step in the evolution of the tester?

4. Diversity in testers
No it isn't, because during this modern day period, the period where I myself became a tester, the
tester evolved with lightning speed and there is much diversity in testers. The first ever system I
tested was a mainframe system, anyone familiar with the black and green screens? And the test
process was as described above. We planned, designed and executed tests, based on different
analysis, review and test techniques and I called myself a system tester.
Then of course other applications followed . Mostly Win32 based client server applications (ERP,
CRM systems). But what surprised me, I didn't have to adapt my skills as tester, because I could test
these new applications like the way I tested the old ones. But, this did lead to difference in function
descriptions. Some functions demanded that you had knowledge of mainframe or CRM. So within the
function of the tester diversity was created.
And not only different application types, but also test types created diversity in the test landscape.
This accounts for all parts of the V-model. You can be a unit tester, a systems integration tester an
acceptance tester, whatever you want. And all of these testers are in the bases the same, but the
focus is on a different phase in the SDLC.
If you had affinity with automation tools, you
could evolve into a test automation expert. If
you like testing efficiency of systems and
applications, you could evolve into a
performance tester.
What about domain knowledge? This also led
to new types of testers, you could evolve into a
financial tester, who's focus lies on testing
financial systems. Or into a tester for the
energy domain.
And what to think about development
methods, TDD, XP, this creates a whole new
kind of tester. If we look at an 'agile' tester. Is this really a different tester? Ok, we need to learn
some new things, become a team player etc, but it is still a tester.
Development environments led to a diversity. All of a sudden, mankind decided that all applications
and content needed to be on the Internet. Once again new testers were created, so called "Web
testers". They did there testing on different browsers, on different operating systems and with
different configurations.
Then there are things like cloud, we need cloud testers, where do the differ from the traditional
tester? Or those testers, who test games for a profession?
And what about the rise of test communities, crowd testing, weekend testing? We as testers keep
on evolving as the world around us keeps on changing.
This article is supposed to give you an insight on how the tester evolved to an app tester, what is an
app tester, what profile does he/she need, what skills does he/she have.
I am not sure, although the majority of testers are skilled professionals, can they be an mobile app
tester?

5. The mobile app tester
Recently I asked myself, what skills does an mobile app tester needs, what is the difference with a
functional tester, or a test automation expert.
To come to an answer, I first take a look on mobile apps and how they differ from the other
app(lication)s, because app is of course an abbreviation of application.
The definition of a mobile app: an application, typically a small, specialized program downloaded
onto mobile devices.
If I dissect this definition, the first thing I see is a small, specialized program. So here is the first
characteristic for the mobile app tester found. Due to the specialized nature of this little program, a
mobile app tester should preferably have knowledge of the domain the app is designed for. For
instance, it could come in handy if the tester who tests a bank app, has knowledge of the financial
domain. So he/she can easily design the desired tests
Because the app is a little program that relies heavily on trends, the time to market of this
application is probably short, there for, development of the application will be short also. This short
development lifecycle will lead to short incremental development, for instance Scrum.
So another characteristic of the mobile app tester is that he/she possesses knowledge of agile
testing, be a team player with multiple disciplines like test automation for regression testing.
Then there is the part of how users acquire this app, they download it onto their mobile device. So,
this means that anyone with a mobile
device can download this app,
anywhere in the world. As a mobile app
tester you need to be aware of this.
What about the language barriers, legal
restrictions etc. Do you as a mobile app
tester need to have in dept knowledge
of this? I don't think so, but awareness
is definitely advisable.
Being able to download and install it
yourself, brings me to think about
security. Recently the first security
issues where made available through an
app, so as a mobile app tester you need to take that into accounting. What if someone finds a way to
capture traffic between your banking app and your bank and modifies the transaction? So it would
be nice if you have some basic security knowledge as a mobile app tester.
This also applies to performance testing. An app, still being a small program needs to perform as fast
as every other program, preferably faster. The typical app buyer is someone who needs this app to
do a specialized job and do it as quick as possible. If I want to see on what gate my flight leaves and it
takes the app over an hour, I am destined to miss that flight. So the mobile app tester can do with
some performance testing knowledge.
But what about all the other "illities" like usability and portability. I think you are already aware of
them, we as testers all should know ISO25010(former ISO9126) and so should a mobile app tester.
What about risk management? Does the mobile app tester needs to have knowledge of risks? So he
can calculate the risks and test by a risk based approach? Apps depend heavy on the impression they

6. make on a user. If you take the functionality and performance of the app in mind. If your app
performs bad and has lousy functionality, the user will be disappointed and will delete the app. But
furthermore, these app stores have rating mechanisms, users can comment on the download. And
you don't want your app to be rated bad and get behind the competition. So yes, as a mobile app
tester you have to nowhere the highest risks are and test them.
As stated above, the app is downloaded to a
mobile device. There are literally hundreds
of mobile devices and a handful of different
operation systems. So here comes a new
challenge for the mobile app tester.
Although tests can be executed on a
simulator, preferably you want to execute at
least a part of the tests on the actual mobile
device. So again, as in the early fifties, you
are debugging, but now maybe we will call it
the Retro-debugging-oriented pahse.
So I think that as a mobile app tester, you
need to have technical skills, maybe a
programming background, so you can
detect, identify and locate the fault. And
communicate this with your fellow team
members who can resolve this.
So, what does an mobile app tester need?
The best profile I can come up with for an app tester is a blend of all disciplines we know of in testing
and the mobile app tester is the centipede in software testing.