Testing-Circus-Vol5-Edition09-September-2014

Volume 5 - Edition 9 - September 2014 

Testing Circus 

4th 

Anniversary 

Edition 

Monthly Magazine 

on 

Software Testing 

Interview with 

Paul Holland 

www.TestingCircus.com


September 2010 - September 2014 

4 Years X 12 Editions = 48 th Edition

4 th Anniversary 

Special Edition 

Volume 5 - Edition 9 - September 2014 


Topic Author Page # 

Interview with Paul Holland Jay Philips 7 

The Power of Ignorance Patrick Prill 12 

How Skilled are You in Menial Jobs Anuj Magazine 15 

Reification Error in Software Testing Jari Laakso 18 

I am a Mobile Software Tester Jean Ann Harrison 20 

Testing The Test Reports Parimala Hariprasad 23 

Modularizing the Test Case Design Llyr Wyn Jones 26 

From A Tester to A Development Team Mate Nimesh Patel 29 

Story of Security Testing, Myth Busters and More Santhosh Tuppad 34 

CAST 2014 - The Best Testing Conference Simon ‘Peter’ Schrijver 36 

CAST 2014 - Conference Just Took Place and I Wasn’t There! Teri Charles 38 

Stop ISO 29119 - An Important Message to Testers ISST Board 40 

Test Events Around the World TestEvents.com 43 

Book Review - Book Worms Corner WoBo 44 

A Fake Tester’s Diary - Part 45 Fake Software Tester 46 

Testers to Follow in Twitter Testing Circus Team 48 

www.TestingCircus.com September 2014 - 04 -

Topic Author Page # 

Security Testing Tips - Part 21 Santhosh Tuppad 50 

Tool To Detect And Remove Security Vulnerabilities Tools Journal 52 

Managing Change in a Test Cycle Tools Journal 53 

Real Device Metrics Under Load Now Available Tools Journal 54 

Testing Circus is Four Years Old Mike Talks 57 

*On the Cover Page - Paul Holland 

Testing Circus Team 

Founder & Editor – Ajoy Kumar Singha 

Team - 

• Srinivas Kadiyala 

• Dwarika Dhish Mishra 

• Pankaj Sharma 

• Bharati Singha 

• Chanderkant Saini 

• Jaijeet Pandey 

Editorial Enquiries: editor@testingcircus.com 

Ads and Promotions: ads@testingcircus.com 

Article Submision: article@testingcircus.com 

Testing Circus India 

Chaturbhuj Niwas, 1 st Floor, 

Sector 17C, Shukrali, 

Gurgaon - 122001 

India. 

© Copyright 2010-2014. ALL RIGHTS RESERVED. Any 

unauthorized reprint or use of articles from this magazine 

is prohibited. No part of this magazine may be reproduced 

or transmitted in any form or by any means, electronic or 

mechanical, including photocopying, recording, or by any 

information storage and retrieval system without express 

written permission from the author / publisher. 

Edition Number : 48 (since September 2010) 


From the Keyboard of Editor 

ISO 29119. Testers, this is something you should be aware of. A standard for 

software testing will definitely change the way you test. The so called 

‘internationally agreed’ standard is far from being agreed with people having a 

difference of opinion. I urge you to read a piece on this proposed standard by ISST 

published in this edition. There is a petition on ISO 29119. If you care for your 

profession, educate yourself and sign the petition. I already signed the petition. 

Don’t suffer from ‘Not my job’ syndrome. 

This is our 48th edition and this marks the completion of 4 years of this tiny 

magazine. It is a happy moment for all of us who volunteer for Testing Circus. 

Someone asked me if we were going to celebrate it in a big way on our 4th 

anniversary. For us, every edition is a celebration because there are lots of effort that 

go behind every edition and without our volunteers, no edition would be published. 

This month we have included articles on a variety of topics. There are two special 

experience notes from CAST 2014. You will also enjoy Paul Holland’s interview in 

this edition. Do read Fake Tester’s Diary entry on ‘Not my job’ syndrome. Thanks 

to Mike Talks who shared his experience with Testing Circus to mark our 4th 

anniversary. 

More in the next edition. Stay tuned. 

Happy testing! 

- Ajoy Kumar Singha 

@TestingCircus // @AjoySingha 

Feedback please! editor@testingcircus.com 


PAUL HOLLAND 

Organization: Doran Jones 

Current Role/Designation: Managing Director, Head of the Testing Practice 

Location: New York, NY 

Interview with Testers 

Paul is Managing Director of the Doran Jones Testing Practice and is a 

principal trainer for the Per Scholas STEP classes. Paul had previously 

been working at Alcatel-Lucent (formerly Newbridge) from 1995 

through 2012. During that time he worked primarily as a test manager 

in the DSL group, and on test automation of ATM switches - focusing 

on Switched Services, Cell Relay line cards, and Frame Relay line 

cards. Paul is one of just three instructors worldwide of the Rapid 

Software Testing course and he specializes in adapting testing 

methodologies to be more effective and efficient. 

* Interviewed by Jay Philips 

1. Tell us about your journey to becoming a software 

tester. How did it start and how this has been so far? 

Was it planned or by accident? 

I was in the third year of four years working on my 

Computer Science degree at Carleton University 

when I realized that I did not want to write code for 

a living. The thrill of creating a piece of software was 

not surpassed by the repetitive nature of the coding. 

When I graduated I looked for a job in IT but not one 

that required coding. I worked for 3.5 years as an 

Application Engineer at Xerox. This was not a testing 

role but I had to perform a lot of troubleshooting of 

customer issues and I found that I was really good at 

that. After a brief five year diversion where I joined 

the Canadian Military as a pilot and flew Sea King 

helicopters, I returned to Ottawa and got a job as a 

tester at Newbridge Networks. I didn’t really seek 

out a software testing job – it was really what was 

available that I thought I could do well. That was in 

1995. So, I guess, it was a little by accident or perhaps 

a better description is I started in software testing by 

taking the opportunity as it was presented to me. 

2. When did you realize your passion was software 

testing? 

The first five years I was a test automation designer. 

I enjoyed the combination of some coding with a big 

emphasis on finding bugs. In 2000 I realized that I 

had not ever received any formal training on being a 

software tester and I received permission to find 

some training. I found Ross Collard who ended up 

being an extreme influence in my testing career. He 

introduced me to the Context Driven Testing 

community and invited me to attend the first 

Workshop on Performance and Reliability (WOPR) 

in New York in 2003. It was probably during WOPR 

that I realized that I had a passion for software testing 

– after I was exposed to other people who are very 

passionate (James Bach, Rob Sabourin, Scott Barber). 

3. Do you regret being associated with software 

testing today? Given a chance would you move from 

testing to any other field in IT? 

Not at all. I love what I do and I currently have no 

interest in moving away from testing. 

4. You are a member of the context-driven school of 

software testing. How does that school differ from 

others? 

The CDT community self identifies itself as a school 

while most other testers are unaware of testing 

schools let alone being able to identify themselves 

with a particular school. The Context Driven School 

approaches each testing problem by analyzing the 


PAUL HOLLAND 

specific details (product/feature, people involved, 

complexity, time, business needs, plus a lot of other 

variables) and then adopt their testing strategy to fit 

the situation. There is the factory school which reads 

specifications, writes scripts and then executes those 

scripts over and over again. The Agile school thinks 

that dedicated testers are not required and that 

testing can be done by designers – and primarily with 

automation. There are other schools but I’m not sure 

if it’s worth listing them here. 

5. You teach the course Rapid Software Testing 

(RST). What are some key items that people would 

learn from taking the course? 

RST is a methodology. An approach to testing that 

can be applied in any testing context. We cover the 

Heuristic Test Strategy Model (HTSM) – an approach 

to testing that is far more diverse than reading 

requirements and thinking of scripts that will show 

the requirements are working. We also cover testing 

vs. checking, modeling, oracles (how you know there 

is a problem/issue), critical thinking, exploratory 

testing, telling your testing story, plus other topics 

which depend on the class and the instructor. James 

Bach, Michael Bolton and I all teach the same course 

but the course experience is very different from each 

of us. We incorporate our own stories, our own 

approach to the exercises and the material. I know of 

one person who took the course three times – once 

from each of us – and he said it was like taking three 

different courses despite the underlying material 

being the same. 

6. According to you, what is lacking in today’s 

commercialized training industry, especially in 

software training? 

The commoditization of the craft of software testing 

is my main concern. Organizations like the ISTQB 

and the ISO 29119 standards are marketing that all 

you need is a procedure to follow to be able to be an 

expert software tester. There is a real threat to the 

profession of software testing coming from the ISO 

29119 “standard”. It emphasizes documentation and 

planning over actual testing. We have seen massive 

failures caused by companies that follow this 

approach (e.g.: healthcare.gov). If companies adopt 

ISO 29119 then the creative and effective testing 

required to find good bugs will be eliminated and 

replaced with a well-documented series of scripts 

that will leave huge holes in the coverage. There is a 

petition started by the International Society for 

Software Testing (ISST) to stop the ISO standard by 

showing that there is no “standard” at all as there is 

significant and sustained opposition to it. Please, I 

encourage everyone interested in the software testing 

profession to sign the petition located here: 

http://www.ipetitions.com/petition/stop29119 

7. What is your next big idea? 

Right now I am working at Doran Jones in New York 

City as Managing Director, Head of Testing Practice. 

With our partner, Per Scholas, we are training long 

term unemployed and under privileged people to 

become software testers (using a program that 

includes 8 days of training on the RST material and 

its implementation) plus 6 weeks of other technology 

training. We will be opening our office in the south 

Bronx this fall and be employing over 100 of those 

students. One of our goals is to bring testing jobs 

back the USA that have been outsourced to offshore 

companies. We will be providing a higher quality of 

testing and also helping employ wonderful people 

who want a career in software testing. All the testers 

will be under the supervision of experienced team 

leads and managers who are familiar with Context 

Driven Testing. We have a few clients already and 

the feedback has been excellent. 

8. What qualities will you look for in a candidate 

when you want to recruit someone for software 

testing job? 


PAUL HOLLAND 

I look for someone who can think critically, selfeducate, 

solve problems and communicate well. 

Their domain expertise is also important but 

definitely less important than the other skills I just 

listed. I am far more inclined to hire someone new to 

software testing than someone who has been doing 

bad testing for years. I find it much harder to un-train 

bad habits than start with someone fresh and instil 

good testing practices from scratch. I am very 

pleased when I have true CDT testers apply to work 

for me - people who are students of software testing 

and have found CDT on their own. They tend to have 

the skills I’m looking for in a tester. 

9. Do you have any advice for our readers on what to 

look for/out when applying for a software testing 

job? 

If you are a passionate test professional and you want 

to feel valued and enjoy your job then you want to 

look for a job that allows you to think while you are 

testing. If the job involves the creation and execution 

of test scripts then I would recommend looking 

elsewhere. If you will have no time to actually test the 

product (instead of “checking” the product with 

scripts) then you will likely become bored with your 

job fairly quickly. 

When applying for a testing job, you should 

emphasize your diverse testing approach, how you 

have improved your skills (reading blogs, attending 

conferences, following thought leaders on Twitter, 

reading books, etc.), show some examples of your 

work (bug reports, test reports, etc.), and show your 

critical thinking/problem solving abilities (using 

examples from your previous experiences). If I 

interviewed someone who showed me those 

qualities then I would be far more likely to consider 

them for the job. 

10. You talk about harmful metrics. What are some 

of the harmful metrics and why do you think they are 

harmful? 

Most software testing metrics are “bad”. I have my 

favorites which are typically the ones that are very 

commonly used without much thought. Metrics like 

“% pass rate” and even the “number of bugs” are 

frequently used to make decisions about the state of 

the software but are, at best, the start of discussion 

points. The primary reason that I started talking 

about bad metrics at conferences was that important 

ship/no-ship decisions were being made based on 

metrics when the metrics themselves can be VERY 

misleading. For example, I have two very similar 

projects that are a week away from a major release. 

Project ONE has a 99% pass rate (and we won’t talk 

about the ambiguity of what it means to “pass” a test) 

and only one known issue which is a critical bug. 

Meanwhile, Project TWO has an 80% pass rate and 10 

critical bugs and about 20 minor bugs. So my 

question is: “Which project is in better shape?” 

The obvious answer is Project ONE but that is why 

metrics are dangerous and misleading. Here is the 

testing story: Project ONE has only one critical bug 

but that bug is one that corrupts user data and it 

happens fairly regularly. The design team has been 

working on this bug for weeks and has absolutely no 

idea about the root cause of the issue nor any idea on 

how long it will take to fix it. They are not even sure 

if they can fix it without a complete rewrite of the 

system. Project TWO has 10 critical issues but the 

design team is very close to fixing all of them (it turns 

out that they all had the same root cause which has 

been shown by preliminary testing of the fix) and 

their low pass rate is caused by minor issues which 

likely won’t impact the customers’ experience too 

much. Well, now it is clear that Project TWO is 

MUCH better off. So, the metrics in this example 

aren’t just meaningless but they are potentially 

harmful because they may cause the management to 

make poor decisions. If the metrics may be lying to us 

then why use them at all? Let’s drop the metrics and 

start telling stories. 


PAUL HOLLAND 

11. What will you suggest to people who want to join 

IT industry as software testers? 

Show your passion. Join the CDT community. We are 

