Skip to main content

7 posts tagged with "interview"

View All Tags

· 13 min read
Yossi Elkrief
Elisha Sterngold

Yossi Elkrief

Interview with Mobile Lead at Nike, Author, Google Developers Group Beer Sheva Cofounder, Yossi Elkrief

Thank you for being with us today Yossi, would you like to begin with sharing a little bit about your position at Nike, and what you do?

I joined Nike for a bit more than two years now. I am head of mobile development in the Digital Studio of innovation. It is a bit different from regular app development but we still work closely with all the teams in WHQ, Nike headquarters in the US as well as Europe, China, and Japan. We really work across the globe, and we do some pretty cool things in the realm of innovation. We develop new technologies and try to find ways to harness new technologies or algorithms to help Nike provide the best possible service to our consumers.

I have experience in mobile for the past 13, almost 14 years now. I’ve been involved in Android development since their very first Beta release, even a bit before that. I also worked on iOS throughout the years, and I’ve been involved in a couple of pretty large consumer based companies and startups.

At Nike we have a few apps, such as: Nike Training Club (NTC), Nike Running Club (NRC), and the Nike app made for consumers, where you can purchase Nike’s products.

We work with all of those teams and other teams within Nike, on various apps as well as in-house apps that are specific creations of our studio, where we work on creating new innovative features for Nike.

One major project that is currently working on completing roll out is Nike Fit, recently launched in China and Japan. Nike Fit, is aimed at helping people shop Nike shoes online and hopefully for other apparels in the near future.

How is it working for Nike, as a clothing company, with a background of working mainly for tech companies?

Nike is a company with so much more technology than people realize. We are not just a shoe company or a fashion company.

Our mission is to bring inspiration and innovation to every athlete1 in the world.

We use a tremendous amount of technology to transform a piece of fabric into a piece in the collection of the Nike brand. Nike may be more faceforward than companies that I’ve worked for in the past, but there is a vast array of technologies that we work with in Nike, or work on building upon, to make Nike the choice brand for our customers, now and in the future.

One of the highest priorities at Nike is the athlete consumers. Because Nike is a brand that is specifically designed and geared toward athletes. We therefore try to keep all of Nike’s athletes at the forefront in terms of their importance to the company. Consumer facing, most of Nike’s products are not the apps. All of my previous experiences in app companies or technical companies that provide a service are pretty different from what I focus on now at Nike. So everything we do at Nike, all the services we provide, are to help serve athletes in their day to day activities, whether this be in sports for professional athletes, or for people with hobbies like running, football, or cycling and so on.

Everything I focus on has to do with providing athletes with better service while choosing their shoes, pants, or all the equipment they need, and that Nike provides so they can best utilize their skills.

Can you tell us a bit about what went into writing your book “Android 6 Essentials”? Do you feel that writing the book improved your own skills as a developer?

I write quite a lot. I don’t get to write as many technical manuals as I’d like, but I do write quite a few documentations, technical documents, and blog posts. Writing the book was a different process, but I really wanted to engage a technical audience, as this audience is very different from that of a poem, or story, which is less for use and more for enjoyment.

Writing the book made me a better person in general because I was working full time in the capacity of my position at the company that I was with at the time, and then on top of all of my regular responsibilities, in order to be able to keep to schedule and hit all of the milestones, and points that I wanted to cover in my book. I had to be very organised and devoted to the project. I had to juggle work, and family, and all of my other responsibilities as well, so I divided my time to make sure I could meet all of my goals. The process was really quite fun because in the end I had something that I built and created from scratch.

I would recommend it, because it gives you an added value that no one else will have, and in the end you have a final product that you can show someone, and say that it was your creation. I think the whole process makes you a better developer, and it helps you understand technology better, because you need to understand technology at a level and to a degree of depth in order to then explain it in writing to someone else.

You also took part in co-founding Google Developers Group Beer Sheva, which is also about sharing knowledge and bettering yourselves as developers, can you tell us a little about that process?

