Transcript of "The testers evolution to a mobile app testerv"
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? Iguess its somewhere between 10 and 20 on a daily bases. We use them to keep in touch with ourfriends and family, read or watch news,have insight in our financial situation ofjust for fun, shooting little birds aroundwith big catapults. This is a hugedifference with a few years ago. Youwhere glad to synchronize your calendarand email with your mobile device andthats that.Within this fast or even extremely fastchanging software development world,how did we as testers adapt to this? Didwe change just as fast? Have we become a new breed of testers? I think not, because we humansarent 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 testingexperience.Lets take a look on how testing and there for the tester evolved over the last 50 years as described inthe concept evolution of software testing using the testing process model proposed by Gelperin andHetzel from their study “The Growth of Software Testing” [ Communications of the ACM, Volume 31Issue 6, June 1988, pp. 687-695]. In their study they speak of 5 phases: - 1956 The debugging-oriented period1957 - 1978 The demonstration-oriented period1979 - 1982 The destruction-oriented period1983 -1987 The evaluation-oriented period1988 - The prevention-oriented period.Each of these periods needed another kind of tester. So lets take a look at the pre historic age ofsoftware testing, the debugging-oriented period.The tester in the debugging-oriented periodDuring this period the testing focus was more on hardwarethan it was on software, the systems where huge mainframesystems and testing was more part of programming thansomething on its own. Some state that testing was part of thedebugging activities. So what would your skills as a tester bein this prehistoric age of testing? My guess is that you wouldbe more a developer/programmer than a tester. And part ofyour tasks was to prove that something you build actually didwhat you expected to do based on a requirement.The first one to describe an actual operational test was Turing in his article "Computing Machineryand Intelligence"[Mind 59, Oct. 1950, pp. 433-460]. The operational test Turing definedrequired the behavior of the program and a reference system (a human) to be indistinguishable to aninterrogator (tester). This could be considered the birth of functional testing.
The tester in the demonstration-oriented periodThe ancient history of testing is the second phase, the demonstration-orientated period. During thisperiod, the meaning of testing and debugging both included efforts to detect, locate, identify andcorrect faults.The systems or applications that needed to be tested during this period were mainly standaloneapplications 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 wasviewed 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 thiswith common sense, but also the first test technique, path coverage, is introduced. After designingthe test, the tester could execute the test and analyze the result. If it failed the tester would pointthis out to the programmer and he would resolve this issue, so the tester could test it again.The tester in the destruction-oriented periodNow we arrive in the middle ages of software testing, the destruction-oriented period. There aretwo important things in this period. The First important thing was the difference between testingand 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 Softwaretesting, software testing was described as " The process of executing a program with the intent offinding errors ". He also stated that test cases or tests were of much greater value if an error wasfound. In the demonstration-orientated phase, proofing the correctness of software could lead toselecting 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 createdifferent test cases with a higher probability to detect them. There for testing is more successful. Thisalso led to other test related activities like verification/validation activities, but also to better analysisand review techniques. Even the first steps were made on describing combined fault detectionapproaches.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 techniqueschanged and new design techniques lure on the horizon. The destruction-oriented period testerbecomes more and more a serious player in the field of software development. He develops newskills and will evolve in to the next phase tester, the evaluation-oriented period tester.
The tester in the evaluation-oriented periodThis is next phase as described by Gelperin and Hetzel, the evaluation-oriented period or as I refer toit as the early modern period of software testing. During this period a methodology that integratesanalysis, review, and test activities to provide product evaluation during the software lifecycle, wasdescribed in " Guideline for Lifecycle Validation, Verification, and Testing of Computer Software" byThe 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 ofevaluation techniques; the basic, the comprehensiveand the critical.It also states that; "No single VV&T technique canguarantee correct, error-free software. However, acarefully chosen set of techniques for a specificproject can help to ensure the development andmaintenance of quality software for that project".Now, the tester does not only needs to haveknowledge of different techniques, he also needs toknow how to combine them to suit his needs. Thetester in this period had a focus on softwarerequirements and design, but relied heavily onanalysis and reviewing techniques.But still, the tester needed to evolve further, because testing evolved further. This takes us to themodern age tester in the prevention-oriented period.The tester in the prevention-oriented periodDuring this period, different experts have written books on the subject. One of the significant bookswas "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 effectivebug preventers known". This extended the definition of testing with error prevention andempowered early testing to lower costs [Boehm].Beizer and Hetzel both contributed ideas that created the mindset that early test design was of greatimportance throughout the entire software life cycle. And here is the big difference between theprevention-oriented period and the evaluation-oriented period. Where the evaluation-orientedperiod relied mainly on analysis and reviewing other than testing, the prevention-oriented periodsees 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 testengineers, test designers, test managers etc. You have specialists in test automation, performancetesting etc. And all of them are highly skilled professionals, not only hard skills but also soft skills. Butis this the last step in the evolution of the tester?
Diversity in testersNo it isnt, because during this modern day period, the period where I myself became a tester, thetester evolved with lightning speed and there is much diversity in testers. The first ever system Itested was a mainframe system, anyone familiar with the black and green screens? And the testprocess was as described above. We planned, designed and executed tests, based on differentanalysis, 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 didnt have to adapt my skills as tester, because I could testthese new applications like the way I tested the old ones. But, this did lead to difference in functiondescriptions. Some functions demanded that you had knowledge of mainframe or CRM. So within thefunction 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 anacceptance 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, whos 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 newkind of tester. If we look at an agile tester. Is this really a different tester? Ok, we need to learnsome 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 applicationsand content needed to be on the Internet. Once again new testers were created, so called "Webtesters". They did there testing on different browsers, on different operating systems and withdifferent configurations.Then there are things like cloud, we need cloud testers, where do the differ from the traditionaltester? Or those testers, who test games for a profession? And what about the rise of test communities, crowd testing, weekend testing? We as testers keepon 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 anapp 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 apptester?
The mobile app testerRecently I asked myself, what skills does an mobile app tester needs, what is the difference with afunctional 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 otherapp(lication)s, because app is of course an abbreviation of application.The definition of a mobile app: an application, typically a small, specialized program downloadedonto mobile devices.If I dissect this definition, the first thing I see is a small, specialized program. So here is the firstcharacteristic for the mobile app tester found. Due to the specialized nature of this little program, amobile app tester should preferably have knowledge of the domain the app is designed for. Forinstance, it could come in handy if the tester who tests a bank app, has knowledge of the financialdomain. So he/she can easily design the desired testsBecause the app is a little program that relies heavily on trends, the time to market of thisapplication is probably short, there for, development of the application will be short also. This shortdevelopment 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 agiletesting, 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 mobiledevice can download this app,anywhere in the world. As a mobile apptester you need to be aware of this.What about the language barriers, legalrestrictions etc. Do you as a mobile apptester need to have in dept knowledgeof this? I dont think so, but awarenessis definitely advisable.Being able to download and install ityourself, brings me to think aboutsecurity. Recently the first securityissues where made available through anapp, so as a mobile app tester you need to take that into accounting. What if someone finds a way tocapture traffic between your banking app and your bank and modifies the transaction? So it wouldbe 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 fastas every other program, preferably faster. The typical app buyer is someone who needs this app todo a specialized job and do it as quick as possible. If I want to see on what gate my flight leaves and ittakes the app over an hour, I am destined to miss that flight. So the mobile app tester can do withsome performance testing knowledge.But what about all the other "illities" like usability and portability. I think you are already aware ofthem, 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 hecan calculate the risks and test by a risk based approach? Apps depend heavy on the impression they
make on a user. If you take the functionality and performance of the app in mind. If your appperforms bad and has lousy functionality, the user will be disappointed and will delete the app. Butfurthermore, these app stores have rating mechanisms, users can comment on the download. Andyou dont want your app to be rated bad and get behind the competition. So yes, as a mobile apptester 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 testingand the mobile app tester is the centipede in software testing.