a very inclusive group and we welcome new comers 

with open arms. Follow CDT testers on Twitter and 

read their blogs and articles. Don’t just accept that 

testing by looking at requirements and writing 

scripts is what testing is all about. Read books, attend 

conferences (especially CAST and Let’s Test), find 

and attend local tester meet-ups and never stop 

learning. 

12. Name few people you would like to thank, people 

who helped you directly or indirectly in your career 

as a software testing professional. 

Wow, it would be very hard to only name a few. My 

biggest thanks has to go to Ross Collard. He is the 

one who first showed me that software testing is far 

more than scripting. James Bach and Michael Bolton 

have mentored me over the past 10 years and have 

welcomed me as an instructor of RST which has 

definitely been a wonderful boost to my career. Keith 

Klain, my current boss, is helping change the 

software testing industry. It was his ideas, drive and 

leadership that made the Doran Jones/Per Scholas 

partnership possible and I thank him for allowing me 

to join him on this journey. There are many other 

wonderful people who have helped and inspired me 

throughout my career: Rob Sabourin, Scott Barber, 

Eric Proegler, Cem Kaner, John Hazel, Martin Hynie, 

Gerry Weinberg, Fiona Charles, and Dan Downing to 

name just a few. 

________ 

Blog - http://testingthoughts.com/ 

Twitter ID - @PaulHolland_TWN 


http://www.testmile.com

Ignorance is the driving force for a Curious Tester 

The Power 

Of 

Ignorance 

- Patrick Prill 

I was thinking a lot lately and also writing about the 

benefit of model thinking in testing, when I recently 

zapped across several science documentaries on TV. 

And maybe it’s exactly those things that revolve around 

my head, they showed me clearly some important parallels 

between the world of science and testing. Together 

with the combination of my first experience of a Weekend 

Testing America session a couple of weeks ago 

about “Deep Testing” and a TED talk from Stuart Firestein 

about the pursuit of ignorance combined a lot of 

loose ends in my thinking and created a new dimension 

of ignorance for me. 

Ignorance in this article means the positive definition, 

the conscious lack of knowledge, the known and unknown 

unknown. Not the dismissive variant: wilful 

stupidity. 

Parallels between Testing and Science 

Professor Firestein brought in his TED talk an example 

from his course “cellular and molecular neuroscience”. 

There’s a big textbook (1.414 pages & 7.7 pounds) about 

the topic that he uses, and his students might get the 

impression that everything about the topic is already 

known and is in this book. But Firestein says, that when 

he is talking with his colleagues about the same matter, 

they don’t talk about what they already know, they talk 

about the things they don’t know. 

When you now draw the parallel to testing, this might 

also be true for a test or project manager or even a rookie 

tester looking at a long list of test cases. They might get 

the idea, that everything in the software is known and 

covered with the existing test cases. When you report 

metrics on test cases and test coverage the “customer” 

even might believe that he is safe with that, because all 

is known. In the meanwhile you and your colleagues 

still discuss with developers about scenarios “what happens 

when”. 

Testing is also using the scientific method to define and 

execute experiments (tests), to create and prove models 

about software and conduct further experiments to verify 

and refine those models. Testing is all about collecting 

more and more information about the software 

under test. 

One part of your job is to describe that the software 

works as intended. So show and tell what you have 

done to check and verify that the software is doing what 

the architects and the customers want. Show what you 

have done to proof the opposite. The other part, the big 

one, is to tell what you have not done. What questions 

do you still want to find answers for? Tell, why you 

have not done it. Inform the stakeholders of the remaining 

risks. Let them decide what to do about it. 

Don’t waste your time. If you “check” around the 

known areas, executing the same test cases over and 

over again, you don’t learn many new things and don’t 

get new insights. If you really have to do those tasks 

often, try to automate them, and get them out of your 

way. Already during automation you will learn more 

things about the software you are testing than you knew 

before and sometimes than you ever wanted to know. 

Good testers seek for more information than only conformance 

with specifications. Testing begins where the 

facts run out. 

Measuring ignorance 

Don’t get me wrong, it’s not possible to measure ignorance, 

because it’s infinite. 

Michael Bolton gave me the basic idea behind this in the 

weekend testing session about “Deep testing”. “How 

can you show/measure how deep you are?” was my 


question. He said, that the length of your mind map nodes is an indicator of how deep you came compared to other 

areas of your model. There won’t be an absolute measurement to it. 

The depth of testing is also about the pursuit of ignorance. You answer more and more questions, and gain new 

facts and information. On the other hand, not a topic in the weekend testing discussion though, you gain awareness 

of your ignorance and add new questions about the known unknown to your model. Depending on your experience 

and your skills, you might run out of test ideas in your deep testing sooner or later. But do you also run out of 

questions? If you realize that this shows you the border between knowledge and ignorance, you can start asking 

questions on each end of your information, what is beyond there. And you can start learning, what you need to 

answer those questions. 

I like the idea behind Firestein’s model that knowledge and ignorance are like the ripples on a pond. Between the 

center and the outmost ripple lies your knowledge, and beyond that wave lies your ignorance. The perimeter of the 

wave describes your known ignorance. So the more knowledge you gain, the bigger the circle gets, the more your 

known ignorance grows. 

Image: The growth of your ignorance 

Models in Testing – Puzzle or Iceberg? 

Mathematician George E. P. Box wrote “Essentially, all models are wrong, but some are useful.” 

Scientists create models to explain a certain topic and to support their theories. As a tester you should do the same. 

Unconsciously you definitely do that in your head. To benefit from that already existing model, you should be 

conscious about that fact and write it down. If you want to know a bit more about that, read my blog. 

Your model won’t be all-embracing, but if you can’t tell the manager which information are missing, yours and his 

picture of the state of the testing are not complete. Firestein brings some examples in his talk that we tend to 

describe those situations as tip of the iceberg, or the missing piece to the puzzle. The problem is, that those examples 


describe things that are manageable (from the tip you 

see, you can estimate the size of the iceberg) or there is 

a definite solution coming with the puzzle. But for science 

and also for complex software that is not true. You 

don’t know how big it really is, or what the picture will 

look like once the puzzle is getting bigger. 

In a project resources are limited (time, people, money, 

etc.). So you have per definition not the slightest chance 

to complete the picture. But with the knowledge about 

your ignorance you can ask the right questions. You 

should come to an agreement in the project what levels 

of knowledge and ignorance are enough, to see as much 

of the picture as you need to know, to enable some well 

informed decisions and keep the remaining risk as low 

as possible under the given circumstances. 

IDT – Ignorance Driven Testing 

Scientists and good testers share a common thought, “I 

am wondering what happens if…” That is one example 

that describes your curiosity to reveal more of your 

ignorance. See all of your testing, the use of new techniques 

and tools, discussions, and approaches as new 

experiments to find out new things about the software 

you are testing, to get more answers and information to 

enrich your model and uncover new questions and 

areas of ignorance. 

When you put your knowledge in a model it helps you 

explain what you know and it can help to show you, 

what you don’t know. And this is exactly what you 

should also tell to your stakeholders. An important part 

in a test report is, what are the unknowns? So that the 

stakeholders can decide if it’s worth the extra time to 

discover those areas or if the picture is complete enough 

to take the risk. 

Ignorance and Precision 

With the knowledge you gain, you are also able to ask 

more and better questions about what you don’t know. 

You gain precision in your knowledge about the known 

unknown. This will help you to plan your next steps, the 

next experiments and tests. This will also help you, to 

find areas you might want to improve and new things 

to learn, like techniques and tools. 

Conclusion – You can only win! 

The idea behind the power of ignorance is hard to describe 

in short words. With the knowledge you gain 

about a subject, you also get unanswered questions of 

the beyond, the beneath or above. The more knowledge 

you gain, the more precise you can ask your questions. 

On your journey to get answers you will gain knowledge 

and you will gain ignorance. Philosopher Immanuel 

Kant said in his “Principle of Question 

Propagation” “New knowledge brings new questions.” 

Learn to see what you don’t know. Testers use ignorance 

to plan their testing, to identify what should be 

done, what the next steps are, where to concentrate your 

energy, and to improve themselves. 

Please allow me to adapt a quote by one word from 

Stuart Firestein at the end that can be found on his 

website. 

Ignorance, all of what we don’t know, and even what 

we don’t know we don’t know, is the driving force of 

testing. 

Patrick Prill has over 10 years of experience in software testing. After four and half years as a tester he 

became test manager, coordinating the work of ~50 people for another 5 years in a big test project. 

His new job as test lead for a software and consulting company for the automotive industry brought him 

back to a smaller test team and the hands-on experience of testing software again. This experience and 

following the discussions and articles of the context-driven testing community relighted his fire for 

testing and bug hunting. 

Patrick is living outside of Munich, Germany and is a proud husband and father of a wonderful 

daughter. In the little spare time he is a wood turner. Partrick tweets at @testpappy. 


Your effectiveness often depends upon your skill in performing seemingly menial jobs. 

How Skilled Are 

You in Performing 

Seemingly Menial 

Jobs? 

- Anuj Magazine 

skills around ensuring successful execution of the 

projects. 

There is a certain fanciness about mentioning 

Innovation as one of the competencies that would take 

your organization to glorious heights in future. These 

days it has become almost fashionable to talk about 

Innovation as only saving grace for the organizations. 

Innovation will almost ways list as areas of 

improvement in most of the performance appraisal and 

career planning forms. 

I think all this buzz around Innovation is largely 

justified given what the companies like Apple, Google 

and many others has done in the past. As much as the 

focus on Innovation is important, the hype often comes 

at the expense of demeaning the importance of precise 

I talked about visionary organizations like Apple and 

Google but while these organizations were breaking 

paths with products highlighting discontinuous 

innovation, emerging economies like China and India 

are silently gaining the mind share of the people all 

around the world with its work primarily around 

focused on supremely delivering on items. Did these 

countries innovate as well as their western 

counterparts? Certainly not but what they mastered was 

the art of executing well even if they were working on a 

product as general as a table cloth or a general 

decoration item or anything else (after all, everything 

around looks to be "Made in China"). 

This example kind of gives us an idea that great careers 

could be built on the premise of Execution excellence 

even if the Innovation quotient of a person is somewhat 

reasonable (not great!). After all, not everyone can be a 

Steve Jobs or a Bill Gates! If Innovation is a sought-after 

skill in today's world, Execution excellence is a 

mandatory one. 

Before I seem like making less sense, let me explain 

what I mean by Execution excellence. 

Simply put - organizations make big plans promising 

bigger, grand results. The results remain just a promise 

on paper till someone goes in the field, makes his or her 

hands dirty and executes on the plan. Excellence in 

execution takes us closer to realizing those lavish plans. 


This list can go on and on but the key questions are - do 

we really give adequate importance to seemingly petty 

jobs? Can we do these jobs/tasks better than they are 

being currently done? 

Further in this article, I am sharing some of the thoughts 

around handling such tasks that has helped me create 

the right frame of mind to handle such tasks 

Though execution of the projects is important, it 

increasingly amazes me to see that many people find the 

execution boring. Especially the part of execution where 

one has to go through those chores repeatedly, again 

and again in an almost monotonous manner. Let me 

give some examples here - 

1. One of the projects that I was involved in testing, at a 

crucial release stage, required a tester to do the 

installation of the product almost countless times (more 

than 100) in different platform to debug an issue. To put 

it in other words, a tester needing to setup OS (5-6 

supported), setup browser (again 5-6 versions), install 

the third party products, install the application under 

test and wait for the error. Though this was a routine job 

but was important to ensure a seamless customer 

experience. 

2. Another example, in an efficient functioning of any 

team, the regular housekeeping activities like managing 

of hardware, inventory, information etc. is important 

but at the same time routine and monotonous. 

3. Sending a weekly report when nothing significant has 

happened can be considered as boring and needless 

when it still serves important status needs of the 

recipients. 

4. For a manager, meeting his team regularly may be a 

routine affair and if not done may lead him to be quite 

out of sync. 

5. Again, a tester going about executing the tests that 

have passed in the past just to ensure that nothing has 

regressed in the product (after all, not all testing can 

lead to bugs!). 

Understanding the role, bigger picture: 

Harsha Bhogle in his 

book- "The Winning 

Way" talks about an 

interesting instance 

related to the game of 

Cricket - 

Unable to work out a way 

to get Tendulkar out, 

Naseer Hussain (in 2002 

series), decided to 

frustrate him by bowling 

a largely negative outside 

the leg stump line. The man assigned to do the job was Ashley 

Giles, a workman like spinner who kept things tight. For the 

next 11 overs, he bowled the outside of leg stump to 

Tendulkar, a tactic that drew much criticism. But it did keep 

Tendulkar quiet and ended up frustrating him. "If you cant 

bowl him out, bore him out.", the critics said, but as Hussain 

suggested afterwards, it was a better option than Tendulkar 

getting a century! It was a boring job for Giles to do and the 

key lay in the Captain's communication of its importance. If 

a player knows his role and implements it well, a seemingly 

small role can become important. 

It is thus important to understand the bigger picture the 

task is helping achieve. Every job on the earth has its 

own dull moments and more often the difference 

between "just" successful and "greatly" successful lies in 

how one handles those dull moments. It is also critical 

to understand one's role in handling petty tasks. As in 

this example, Giles knew the line he had to bowl and not 

try anything else. Role clarity comes with effective 

