We live in a world consisting of almost 200 countries filled with thousands of languages. But is the language of testing universal? Have you ever wondered if testing practices in other countries are similar to yours?
Well, I hope that this article gives you a perspective of testing from a different culture. I introduce you to Jari Laakso, a software tester from Finland, living and working in Romania since 2007. Jari is a department manager for YOPESO, a 100 person outsourcing company with offices in Germany, Romania, Moldova, and Malaysia. He has a passion for solving & creating puzzles, which makes him an excellent test practitioner. He has not only tested software, but has a background in hardware (testing electric wheelchairs, robotics, and mobile devices). He is an experienced trainer for testers & monitoring internal processes. Jari is an active member in the context-driven testing (CDT) community, a member of the Romanian CDT community called “Tabara de Testare (TdT), and a member of the Finnish Association of Software Testing (FAST).
Jari’s background, his extensive practice in testing, combined with his desire to learn new methodologies and practices that are facing us in 2013 and beyond, make him an excellent interview candidate for our article. Now, let’s learn more about Jari!
Jari will now take your questions!
QUESTION 1: What are the two biggest testing challenges you face regularly that you’ve found good ways to manage? Conversely, what are the two biggest testing challenges that you haven’t been able to overcome or manage to your satisfaction yet?
Dawn Haynes, Principal Trainer & Consultant, PerfTestPlus, Inc., Florida, USA
Jari: I’d say it’s quite challenging to balance between test cases and exploratory testing. Currently we are handling it so that we do exploratory testing during a spring and at the end we execute “release testing” (where we also include exploration). There are actually many challenges included in this topic because many people seem to believe having test cases solves a lot of problems.
This leads to the biggest challenge I often face; the mindset of different people. It took a lot of time and energy to figure this out. It would have been easier if I would have read “correct” blogs some years ago. Especially people who don’t understand testing often seem to have strong opinions on how testing should be done, how it should be reported and whatnot.
One testing challenge I haven’t yet solved (to my satisfaction) is how I could be involved in more projects in our company. I do spot-checking, but I think the company could use my testing skills more. However, as I am a manager, I have other duties and other things are expected from me.
Another interesting testing challenge I haven’t solved (to my satisfaction) is figuring out how to do the testing in a relatively short time in a project where we update usually 30 different web sites at the same time. But here’s the catch; we don’t do it always, sometimes only some sites are updated and even though they have the same basic structure, they contain somewhat different options. Include browser coverage in the soup and there you go. I might blog about this later if I get the clearance for it.
QUESTION 2: Let’s say you hire a tester, that has three traits that make her an excellent tester. What could those traits be?
Aleksis Tulonen, QA Consultant, Comiq Oy
Jari: I am tempted to answer with humor, but I’ll try to resist. All the excellent testers I know are passionate about testing (they read and write about testing), they are creative/inventive and they are great storytellers. Those are some of the qualities I am looking into when I am recruiting testers. Because I’m not good friends with rules, I’ll give a fourth one also: courage. I can’t see anyone doing a great job in my department (or field, for that matter) who doesn’t have a lot of courage.
QUESTION 3: I noticed that most of the time the QA team and development team does not gel well.?What are the important factor(s) that will help build cohesiveness between QA team and the developers?
Madhavi V, PM, Financial Services, Chicago, USA
Jari: What a wonderful question and a good timing because I’ve been working on this topic lately. Group cohesiveness has basic causes that have been discussed over for decades. I presume you are already familiar with the general theories so I’ll comment only on testers grouping up with programmers.
On a language level, you could stop talking about “QA” and “development team”; especially separately. Testers are part of the development team, thus, they are developers, too. By calling them “QA”, you are implying they have control over the quality of the product. In a way, this could also mean they take the heat when problems are found from production.
On a personal level, you could figure out what things they like in each other and what not. Then start working on those things. Maybe you could give them team-building exercises. What I’ve done a lot is to follow-up on their communication. This includes bug tickets, meetings, e-mails etc. Sometimes programmers don’t give much appreciation to testers who don’t know how to code. In this case, you can explain them how testers bring value differently to the team or for example ask testers to learn to code.
I’ve seen this work out great when the management has done their part well. It doesn’t guarantee it, obviously, but it helps that the team shares the same vision and understanding where they want to go. Once they get that sorted out, they split the responsibilities and start working. Otherwise, you might run into discussions where programmers don’t want to receive bug tickets from testers – even though testers are there to make them look better!
QUESTION 4: As someone who follows testing speakers, authors, bloggers, etc. globally, what things are the North Americans talking a lot about that don’t seem overly problematic/important in Europe. Conversely, what things do you see as problematic/important in Europe that North Americans aren’t speaking/writing very much about?
Scott Barber, Chief Technologist, PerfTestPlus, Florida, USA
Jari: I see North Americans writing and talking a lot about things which matter to me. It’s somewhat surprising to see how testers face the same problems all around the world. Sometimes I feel pretty much everyone I follow is talking about the same problematic and important things. Although I think ISTQB and TMap have a bigger role in Europe, that feeling might be because of my history. In addition to this, I believe there isn’t that much discussion on how to successfully outsource (or more like offshore) testing. These stories come mostly from countries where offshoring is more common, such as Romania and India.
What I find utmost interesting is that performance related testing is not up in the air that much. Surely you and some other amazing testers like Mark Tomlinson talk about it, but for some reason I haven’t seen much about that topic. One reason might be that people often connect performance testing as something only performance testing experts should do. Even more, some think it’s mostly about trying how much load (of some kind) the system can take until it goes down. So, maybe the North Americans, who I am following, talk a lot about performance related issues which are not seen so important in Europe, and in the same time they are very important, but the North Americans are not heard well enough at this part of the world.
QUESTION 5: Nowadays automated testing is a ‘must have’ skill and the Agile methodology gains more and more on popularity. Clearly the focus is on shortening the ‘time to market’. Reducing time on testing.?Question: What do you think will be the role of the software tester in the near future? Will we just translate specifications into test cases while test execution will be automated even more?
Eelco Van Orden, Test Specialist, TFG – TestDynamics, Zoetermeer, Netherlands
Jari: I take it that with “automated testing” you mean writing test scripts on some programming language and then making a computer to execute those scripts. There is a whole lot of “testing vs. checking” and “test/check automation” articles online so I won’t go into that.
For those testers who like/know to code, there will be more opportunities to work on writing scripts. For those testers who want to learn to become excellent testers, there will also be an increased need on the market. I don’t see the field changing that much. New tools which make us better testers keep appearing, but the most important tool is the brain. The kind of work your last sentence describes is quite far from the kind of work I see great testers doing; however, I am not saying great testers would not use tools when they are helpful.
QUESTION 6: What would you consider to be the main difference(s) in testing hardware versus software? And how do the ‘testing people’ differ in this different worlds? (as I consider these worlds to be different, could be that you have other experiences of course)?
Rob Van Steenbergen, Tester, Chickenwings Test Consultancy, The Netherlands
Jari: The senses we use to observe the product under testing differ quite much. Ok, we have all heard the jokes about smelling code, but with hardware the situation is definitely different from how it is with software. But there are a lot of similarities, too. Both kind of testers evaluate how the product is made, what it consists of, what kind of input/output it handles etc.
I think hardware testers don’t speak so much about “do testers need to know how to write code”, but they might talk about understanding electronics, for example. When we compare for instance testing an online restaurant and an electric wheelchair, the differences are quite obvious. But even if the testing is a lot different, the same principles apply on the background.
One big difference is that software testers don’t break code, but hardware testers can break pretty much anything. Having that said, while being a hardware tester, I noticed it wasn’t always so easy to get new versions and more instances of the product for testing. I don’t remember ever having development, staging and live environments, but that might be just from the projects I worked in.
QUESTION 7: How would you advise testers to develop their career path? How to grow and change? Are there new roles (besides management) that you could share?
Mark Tomlinson, Independent Performance Consultant
Jari: I think it’s good for testers to specialize in something, but also to keep the general testing skills on a high level. It’s a bit like looking at musicians, athletes, chefs and so on. I see them building their career in the same way as testers do; a lot of practice and hard work on the skills that are relevant for them. I know a lot of testers who are happy with their work, respected by their peers and continuously keep improving their skills. They read, talk and learn testing; but not only testing. Some work inside product companies, some consult management and project teams, where as some build their own business around testing. There’s a lot of room where to move once people find what they want to do.
When it comes to roles and titles, I have a small allergy with them. I am not really against them, but I see them overvalued and misunderstood up to some degree. But I am happy with my latest change, since I became a department manager (and changed the company), I can do a lot more hands-on testing than when I was a test project manager. Different companies, different roles and titles.
QUESTION 8: Describe an ethical dilemma you have faced as a tester.
Mark Tomlinson, Independent Performance Consultant
Jari: Numerous times I’ve been asked to do things I see rather pointless and even harming (for the project, for a client, for the team…), but years have changed me to learn how to handle those situations better – and mostly how to fight back. After all, those are the kind of fights we need to have in order to do a good job. On a short term they might hurt us, but I have faith they will work out great on a long run.
One typical example around this topic is to receive a request to create documentation (metrics, bad kind of test plans, test cases against requirements etc.). At very least, in my opinion, when receiving a request like this, a good tester will explain the possible problems and tries to find out what else could be done in order to help the client. They might want to build confidence in the tester’s skills and questioning intelligently their method could just do the trick already during the discussion.
QUESTION 9: You are the active member of CDT community. As a CDT leader, what are your challenges? What are the wins?
Anna Royzman, QA Manager, Liquidnet Holdings, New York, USA
Jari: CDT to me is all about challenging others, working on testing skills, and fighting for good causes. The community is amazingly supportive and there are always people ready to help. It takes a lot of time so one needs to accept some cuts in things one can do. Luckily people often don’t even notice how many hours they spend unproductively on a weekly level. Managing all my activities while becoming a dad has been a great challenge; and yet, I can still rest sometimes.
QUESTION 10: Is software testing an art or a science? Is there such a thing as testing ‘best practices’?
Todd Shultz, QA Mob
Jari: Software testing is both and more. It’s an art when it comes down to expressing human creativeness and imagination. It’s an art when connected with language skills. It’s an art because it’s a specific skill developed through practice. But it’s also science because it’s systematic study through experimenting and observing.
There are no (testing) best practices, but there are practices that have seemed to work out well in certain cases. The people who I have heard defending best practices do it usually for either or both of these reasons: they are selling the best practice and/or they don’t really mean best but something else. The first is highly unethical in my opinion. The second is depending on case by case, but possibly some sort of laziness or not caring to express oneself clearly; at least not caring how much negative effects such term can have (and already has had) on our field.
QUESTION 11: Did you notice any differences between Finnish and Romanian testing culture? Does your approach differ – and are there similarities – when testing hardware and software?
Phil Kirkham, Tester, Atomic Object, Grand Rapids, MI, USA
Jari: I’ve worked with people from various countries and there are indeed a lot of differences. But even if I’ve seen those differences, two key factors are the company culture and what kind of clients the company has. So, although I see many companies in Romania are doing “cheap” (I use quotations because the implications can actually be really expensive) outsourcing and they compete mostly with pricing, there are some fantastic companies also, such as Altom. If you haven’t yet heard of Altom, heat up your favorite search engine and look them up.
I think many of the differences can be tracked down to the cheap outsourcing culture instead of testing culture of a country. Maybe one could consider that the main testing culture difference; nobody really goes to Finland to find cheap outsourcing in software testing. Coincidentally, due to the high growth of Romanian IT business and poor economy, a tester can expect proportionally hugely higher salary in Romania than in Finland.
In regards to hardware and software testing, I’ve replied on an earlier question.
QUESTION 12: It seems to me that a high percentage of the blogging and speaking testers are working on some sort of web-applications or at least software-only products. With your background from wheelchairs and robotics, do you recognize any major differences in the testing cultures of the embedded software world compared to the software-only camp?
Geir Gulbrandsen, Test Team Lead, Aker Solutions AS, Oslo, Norway
Jari: I’ve answered above for the hardware part, but didn’t touch base with embedded world. Here’s one thing I learned today: I know now how to break into my house, steal things, get out and not make the alarm go off – without cutting wires or tampering devices. That’s what they don’t teach you at web testing! I’d note also here I’ve never had to purchase standards to be able to test software so that it can be sold. This has happened with CE testing and as I’ve talked with Griffin Jones, alas, adhering only to the standards doesn’t make the products actually safe to use. There is a lot to think and talk about there.
QUESTION 13: Describe testing prototype or engineering model hardware. Describe testing the EMI susceptibility of the wheelchairs?
Griffin Jones, Software Tester & Testing Coach, Rochester, NY, USA
Jari: There are some interesting aspects in testing prototype hardware. In a way, the tester might not want to break it because he might now know when he gets a second one, but in some way the tester wants to know some limitations of the product. On the other hand, prototype hardware can break really easily or be too resistant. (“Too resistant” in this case refers for example to cases where there is a consumer who is expected to change a device after a certain period.) So even if I often advice testers to start testing a new product mostly by gently looking at the features, the start with a prototype hardware might be even more gentle – or harsh. Test environments too might get a whole new meaning because you just might be asked to fly to Australia to test the device there. What I’ve found important is to be able to communicate the product’s potential future problems; which I see similar with testing software.
I’ve learned from some of the hardware testing the importance of being able to collect data. Let’s imagine you have an A class prototype of the new Lumia mobile phone. The covers of the phone are not likely going to reveal too much of the design that will be intended. (Just like with cars, if you have seen pictures of prototypes that are far from production-ready.) There will be debugging and reporting software included in the firmware package, so if the device crashes while you have having a Mai Tai on the beach, the engineers might even figure that out. This is yet again a question that would deserve at least a blog post to write about.
When we did the CE testing for the wheelchairs, we focused on the CE certificate which didn’t require us to do EMI testing. It’s actually quite disturbing, but the standards required us to make sure certain measurements for slowing down, accelerating, noise, climbing on an angle etc. but there was a huge amount of safety-related things overlooked. I can’t say for sure, but I believe this topic is taken more seriously in the US. Maybe an FDA kind of thing.
I would like to add here when we did the CE testing, we needed to build all kinds of environments, slopes, buy different kinds of materials (friction coefficients) and for example measure the noise level. Acceleration and breaking measurements required us to make a device of our own and put embedded software in it because a stopwatch wasn’t accurate enough. My point is, the testing was done for a consumer product instead of a medical device. This might be totally different nowadays and especially in the US, but that was the reality for me.
QUESTION 14: How do you approach growing your team? Is size more important than skill? Also how do you promote CDT in an organization used to more traditional methods?
Kate Falanga, Quality Assurance Manager, Huge, Inc., Brooklyn, NY, USA
Jari: I am not sure what you mean with comparing growth and skill. If you mean growing the amount of testers, then the answer is we do that based on needs. We’ve been increasing the tester amount really carefully because we are also going through some big organizational changes. Since we do slow growth based on needs, I can focus on getting the right kind of skills and persons in the team. We also focus a lot on skills in our internal training and learning programs.
There’s an old saying about poker, which states it’s a hard way to make an easy living. I can use the logic the other way around and tell testers how their lives will become easier (in some aspects) once they start working hard. How we have done this is to talk about values, the principles of CDT, and philosophy of testing. We’ve come up with a load of exercises and challenges. Some of them were logical, some lateral, but mostly the focus has been on critical thinking and improving skills to ask details about the context. Sometimes testers don’t know from where to begin, so you might help them by asking context-revealing questions of their projects.
I’ve been thrilled to see companies moving to Agile, Lean, Kanban or whatever, but not because I see those as full answers to some problems, but because it means they want to change. If there is will to change, we can use that will in our advantage. On the other way around, if there isn’t will, most likely we need to show examples why CDT could help the company. It’s good to notice here there isn’t a “CDT way” to test. It’s not a technique or set of rules how the testing is done. It certainly doesn’t tell what one should do with test cases, script automation, or test reporting.
I want to add a really important note still. Testers are responsible of their work. (Ok, there are cases when this is not true, but since I’ve not worked under those conditions, I would not speak from experience.) It’s the testers’ responsibility to do a great job. It’s nobody else’s job to tell the tester how the job should be done. They might do it anyway, but in those cases we need to stand up. Once you get the people understand this, rest assured magic will happen. Context-driven testing can’t be done by people who are bossed around.
QUESTION 15: With your background in hardware testing, do you combine your knowledge with hardware, software and firmware to conduct test design for your mobile testing? Could you share an example which could be applied for other mobile testers?
JeanAnn Harrison, Software Testing & Services Consultant, Project Realms, Boston, USA
Jari: Human beings are fantastic in combining their experiences and knowledge to testing ideas. If you look for example testing a Java mobile application and you want it to work with some older devices, you want to take a look on the firmware differences between some of the devices. After you find a bug, your brain will take a few spins and you’ll see yourself reading through forums and figuring out a whole new set of tests. Now try some Symbian S60 apps and your brain starts frying!
What I find important is to understand what all kind of sensors and other things inside the device (might) affect the observed test results. Tilt the phone, change lightning conditions, walk with the device while testing, test in the basement, try different interruptions (receive SMS/call/e-mail, plugin the charger, make the battery run low…) and all that. There is a fantastic book by Jonathan Kohl about mobile testing which gives insights to the topic, but doesn’t go to the fine grain details of firmwares. That is a whole new world!
QUESTION 16: I am interested in the biggest personal surprise you experienced when coming into the new environment / company – both good & bad?
Mira Razman, Slovenia
Jari: I came to a company with a very young testing culture with various kinds of people in the team. We have been actually hiring people in the department so that their skills and backgrounds vary a lot. One of the most amazing things was all the sudden getting to sit around testers who know psychology, law and whatnot.
The worst personal surprise, hmm, I don’t really know; possibly that my friend left the company a few months after I was hired. But it was bad only at that time. I think it worked out well for our company, for him and for his new company.
QUESTION 17: Where would you start to train a new tester, hired in with no prior testing knowledge; or how would you approach training a new hire with prior testing experience if the new hire regularly questioned the style or methodology of testing that you use?
Erik Davis
Jari: Now there are a few interesting questions. Training new testers is fun because it means I can do pair-testing! I think working side-by-side with someone is a fantastic way to train them to do their work. By doing that, you can also compare different ways to approach testing and challenge each other for example by asking “why did you do that”, “what made you find that bug” and “what else could you try”.
QUESTION 18: How do you deal with international ubiquity of meaning – for instance, that a test case definition holds different meanings in different cultures, geographies or countries?
Mark Tomlinson, Independent Performance Consultant
Jari: Most people I work with think of test cases in different ways. That’s one of the reasons why it’s important for testers to learn asking questions. For example, let’s imagine a client asks us to create test cases for a project. Some of the questions we might want to ask include: what does the client mean with test cases, what problem(s) they want to solve by creating test cases, and if the client has a specific relationship with test cases. Instead of “dealing with it”, I go pretty much on my instincts of the situation and adjust over time; if there is time. But yet again, it depends…
QUESTION 19: Most testers face similar problems – ambiguity, conflicting expectations, and time pressure. Could you tell us a story about a time you had to face those problems, what you did about it, and how it turned out?
Matt Heusser, Consulting Software Tester & Writer, Excelon Development, Michigan, USA
Jari: Hmm, let’s go with time pressure, because that is a fun topic. We had a tremendous amount of combinations to test only when it comes to environments (I will call them like this, but if someone is interested to know the actual details, we can talk about it). We had an application to test with a 2-week release cycle. During the sprint, we were testing the tickets and then exploring other parts of the application as much as we could. First, we just tried to see how it goes for a few weeks. It didn’t go too well, so we needed improvements in testing more of those environments in the same timeframe.
We thought to try as much variance as we could and switch between different setups while testing. This started much better, but we still kept missing a lot of things. This happened mainly because some things only appeared with some configurations. At this point I thought to ask more testers in the team and presented some basic calculations with the configuration coverage we could provide. Obviously we didn’t get more testers, but another request to keep optimizing.
Finally, we got to a place where we optimized pretty much everything we could with local optimizations in the testing team. (Yes, it’s not *everything* and “local optimization” is a very broad kind of description of what was done.) But how it turned out? Programmers kept making mistakes and we still couldn’t catch all of them, but we were able to reduce greatly the amount of severe (to the client and their customers, in general) problems in production.
QUESTION 20: You manage an outsourced test team. Can you describe an experience of how you effectively ramped up you test team’s knowledge in a new domain area?
Paul Holland, Consulting S/W Tester & Teacher of Rapid S/W Testing, Testing Thoughts
Jari: There was a case when I thought it would be the time for some of the testers to learn using tools in order to increase the depth on how we did web testing. While showing how the basics of the tools worked, I explained some things about POST parameters and for instance about different validations. I handed over the tools, asked to try them on the projects, and present their results after 2 days. During this 2 day period I was there answering their questions and giving direction when it was needed.
After a few days, we took a meeting room and showed some of the bugs they had found. We discussed on how the bugs were found, what triggered the tests, and why the bugs were valuable. We tried testing more around the bugs to see if something else comes up and finally we talked together how to write the titles for the bug reports. After people noticed how differently they used the same tools, I saw some sparkles in their eyes.
Possibly not quite the story you were hoping for, but I have been waiting to share a bit of this. I believe we might have some discussions at Let’s Test conference so please challenge me there again!
QUESTION 21: How best can I do the effort estimation when We do not enough budget approval for 5 more (contractors) resources and all the work is handled is handled by 1 test lead. The resources who worked has the subject knowledge and are let go due to budget and head office approval issues.
- How can I gain a buy in from Head office any tips for approval of 5 more resources to complete work in 8weeks go live time and
- How can I show the effective test effort estimation for 5000 test cases execution and 20 high defects fix retest in 6 weeks time to retain those 5 resources?
Pavani Gajula, Test Lead (AVP), Bank of Tokyo, New Jersey, USA
Jari:
- Testing estimation is really a negotiation about how much someone is willing to pay for testing.
If the Head Office doesn’t see it necessary to pay for more testing, maybe they are not interested in
receiving more quality related information about the product; or maybe they just don’t have the budget
for it. You can explain them how this might affect the quality and for example you can illustrate what
kind of bugs will likely be missed due to small amount of testing time – you can show what testing will not happen at all because of this change. - I don’t have any details of those test cases, defect fixes or other parts of the product, so I
can’t imagine what the numbers mean to you or to the Head Office. Have you told them what all you won’t
be able to do if the testers are not kept in the team? I might be wrong here, but to me it sounds like
you have been talking about numbers with them. If you tell them “I can do only 1000 test cases”, they
might not see the same implications in it what you see, so try to look into your thinking and explain
them the risks you see.
Generally speaking, I see great dangers in your writing. When testing is communicated as numbers and people are referred to as “resources”, it gives the impression the work is something anyone can do. So, by using language like this, you might harm the testing team. There could be one problem; their work is not seen valuable because of the way how it’s communicated. But as implied, my impression is only from a few lines of your text and the reality can be completely different.
QUESTION 22: I know you are a fan of context-driven testing, but our readers come from all sorts of background. So I’m going to give you an impossible question. Without knowing anything else about the STQA Magazine reader – what trends do you think are impacting software testing today, in such a big way, that testers should be aware of, and what should they be doing about it?
Matt Heusser, Consulting Software Tester & Writer, Excelon Development, Michigan, USA
Jari: Until now, I’ve tried to answer questions deliberately without asking questions in my answers. Surely I will be happy to go into more details if anyone contacts me. I’ve made some shortcuts mostly because I am not writing the answers to my blog, where I would have the comment notifications and good discussion possibilities. But now I’ve faced a question that is really impossible (for me) to answer.
So, instead of leaving it there, let’s list a few of things I have seen affecting software testers from my current home country. Tabara de Testare (TdT) is growing in Romania; at least in Cluj-Napoca where I am meeting the testers. TdT is a local testing community where we (again, I am talking about what is happening in Cluj-Napoca) keep growing popularity and I hope it’s because of the utmost interesting discussions and debates. Some people decide not to come to the MeetUp’s, but hey, nobody said it’s going to be easy there. We challenge, criticize, advice, and have a lot of fun while doing it. My advice would be to join us and check it out.
The second thing I feel testers (especially in Romania and nearby countries) should pay attention to is “the thinking Indian tester”. They are a lot and they have very strong leaders. Of course, there is a lot of certification business going on, but the Indian testers who use time to learn their craft are really just starting to peak up. So we, in Romania and around, need to make ourselves more valuable for the business. That doesn’t mean only hunting bugs, it means what Scott Barber (among others) keeps telling about; we need to deliver business value by for example making analysis between competitor products.
QUESTION 23: As a tester, do you become more productive if you sit beside another QA of the same project, beside the developer the same project, beside the BA of the same project, or if you sit as far away from your project team as possible?
Rogelio Caga-anan, Jr.
Jari: I am tempted to answer “42” because this is one of those questions where the answer begins “It depends” and it never really ends. I would be very happy to have people from the same project around me, but in most of the cases I don’t have that luxury. On the other hand, it might not be a luxury if the relationship between those people would be poisoned; or if the BA is in jail and I would need to move there.
I noticed you asked about productivity, which makes me wonder if you really meant that or you meant something else. However it may be, there is no single correct answer here. In general, how I have observed from my own work, the more people I have around, the easier it is to talk with them (until we were ~30 in one room from the same project) and extract information what I need in order to do a great job. It’s not mandatory, but there are some potentially good benefits.
QUESTION 24: As a tester, what is your outlook on Cloud Testing?
Naveen Kumar N, Test Engineer, QAInsights, Mysore, India
Jari: I think cloud testing business will keep on increasing at least for a while until something else comes up, but I think there are some misunderstandings around cloud testing. At least those people who I have heard praise it have claimed it’s very easy to make compatibility testing in the cloud, applications can be verified against requirements just like that, and for example costs become lower. If this would really be true, wouldn’t most be doing it already with great results? Oh yeah, I forgot that we don’t have a good definition of what the “cloud” is. For me, it means getting computing resources from the network, thus for example crowd sourcing is not cloud testing, in my opinion.
QUESTION 25: In Agile methodology testers execute test cases on daily builds. How do you ensure application is regressed to deliver a stable build to client at the end of sprint?
Giri Ongole, QA Manager, Charter Global, Hyderabad, India
Jari: Instead of answering to the question, I will explain a few problems I see in what you wrote. Because you work as a manager, I think this is very important and I hope we can continue the discussion somewhere else. Maybe you could ping me on Skype, Twitter or e-mail and we’ll see then better.
Firstly, that has nothing to do with Agile methodology. I’ve seen many Agile projects that had zero test cases. I’ve seen many Agile projects that had no daily builds. I think we could have interesting discussions about your test cases, how you make them, what you hope they find etc. There is nothing wrong in test cases, in my opinion, but I think they are hugely overrated.
Secondly, when you say “regressed”, you most likely mean the testers have tested the application for regression problems. As far as I am concerned, it’s important for us to focus on the language we use and continuously improve it. So when you mean to test for regression problems, don’t say “regressed”, which would imply the product is made worse on purpose; except if that is what you want.
Thirdly, I don’t know what a “stable build” to you is, but there is no possible way we can ensure quality by testing. No test can be repeated perfectly, thus each time a user does something on a product, it’s a new use case. Being a new use case means you could not have possibly tested it to make sure it will not have any bugs. If you want me to open this up more, please let me know.
Fourthly, if you have had problems with quality, chances are the following things could help you out – no matter what m(e/y)thodology you have: drop the test cases or most of them and focus on giving time for testers to test and be creative, help programmers make better code by letting them learn from their mistakes, test the user stories before they become code, help testers to learn their craft (send them to a Rapid Software Testing [RST] course, for example), and become a great tester yourself too.
You can go to http://jarilaakso.blogspot.com to read Jari’s blog, or follow him on Twitter where he is @jarilaakso
Next issue we’ll interview Melissa Tondi. Melissa has been in the Software Test/QA/Quality Engineering field for more than 15 years. She has focused on organizing Software Testing teams around three major tenets: efficiency, innovation, and culture. In her current role, she is the Vice President of Mobile practice for ProtoTest and the founder of Denver Mobile and Automation Quality Engineering (DMAQ) community. Her previous roles have been as Director of Software Quality Engineering for a 150+ person organization for the world’s largest education company, QA Consultant for healthcare, finance, and software-as-a-service (SAAS) industries, and the President of Colorado’s Software Quality Association of Denver (SQuAD).
In her role with ProtoTest, she is building a Testing practice in the innovative world of Mobile where the concentration is on Functional, Performance, Security and User Experience and the innovative testing techniques that are rising in the Mobile Testing arena.
Please email your questions, name, and location with ‘Ask The Tester’ as subject line to
mikewlyles@gmail.com
About the Author
Mike Lyles Mike Lyles is a Quality Engineering Program Manager with over 22+ years in IT: development, PMO, and Software Testing. His experience spans functional testing, test environments, software configuration management, test data management, performance testing, test automation, service virtualization, building testing organizations, defining processes and methodologies, and standing up measurement programs
Mike is an international/keynote speaker at multiple conferences, and is regularly published in testing publications and trade magazines. Mike’s passion to help others improve and grow in the field of testing, leadership, and management is his key motivation. You can learn more about Mike at http://about.me/mikelylesopinions are his own and not those of his employer.