The main aim of Google Developers Group is sharing knowledge. When we share knowledge we can learn from everyone. Even if I built each of the pieces of a machine myself, when I share it with someone else, they can always bring to light something that I was unaware of; some new and interesting way of using it. Sharing with people helps more than just the basic value of assistance. Finding a group of peers that share the same desire or passion for technology, knowledge, and information, this is a key concept in growth, for everyone in general.

On that note, we are seeing an interesting trend in development: even though mobile apps are becoming increasingly more complex, the industry has succeeded in reducing the occurrence of crashes. Is that your experience as well and if so, what are, in your eyes, the main reasons for this shift?

It’s really a two part answer.

Firstly, both Google and Apple are providing a lot more information, and are focusing a lot more on user experience in terms of crashes, app not responding, bad reviews etc. Users are more likely to write a good review if you provide more information, or create a better service with more value for them. Consumers in general are more interested in using the same app, the same experience, if they love it. So they will happily provide you with more information so that you can solve its issues, and keep using your app rather than trying something new. We call them Power Users or Advanced Users. With their help, we can keep the app updated and solve issues faster.

The second part of the answer is that all of the tools, ID integrations, shared knowledge, documentation, has been vastly improved. People understand now that they need to provide a service that runs smoothly with as little interference as possible for the user and they do their part to make sure that these issues remain as low as possible in the apps. We want a crash rate lower than 0.1%. So we work 90% of our time to build an infrastructure that will remain robust and maintain top quality, with a negligible amount of crashes, exceptions, and app issues, in general, that will harm and affect the user experience.

Do you believe that all bugs should always be fixed? If not, do you have ways of defining which ones do not need to be fixed?

As a perfectionist, yes, we want to solve all of the app issues. But in terms of real life, we work with a simple process. We look at the impact of the bug. How many users are being impacted? What is the extent to the impact? What does the user have to do in order to use the service? Is it just a simple work around or is it preventing the user from using an important part of the app?

Do you close insignificant issues, or are they kept open in a back office somewhere?

No, so we are very careful and organized about all of the issues that we have in the system. We document every issue with as much information as possible. Sometimes you can fix an issue with dependency and provide a new version for some dependencies and then because of all the interactions of the code versions you have some issues being solved even though you didn’t do anything. So for example, this doesn’t happen much, but sometimes we have issues in the backlog that can remain unsolved for more than a month.

What is your view on QA teams? Some companies have come out saying that they don’t use QA teams and instead move that responsibility to the developer team. Do you believe that there should be a QA Team?

I believe that companies should have a Quality Assurance team, which is sometimes also called QE, Quality Engineering. I think as a developer, working on various platforms, when you implement a new feature or service, give or take on the architecture of the technology, the actual issue can be quite difficult to find. This requires a different point of view than the developer. When you develop or write the code, you have a different point of view in mind then users often have when it comes to using the app. 90% of the time users will actually often behave differently than developers anticipated when writing the code. So when we design the feature, sometimes we need to understand a bit better how users will interact. We have a product team that we involve and engage on an hourly basis. The same goes for QA. We use QA in our Innovation Studio as well, but the same goes for our apps. We are constantly engaging QA to see how to both resolve issues and understand better how the user will interact with the app.

What is your position on Android Unit testing: How are the benefits compared to the efforts?

With testing in general, some will say it's not necessary at all and will just rely on QA. I don’t side with either. I think it is a mix. You don't need to unit test every line of code. I think that is excessive. Understanding the architecture is more important than unit testing. It's more important to understand how and why the pieces of the puzzle interact- to understand why to choose one flow over another, than to just unit test every function. Sometimes pieces of the puzzle are better understood with unit testing, but it is not necessary to unit test everything. That said, the majority of our code does undergo UI and UX testing.

What do you think about the fact that with Kotlin, you don’t state the exception in the function, this is unlike Java or Swift, which both require it. Which approach do you prefer?