communication not only on Leader's part but also the 

follower's part. A follower can always ask right 

questions to understand/clarify what is expected of him. 


Being a true team player: 

Rahul Dravid in Harsha Bhogle's book- "The Winning 

Way" talks about his view - 

I have noticed that good team players view success very 

differently from the rest. They are motivated without really 

worrying about the credit. That’s not always easy. Anyone 

who has fielded at Short leg, knows what a Thankless job it is, 

besides being risky. You put your body on the line, have to 

work damn hard and may have nothing to show for it. When 

given that position, there are those who are reluctant to put in 

the hard work, hoping that will be made to field in another 

position the next time around, and there are others who give 

it their best and actually become specialists. 

Situations like diving or fielding, in which you put your body 

at risk, or where you are required to play a role outside your 

core-competence areas demand more work from a player and 

therefore require you to put the team before self. The funny 

thing is that you cannot hide your attitude from the team 

mates. If you're selfish, you will be found out in no time at all. 

But if you are a Team-player, the team will know and 

appreciate that as well. 

True team player attitude calls for helping team deal 

with difficult (and also monotonous) tasks by setting an 

example. Handling petty tasks often require more 

patience and situational awareness than many of the 

other tasks. The way these tasks are handled often 

brings about the Leaders in people. 

Having a Strong Professional value system: 

Subroto Bagchi in his 

book - "The 

Professional" in one of 

the chapters makes a 

mention on how he 

had been able to do 

justice to his writing 

talents along with 

handling a high profile 

job. He has 3 books 

and multiple columns 

to his credit, he says - 

...One point I want to 

make is importance of 

taking every assignment 

seriously. Whether I 

wrote a column or an invited occasional newspaper piece or 

for that matter a book, I gave it all I had. To me, my writing 

commitments were no different from a purely professional 

commitment at work. This called for many personal sacrifices 

because it was always like having two jobs. 

Though his point is not exactly about handling 

monotonous task but many things that he talks about 

here are applicable to the context e.g. "Treating every 

assignment seriously", "I gave it all I had", 

"Professional commitment, these are all valid metaphors 

for handling the dull, monotonous work. And if these 

are kept in mind, I believe every task will get the 

importance it deserves. So, having a strong Professional 

value system helps deal with any challenging or dull 

professional situation. 

After all, no amount of Innovation can really help us 

completely get rid of seemingly boring jobs. So why not 

embrace it and give your best shot! 

Can you call yourself as an expert of handling menial 

jobs? 

Anuj Magazine is a software testing and general management professional at Citrix Inc. Anuj likes to 

explore new avenues/sciences and their intersections with software engineering and has contributed to 

a good deal of work in this area. He regularly share his knowledge and experiences as a conference 

speaker and writes frequently on diverse topics like software testing, management, sports, and handwriting 

analysis. Anuj tweets at @anujmagazine. 


Reification Error 

in Software 

Testing 

“Reification generally refers to making something real, 

bringing something into being, or making something 

concrete.” (Wikipedia) 

“Reification (fallacy), the fallacy of treating an 

abstraction as if it were a real thing.” (Wikipedia) 

In software testing, abstractions are often believed to be 

concrete things. In this article, I present a few examples 

of typical reification errors and problems around them. 

Reification itself is not a bad thing, but due to reification 

fallacy, stakeholders and clients often believe software 

testing is about pressing buttons and clicking with the 

mouse, and that testers should produce tangible work 

products. In reality, essentially, the testing happens in 

our minds and the inputs we give to the system are a 

small part of the actual testing process. 

I find that reification fallacy is not often enough talked 

about. Sure, different kind of resistance to metrics exists, 

but reification doesn’t seem to be a topic many testers 

are talking about. I believe partial reason for this might 

be the lack of knowing the term, thus I decided to write 

a bit about it. I know many testers have troubles 

expressing their frustration with metrics, so I hope the 

writing will help also them. 

- Jari Mikael Laakso 

really want to know that they believe the number would 

describe. 

From my experience, a person who asks test case counts 

will most likely also say “we need at least one test case 

per requirement”. Just that test cases, requirements, and 

coverage are not concrete things. What if I write three 

test cases per each requirement (or desirement, like Scott 

Barber likes to say)? Will quality and coverage get three 

times higher? Well, are those test cases and 

requirements of identical value…? 

Having three test cases is not necessarily better than 

having one, or even none. It doesn’t mean we have 

improved coverage. It doesn’t mean quality of the 

testing is any higher; and definitely it doesn’t mean the 

quality of the product is directly related to these counts. 

A test case is someone’s idea about testing a product. 

How do you quantify an idea? 

Quality can’t be counted, just like Klout can’t measure 

my influence. Quality, Klout, and influence are not 

things. Quality is, in fact, a special case as many people 

seem to also claim one can build it in. James Bach wrote 

about this myth 5 years ago. I urge testers to read it and 

think about the nature of quality. 

When abstract ideas become, in our minds, concrete 

things, we might believe counting them makes sense. 

This leads to thinking that abstract concepts can be 

located and measured. For example, I was recently 

requested to count how many test cases a project has. I 

asked for a reason and received an answer along the 

lines of “we want to know the test coverage”. I didn’t 

reply with a number, but explained some of my 

concerns and continued by asking what is it that they 

I’ve often seen bugs counted for various reasons. 

Management might say one critical bug doesn’t stop a 

live release, but once they are informed the bug 

prevents users from logging in, they might reconsider 

their rule of thumb. And then again, there can be several 

reasons to deploy live something that has a dozen 

critical bugs. A bug is a relationship as is quality. 

Thing-ifying and counting bugs is a classic example of 

reification fallacy. 


Time and again I hear how a manager (or other client of 

testing) wants to see various kinds of metrics based on 

counting bugs or for instance test cases. Since these are 

ideas, instead of concrete things, counting them is a 

reification error. However, instead of only telling the 

stakeholder “you are making a reification error”, it’s 

good to learn to explain your testing. Engage people in 

discussions. Learn to ask questions to find out what you 

are needed for. Find ways to give them the information 

they want to know. 

Once you get your stakeholders out from thing-ifying 

testing and starting to see it as a performance of an 

intelligent human being, you will notice you have won 

a big battle and can focus on more meaningful things in 

your work. Instead of trying to meet foolish numeric 

goals, which are based on errors in thinking, you can 

focus more of your time to provide your stakeholders 

information about the perceived quality of the product. 

Because reification fallacy causes a lot of harm to our 

software testing industry, we should talk more about it. 

We should keep our colleagues informed of it. It’s a long 

time since I’ve seen “lines of code” metrics for 

programmers; which is very good. Programmers didn’t 

pull this off yet completely, nor has it been an easy fight, 

but from my viewpoint, they are taking the winning 

side. 

I like to be a winner and I like to help others become 

winners, too. This one we can win by spreading 

knowledge and challenging assumptions. Even if 

something is in your issue/task/bug tracker, it doesn’t 

make it a concrete thing. Keep reminding people of that 

and give them alternative options of discussion and 

decision making. When people fall to the reification 

fallacy, help them get out from it. 

Jari Laakso is a software testing professional who constantly strives to become better. He likes to talk and 

write about software testing, which has enabled him to connect with hundreds and hundreds of testers 

all around the world. His pursuit of deeper understanding of testing requires, in his opinion, studying 

various sciences, including linguistics and semantics. Jari has spent about a decade in testing, out of 

which most on software side. Since 2007, he has worked in different managerial positions, but always 

tried to keep up with his hands-on testing skills. In addition to this, he is a proud father of one. 

Jari tweets at @jarilaakso. 


Am I a Hardware 

Tester, a Software 

Tester? No I'm a 

Mobile Software 

Tester! 

- Jean Ann Harrison 

Anyone who has attended one of my presentations or 

heard one of my webinars knows how I stress the idea 

of incorporating various hardware and operating 

system conditions to see how the software is affected. 

Now there are exceptions where changing up these 

conditions will not have much of an effect or any at all 

with regards to mobile web application and mobile 

website testing projects. I often use the terminology of 

“Testing Beyond the GUI” and entitled one article with 

this title which contain some specific examples of such 

tests to consider. With that said, however, I thought this 

article would tackle some other examples of a mobile 

tester might want to consider to add as part of their 

regression suite. 

There are testers who absolutely do not consider testing 

hardware or OS conditions as a necessary part of a 

mobile tester’s repertoire. “You’re wasting your time” 

or “It’s not our job, we only test the software” and other 

such comments have been told to me. And yet, what 

many of these naysayers are responding to, is based on 

one type of mobile testing project. Usually it’s the 

mobile web application which doesn’t have such a 

strong dependency of the actual device like mobile 

hybrid and mobile native apps do. However, there is 

still some dependency on the device with mobile web 

apps. These mobile testers are not considering mobile 

software is a part of an entire system where software, 

operating systems and hardware all have to work 

together for the complete user experience. These mobile 

testers do not consider the hardware and operating 

system conditions have a direct impact on software 

behavior. 

So let’s consider some specific examples of how 

hardware and Operating System conditions affect 

software behavior. Notifications are something we take 

for granted when using our devices. Does your 

software app use notifications? Did you consider 

testing the notification action beyond of the positive test 

case? Did you ask “What if ….?” Notifications are 

functions where the mobile app engages with the 

operating system and the hardware to display that 

notification visually, audio or both. 

Why don’t we explore a few what ifs further? Set up: 

Your mobile hybrid app sends both a visual and audio 

notification to a device once the app receives data from 

another source. That data is packaged in a particular 

protocol and the notification is to use both visual and 

audio indications. What tests would you start beyond 

the idea of sending data packed per the protocol and 

witness the device behavior? Keep in mind some 

devices have both visual and audio indications, some 

devices have visual indications only from the operating 

system level while other devices display LED lights 

visual on the case of the device. Not all devices are 

equal. So testing on the actual device becomes 

important for this type of test. 

Side note: There are companies who offer virtual access 

services to various devices where you can rent time to 

conduct your tests. Some examples of mobile device 

testing providers: Perfecto Mobile, Device Anywhere, 

Keynote as well as other options. Do your research 

before providing a budget to build your own test lab. I 

personally do not advocate one company over another. 

You will need to do your research to find which 


company works best for your mobile app and testing 

approach. 

Checking the notification functionality involves 

reviewing whether or not the software receives a 

message and reads the protocol to accept the message. 

The software then generates a notification to the 

operating system to display that notification, however it 

was designed to be displayed. Now, the test case ideas: 

1. End to end positive functional test 

2. Timing/Response: How soon does the software 

receive the message to display the notification and how 

long the actual display occurs? 

3. Interruptions: Software receives the message to 

send another message to the Operating System to 

display the notification but before the message is sent to 

the OS, a phone call occurs. Does the notification still get 

displayed or does the phone function need to end the 

call? What if your device receives another notification 

sent to the OS but the notification message to the OS was 

sent after your mobile apps, but the 2nd notification was 

displayed? Your notification was never received or 

displayed until much later or perhaps if another 

notification needed to be sent? 

4. Display of Notification: With a low battery, does 

the notification display function change at all? If the 

display is supposed to be both audio and visual, is only 

one type of notification displaying the notification? 

What if the device is very hot from use or charging of the 

battery, or both, the notification behavior changes? 

5. Resources: Your device’s storage is almost full. 

Does the software’s notification messages generate the 

display of the notification? What if you have several 

notification messages needed to generate the display? 

How does your application handle the lack of 

resources? What’s the limit the App needs before 

problems of notification arises? 

Now we can see these topics are all related specifically 

to mobile testing because the notification function itself 

is primarily a mobile function and the app under test. 

Would a hardware tester test how software behaves 

based on resources? Software affects the hardware and 

vice versa but when it comes to understanding software 

behavior, the mobile software tester has to be a talented 

test designer. Why? Because rarely are the 

requirements written with consideration to hardware 

and operating system limitations. We don’t know what 

we don’t know. Mobile testers need to be a bit like 

Christopher Columbus; not respected for the 

complexity of the testing, the test design are given no 

time to complete their exploring. Changing up various 

hardware and OS conditions can help to flush out more 

information of the software behavior. And this is why 

I advocate to not just rely on automation and emulators. 

There is a need for testing directly on devices, manual 

testing, include the hardware & operating system 

conditions which can reveal buried treasure of bugs. 

Jean Ann Harrison has been in the Software Testing and Quality Assurance field for over 15 years 

including 7 years working within a Regulatory Environment and 8 years performing mobile software 

testing. Her niche is system integration testing with focus multi-tiered system environments involving 

client/server, web application, and standalone software applications. Mobile software testing includes 

mobile native apps, mobile hybrid apps, mobile web applications and mobile websites. Jean Ann is a 

consistent speaker at many software testing conferences, a Weekend Testing Americas facilitator as well 

as making guest appearances. She is currently a columnist in Software Magazine as well as conducting 

webinars on mobile software testing and writing for various publications. She is always looking to gain 

inspiration from fellow testers throughout the software testing community and continues to combine her 

practical experiences with interacting on software quality and testing forums, attending training classes 

and remaining active on social media sites. In her free time, Jean Ann enjoys watching and participating 

in various sports and in particular is a former competitive figure skater and working to gain back her 

skills to compete once again. Jean Ann loves participating in the fine arts including oil painting, 

attending symphonies, opera, music concerts and Broadway caliber theatre. Jean tweets @JA_Harrison 


KEEP CALM 

AND 

POST TESTING JOBS 

@ 

TestingCircus 

Submit #testing jobs for free and hire great testers who care about testing. 

http://www.testingcircus.com/submit-jobs/ 

Current Testing Opportunities 

http://www.testingcircus.com/jobs/ 


Testing The 

Test Reports 

- Parimala Hariprasad 

I was one of the judges on STWC World Cup Asia Team. 

I had the privilege to review bug reports and test reports 

of several teams. I was appalled at the quality of test 

reports from several teams. Some were a copy paste of 

all the bug reports, some talked about task breakup, and 

few others had all information that was useless to 

stakeholders who could make decisions based on the 

test report. Hence, the need for this article. 

What is a Test Report? 

A Test Report is a story – about the product, about 

testing and how well / how poorly testing was 

performed. Test Report is a window of information to 

stakeholders. It is critical that test reports are presented 

well enough for them to make suitable decisions. In this 

article, I would like to highlight important components 

of a test report and what sets a test report apart from the 

run of the mill reports I described at the beginning. 

Components of a Good Test Report 

Overview 

Summary – brief summary of what the report contains 

along with all sections (No, this is not same as Table of 

Contents) 

Mission 

What do you plan to accomplish through testing? Find 

bugs? Identify risks? Clear blockers? Provide 

information to stakeholders? Which stakeholders? 

Answering these questions will help you understand 

why you set out testing in first place. 

Context 

What is the context in which the product/project is 

tested? What are the Assumptions? What are the real 

world conditions? 

Test Coverage 

- Coverage 

Tell stories of how testing was done. What types of 

coverage were accomplished, techniques applied, tools 

used, results found and so forth 

- Feature Coverage 

Mindmap based visual tool that lists out all the 

features that are tested. Features that are not 

tested, blocked or paused will have 

corresponding interpretations. 

-Platform Coverage (Test Environment) 

Test environments include hardware, software, 

application specific configurations, device 

settings in case of mobile devices, list of 

tools/technologies/languages used and so forth. 

The coverage can be broken into below subcategories: 

- OS Coverage 

Operating systems that are covered 

during testing 

- Browser Coverage 

Browsers that are used for testing 

- Device Coverage 

Mobile devices with different 

manufacturers, device models, device 

sizes, screen resolutions, network 

carriers that are covered during testing 

- Data Coverage 

Data dependencies handled as part of 

one time test data setup or for ongoing 

testing 


- Testing Techniques used 

Highlight different test techniques used to 

perform different tests. This can be showcased in 

a mindmap for better visibility 

Testing Status 

A summary of testing status and test results for all tests 

done is an important aspect of test reporting [No, this is 

not a count of Pass vs Fail]. This contains a detailed 

story about the overall health of each and every feature 

in the product/project. This also contains a summary of 

what was tested, to what extent testing was done, what 

kind of bugs were found, what risks do they bring and 

how it might impact users. Testing status must keep 

target stakeholders in mind and present status that will 

highlight potential risks and problems which will help 

them make key decisions. 

Risks 

Why did you choose to perform some tests over others? 

How did you prioritize? It is important to say why you 

covered tests and how critical they were. Highlight 

which tests were not performed and how they might 

contribute to the overall risk of the product also needs 

highlighting in this section. Identifying a list of 

problems in the product beforehand, planning tests to 

mitigate these risks using a mitigation plan to reveal 

these risks is highly beneficial. 

● Stakeholders – Who does it affect? 

● Who are the stakeholders? 

References 

This section includes all the reference documents, 

detailed test reports, detailed bug reports and related 

summary documents on the product that might be of 

further interest to stakeholders. 

What Story Do You Intend To Sell? 

Test Report is a sneak preview into what testers think 

about the state of the product. It is an opportunity to 

alert stakeholders about current risks in the product 

contrary to the idea of risks they may have. It talks about 

about how things can get better if tester’s information 

was used effectively. It helps stakeholders make critical 

decisions based on the progress made during testing. 

A good test report is a window of opportunity. What 

does your test report look like? 

Parimala Hariprasad spent her youth studying people and philosophy. By the time she got to work, she 

was able to put those learnings to help create skilled testers. She has worked as a tester for over 11 years 

in domains like CRM, Security, e-Commerce and Healthcare. Her expertise lies in test coaching, test 

delivery excellence and creating great teams which ultimately fired her because the teams became 

self-sufficient. She has experienced the transition from Web to Mobile and emphasizes the need for 

Design Thinking in testing. She frequently rants on her blog, Curious Tester 

(http://curioustester.blogspot.com). She tweets at @CuriousTester and can be found on Linked In at 

http://in.linkedin.com/in/parimalahariprasad. She currently serves as Delivery Director at PASS 

Technologies AG. 


Advertise in Testing Circus 

$50 


- Read by real testers, 

Not automation bots. 

We are offering huge discounts for 12 months regular ad booking. 

***Advertisement rate starting $50/per month. 

http://www.testingcircus.com/advertise 


Modularizing 

Test Case 

Design Using 

Flowcharts 

- Llyr Wyn Jones 

Test Case Design 

When building test cases, and the corresponding data, it 

is a common practice to work out the design steps for 

each one, and for each design step, the corresponding 

test conditions. This is mostly done using Excel spreadsheets, 

and a great deal of copying and pasting is required 

to make sure all of the test cases have the correct 

data conditions. This is, as you can imagine, an extremely 

tedious and error-prone process; one wonders: surely 

there is a better way to achieve this? 

The good news is: yes, there is! However, before we 

delve into the solution, we must touch on a related 

problem with existing test case creation techniques: the 

lack of intelligent de-duplication methods. This may 

seem to be an unrelated subject, but it turns out that 

removing redundancy in test cases is key to being able 

to duplicate work quickly. 

A test case can easily be thought of as a path – a sequence 

of blocks separated by arrows (the arrows indicating 

the direction of travel). For example, 

Enter username à Enter password à Click OK à Log 

in successful 

is an example of a test case for a log in dialog, starting at 

‘Enter username’ and finishing with ‘Log in successful’. 

Another test case could look like: 

Enter username à Click OK à Log in unsuccessful 

(this could be testing the requirement that a password 

must be non-empty, for instance). Notice that two of the 

design steps are common to both test cases. In an Excel 

spreadsheet, one would create the design steps for the 

first test case, then copy and paste the relevant details 

for the second test case. This may not be too bad for two 

test cases, but when there are, as is typical, hundreds of 

test cases (with tens of different data conditions) it becomes 

prone to error: errors that are not straightforward 

to spot. 

This is where flowcharting really comes to the fore: in 

the flowcharting paradigm, design steps are linked together 

to form a flowchart, and test cases are then merely 

paths through that flowchart. 

Let us put the above example into a flowchart, with the 

corresponding data conditions): 

For brevity, we ignore the expected results (i.e. login 

successful/failed) for now. Notice that we have two 

paths through our flowchart: 


Enter username (‘JohnS’) à Enter password (‘abc’) à Click OK 

Enter username (‘JohnS’) à Click OK 

Also, notice how both ‘Enter username’ and ‘Click OK’ are only defined once in the flowchart – since both paths go 

through them, it is possible to only define them once. If it isn’t possible to define them once (there are certain 

technical reasons why this can’t always be done), a related concept called ‘Cloning’ is possible: this serves the 

purpose of establishing that two blocks are identical, and that changes made to one will be reflected in the other. 

Now, defining the test data for ‘Enter username’ will only need to occur once: that is, in the design phase in the 

flowchart itself. Building the test cases will automatically inherit all the necessary test conditions from the blocks in 

the design. This is what we mean by inheritance: the test cases inherit the properties of their individual design steps 

– it means that the majority of the work only has to be done on the design steps: the test cases then take care of 

themselves. Perhaps an easier way of thinking about this is by considering the flowchart as a form of ‘template’, 

where all the design steps are associated with test conditions, and, when the test cases are built, they are built using 

details from the template. 

In many respects, it is very similar to the existing cut-and-paste method used for Excel spreadsheets, and you may 

be wondering what the difference is, beyond this being an automated cut-and-paste operation. The key differentiator 

is what happens when test cases are changed after they have been created. 

Change Impact Analysis and Inheritance 

We have already seen that test cases inherit the test conditions from the flowchart design, but we haven’t quite seen 

the full power of that capability. Being able to design test cases without worrying about the test conditions for each 

test case – leaving that to the template to fulfil – is merely a fraction of the consequence. To get the most out of the 

flowcharting paradigm is to consider how it handles changes, both for individual test conditions and the structure 

of the overall flow. 

Let’s examine the former first, by revisiting the example above. Let’s suppose that the test conditions have been 

changed to: 

Since the test cases are merely paths through the flow, 

they inherit the test conditions from their design steps. 

In particular, they also inherit the changes in the test 

conditions. The test cases will now look like: 

Enter username (‘PeterB’) à Enter password (‘123’) à 

Click OK 

Enter username (‘PeterB’) à Click OK 

Again, the impact on two test cases is not particularly 

big, but the true value lies when you have hundreds of 

test cases: the process of going through every single test 

case, making sure that all the test conditions have been 

changed correctly, is an extremely tedious process, and 

is far more prone to errors than the copy-and-paste 

process used to build the test cases in the first place. 

Using this methodology, the changes are automatic, and 

are guaranteed to be correct by the principle of inheritance! 

So far, so simple, and we have not even leveraged the 

true power of the flowchart for the purposes of change 

impact analysis. This comes when the flowchart’s structure 

has been changed. Let us assume that the above test 

cases have been executed, and a tester realizes that the password field has not been blanked out (i.e. the user can 

actually see the password he/she just typed in). This is contrary to most log-in screens, so the business analyst then 

decides to put in an extra block just after ‘Enter password’: 


This is where the flowchart paradigm really comes into 

play, as the flowchart determines which design steps 

are related to one another – in this case, the change 

means that whenever ‘Enter password’ appears in a test 

case, it must now be followed with ‘Make sure password 

is blanked’. 

The test cases will now look like: 

Enter username (‘PeterB’) à Enter password (‘123’) à 

Make sure password is blanked à Click OK 

Enter username (‘PeterB’) à Click OK 

The only test case which has changed is the first one, 

since the second one never went down the ‘Enter password’ 

route. 

Conclusion 

In our experiences in the field, we’ve discovered that, 

using the flowcharting paradigm, great savings can be 

made by using the principle of inheritance to derive test 

cases from a flowchart design. The greatest of savings 

are made during the change impact analysis procedure: 

instead of spending hours going through test cases to 

find those that have changed then making sure that they 

are correct, it is far more cost-efficient to let the flowchart 

determine where the changes are, and fixing the 

‘broken’ test cases accordingly. 

About the Author 

Llyr Wyn Jones is a Senior Programmer at Grid-Tools, the leading Test Data Management Company. He 

has invented, developed and implemented new software solutions for multiple worldwide clients. He 

tweets at @gridtools. 


From A Tester 

to A 

Development 

Team Mate 

- Nimesh Patel 

A few years into my career as a Professional Software 

Tester, I had been working at a company with some 

great people in a nice, outgoing, dynamic environment 

as a software tester on the test team - a team of about 6 

people. I enjoyed what I did and even back then, I was 

a tester who was always looking to learn new things and 

make myself a better, more skilled tester. One day, my 

manager at the time approached me about an 

opportunity he had recommended me for - it was an 

opportunity to be a part of the Research & Development 

team at the company as the software tester. I had built 

a good reputation on the team I had started on and 

amongst some of the other teams and individuals at the 

company. He also believed that I needed a new 

challenge at the company, and I believed that as well. 

As it turned out, it was an excellent challenge for me. 

He mentioned that I would be learning a lot, things that 

would really enhance my technical knowledge as a 

software tester and that it would only help my career, an 

assessment I agreed with as well. I took a few days to 

think it over, after which I made the decision to accept 

the opportunity to join the R&D team. At the time I 

knew it was a decision that would eventually be great 

for my career and towards my goal be being a better, 

more technical, and a more skilled tester. Little did I 

know then what I know now, that my decision to join 

the team would have a tremendous positive impact on 

my career as a professional software tester. I was under 

a lot of pressure (most of it from myself), and the 

learning curve I faced was steep. Things didn’t go 

smoothly right off the bat, it was actually quite rough in 

the beginning, but as I continuously put in the work and 

effort, things got smoother and from there, things went 

great. 

Joining a team of developers 

They were now my team & I was a part of theirs... 

Now for the first time in my career, I was a member of a 

team with no other software testers on it. Instead, the 

members of my team were primarily composed of 

developers, a scrum master, and a product owner (we 

worked within an Agile Scrum software development 

framework). This was a big adjustment for me. I had 

never worked on a team surrounded by people who 

weren’t software testers. I no longer had a test manager 

(or a test coordinator) presenting my test results and 

findings to stakeholders, I was doing it myself. On the 

same account, if a development manager or lead wasn’t 

in favor of information I had found, I no longer had a 

test manager to “shield” me in this type of situation. 

The “safety net” of being around and on a team full of 

testers, was gone. This was one of the best things to 

happen, it allowed me to grow as a tester and as a 

professional. There was a lot more responsibility on my 

plate now, but I saw it as a lot more opportunity. 

I wanted to show & prove to them that I was there to 

make them look good... 

The developers I was now working with, my new team 

members, had never directly worked with me before. It 

seemed that they weren’t yet sure if I was going to be an 