I think for each platform there are different methods of working. Both approaches are fine with me. I think the Kotlin approach for Android, or for Kotlin in general, gives the developer more responsibility as to what can go wrong. You need to better understand the code and the reasons behind what can go wrong with exceptions when working with Kotlin. You can solve it using annotations and documentation, but in general people need to understand that if something can go wrong it will. They need to understand then how to solve it within the runtime code that they are writing, or building. If you are using an API, then API documentation will provide you with a bit more knowledge as to what is happening under the surface, and in terms of architecture, yes you need to know that when using an API function call or whichever function you are using within your own classes, you still need to interact with them properly, so it drives you to write better code handling for all exceptions.

Do you feel the fragmentation of devices or versions in Android is a real difficulty?

Yes, we see different behaviors across devices and different versions, and making sure that the app runs smoothly across all platforms can be a bit rough. But even so, it is a lot better than what we had in the past. I hope that as we progress in time, more and more devices will be upgraded to use an API level that is safer to use, and will mitigate fragmentation. Right now, some of the features that we are building, for example API 24 and above, have major progress in comparison to API 21 and above.

As a final question, which feature would you dream that Android or Kotlin would have?

I never thought of that, because, a week ago I would say camera issues on Android. But a month ago I would say, running computer vision in AI on Android on different devices. Camera issues are due to different hardwares. Google is doing a relatively good job in trying to enforce a certain level of compliance and testing on all devices. You have quite a few tests the device has to pass both in hardware and in API. But we still see many devices attempt to bypass, or give false results to the tests.

I would say giving us support for actual devices as far back as five to seven years, instead of three, and giving an all around better camera experience over all devices.

Thank you very much to Yossi Elkrief for your time and expertise!

Shipbook gives you the power to remotely gather, search and analyze your user logs and exceptions in the cloud, on a per-user & session basis.


  1. If you have a body, you are an athlete.

· 13 min read
Dotan Horovits
Elisha Sterngold

Dotan Horovits

Interview with Technology Evangelist | Podcaster | Speaker | Blogger at

Dotan started his career as a developer, moved to become a System Architect and Director of Product Management. This gives a broad understanding of various aspects of app development, which is extremely relevant for this blog where we focus on app quality in a broad sense. Today, Dotan is a Technology Evangelist, Podcaster, Speaker and Blogger

On LinkedIn you present yourself as Principal Developer Advocate and Technology Evangelist. Can you describe what you mean by these titles?

Essentially what this means is that I help the developer community use the products at my company, as well as with the broader open source projects in the domain, in my case DevOps and observability domains by sharing knowledge about tools, best practices, design patterns, etc. I also keep watch on the community pulse to make sure our own products meet the needs and desires of the community. I make sure it's a bidirectional channel where I can bring in the actual feedback and voice of our users into our company practice.

How do you see the place of logs in monitoring and solving issues?

Logs are an essential part of monitoring obviously, maybe the oldest and most established method of understanding why things happen in our system, especially why things go wrong. This is due to the fact that the developer who wrote the specific piece of code, essentially creates the output for what is going on in that piece of code. Therefore logs are just a very rich and verbose piece of information, and are the basic foundation for monitoring. It is important to say that logs today are not enough. You need to obtain fuller observability. Logs are one essential pillar, but they are usually accompanied by metrics and traces as well. These are the classic pillars of Observability upon which, together with potentially additional signals, one can get the broader picture of what goes on in the system.

Where do you see logging platforms in 5 years?

Logging has traditionally been very focused on the human aspect of the users. As I said, the developer outputs what goes on in the business logic that he wrote. Usually, it was outputted as plain text for humans to read. Plain text logs that are created for humans to read, they were unstructured and simply not scalable. These days when you have such a massive amount of logs in today’s distributed systems and microservices, we must use automated systems, and I foresee that these automated solutions will continue to grow and develop and we will see that people will be increasingly using log management systems and automation to aggregate, analyze and visualize log data. For that purpose we will see a growing shift going from unstructured to structured formats, plain text to machine-readable formats such as JSON. We will see more work toward log enrichment with metadata in order to attain better system insights, we will see more advanced centralized log collection, ingestion, indexing, and management. Instead of developers having to traverse hundreds of servers, there will be one centralized place where one can visualize, analyze, register, and create automatic alerts based on the logs. This shift is already underway and will accelerate. Going beyond that, as I said, logging will become much more integrated with the other signals in the observability domain, everything from the correlation between logs and metrics, logs and traces, as well as traces back to logs, and by traces I am referring to Distributed Tracing. This is another way in which I foresee logs will be integrated with other signals and events. The final direction perhaps in which I see for the future development of logging is through AI and machine learning. I believe that they will take an increasingly larger role with respect to analyzing and processing logs efficiently as well as proactively because as opposed to the constraints people face when attempting similar processes, AI and machine learning systems have the power to develop and advance incomparably faster.

I know that you are a big champion of Open Source. On your LinkedIn profile you write that your passion is: Tech, Innovation, and the power of communities & open source. I would like to hear your reasoning behind this, but maybe you can start by talking about what limitations you experience with Open Source.

I am a great advocate of Open Source. It’s hugely popular. Many developers already have the skill sets, so you have lots of users who are very familiar with the platforms, and a massive community pushing it forward. There are however several issues with it. The first thing that comes to mind is a common misconception. Often people think Open Source is equivalent to free. It is not zero cost. Yes you may not need to pay for a software or service license however you still need to invest in developers, devops, to install, operate, manage and scale. It is important to understand this. Many times new startups will begin with Open Source, as it is relatively manageable and cheap, however as they scale out they realize that the do-it-yourself model of Open Source is not as trivial as the organization scales out.

Another thing that I often encounter with individuals who are just starting to use Open Source, is as they adapt it to use in production, they realize that Open Source projects are really focused on one core capability. They put less focus on peripheral or administrative capabilities such as user and role management, team collaboration, single sign on (SSO), easy deployment, and so on. These features, I call them commercial grade or enterprise grade, and are not usually an inherent part of Open Source Software, but are needed to run things in production environments. Some vendors develop these additional capabilities on top of the open source project: so Grafana Labs or Elastic, or my company develop an additional wrap-around to Open Source to provide another layer of enterprise grade capabilities that is applicable for businesses in production as well.

Recently there has been a security breach with log4j, which is also based on Open Source. Is Open Source less safe than Closed Source?

The Log4j CVE was definitely painful for many of us, including for us in my company. Actually many Java products are based on log4j, but we are happy to say that is based on Logback, so we are not actually users of log4j, so specifically for us it was pretty smooth all things considered. Then again, the claim that Open Source is less safe would be one that I would have to disagree with, in principle. I believe the contrary is true. Open Source is safer than closed source. At least the popular Open Source projects are less prone to bugs and security vulnerabilities than closed source. That is thanks to the transparency and involvement of the vast user base and developer community that are constantly detecting, advancing, and fixing issues together. I understand that log4j had this bug for quite some time and no one detected it. However in commercial products the bugs are no less severe, perhaps they are much lower profile only because they are being detected and managed behind closed doors, whereas log4j was Open Source. For known CVE’s out there, I think over 90%, you can see patches and releases out there already, so the turnaround of the community is often much faster than commercial products. I definitely feel very comfortable with the security of open source, and as a developer community and community of software owners, we must remember that at the end of the day it is our responsibility to manage the dependencies and control them just as we need to do for licencing because it is ultimately our architecture and thus our responsibility to mitigate all this.

Elasticsearch has changed their licensing model. What does it mean for the user community?