obstacle for them or if I was going to contribute to the 

team. I wasn’t there to cause chaos for the developers, 


nor to waste their time having them read through tons 

of bug reports I had logged into the bug tracking tool. I 

wasn’t there to point out and glorify bugs I discovered 

due to coding. I wasn’t there to slow things down or get 

in the way of deadlines. I was there to make them look 

good - but it wasn’t enough for me to just say that to 

myself, or even say it to them. I had to show them and 

prove it to them. Over the course of a few months (and 

tons of work and effort) I did, but it took a lot time and 

a lot of learning. 

Worked with them, and took the time to learn 

I showed them that not only was I willing to work with 

them, but that I genuinely wanted to work with them 

and that I wanted to learn. I had a lot of energy and was 

really up to that task and I wanted them to see that. I 

spoke to the technical lead on the team and got his 

feedback about how I could approach the different 

developers and how I could become a valuable and 

contributing member of the team. He offered his 

insights, after which I thought about his 

recommendations and how I was going to go about 

putting my plan into action. 

I wanted to learn more about the different components 

that made up the system that the team built from the 

ground up and continued to do development & testing 

work on. I asked the developers questions about the 

different components and how they were all integrated 

together, the data and information flows, and in which 

ways they were independent from and dependent on 

each other. When the developers took time to explain 

these things to me, I always made sure to take notes. I 

informed them that I would be taking notes so that I 

could review them later to better understand and so that 

I wouldn’t need to ask them the same questions again. I 

made it a point to review the notes towards the end of 

the day, or even on my way home which sometimes 

prompted me to ask further clarifying questions. One 

thing I found extremely useful when they explained 

things to me using the whiteboard, was to draw out the 

diagrams of components, flows, and business logic, and 

other important information. I always made sure to 

re-draw the contents of the whiteboard or even take a 

picture of it. This was one of the most useful techniques 

that helped me the most when I first joined the team, to 

be able to understand the technicalities and interactions 

between the different system components. It enabled 

me to ask better questions about the implications and 

risks of the development work being done. I was able to 

think of potential problems or things nobody had yet 

thought of within the system when discussing the 

development & testing efforts of new features. I was 

able to design my tests better, and do more effective 

testing because of the knowledge I obtained regarding 

the components, and the information and data flows 

between them. As a result, I was able to focus my 

testing and coverage, which enabled me to provide 

more valuable information from the testing I was doing, 

in the available time I had to test. 

A lot of times when I was providing information about 

the behaviors I was seeing during my testing, the 

developers would access the Linux server to check 

system and error logs to get more information on what 

was happening. I took a lot interest in this as I was 

curious and wanted to see how they were further 

investigating what I was telling them from my testing. 

One day, one of the developers asked me if I had an SSH 

client on my machine and the accesses to log into the 

server myself. I was able to install an SSH client and get 

information on the accesses and permissions I would 

need to log into the server. Once I had what I needed, 

the developer took some time and explained the 

directory structures to me, and where some of the logs 

and files were located. They showed me commands I 

could use and how to use specific search commands to 

follow, and apply filters on for specific keywords I was 

looking for within the log files. I wrote down the 

directory structures and the different Linux commands 

they were using. It took me some time to get more 

comfortable navigating the different directories and 

using the different commands, but as I used them more 

regularly, and was able to find the information I was 

looking for, logging into the server to further investigate 

during testing, become one of my favorite skills to use 

from my arsenal. I was able to quickly and better 

investigate the causes of some of the behaviors I was 

seeing, and provide this detailed level of information 

back to the developers, who in turn were able to use the 

detailed information and quickly correct pieces of the 

code, or components where the problems originated 

from. The understanding of the Linux server logs, in the 

context of our system allowed me to further investigate 

during testing and allowed the developers to focus on 

their development and less time investigating causes of 

some bugs and troubleshooting abnormal behaviors. 


Paired Testing 

My team and I worked in an open space concept, and in 

an open communication style atmosphere. As the 

developers and I got to know each other better, and got 

to know each other’s working styles better, they 

occasionally asked me to log into their local machines so 

that we could do some testing on new development 

items or bug fixes before they would commit their code 

and deploy to our development and test environments. 

I enjoyed this activity, it allowed for quick feedback and 

also saved us time instead of having to deploy, test, fix, 

re-deploy and test again later. 

Other times, while testing and continuously providing 

quick, regular feedback (this was how we worked) the 

developers would come over to my desk, and we would 

test new features, existing features, and potentially 

impacted features together. This allowed us to look at 

the application or features we were testing from 

different perspectives and helped us identify and find 

bugs or the particular types of information we were 

looking for depending on our testing focus at the time. 

It was also fun and productive as one persons thought 

process often led to great test ideas from the other. 

There was one developer in particular whom I tested 

with, at his machine without the use of any UI or tool, 

but rather by looking at his code. This was actually one 

of his ideas (an awesome idea), and it allowed me to 

contribute to the development efforts in an entirely new 

way. We would chat about what the code was meant to 

do and for which feature we were developing and 

testing, and we would go through the different code 

statements, conditions and branches and work together 

to think about which logic was covered, where and 

which cases were accounted for in the code, and work 

together to brainstorm and identify cases which possibly 

were not covered. This was an entirely new way for me 

(at the time) to be able to use my testing mindset and 

perspective to work together with a developer. 

How I said things 

Early on in my career, I often saw some (a small number) 

software testers approaching and informing developers 

that they had found some bugs in the application, in a 

tone and with a facial expression reminiscent of a smirk, 

as if they were bragging and shoving the fact that they 

found bugs due to coding, in the face of developers. I 

never quite understood this, nor grasped the concept. 

Furthermore, I remember seeing the faces and reactions 

of the developers and understood the animosity 

between developers and testers in some companies on 

some teams. I knew just from witnessing this, which I 

never wanted to be one of these testers (and for the 

record, the vast majority of the testers I’ve worked with 

did not do this). I paid extra attention to the words I 

used, how I used them, and the tone in which I used 

them. 

I never walked up to any of the developers with a smirk 

on my face and said something along the lines of “Hey 

I’ve found some bugs in the application and broke your 

code”. I respected software and developers way too 

much. I considered the working and communication 

style on our team (open communication with a focus on 

quick and regular feedback) so that when I found bugs 

or something not working “correctly” I would always 

try to find as much information I could supporting the 

behavior I was seeing regarding the bug and its extent. 

I made it a point to always tell the developers I was 

working with, in an informal way, and offering for 

them to come take a look at my observations at my 

machine. Depending on what the behavior was that I 

was observing, and in which component it was likely 

taking place in, I often asked the developers if they had 

committed and deployed the code for that specific 

component or feature yet. I also learned the check in, 

check out and deployment process and system we 

used, therefore I would also go check myself at times. 

The point was, I was always communicating in an open 

manner and in a non-threatening tone. I focused on 

communicating in a helpful manner, for example, “Hey 

can we look into this a little further because something 

doesn’t seem right”. 

I also learned when to bring things up. We worked in 

an Agile Scrum development framework, therefore I 

made sure I was always explicit (yet respectful) in my 

updates. If there was an issue I had discovered that 

would require some additional time (more time than 

usual) for the developer to come to my machine so that 

I could show them my findings, along with supporting 

information from my investigation, I would mention it 

in the morning stand up and ask a timeframe in the day 

that we (together) could look into it further. I think this 

showed the team that I wasn’t just finding bugs, 

reporting them and cleaning my hands of them - but 

that I wanted take the time to show them, and work 


with them to resolve them. If there was a discussion I 

had with a developer the previous day, and I was still 

unsure of the outcome of the discussion because it still 

somewhat contradicted my understanding, I would 

bring it up at the morning stand up (so that it could be 

brought to the attention of the correct people to be taken 

offline). I would explain my initial understanding and 

where the contradiction still remained based on what 

was discussed. This helped with transparency and for 

the whole team to chime in, and open up the discussion 

to determine if we were indeed all on the same page with 

the same understanding. In some cases we discovered 

that understanding on some things weren’t completely 

unanimous. Most importantly, it didn’t attempt to put 

anybody on blast. The approach I used in my 

communication with the team helped me become a 

welcome member of the team, and be recognized as 

contributing member and team player. 

Got to know them... 

Just as I was extremely passionate about Software 

Testing and was always looking to enhance my skills, the 

developers on my team were equally passionate about 

Development. Over time, the understanding of being 

truly passionate about one’s craft allowed us to have an 

even better understanding and respect for what the other 

did. 

What they believed in and practiced as Developers 

Some of the things I spoke about to the developers on my 

team were their backgrounds as developers, where their 

interest in software and development stemmed from, 

how they got started and what they believed in and 

practiced as professional developers. It was interesting 

to hear the types of systems that they had helped 

develop before they had started working at the company 

we worked at, what types of industries they had worked 

in, what coding related work they did on their own time, 

and how they were increasing their knowledge and skill 

level. I had numerous discussions with them about their 

thoughts on information technology and software, this 

made for great and very insightful conversations. What 

made the conversations even more interesting was the 

fact that my discussions with each of the developers was 

different with each individual given the fact that their 

interests, backgrounds, coding they did outside of work 

were unique. Over time this led to a friendship between 

myself and each of the developers, unique friendships 

(that exist to this day even though we don’t work 

together anymore). 

Going out for lunches 

From time to time I also went out to lunch with the 

developers on my team, often on a one to one basis. 

This allowed us to informally chat about the projects, 

the user stories and features we were working on, 

different partners we were working with and how that 

was going, as well as technical implications and 

decisions. This gave us a chance to brainstorm about 

the aforementioned topics and get into deep 

discussions about them. If the lunch was with the 

technical leads on the team, they always made sure to 

ask about my feedback for testing matters, and again 

that led to great informal discussions regarding testing 

matters in the context of our team. Over time working 

with the team, and the manner in which I did, focusing 

on integrating myself as a valuable and contributing 

member of the team and taking the time to get to know 

the developers, helped me build credibility (within the 

team) and build a great trust level amongst the 

members of the team - all of which helped us run like a 

well oiled machine and at the same time, having fun 

learning from each other and working together. 

Final Thoughts 

As I mentioned at the beginning of this article, I knew 

this would be a great opportunity for me to accept, but 

little did I know how great the opportunity would 

actually turn out to be, considering the amazing impact 

it ended up having for me as a professional and as a 

software tester. The things I learned, both on the 

technical and software side, as well engaging with and 

working on a team with individuals who were not just 

software testers, was superb. The experience was 

invaluable - to this day one of the greatest work 

experiences of my career so far. 

I have worked at different companies and on different 

projects with different teams and different developers 

under different conditions. At my current place of 

employment, I work very closely on projects with both 

software testers and developers, and have a great 

working rapport with both my fellow software testers 

and with the developers. I use many of the things I 

learned and applied in my experiences, on a daily basis, 

and encourage other testers on my team to do the same 


(I try to tell different testers in different ways as 

everybody has their own style). At my current place of 

employment the efforts have led to a cooperative, 

productive, and fun working environment. My efforts 

have also been recognized by others. I’ve been told by 

my managers that the developers on the projects I work 

on enjoy working with me, given my testing skill, and 

how I engage them throughout the projects we work on 

together. 

Working well with talented teams composed of 

individuals in different roles, focused on different 

activities is extremely important as companies are 

slowly starting to realize that testing isn’t something 

that should be done alone, or after development is 

complete, but rather that testing is actually an 

important and valuable activity that goes hand in hand 

with development. As this becomes more common, it 

will be important for software testers to evolve and 

learn to enhance their skills and how they work with 

other members of the team - and I don’t mean just other 

software testers. 


Nimesh Patel is an experienced, passionate and skilled Software Testing Professional based in Montreal, 

Canada with 9 years of experience in Software Testing and Quality. He is a strong believer of the context 

driven testing approach and applies it in his testing, while continuously learning and improving his skill 

set by applying the skills, concepts and ideas driven by the approach. As a hands-on Software Tester, 

Nimesh is actively involved in the testing efforts of all the projects he’s involved with and regularly 

collaborates with both team members and project stakeholders. He has tested different types of software 

applications with different testing missions and his specialties include testing web, mobile, insurance, 

financial and SOA based software applications. Nimesh is also an organizer for Montreal Insights Into 

Software Testing - a Software Testing peer conference & workshop held annually in Montreal, Canada. 

Nimesh tweets at @QualityCaptain. 


Story of 

Security Testing, 

Myth Busters 

& More 

- Santhosh Tuppad 

I often hear people asking me, “Santhosh, coach me on 

security testing / hacking” and my response has been, 

“Demonstrate some things to me so that I can invest my 

time on coaching you” and most of them have not come 

back to me. Now, it is lack of interest or passion, I do not 

know and not interested to know. My gut-feeling says 

that, it is the passion one carries for hacking instead of 

learning it to get a better job or earn more based on the 

myths that the industry has. I started to hack when I was 

16 and it was not a course that I went for, but interest. 

And today, I feel that to learn security testing; one need 

to have interest without any other expectations like 

money, better job offer or any other thing. 

I am not a traditional type of ethical hacker, but to me it 

is like growing in slum of hacking world where I did not 

use any techniques, but learned in a unique way 

because hacking was so interesting to me that I used to 

dream about hacking credentials or hacking web 

applications. I have never feared anything while 

learning to hack. If I had fear and was educated about 

the cyber laws, may be I wouldn’t have learned it so 