Elasticsearch has become widely popular for log management and analytics, open source under Apache 2.0 license. Less than a year ago, Elastic B.V. the company that owns and is backing the elasticsearch project has decided to relicense elasticsearch and Kibana to a non-open-source license, it is actually a dual license, SSPL and Elastic License, bottom line, it is non-OSI license (OSI being the organization that essentially defines and validates the open source licensing). For the users, this essentially means that those who were counting on the open source being something they would be free to modify the code and adapt it to their needs, this is no longer the case. So, some users are fine using it as is, closed source. For others, it is important to have the flexibility and freedom to make these sorts of changes. Those who care about continuing to develop and better the software through the community, this will no longer be the case for elasticsearch and kibana. The other pieces of the ELK Stack, if you use the client libraries and the Beats, for example, filebeat, metricbeat, logstash and so on, are still Apache 2.0, however it is important to note that even there they inserted all sorts of version checks to verify the version of the elasticsearch cluster to which they ship logs. This is a breaking change, so if you don’t work with an approved distro, or even an older elasticsearch open source clusters (Elasticsearch 7.10 or earlier), it may break so you won’t be able to actually ship your logs to your elasticsearch distro anymore. So, it is a problem and the community has had adverse reactions. For example the community, after seeing this, then gathered around a fork of elasticsearch and kibana, it’s called OpenSearch, which is backed by significant vendors, the most prominent one being AWS, or Amazon Web Services. My company is part of this endeavor, whose goal is to keep elasticsearch and kibana open source. So OpenSearch is really an independent project that started off as a fork, and it is also a very interesting path forward for those who like elasticsearch but who wish to continue using open source.

You work at, can you tell us what offers? offers a cloud native observability platform that is based on popular open source tools. These include elasticsearch, as we mentioned, now OpenSearch, Jaeger, Prometheus, OpenTelemetry, and others. Essentially, we provide you with the ability to send your logs, metrics, and traces into one managed central location. There you can search, visualize, and correlate across your different telemetry data. So you can correlate your logs with your metrics, your traces with your logs, and so on in one central place. As I said it’s all based on open source so if you are already familiar with the Kibana UI or with Jaeger UI or with Prometheus and Grafana, you won't need to learn some proprietary UI or APIs or formats or query languages, it’s all based on open source formats that you already know and are familiar working with.

Where do you see product quality going in the future?

I think the most interesting paradigm I see is the shift of responsibilities towards engineers. Engineers are owning more of their respective features all the way to production deployment and beyond. Which means, we need to make it easy and accessible for engineers to understand the piece of software that they wrote and how it will behave in production and then once it’s in production to be able to monitor and make sure the quality of the product is maintained. This is why I am very passionate about observability. I believe that observability will play the role of the hero in enabling engineers to have at their fingertips the power to understand the telemetry and state of the system at any given time. They will be able to understand trends over time, even historically. By the way, with we understand that you cannot separate the issue of security from devs and DevOps practices, these are currently being called DevSecOps, and they are becoming very integrative. So even down to understanding how my system is vulnerable, and including all of this under one single pane of glass. This is how I see enabling the product quality starting from engineering and going all the way to production and beyond.

Do you find that there is a difference in user sensitivity towards poor product quality between different age groups or across different countries? Has it developed over time?

I think we as consumers have grown used to better user experience and new services. If you look at Saas services, on-demand, PLG (product-led growth), such as Netflix, etc. This user experience as consumers has educated us to expect a certain level of quality from the products that we use, even in our business interactions. This is why I believe that younger generations who are more exposed to newer SaaS offerings, are more informed, educated, and accustomed to these high levels of services. However, in general we, as a population are becoming much more keen in our expectation to receive a high level of quality in our user experience and this is something that we will see become very prominent. This is a nice segway to mention my podcast, OpenObservability Talks, because I am actually going to have an episode this week devoted to SaaS observability which will discuss how SaaS observability is key to enabling this level of quality of experience with SaaS products.

Do you have a dream tool that hasn’t been developed yet?