well like I do now because at the teenage may be I 

would have got scared and left my learning. It was good 

that I did not choose any mentor at that time because he 

/ she would have told me about cyber laws and my 

learning path may have changed unfortunately. I am 

happy that I did not have a mentor or coach and I 

learned it in my own style. Nowadays, it is very 

fashionable to say, “I have a mentor or I am being 

coached by so and so person from the industry”; well I 

have something different to say here, “Not necessarily 

you need a coach / mentor, what you need is a GENE to 

learn it and a HEART to beat for hacking”. 

Scientists in History Never Had Certifications 

Now, let us speak about certifications in Ethical Hacking 

or Security Testing. People started telling me to do 

certification in ethical hacking and I said, “I know more 

than what a certification guy can do, In fact, my skills 

are nowhere comparable to the person who is certified 

ethical hacker. I respect skills over certificates. Many 

organizations look for certified ethical hackers who may 

just know the surface of hacking and not in depth 

knowledge about software security. Now, black-hat 

hackers compared to most of the certified ethical 

hackers know much more about attacks, techniques and 

keep on exploring while certified folks may just keep 

doing the same things when they are on project. Now, 

this is a BIG problem that information security industry 

is facing. It is like, “Hackers are born and they are not 

made”. By saying this, I am emphasizing on passion 

element that needs to exist in a person to learn hacking 

/ security testing. 

Tools Are Never Enough 

Many people ask me these kinds of questions which 

kind of doesn’t make sense to me, “Which tool should I 

use to crack the password? Which tool will help me to 

get Wi-Fi password? Which tool will help me hack 

Gmail, Facebook, Yahoo?” and many other questions. In 

my security testing workshops as well, people do not 

want to listen to listen to the different stories which 

helps them to get the mind-set of hacker, they are so 


wanting to start using tools like ready-to-eat food. They 

like straight forward answers and not really exploration. 

I recommend that people need to first get the mind-set 

and then skill-sets can be acquired. Or else you may 

learn 100 tools, but you still do not know how to use 

them because you are not getting ideas. Like McLuhan 

says, “A fool with a tool is still a fool” would be apt for 

such people. 

OWASP Top 10 Attacks Are Not Sufficient 

OWASP Top 10 attacks are major attacks that happen in 

most parts of the world compared to other variants of 

attacks. It doesn’t mean that, security testers need to stop 

at these OWASP top 10 attacks. And again in OWASP 

top 10 attacks, there are different combinations which 

need to be covered and again testers fall in to the trap of 

not testing them. Testing itself is exploratory and 

security testing being one of the quality criteria has to be 

exploratory! What OWASP gives is guidelines and 

cheat-sheets which are powerful, but going beyond them 

is what makes a great security tester who is competing 

with black-hat hackers. 

Understanding How Computer Works is The Key 

It is added value to your skills if you understand the 

hardware and software part of your computer. Hacking 

is not only with respect to software, but understanding 

how your keyboard works or your hardware works 

could help in hacking software. Example: I learned about 

“How keyboard works?” to understand better about 

keyloggers where they record each and every keystroke 

from your keyboard (And this is one way how someone 

can install a keylogger on your computer and they can 

keep receiving the logs of your activity including your 

passwords because it is basically recording every 

keystroke as password is typed using keyboard. Explore 

more!). I would like to mention about the source which I 

find interesting, http://howstuffworks.com/ 

Taking The Learning Forward 

As hacking or security testing flows in my blood along 

with other quality criteria of software testing, I 

consistently practice by thinking, reading, conversing 

with people, delivering workshops and lot more! It is 

very easy that you may feel you are exhausted with 

ideas, well that’s the beautiful state to be in. When you 

feel ideas are exhausted, that’s where black-hat hackers 

make progress in thinking better. You can do better too, 

do not give up! 

This is more of mind-set related article which is one of 

the critical skills required for a hacker. Stories help reveal 

a lot and this is my story which you may use it for your 

learning. Remember this, “You got to be a black-hat 

hacker to be a better white-hat hacker” 


Santhosh Tuppad is the Founder at Test Insane Software Testing Services. He is known for his testing 

skills around the globe. Santhosh Tuppad has 5 years of experience in software testing industry. He has 

won several testing competitions and people die to work with him. He believes in technical skill-set and 

has been a hacker since 16 while he fell in love with computers at the age of 12. He is a die-hard fan of 

his heart and always follows it come what may. He blogs on Software Testing at http://tuppad.com/ and 

has also been a contributor for several software testing magazines on the web. He has been speaker at 

various conferences and also contributes to the software testing community by coaching testers on 

security testing for free.His personal passion include driving, fitness, off-roading & more. Follow him on 

Twitter @santhoshst 


CAST 2014 

- The Best Testing 

Conference I Have 

Ever Been To 

- Simon ‘Peter’ Schrijver 

This years CAST conference in New York was awesome, 

even epic. It was perhaps the best conference ever I have 

been to. The three previous CAST I have been to (Seattle, 

San Jose and Madison) were great. Most other 

conferences I have been to are too commercial and 

related to certification institutions. This is not at CAST. 

As a tester you can speak freely and share your 

experiences with others. You can talk to everybody. 

To show you how open a conferrence such as CAST can 

be I show you some selfies I made with some of the 

participants. I categorized them a bit to give more 

context to my story. 

First the organizers of the conference; Bernie Berger, 

Anna Royzman, Keith Klain and Paul Holland. All well 

known in our community. 


What is also possible at CAST, is you can to talk some of 

the great voices of our test community. People like Fiona 

Charles, Anne-Marie Charret, Seline Delesi, Matt 

Heuser, Ben Simo, Matt Barcomb, Michael Larsen, John 

Stevenson, James Christie, Doug Hoffman, Michael 

Bolton and James Bach. You come with you story or 

experience and they will give you feedback. They can 

guide you to reference material they have themself or 

they guide you to sources of material that will benefit 

your work as a tester. 

I was this year selected as a facilitator for the talks and 

even a keynote. I had the privilege to facilitate the talk 

of Ale Moreiros, Jean Paul Varwijk, Huib Schoots, 

Parimala Hariprasad, Jay Philips and Jean-Ann 

Harrison, Ben Simo, Richard Bradshaw and Justin 

Rohrman. 

But what this conference also makes interesting is you 

meet old friends from previous CAST conferences and 

even other conferences. People like Alex Bantz, Helena 

Jeret-Mäe, Tony Bruce, Martin Hyne, Curtis Pettit, Peter 

Walen, IlariHenrik Aegerter, Jason Coutu, Lars Sjödahl, 

Stephen Blower, Markus Gärtner, Iain McCowatt, 

Thomas Vaniotis, Christine Wiederman, Perze Ababa, 

Claire Moss, Henrik Andersson, Erik Davis, Maria 

Kedemo, Ben Kelly, Eric Proegler and Griffin Jones. 

You also meet new people to which you talk to during 

the conference or you only know via twitter. Some new 

friends I made are Josh Meier, Rachelle Below, Nathalie 

Bennet, Katrina Clokie, Kate Falanga, Mike Lyles, 

Damian Synadinos, Shak Schiff, Nithin Shenoy, Smita 

Mishra. 

One special person I have to mention is the masterfacilitator 

and a good friend of mine, Rich Robinson. He 

did a fantastic job this year making sure that all the 

speakers felt comfortable by assigning them good and 

helpful facilitators. 

The CAST conference is sometimes a reunion, because I 

meet people who find CAST the most important 

conference and spent their limited budget to be at 

CAST. I heard even that some persons pay the 

conference out of their own pocket. When I determine 

my conference budget and time, I first plan CAST. After 

that comes the rest. I even went that far that I was away 

during my wedding anniversary and even my own 

birthday. 

CAST also organizes activities which are organized in 

the evening, when the regular daily activities are 

finished. People also join together and have diner with 

eachother. Some of them also organize LeanCoffee, at 

7:00 AM in the morning. Talking about test subjects 

which have the interest of the group. We even have a 

Test Retreat organized by Matt Heuser on the Saturday 

before the start of the CAST conference. It is not related 

to CAST but and extra 1 day conference you can attend 

and make your stay a bit longer. 

This years CAST conference had for me two topics that 

resonated with me for a while. It is the keynote of Trish 

Khoo where the subject 'a tester must learn to code' 

came into the discussion. This topic really has the 

attention of the test community. Big new-age companies 

like Google and Facebook say they don’t test of have no 

test team, but if you read between the lines, test 

activities are still going on over there. 

Further the talk of Richard Bradshaw about the subject 

of Test Automation is not replacing people, is not faster 

testing or not more time for exploratory test. The goal of 

test automation is to support your test and not replace 

your manual test. 

The three days were very energetic. A lot of 

conversations. CAST stands for the fact that they truly 

put the CONFER in the conference. See ya at CAST2015. 


Simon ‘Peter' Schrijver is a very experienced all-round tester, who has worked since 1997 as tester, test 

coordinator and test manager. He has several years of experience using SBTM as a test approach. Since 

2005, Simon works as an independent consultant. He visits annually several conferences to keep his 

knowledge up to date and where necessary, broaden/deepen his knowledge with (self-)training. 

Simon is also an active member of TestNet and (co-founder) of the Dutch Exploratory Workshop on 

Testing (DEWT). In these communities of enthusiastic testers, he is active with peers and discuss with 

them about the testing profession to keep up to date and improve them selves. He tweets at 

@SimonSaysNoMore 


The CAST 2014 

Conference Just 

Took Place and I 

Wasn’t There! 

- Teri Charles 

I so wanted to be at CAST (Conference for the 

Association for Software Testers) this year, but it wasn’t 

meant to be. Like so many other testers around the 

world, I was not physically there, but was at home 

wishing I was. But thanks to CAST and some great work 

on their part, those of us who weren’t present had a 

chance to 

experience the 

excitement of one 

of the best testing 

conferences on the 

planet. A live 

stream was setup 

to show the 

keynotes, several 

other sessions (but 

not all of course, 

gotta get yourself 

there!), and a 

nightly recap with 

different guests 

each night. And I 

for one could not 

be more grateful to CAST for doing this! Here’s what it’s 

like to participate in CAST without actually being there. 

Things got started early Tuesday morning in my time 

zone (Mountain), the first day of the two day conference 

sessions. I signed on to the webCAST, really not sure 

what to expect. How does this work? Would I really be 

able to see or hear anything? Would there be a good 

connection? Would I be able to time bathroom breaks?! 

As I waited for things to start, a very cool thing began to 

happen. Other testers from all across the world in many 

different time zones began to pop into the chat section 

that was setup on the streaming site (uStream). People 

started to tentatively type out things like “testing, 1, 2, 

3” to see if the chat was working and several of us 

started saying hello to each other and connecting with 

one another. I felt excited that I was going to be able to 

share this experience with other testers, even though we 

weren’t physically 

in the same room 

or at the 

conference. Not 

being in New York 

at the conference, I 

immediately found 

some comfort that I 

would at least be 

able to participate 

in this way. And 

then just like that, 

the webCAST came 

on, the audio and 

video were 

excellent, and the 

conference began! 

First, announcements and introductions were made. But 

wait…what were these commercials that began to pop 

up? If you were participating in the webCAST, you 

know what I mean. The product that was used for the 

stream is free for users, but that means commercials will 

come on (which really is a small price to pay), and yes, 

that means right in the middle of someone’s session. But 

the chat session lit up with many of the testers letting 

others know about which browsers to use for ad 

blockers or to let them know they could subscribe to the 

product for $3.99 a month and then cancel as soon as the 


conference was over (which is what I did). Things were 

back on track and commercial free! 

For the next two days, I watched almost every minute of 

the live stream. Some sessions I watched on my laptop, 

and some I watched on my flatscreen TV using my iPad 

connected to my Apple TV. Fancy! It was wonderful to 

actually get to see and listen to people that I have been 

following on Twitter, reading their articles and blog 

posts, chatting on Skype, and participating on things like 

Weekend Testing. These are some of the best testers in 

the world, and it was a treat to have the opportunity to 

see, listen and learn from them on subjects such as: 

thinking of testing as a ‘performance culture’, testing 

standards, adding value in agile, exploratory testing and 

NASA, adventures with the buggy HealthCare.gov site, 

test automation, adding ‘art’ to STEM (STEAM), and 

much much more. And there was also the unexpected 

treat of watching people I recognized walking past the 

cameras! 

But being that we’re in the social media age, we also had 

Twitter to give us all another way to be involved. Many 

attendees that were at the conference were tweeting 

excellent highlights from the sessions that were not live 

streaming, so those of us online were able to hear what 

was being presented in those sessions. And those of us 

online were also tweeting our thoughts and feelings on 

the sessions we were able to watch, which the CAST 

attendees enjoyed as well. And to add to the cool factor, 

during the question/answer portion at the end of each 

streamed session, those of us online were able to tweet 

questions using the “Tweet Printer” to whomever was 

speaking and listen to it asked and answered live! From 

our mouths to their ears! 

It’s not my intention to slight anyone’s session because 

they were all fantastic, but I have to say, my favorite was 

Ben Simo’s session on his experience with the 

HealthCare.gov site. Ben’s story is riveting and as I 

tweeted after watching his session, this was a master 

class in testing. Ben started out like so many others in 

the United States looking for health insurance for a 

family member, but he very quickly saw (like so many 

others!) how horribly buggy the site was. Ben couldn’t 

help himself and his tester hat came on. He not only 

kept finding things, he blogged about it. You can only 

imagine how excited the government was about that! I 

plan to watch this several more times and take notes to 

learn from him and improve my own testing. And I also 

plan on suggesting to other testers to watch this when 

they want a great example of exploratory testing. This 

session along all of the CAST 2014 videos can be seen at 

https://www.youtube.com/playlist?list=PLQB4l9iafcel 

XpJnK6IyDsoFeEb1icqrl 

Last but certainly not least, one of my favorite parts of 

the webCAST was the nightly recap. Benjamin Yaroch 

and Dee Ann Pizzica did an amazing and very 

entertaining job talking about that day’s sessions as 

well as interviewing several of the conference speakers 

such as Alessandra Moreira, Ben Simo, Karen Johnson, 

James Christie, and others. It was a very nice informal 

way for those of us not at the conference to get a deeper 

experience of how these testers thought. It was very 

interesting listening to them “just talk” about whatever 

was on their minds as the conference attendees mingled 

behind them. 

Yes, actually physically attending the CAST conference 

would be the best experience, but if you are unable to 

go, watching the webCAST is a great way to 

participate. I am determined to go to a CAST 

conference in the future, but the live stream gave me a 

glimpse of what the experience must be like which I 

can’t thank CAST enough for. And I cannot wait to be 

there! 


Teri Charles has been a Software Tester for over 10 years. She is a Context Driven Tester, organizer of 

the Boulder QA Meetup, BBST Foundations graduate, Rapid Software Testing (RST) class with James 

Bach, a Per Scholas mentor, and a volunteer/instructor with GDIBoulder. Teri's blog can be found at 

bouldertester.blogspot.com and she regularly tweets at @booksrg8. 


ISO 29119 

An Important Message to Testers 

Last year the International Organization for Standardization released the first three parts of the ISO/IEC/IEEE 29119 

Software Testing. Two further parts are due to be issued during 2014 and 2015. 

ISO 29119 is marketed as an "internationally agreed standard". This term may give the impression that the standard 

has been agreed by the testing community and enjoys broad support. Intentionally or otherwise, this is an implicit 

claim that the standard represents the testing profession as a whole. This may encourage politicians and regulators 

to mandate the use of 29119 in certain industries, on the belief that the matter of "how-to-test" has been settled. It 

may spur organisations into adoption, assuming that, when they implement the standard, they are making use of 

the best the testing profession has to offer. It might encourage some buyers of software to mandate the work that 

they commission has been tested in accordance with the standard. And if you believe the above is simply fanciful 

speculation, you need look no further than ISO 9000 for an example of how a standard was adopted by more than 

a million companies due to such political intervention and market coercion. 

Given the potential ramifications of such a claim, how do ISO ensure that there is international agreement? Their 

standards are drafted by a committee composed of individuals from various countries. These drafts are reviewed 

by numerous other committees organised by national member organisations. This review process is meant to 

ensure that standards are the product of consensus, or at least, a consensus amongst those who participated. 

But does such a process support the claim of representing testing as a whole? Of representing YOU? No. 

"Internationally agreed" means nothing of the sort; it means that a relatively small group of people, from various 

parts of the world, have come to some agreement as to how THEY view software testing despite what YOU might 

think. If you are on the outside, your view doesn't count. If you are on the inside, you get a say - at least until you 

disagree. 

Yet ISO, or at least some of its claims, seem to aspire to something more. ISO define the consensus that they seek as 

"general agreement, characterized by the absence of sustained opposition to substantial issues by any important 

part of the concerned interests”. 

We are testers. We are deeply concerned about the state of testing today, and deeply concerned about how it 

develops in the future. We oppose this standard, on the grounds that standardising a highly variable creative 

activity is fundamentally flawed, that doing so will increase the cost and drive down the value of testing, and that 

standardisation will inevitably stifle the development of our craft. We oppose this standard on the basis that there 

is no general agreement. For these reasons we have started a petition calling on ISO withdraw those parts of the 

standard that have already been issued, and suspend publication of the remaining parts. 

Many testers stand in opposition. Our petition has already been signed by more people than there are members of 

the ISO working group who drafted the standard. Many more are ignoring ISO 29119, not because they accept it, 

but because they hope that it will not affect them. This cannot be taken as tacit consent. 

Will ISO listen? Or will they choose to ignore those who oppose? The answer will turn on whether they consider 

the dissenters to be an "important part" of the testing profession. 

Do you oppose this standard? Do you want your voice to be heard? Or are you willing to be deemed unimportant 

by ISO? 

To find out more, links to articles discussing ISO 29119 can be found here: 

http://www.commonsensetesting.org/stop29119/ 

Please support the #stop29119 movement. You can do so by signing the here: 

http://www.ipetitions.com/petition/stop29119/ 

- Henke, Iain, Ilari, Johan 

The Board of the International Society for Software Testing 


Have something to say about #testing? 

Consider submitting your testing article to us. 

Reach out to thousands of real testers worldwide. 

Future Edition Themes - 

● Testing in Cloud - (Last date of submission - 20 th September) 

Our Recent Contributors - 

Write to us - article@testingcircus.com 

www.testingcircus.com

Still relying on 

reading 


from tweets 

& facebook 

updates? 

To Subscribe 

Click Here 


www.testingcircus.com 

Subscribe 

just with your 

email id and 

get the 

magazine 

delivered to 

your email 

every month, 

free! 



Book Reviews 

BOOK 

WORM’S 

CORNER 

This is our anniversary edition. And hence, reviewing a book that’s 

responsible for this anniversary. A book responsible for anniversary? 

Yes. You read it right. The book inspired this entire column and started 

it all for me. “Testing Computer Software” by Cem Kaner. This was the 

1st book that I read on Software testing. Lucky me. The book got me 

hooked and was followed by many other books. 

I would request the reader to read this with an open mind. As a person 

with 30+ years of testing experience quoted, “a mind is like a parachute; 

it works when open”. Though this book is on testing, it does not look 

like it was a book written for only Software testers. What works is that 

this book gives you a good idea of how software testing was done in the 

Mid-80s and early-90s too. That will help you understand how Software 

testing evolved with time. 

If you have your own preconceived notions about testing, then this 

book will not work for you. It gives the author’s perspective of Software 

Testing. 

There will be a lot of concepts and definitions; my request to you is to 

understand the concepts and definitions and not assume those definitions 

are used worldwide. If you are from the ISO/SEI process schools, 

you may feel short-charged due to the lack those process-school recommendations, 

but I would still encourage you to give it a read and finish this book. You will emerge that much stronger 

since you will know what the process-schools don’t talk about. That will help you merge the best of both worlds and 

implement them in your projects ---- that’s where I think this book would help you. 

This book has multiple editions; instead of trying to read the latest edition, I would request you to find and get your 

hands on the 1st edition. Having been published in the late 80s, this book was then a bible of sorts to the testers when 

Software Testing was not as big as it was today. Getting your hands on this edition would mean you can read and 

appreciate the content which was edited out or added in the later editions. 

At the end of the book, you would be left wondering if you’d be a better student of Software Testing if the author had 

taught you Software Testing!!! Buy it here. 

Love, 

WoBo 


Become our fan - 

https://twitter.com/_sahi 

http://www.facebook.com/sahi.software 

Request a free demo by sending us an email at support@sahi.co.in 

http://www.sahi.co.in

A Fake Tester’s Diary 

http://www.testingcircus.com/category/a-fake-testers-diary/ 

Part 45 

Not My Job 

ISO 29119 --- The latest big thing. One set of people are 

supporting it. A second set of people are opposing it. I 

have tremendous respect for both sets of people since 

they are having an opinion and are willing to voice 

their opinions to support or oppose 29119 (as they see 

fit). However, there exists a third set of people who are 

indifferent and do not offer 

an opinion. They seem to 

say --- “It’s not my job”. 

Those are the set of people 

that I am worried about. If 

you are reading this diary 

entry, then I believe that 

you belong to either the 1st 

or 2nd set of people. My 

request to you is to find 

out at least 5 members 

from the 3rd set and ask 

them for an opinion and 

request them to express 

their opinion. ISO 29119 

can potentially change the 

world of Software Testing. 

Please have a healthy 

debate to be or not to be. 

Don’t be indifferent. 

In the anniversary edition, 

thought it would be good 

to write about why I have 

a job. What am I supposed to prevent? Am I expected 

to find bugs or prevent bugs? I don’t have the answers 

to all of this. But I what I know is that I am expected to 

prevent some of the below disasters. 

Mars Orbiter story 

A 125$m budget Mars Orbiter. The project had 

engineers working from around the world. These 

engineers did not effectively communicate with each 

other. Some of them were working in the metric 

system while others were working in the US imperial 

system. Their inability to communicate with each 

other ultimately caused crash of the orbiter into the 

Martian atmosphere. 

The Comet Jetliner Crash 

later. 

The trains of France in 2014 

Comet Jetliners had two 

windows blown in midflight. 

This was caused due 

to square windows in the 

flight. Metal fatigue 

caused cracks in the 

window edges; due to this, 

pressurized cabins 

exploded. 

The Millennium Bridge 

problem 

The 1st pedestrian bridge 

opened in 2000. It closed 

within 2 days. A wobble 

was identified under the 

visitor’s footsteps. This 

was caused by human 

tendency to match foot 

steps to the span sway to 

keep balance, magnifying 

lateral movements. This 

was fixed and reopened 

France inaugurated a new fleet of trains in 2014. After 

the trains were launched, they found that the trains 

were too big to fit into the stations. Someone forgot to 

do a “reality check” and they are now trying to trim 

back the rail platforms. The lack of coordination 


etween the 2 state rail bodies of France caused this 

“mind-boggling” and “tragically comical” disaster. 

On the flip side, below is a story where a disaster was 

averted by an undergraduate student. 

Citi Group Center in New York 

When Citi Group’s New York headquarters was built 

in 1978, at a late stage, an undergraduate student 

identified that there was a design flaw. He identified 

that the architect did not account for wind loads when 

the wind blew from a specific direction against the 

corners. This meant that the building could effectively 

blow over in windy conditions. The architect listened 

to the student and modified the design to fortify the 

building. The building still stands. 

Keep Calm and Be Indifferent NOT 

Now, these all these projects would have people with 

varying designations; disasters could have been 

prevented if someone had not said “NOT MY JOB”. 

The undergraduate student working for the Citi group 

building could have done the same; but he took the 

problem up to the desk of the Chief architect. Saying 

“Not My Job” causes “Indifference”; this 

“indifference” across levels can kill the product that 

you are building. Please stop being INDIFFIRENT 

TODAY. Participate in key decisions within your 

projects and outside too; ISO 29119 --- to be or not to 

be, take a stand. 


#Testers2Follow 

Henrik Andersson 

Just another crazy tester trying to make it in the world. 

https://twitter.com/henkeandersson 

Erik Brickarp 

Passionate software tester and psychology hobbyist. 

https://twitter.com/Brickuz 

Jean-Paul Varwijk 

Passionate about software testing. 

#ContextDriven #DEWT #MiagiDo 

https://twitter.com/Arborosa 

House of Test 

House of Test is a company filled with passionate, context-driven 

testers. Based in Lund, Sweden, with local branches in Copenhagen, 

Gothenburg and Linköping. 

https://twitter.com/houseoftest 

http://Twitter.com/TestingCircus 



Testing Circus is a world’s leading English language magazine for software testers 

and test enthusiasts. Monthly editions since September 2010. #testing 

Follow us at https://twitter.com/TestingCircus 

#Follow Us On Twitter 

https://Twitter.com/TestingCircus 

Over 100 testers to follow at Twitter - http://www.testingcircus.com/testers-in-twitter 


Security Testing Tips 

Kick-Start Https / SSL Testing 

Part 21 

- Santhosh Tuppad 

Often people love web applications with SSL. Even 

Google spiders love websites with HTTPS / SSL certificate. 

To help you understand better, SSL is nothing 

but HTTPS that you see while browsing some of the 

web application. Most of the testers does only one test 

for SSL and that is if HTTPS is visible in URL address 

bar or not. Well, that’s really cranky in 

my opinion as you need just pair of eyes 

in order to check it. 

Where do we use SSL? 

SSL or HTTPS need to be used for the 

web-pages where sensitive information 

exists. Example: Login form needs to be 

sent over the wire in encrypted form 

and HTTPS does it. If you enable 

HTTPS for static pages which are public, 

then it may slow down the performance, you don’t 

need HTTPS for displaying the public web-pages like 

contact us, about us etc. 

Some of the pages where you need to use HTTPS? 

Change Password 

Registration Form 

My Profile 

Any web-pages which are private to logged in users 

session 

Note: It is not only for web-pages, it could be for your 

client-server applications where data needs to be encrypted 

and the protocol used is HTTPS. 

1. HTTPS should be enforced when tried to use 

HTTP for web-pages where the data needs to 

be transferred is confidential & needs encryption 

2. Check for SSL certificate is from the trusted 

vendor 

3. Check for SSL certificate consistency in different 

web browsers 

4. Test for the BEAST attack where hackers or 

attackers may be able to decrypt the encryption. 

5. Check if HTTP Strict Transport Security 

is enabled for your server. 

Now, this is sufficient to start with SSL 

Testing. Advanced learning is the next 

step! 

Quick tips for learning more about SSL 