Well, I have many but I guess the one that is most relevant for these cold winter days that we are having here is a tool that will be able to turn on the boiler on time so that I can have a hot shower when I get home. Certainly for my children, this would be the one that would have the most impact these days. Perhaps an app that would be able to help you detect and avoid exposure to the areas with the highest Covid levels. These are the two tools that would be most useful these days.

It was great speaking to you, you gave us an eye-opening perspective on logs as well as on the subject of open source software. As a developer I have always appreciated open source, and as such Shipbook is open source on all levels, including our SDK, so I found your input very interesting. Thank you for your time.

Shipbook gives you the power to remotely gather, search and analyze your user logs and exceptions in the cloud, on a per-user & session basis.

· 11 min read
Yair Bar-On
Elisha Sterngold

Yair Bar-On

Interview with Yair Bar-On | Serial entrepreneur whose company, TestFairy, was acquired earlier this year by Sauce Labs

Yair Bar-On is a serial entrepreneur whose company, TestFairy, was acquired earlier this year by Sauce Labs. TestFairy is a mobile beta testing platform, handling app distribution, session recordings, and user feedback, in enterprise and secure environments.

Beta Testing is an important part of overall app quality and therefore we are very pleased that you agreed to join us for this interview for our blog, which focuses primarily on different aspects of app quality.

Please tell us about the background and history of TestFairy.

TestFairy was founded by myself and my co-founder, Gil Megidish back in 2013. We started the company after developing mobile apps in our previous company where we had some quality problems that we needed to solve. We had customers in the field with problems and we tried to solve those problems remotely, we had no idea what was happening over there, and that is how TestFairy began, by solving a real problem. Today TestFairy helps large companies manage their mobile development lifecycle. We do quite a few things across the development lifecycle. It starts with app distribution, which is a process of helping developers put their apps in the hands of users and help them with their beta testing. We can then record videos of exactly what your users are doing with your app. We have in-app feedback capabilities, allowing users to report bugs from the field, and in production we help customers with Remote Support and Remote Logging. So, in other words, with TestFairy you can have testers or real customers use your app, and you’ll be able to solve problems and have bugs reported through a very user-friendly easy interface. All this is just the beginning. We have recently joined Sauce Labs, which is the leading provider of quality software and digital confidence. Sauce has a very powerful service providing developers with real mobile devices in the cloud, that you can use for your testing, as well as emulators and simulators that you can use to test your apps automatically. TestFairy joined Sauce Labs to enrich the offer for mobile developers.

After getting acquired by Sauce Labs, you went from being a small independent company to being part of a much larger organization. What influenced your decision?

Right at the beginning of our talks Sauce Labs has inspired us with their vision. Sauce has acquired five companies over the last year, and you can only guess that more awesomeness is coming. The idea is to expand and become a one-stop-shop for all your digital quality needs. The world relies on code, and you need to make sure your apps, websites, and digital services are all properly functioning. Businesses need digital confidence. Your product needs to work 100 percent of the time. You can’t have your app at a B rating. Anything less than excellent is just not acceptable. What Sauce does is help you test your digital assets, end to end, in a very efficient way, allowing you to test your mobile apps on real devices, on emulators, and on simulators, as I previously mentioned. We have recently acquired API Fortress, which is now a very important part of the Sauce platform. It allows you to test the server APIsthe ones that are used to communicate with your apps, so that your testing is no longer limited to the front-end alone. Another company that joined Sauce is Backtrace, who is the leading crash reporter and error handling solution for mobile, web and gaming consoles. Many of the biggest gaming companies in the world use Backtrace. Crashes are not just about getting a stack trace, and fixing a bug. You need to see trends, and real-time information that can help you understand your users and where they are encountering difficulties. Taking that information and connecting it to your pre-release testing is super powerful and this is what companies are looking for. Imagine you are able to look at a crash and a minute later fix your tests to make sure that this crash will not happen again. All that can be done in real-time, not to mention AI and machine learning capabilities. Another service recently acquired by Sauce is AutonomIQ which is a low code environment that allows people who are not developers to build test automation for services that are used by their company, like Salesforce. The people who write those tests and build them don’t have to be engineers, they can be analysts, they can be product, they don’t need to learn how to code, they just need to know their systems. The last one I’ll mention, which was the first acquisition chronologically, much earlier on, is Sauce Visual. The Sauce visual testing platform allows you to test how your product looks across versions, across environments, platforms, and devices, so that you can look for visual problems during your regular testing.