1. Try installing the self-signed certificate 

for your blog or website 

2. Buy a certificate and try installing on 

your own. For learning purpose, even you may 

want to use Trial certificate license. 

3. Understand your server, IP address, Port, 

Hostname, Issuer, Validation Type (Example: 

Domain Validation), Signature, Public Key etc. 

These are some of the terminologies that help 

you to understand SSL certificates better. Once 

you understand what these do, you may want 

to brainstorm or associate test for every entity. 

I am going to stop here as anything more than this may 

be overflow or a bouncer for you. Last, but not least; it 

would be great if you get into network level learning 

and protocols level learning along with Cryptography! 

Finally, SSL is not a fool-proof solution. Security is like 

adding layers and you never get to know till someone 

exploits it. 


www.TalentPlusPlus.com 

? 

www.TalentPlusPlus.com 

Confused what to do with your career? 

We can HELP 


Is Contrast.Net the Tool To Detect And 

Remove Security Vulnerabilities? 

New threats 

emerge every 

day for 

challenging 

a p p l i c a t i o n 

s e c u r i t y . 

P a y P a l , 

Linked In and 

other major 

websites have been hacked. While there is Open Web 

Application Security Project (OWASP) there are quite 

a few new tools emerging to improve security of 

application. Contrast Security has launched new tool 

for .Net Web Applications to continually self-test for 

vulnerabilities. 

One of the recent reports suggests that a typical web 

application has over 22 serious, undetected security 

issues and can cost over $5,000 per vulnerability to find 

and fix. Since many large enterprises have hundreds of 

web applications, the total cost of securing all of their 

application can easily run into millions of dollars. 

Top 10 security vulnerabilities listed on OWASP: 

1. Injection (Sqli -> SQL Injection) 

2. Broken Authentication & Session Management 

3. XSS (Cross Site Scripting) 

4. Insecure Direct Object Reference 

5. Security Misconfiguration 

6. Missing Function Level Access Control 

7. Cross Site Request Forgery (CSRF Or XSRF) 

8. Using Components with known Vulnerabilities 

9. Unvalidated Redirect & Forwards 

Once installed on IIS servers, Contrast for .NET 

analyzes applications built using Microsoft.Net 

framework for dangerous security vulnerabilities 

during development, testing and operations including 

those running on Azure Cloud service. 

Key features of Contrast .Net are: 

Real-Time Vulnerability Detection: 

Contrast instantly identifies the OWASP Top Ten and 

many other dangerous security issues introduced in 

custom code, libraries and run-time configuration 

automatically with no expertise or effort required. 

Actionable Code-Level Pinpointing and Expert 

Guidance: 

Developers get stack and data flow traces, library 

inventories, and instant validation capabilities speed 

remediation, which helps in pinpointing the problems. 

Highly context sensitive expert code-level guidance 

educates developers about secure coding practices. 

Automatically generated WAF (Web Application 

Firewall) rules enable Dev/Ops and test personnel to 

patch any issues that make it to production. 

Continually updated cloud intelligence assures that 

only the latest and most secure libraries are used. 

Portfolio-Class Scalability: 

Executive-level portfolio views deliver management 

visibility of organizations entire application security 

posture in real-time and across the software delivery 

lifecycle. 

Agile Speed and Automation: 

Scriptable silent installers, automated updates and a 

REST API and reporting enable Contrast to passively 

integrate into virtually any development and 

deployment process, continually discovering 

vulnerabilities no matter how frequently application 

code changes. 

Instant Compliance Reporting: 

Because Contrast operates continuously, it can generate 

always accurate PCI DSS, HIPAA, DISA AppSec STIG, 

and other compliance-ready reports whenever needed 

in seconds. 

Easy and Secure: SaaS or On-Premises Deployment: 

In the time it takes to read this page, you can register, 

run and discover application security issues 

using Contrast’s SaaS service. It's that easy. An onpremises 

deployment option is available as a part of 

Contrast Enterprise. Both options scale to any number 

of servers and applications with little additional effort. 

www.TestingCircus.com August 2014 - 52 -

Managing Change In A Test Cycle 

Q u a l i t y 

a s s u r a n c e 

teams need to 

be prepared for 

sudden changes 

that might 

occur during 

the production 

process. 

Accounting for changing development expectations 

and software market conditions has become a fairly 

common occurrence for developers and quality 

assurance professionals. When stakeholders and upper 

management first outline the requirements of a given 

software project, some development teams make the 

mistake of taking those guidelines as gospel. 

To be sure, initial requirements are crucial to the 

development process, giving team members clear goals 

for completing a project. However, today's marketplace 

can be capricious, fluctuating significantly in a short 

period of time. 

User feedback that is received later in the production 

cycle may contradict earlier goals. This lack of 

predictability has required QA management to plan for 

the unexpected and put together a test team capable of 

rolling with the punches and effectively addressing 

whatever new challenges may emerge. 

Embracing change has been a hallmark of agile 

development since the approach first emerged. 

Although many organizations still adhere to what is 

essentially a waterfall structure of development, agile 

processes are often incorporated in some capacity. 

A strictly linear approach to development and testing 

is no longer sustainable, as these rigid processes will 

impede a QA team's ability to account for new 

requirements and expectations. These shifting demands 

could come from the market, consumers or company 

executives, sometimes requiring production members 

to react swiftly in order to stay on track with their 

release schedules. 

Writing for the Software QA and Testing Resource 

Center, quality assurance expert Rick Hower suggested 

that team leaders directly consult with upper 

management regarding the possibly of production 

changes occurring during a project's lifecycle. If 

particular development shifts can be predicted ahead 

of time, QA teams and developers will be better 

prepared to address those changes without severely 

impacting the release schedule. 

The need for communication 

An agile approach to quality assurance can ease the 

burden placed on software testers by better integrating 

their efforts with the development process from the 

outset. This way, if and when a requirement change 

arises, developers and testers can work as a cohesive 

unit to address the ensuing software issues. Forrester 

analyst Diego Lo Giudice explained that revisions to 

the production plan can have far-reaching effects, 

requiring greater communication capabilities across the 

organization. 

"The huge change of testing has an impact on all of the 

testing tools categories: from test management tools to 

functional and non-functional automation testing to 

performance and load testing to security and test data 

management tools and, finally, to the newcomers' 

services virtualization for software testing tools," Lo 

Giudice wrote. "More than ever there is a need for a 

constant flow of information among [business 

analysts], developers and testers." 

In a white paper studying the challenges facing agile 

software developments, Rex Black Consulting Services 

agreed that facilitating communications between 

disparate production roles and management positions 

was essential to optimal quality assurance. 

A high-quality test management system can 

substantially help these efforts by providing a single 

interface to provide real-time updates and store test 

tools. This way, team members can be kept apprised of 

any new developments that could affect the 

production. In addition, proven automated test scripts 

can be saved and made available through the testing 

dashboard, meaning QA teams will not need to start 

from scratch just because the parameters of a project 

have been suddenly altered. 


Real Device Metrics Under Load Now 

Available By Partnership Between 

Neotys And Perfecto Mobile 

Testing for smartphone apps is always challenging given the variety of smartphones, different OS and screens. 

They part of business gear as well for business people on the move. It is challenging to develop apps which could 

perform well. 

Based on one of the recent surveys, about 52% of the apps fail due to poor performance issues. 

Other reasons of failure of apps are also: 

• Insufficient device coverage 

• Spending less time on testing the app 

• Lack of user experience due to bad user interface 

It is only correct to say that though the functionality of app is really good, if performance is bad or user experience 

is bad, app is bound to fail. One of the solutions mentioned in the whitepaper by perfecto mobile is as follows: 

Neotys has 

partnered with 

Perfecto mobile to 

help improve the 

performance of the 

apps. The new 

i n t e g r a t i o n 

between Neotys’ 

NeoLoad load and 

p e r f o r m a n c e 

testing solution for Web and mobile applications and Perfecto Mobile’s MobileCloud Platform enables 

organizations to understand the complete end user experience of their mobile users before releasing their 

applications into production. 

The 100% SaaS-based platform, MobileCould from Perfecto Mobile enables users to access real smartphones and 

tablets, as well as emulators, globally and across carriers. Neoload provides features users need to carry out load 

tests and analyse the results with easy to use interface. 

Partnership between Neotys and Perfecto Mobile helps users or test teams to get real device metrics (CPU, 

memory, battery, etc.) correlated in real time with results from a full load of virtual users for measurement of 

the complete end user experience. Testers can now determine exactly what performance an end user is 

experiencing on the device side while the application is under load. 

“Faster time to market, better software quality and higher productivity are important to all software teams, but 

it’s even more crucial for mobile app teams because customers are giving them one chance to get the user 

experience right,” said Gerald Labie, CEO, Neotys USA. “The combination of our two solutions is huge for our 

customers. The ability to pinpoint performance problems, whether they are on the device side or the application’s 

back end, earlier in the software development process allows teams to make changes before they become costly 

issues in production.” 


Are you missing what others are 

sharing on our 

page? 

http://www.facebook.com/TestingCircus 


Article 

Submission 

Guidelines 

Do you have something to share with the 

testing world? We can make your voice 

heard to testers. 

http://www.testingcircus.com/article-submission-guidelines 

Article submission guidelines – 

● Subject of article can be based on any area of Software Testing. If you want to publish your article on 

theme based subject please read our announcement of monthly theme published in our site. Article 

can be submitted without any theme based subject. 

● There is no minimum and maximum length of article. If you feel the article is lengthy, please divide 

the article into logically separated parts so that we can print them in a monthly series. 

● Give a meaningful title to the article. If you want a sub-title as well , then add that in a different line. 

● Add images/pictures if necessary. If you are using any image/picture which is not yours own work, 

please include the source. Take care of copyrighted materials. Images need to sent separately with the 

article. 

● Send us the article in MS word (doc/docx) format only. Pdf files are not accepted. 

● Write a short write up on the author(s). Usually 7/8 liners in 3rd person descriptive language. 

● Include photograph of author(s). Preferred in high resolution .jpeg/.png format. Ideal size would be 

50mmX 50mm. 

● You can send your article any time. Since we publish every month, your article can be included in any 

month. There is no such thing called as a dead line. 

● Send in your article to article@testingcircus.com with a subject line “Article for Testing Circus – 

Author Name – Title of the article” 

● If you think you can write a column in Testing Circus for at least 6 months, please submit 3 articles in 

advance. We are open to any idea that may improve the user experience of Testing Circus. 

● We will publish the articles in our website a week after the pdf magazine is published. 

We need articles on 

Testing in Cloud 


4 Years, 48 Editions, September 2010 to September 2014 


is Four Years 

Old? 

How time flies. Testing Circus has been a fun addition 

to my life ever since. I’ll let you into a little secret, I’m 

not the world’s greatest reader. I have a good deal of 

textbooks at home, and I make slow progress through 

them. 

Testing Circus has allowed me to get an 

exposure to different aspects and ideas 

within testing that I’d not normally have 

been exposed to. Often it would be a 

launch pad to an area I’d not heard of 

before (Cloud computing, mobile applications, 

agile testing have all grown in this time), but 

on reading one article it’d spark an 

interest, and just enough knowledge to 

start looking for more. When I took my 

first steps into test management in 2011, I found many 

articles, especially Bernice Ruhland’s frequent series 

invaluable, often backing up my experiences. 

Having come from the defense industry prior to 2010, 

we were not renowned for going outside of work and 

talking a lot about what we did – typically men in black 

would appear to have a quiet word with you if you did! 

And so most of my mentors and people I talked testing 

with were a small insular group within defense 

applications. 

Through Testing Circus, I started to learn of the world 

wide network of testers out there on the Internet, and 

introduced me to Twitter and Twitter handles. Trying 

to fit talking about testing into 140 characters was 

definitely a challenge. 

But this was the right magazine at the right time. I 

found myself at work writing an “onboarding to 

testing” document for my latest company, the kind I’d 

written at every company so far. And I felt “wouldn’t it 

be nice to share some of this stuff” – out of 

it my blog, now at 150 entries was born, 

and the passion to write about testing. 

we do. 

- Mike Talks 

Because I was writing in my spare time, 

and because really to get someone to read 

about testing outside of hours, you need 

an incentive. Hence I’ve always tried to 

have a sense of fun in my writing, over 

writing academic pieces. Looking for the 

fun that we know is at the heart of what we 

do on those days we get a thrill out of what 

It was only natural I’d end up submitting to some of the 

testing magazines. Testing Circus was the first 

magazine to publish one of my pieces, and over the 

years I’ve found them really helpful and supportive. I 

know I’ve managed to find my own voice in testing 

thanks to this magazine and its support. 

Looking forward to the future, I hope that there are 

readers out there who feel it’s time for them to take a 

gamble and start writing. The test community is a 

diverse group, and we get stronger with every tester 

who manages to find their voice. 

And so looking ahead, I look forward to reading YOUR 

articles – find your voice and submit! 

Mike Talks works as a Test Manager in Wellington, but has appreciated plugging into the larger test 

community through Testing Circus and Testing Trapeze. Mike tweets at @TestSheepNZ. 


SEEKING CONTRIBUTORS 

Write to us 

editor@testingcircus.com 

http://www.testingcircus.com/article-submission-guidelines/

Testing-Circus-Vol5-Edition09-September-2014

Create successful ePaper yourself

Delete template?

Save as template?