Looking at Sauce’s impressive portfolio, you can understand why I mentioned that this was inspiring.

Are there any specific issues when it comes to mobile app quality or do you see mobile apps the same way as all other kinds of software?

Absolutely. I’ll start by saying that by definition, mobile is remote. If there's an issue with your app it is always happening somewhere else, not at your desk, or on your screen so you can’t open up a new window and inspect an element and see what is happening on your mobile device on Chrome. Issues happen on a mobile device somewhere in the hand of a person that in many cases you don’t know and cannot communicate with, and under these conditions you need to start solving a problem. That is the beginning. Second, the mobile environment is extremely fragmented. You have so many Android devices, and so many iOS devices, across hardware and software configurations, different levels of OS versions and locals, and this is before we get to the mobile device itself that needs reception, wifi, battery, and more. Mobile is just so much more complicated than web or desktop development. Whenever something goes wrong, the person reporting the bug has a lot of work. They need to take screenshots, they need to pull out logs from their devices, to explain what they did. These are some of the things we are able to solve at TestFairy that help mobile testing be done properly. Together with the things that Sauce Labs has built a powerful platform we manage to make developers' lives easier.

How do you see the relationship between Beta Testing and QA? Can good Beta Testing make companies save on their QA?

There are lots of stages in quality. First, we have to split the subject of QA into two parts, there is automation, and there is testing done by real people. The world of automation is very important for any company we speak to. Companies test their apps with many technologies including Espresso, XCUITest or Appium or on the Web with Selenium and other tools. I don’t think you’ll find companies that don’t do any automation. On the other hand, you have manual testing done by real people, which is not going anywhere, and this incorporates a number of stages. Some companies look at alpha, beta, delta testing and so on. Others will look at QA and dogfood. These are all different stages that are done by different stakeholders in the organization. The typical QA will be done by QA professionals, who are people that work inside the company whose profession is quality. They will test your app or your product manually and automatically. Their job is to find problems. Beta testing, or as we call it “dogfood”, some companies call it “catfood”, or even “monkeyfood”, there are lots of names for “dogfooding”. “Drink your own champagne”, is another term that is very popular. These are terms relating to companies with a process by which company employees use the company app in order to look for problems before the app is released to production. We work with many of the largest companies in the world and help them with their dogfood process. One example that I always like to mention is Groupon. Groupon has thousands of employees who use TestFairy to manage their worldwide internal beta testing. They actually call it “catfood”. Their internal process allows any Groupon employee in the world to report bugs directly to the mobile team in Chicago, in real-time. All they need to do is shake their phone, sketch on a screenshot, and hit the send button. That bug report goes directly to Jira, that is used by the R&D team and they get bugs in real-time. This allowed people to report bugs in a much more convenient way than before and it allows developers to see and fix bugs faster. It is very important to make bug reporting easy. We spoke to lots of companies and asked users if they had a case where they had a bug that they found during internal testing, but that was not reported, and then the same bug showed up in production. The answer was yes in many cases. When we asked them why they didn’t report the bug, the answer was either, it was too complicated to report, or they didn’t have time and they couldn’t be bothered with conference calls or follow ups, or they didn’t want to report the bug at the time since they were sure they knew about it. Then when we showed them TestFairy and for them it was just a life saver, because reporting a bug takes seconds. All you need to do is shake your phone and hit send, and the bug will appear on Jira.

What is special about beta testing is you can do it with people who are not technically savvy. You can do it with literally anyone, the people in finance, or the warehouse manager, operations department, whomever. They are not technically trained, you wouldn’t necessarily talk to them about your mobile app development, but they think like your customers, and they work in the company and want your company to succeed. If you will let them help you test your app, they will very likely be helpful in finding problems and be willing to report them in real-time.

There is a lot of shifting left. Developers do more. And we see a lot of quality going to production. Some of the trends I think we’ll see more and more of is that quality signals from Prod will go back to the development process and the automatic testing process that is done pre-release and will connect, automatically. We hear that from many of the Sauce customers. We see this in the questions we get from our largest clients who built their development process for the upcoming years ahead. I think that this will be a significant trend that we will see evolve.

What is the importance of logging in Beta Testing?

TestFairy can collect logs from remote devices. So if your app writes logs and you want to get logs and put them in your central logging server, TestFairy can help with that. Some of the biggest players in logging are Sumo Logic, Splunk, Coralogix, Log4J,, and many others. If you want your logs from all your remote mobile apps to be sent to your logging server, you can do that with TestFairy.

So TestFairy is an intermediary between the mobile apps and the cross-platform logging service providers?


Do you have a dream tool that hasn’t been developed yet?

Yes… but I can’t tell you about it. Because if I tell you, it won’t be a secret any more :)

True… true.. Thank you very much for your time, and for sharing your expertise with us, it was very eye opening. You gave us a different perspective on the ways in which companies, and especially larger companies, ensure their apps maintain high quality.

Shipbook gives you the power to remotely gather, search and analyze your user logs and exceptions in the cloud, on a per-user & session basis.

· 20 min read
Vandad Nahavandipoor
Elisha Sterngold

Vandad Nahavandipoor

Vandad has written a number of books published by O'Reilly such as iOS programming Cookbook, Swift Programming Cookbook and others, what’s more recently he has been publishing a ton of content, including videos with tips and tricks relating to Flutter on Youtube and Github. Vandaad currently has more then 2000 stars on Github for “Flutter Tips and Tricks”.

He is employed as the Lead iOS developer in Telia Smart Family. Telia being the leading communication service provider in Nordic Countries.

· 14 min read
Eran Kinsbruner
Elisha Sterngold

Eran Kinsbruner

Eran Kinsburner who is Product Management and Quality in a number of very large corporations such as Texas Instruments, GE Healthcare and Sun Microsystems. For the last 10 years he has been the Chief Evangelist at, first at Perfecto and later at Perforce Software. Not less important, Eran is a Best Selling Author of a number of books focusing on software testing and quality of which the last one called Accelerating Software Quality was published last year. With this background you are likely to be the absolute best suited person for this blog, which looks at various aspects of mobile app quality.

· 9 min read
Hillel Fuld
Elisha Sterngold

Hillel Fuld

Hillel Fuld has been named the 7th top tech blogger worldwide, he is named Israel’s top marketer, and on Forbes, was dubbed “The Man Transforming Startup Nation to Scale up Nation.” Hillel is a global speaker, tech blogger, startup marketer, and leading online influencer.

· 14 min read
Antoine van der Lee
Elisha Sterngold

Antoine van der Lee image

Antoine van der Lee has an excellent Swift blog SwiftLee, and works at Dutch digital giant WeTransfer.

How did you get into blogging about Swift and iOS in the first place?

The main reason for me was that as an engineer you need to stay up to date anyway so that is reason enough to learn a new topic. My way of learning has always been to write it down, summarize it, as well as creating a logbook myself for whenever I want to go back to revisit a certain topic. The logical step afterwards, for me, was to create a blog and use that to write down my learnings in a way that is beneficial for others to learn from. That process started very simply. My first articles were something like four short paragraphs, no intro, no conclusion, lacking the structure that you would expect from a good blogger. Over time, everything improved. But yes, the main reason was initially for myself, to build up a knowledge base that I could return to!