Mobile Devops+Agile Keys to Success

The need for mobile applications has increased manyfold in this technological era. They have changed the way we interact with our surroundings. Therefore, developers are seeking more convenient ways to create mobile applications. Which not only guarantees the highest quality but also ensures less time to market.


DevOps and Agile are two approaches that have emerged as critical players in this space. These technologies help a developer create more professional, reliable, and efficient mobile applications that aim to enhance the users’ overall experience.


DevOps is a  methodology that combines operations and development. To streamline and automate the entire app development process. While Agile is a methodology that mainly emphasizes development, teamwork, and continuous feedback.


Whether you are a professional developer with years of experience or just starting your career as a mobile app developer, adopting DevOps and the Agile approach will surely help you to develop the best mobile application that your users will love. Let’s find out how the developers can leverage these platforms to benefit their projects.


Delivering a high qualified software is not a Unique Selling Point anymore but a prerequisite for better customer experience. In the present era, the customer is very educated about the choice and comparison between the best services or products. Along with quality goes the promptness in service delivery. In terms of Quality Assurance, both can be achieved by implementing Agile and DevOps best practices. The developers have achieved a lot in terms of solving quality issues and delivery with the help of automation. To ensure constant success in this maneuvre, the firm has to ensure that the metrics to be tracked are chosen rightly in order to maintain the quality throughout the development process.


The delivery of mobile apps is done differently than other ordinary apps. Although the elements of Devops – agility, Continuous integration and continuous enhancement are followed in both the cases but specifically in case of mobile apps, there has to be a unique strategy and tools.


What are the mobile application delivery challenges?

Mobile apps are built for smaller screens, need of touch output are completely different than that of web apps which need mouse or keyboard. Apart from these, it faces other challenges like:


Fast Delivery

Mobile app users are used to fast service of apps, automated updates and quick response time. So to maintain the competitiveness, the mobile app industry has to focus on methods and tools that leverage quickness and quality of the output delivered. The faster the performance of the apps and updates, higher will be its chances to overpass the competitors.


Design and build of Mobile Apps

Mobile apps are built on a different understructure. The entire build and design exercises have to be executed and tweaked according to the screen size and device architecture. Also, based on the advantages of mobile device, the apps should utilize the features like camera, GPS, Bluetooth, voice/video calling to give an edge to the app’s friendliness and captivating ability. If the mobile app is poorly fabricated, it will quickly drive away the users.


Competition in the market

As per the latest statistics, there are about 2.8 million Android apps and 2.2 million apps available on Apple store and thousands more are released each month. The app with the unique features will only be chosen and the competition increases as the mobile device market advances.


App Store dependability

Who knew that app store would be a challenge? Yes, most of the times the apps cannot be deployed directly to the device, it has to go through the app store. This acts as an additional step in the process which delays the app deployment on the user’s device. It also restricts the developers to push direct updates or critical bug fixes in the app. So instead of being a ‘continuous delivery’, it becomes ‘awaited delivery’.


Above are some of the most common challenges that are faced in mobile software delivery but how to meet these challenges?


The Devops team can follow a more analytical approach to the software delivery with a concrete set of Devops principles.


1. Early Monitoring
2. Achieve quality at good Speed
3. Multiple Channel Visibility
4. Automating to the maximum
5. Constant feedback


1. Early monitoring:

Most organizations tend to monitor their built apps only in the production stage after releasing it to the end users. This is the biggest mistake they can do. The DevOps team will have to reconsider this practice and work on a different approach by monitoring the critical measures at pre-production stage. Continuous monitoring and making early stage improvements would really matter in the overall app success.


2. Achieve quality at good Speed:

To achieve ultimate success, the DevOps team has to focus on quality with speed and also consider the cost it would incur. To accomplish this powerful goal, the team has to adopt DevOps and agile practices alongside. According to Forrester analytics reports, the firms who have adopted this approach has seen a rise in the benefits like technical and functional quality, and high delivery frequency. By emphasizing on building the expertise of the resources, implementing continuous testing, involving testers as a part of integrated testing phase, automating end to end functional testing and by implementing shift-left testing at all levels of development cycle, the firms give the software testing a new face leading to business transformation.


Agile and DevOps


3. Multiple Channel Visibility:

Mobile apps have to be built for serving different platforms. Along with the web version of the app, the DevOps team has to deliver a mobile version in most scenarios. In order to attain this understanding, developers need to analyze what is the journey of the users when they decide to switch from web to mobile apps and one device to another. This is a critical data that would be the deciding factor in developing the app for different channels.


4. Automating to the maximum:

As per the Forrester study conducted on the success of advanced Devops+Agile firms, the firms have automated most of the testing processes by 50 percent in order to reap the benefits of successful Mobile Devops. The result is faster and quality software delivery by a continuous testing implementation.



5. Constant feedback:

This is the most discussed and the most important point. The developers must identify the issues the application is facing in all the stages of delivery in order to take corrective actions on time. DevOps team has to be vigilant and responsive to all the issues that arise at every step. In this fast-paced Mobile app development market, this is a must have key point.

Benefits of Agile and DevOps Integration

  • Enhanced client satisfaction and reduced time to market.
  • Improved delivery speed and efficiency.
  • Enhanced team cooperation and communication.
  • Increased focus on innovation and continuous development.
  • Ability to respond quickly to changing company needs.

Implementing Mobile DevOps: A Three-Step Guide

Organize Continuous Delivery and Integration

  • Integrate and track all code, scripts, documents, and configurations.
  • Ensure build consistency and version control for scripts.
  • Keep separate builds for each target platform.

Implement monitoring and testing

  • Use automated testing techniques to test the application.
  • Utilize virtual instances to test the app ecosystem more quickly and affordably.
  • Add a third-party SDK integration for ongoing app monitoring.

Concentrate on Delivery and Quality

  • Check code integrity at each level of development.
  • Monitor the app for any flaws and improve functionality.



Mobile DevOps is a distinct software practice which is built on top of the traditional DevOps mechanism. It demands an extra attention to all the processes in order to produce a fast and quality software delivery, extraordinary application design and commendable user experience to facilitate success in the mobile application market. It carries a bigger picture by focusing more on the ‘business DevOps’ rather than just ‘DevOps’. To attain maximum DevOps Feat, the DevOps team has to be a step ahead in adopting new analytical approaches at every step of development and delivery. It has to be instinctive and provide continuous visibility to the delivery pipeline to gauge the ultimate app performance in the User market.

Choose pCloudy for your Mobile DevOps and Agile needs. Our cloud-based testing infrastructure offers comprehensive solutions that can help you to expand your target audience, enhance testing efficiency, and ensure the quality of your apps. With over 5000+ real devices and browser combinations, our platform provides Continuous Testing, DevOps, Advanced Automation, AI-based Visual testing, Robotic Process Automation, Real-time Test Analytics, and more. We also offer 24×7 support to help you address any concerns you might have. Don’t hesitate to contact us to discuss your Mobile DevOps and Agile needs today.

DevOps helps enterprises to build software at a fast pace and with minimal issues. The time to market is accelerated and the bugs are fixed faster in continuous deployment with the help of automated tools. AI is much in line with DevOps as the main focus is on automating the process and with AI the system can identify patterns, anticipate issues and provide solutions. The proactive approach improves the overall efficiency of the software development life cycle. So let’s have a look at how AI is transforming DevOps.


Feedback Loop and Correlate Data

The main role of DevOps is to take continuous feedback at every stage of the process. often people use performance monitoring tools to get feedback on running applications. These tools gather much information in the form of log files, data sheets, performance matrix, and other types. The monitoring tools use machine learning to identify the issues early and make suggestions. The DevOps teams use these suggestions to make the necessary improvements to the application. Many times teams use two or more tools to monitor the health of the app and the data from all the platforms can be correlated by the help of machine learning to get a more deep understanding of the app functioning.
AI Plan Release Debug - DevOps

Software Testing

AI is changing DevOps for good by enhancing the software development process and making testing more efficient. Whether it is regression testing, user acceptance testing or functional testing, these all produce a large amount of data. AI can figure out patterns in the data collected in the form of results and identify poor coding practices which produce a lot of errors. This information can be used by the DevOps teams to increase their efficiency.

Anomaly Detection

DevSecOps is one of the essential aspects of software development as security is the key to any successful software implementation. Distribution denial of service attacks are increasing and the business needs to prepare themselves to protect their security systems from hackers. DevSecOps can be augmented using artificial intelligence to enhance security by central logging architecture to record threats and running machine learning based anomaly detection. This will help businesses proactively attenuate the attack from hackers and DDOS.


DevOps approach might create scenarios where the team receive an overwhelming amount of alerts without any priority tag. This will create ruckus in the teams as it will be very difficult to handle all the alerts in the continuous development environment. AI can help in this scenario by tagging the alerts and prioritizing them so that the urgent ones can be worked upon immediately.

Root Cause Analysis

To fix an issue permanently, a root cause analysis is necessary. Although it might take time to do it compared to fixing the issue with a patch which will provide the instant solution. In order to find the root cause of an issue, the developers will have to spend time which will delay the release of the product. AI can speed up the process by finding patterns in the data collected and implement to fix the root cause.
The collected data can be used by implementing AI to find a pattern and speeding up the development process. The organized data is more useful and makes prediction possible. The best practice is to use machine learning to automate the tasks which are time-consuming which will ensure the smooth and effective functioning of the DevOps teams.

Related Articles:

  • Bureaucracy And Other Unlikely Roots of a Fledgling DevOps
  • Mobile Devops+Agile – Challenges and Keys to Success
  • pCloudy’s DevOps Journey: Lessons Learnt While Scaling Up!
  • Moving Beyond Traditional App Testing with AI and DevOps
  • Code Review in a Startup: Balancing Perfectionism and Sanity at the Speed of Thought
  • [xyz-ihs snippet=”quickLinks-scaling-up”]

    Fledgling DevOps

    Here I present the 4th blog in the DevOps series showcasing our learning while #scalingup. Read our previous blog to know about the lessons we learnt from our scrum.


    Most DevOps patterns are exhaustive and would need some strong commitments, in terms of both time and effort which is why many a times people hesitate to introduce DevOps to their teams. Because there usually is a lot of change required in your way of working and the way your workflow flows when you try to retrofit a DevOps into your setup. More so if you did so without thinking hard about the consequences. So how did we create a continuous system of delivery? How did we make a system that is robust yet flexible enough to incorporate the needed changes?


    DevOps has a unique challenge. It is difficult to retrofit DevOps into a running system and doing that is not going to directly bring revenue. So in a running startup setup we simply cannot imagine stopping everything, spend time exclusively on this and then go back to our other tasks. But it does not mean that we can’t’ have a functional DevOps, it only means we have to go from MVP (minimum viable product) to MVP on this, and the earlier MVPs might seem pretty embarrassing but it is useful to prove the concept first and then go on and build the concept. Else you might end up with a sophisticated solution that is working but may or may not be what you need.


    I have already talked about our thought process where we are against blindly reinventing the wheel or retrofitting someone else’s wheel onto our vehicle. The same goes for DevOps, barring obvious things, we never did any upfront development for DevOps or DevOps processes, rather we went step by step automating bits that we could and bureaucratized bits that we couldn’t. And then went back and discarded the failed MVP, and formalized the ones that have passed. And as always kept doing it. Because above all DevOps is a result of the Agile attitude more than anything else. If you are not thinking agile when you build your DevOps, then you will end up with a random bunch of automated tools, and not a living, breathing system of delivery.


    So, here are our bunch of tactics that we used at different times during our evolution to achieve a successful clockwork.



    The most bureaucratic of them all. Forms are the ultimate icon of a bureaucracy. Whenever you want any service done from any bureaucracy, you have to fill a form. And it definitely looks uncool. However there is a reason why it is still going strong across the world both offline and online. The primary benefit of a form is that you get all the data you need in the correct format and it is easy to find out if any required data is missing. This helps because data being missing can be addressed at the very beginning and not later on. Where we use forms is when one group of people need a service done by another group whose work is totally different from the first. For example, when developers want the deployment team to deploy something somewhere (any of our test envs or staging or production) now a developer could do it. But the deployment team owns the passwords and access to the staging and production setups which devs do not have and they also own the best practices which the dev team may not know. One of the problems they faced was that each developer had a different idea of how to push their artifacts to production. For devs of one domain, just copying code was enough, others needed binaries to be changed, still others wanted binaries and configurations to be changed. Some needed process restarts and others did not. Some needed server restarts while others did not. For some devs running an update script was enough while for others some other thing also had to be done. It was very difficult to keep track of these. One solution would be to have the deployment automated. And that is where we eventually reached. But that was not a one day job, and till that was done, we could not have stopped deployments.


    So we needed to make sure that the deployment team had the right info when the request was made and not then the team had done half the deployment. We experimented with emails, but most devs wrote what they thought was relevant and not what really was relevant. So we asked developers to mention all that was needed. But that also was not too clear a requirement. And many still missed the requirements. So we created a form. The biggest advantage, is that the developer cannot now accidentally miss any important info. It is difficult to miss info when the form explicitly asks for info. So now developers fill all the info even the ones they think are obvious or irrelevant. And the deployment team was now empowered to act like a bureaucracy and reject a form for data not filled. This worked like magic, our deployments became less buggy and there was far less cases where dev and deployment teams were arguing about what they meant when they said something. The direct result of adding deployment forms was that our deployments were now far less broken.



    It is the checklists that eventually gave us the idea that forms can also work. Checklists are the zero brainer tool of choice for a lot of people. And it has been so for almost a century now. Perhaps more. However the power of checklists are often underestimated or ignored. You need to read The Checklist Manifesto – by Atul Gawande, to understand how important and valuable checklists are and how crazy it is to ignore them. There was a huge list of things that we were many times not doing right or missing small or obvious steps. And no matter how much we tried we would many times repeat the same mistakes over and over again. And usually our bandwidth was too tight to go deep into each of those issues and find out what went wrong. The responsible person would say that they have done each step as it is supposed to be done. Obviously they did not think that they had done wrong. Because if they thought they were doing the steps, wrong they would not have done it the first time around. No one likes to do the same things repeatedly. Of course many such processes eventually got automated, but till they did, there needed to be a solution. Also not everything can be automated. So we created checklists for every repeated process. And placed them in prominent and easy to find places (physically and in our intranet) This also worked like magic. Soon the number of errors in repeated processes saw a huge fall. Once the errors reduced, the people handling those tasks got more time and bandwidth and they had time to fix their processes and also to automate them. This way the manual process need to be no longer done by a human. This brings us to the next step.


    Micro Automations

    While it was clear to us long time back that there needs to be a lot of automations in our day to day work, there was one thing that did not allow us that immediately. And that was that automations take time and usually features for customers had highest priority and lowest available times. So when do we spend time on automations? For some time we just postponed the automation work thinking that after the present set of issues are finished, we would have time to work on automations. However we soon realized that this is a mirage and being the startup that were, getting bandwidth for this sort of thing will not be a reality any time soon. But does that mean we abandon it and the benefits that they would bring ? No, what we did was, we took time to make sure that whatever bits we could automate, we would. And make sure that we keep using it unless it was totally unusable.

    We made sure we set out to automate only small bits. I call the process Micro Automations. As the name suggests, we only automate a small bit at a time. We also ensured that each bit that we automate is SMART, (specific, measurable, achievable, realistic and time bound). And also we made each bit small enough that it can be done part time by one or two people knowing very well that the main features clearly have priority.

    This ensured that over time, we automate more and more bits of processes like our build systems, deployment process, automation tests etc. Bit by Bit. Over time, however we achieved a lot. Finally after all these months, we look back and marvel how much we have actually achieved. As the old adage went, we won the race, by being slow and steady.

    There are many more such things that I would like to talk about, but I would like to limit myself to the bureaucratic ones that we attempted. We wanted to make sure that our focus was on the problems pCloudy was supposed to be solving for our customers, while at the same time, we ensured that we were also becoming future ready and being more and more ready to scale further as an organization. Your comments and insights are welcome. I would like to have a conversation about that in the comments section.

    Prashanth M Nair | Posted on | 2 min Read

    [xyz-ihs snippet=”quickLinks-scaling-up”]

    This is the third blog in the #scalingup series. Read the previous blog to find out more about our DevOps journey while scaling up.


    What is Scrum ?


    No Really, What is scrum ? How do you define Scrum ?


    A Scrum, as you can see in the image below, and as per wikipedia, is the method of restarting play in a Rugby game that involves players packing closely together with their heads down and attempting to gain possession of the ball.




    I am pretty sure that is not the definition that you wanted to see, at least not in this blog. But, bear with me for a couple of seconds. It was not a failed attempt at a bad joke. I just wanted you to see the imagery and get a feel of what is happening. Also I wanted to throw some light on the history of that name. How did a Rugby method give its name to the popular Agile methodology that we use almost throughout the software engineering world.


    An oversimplified definition of scrum is that it happens to be a common Agile framework where actions are planned to be completed in timeboxed intervals known as Sprints and progress is tracked on a daily basis in short meetings known as Daily Scrums. This daily Scrum is a stand up meeting with team members standing in a rough circle and explaining their set of points. Since this arrangement looks like a civil version of the Rugby Scrum, both the daily meeting and the process take the name of this particular Rugby activity. The point of this is that the entire team meets, gets to know the statuses of all the activities being done, finds mechanisms by which anyone who is stuck gets help and any one should also be able to suggest improvements etc. Because of this nature, It also allows for course corrections and other changes needed to make sure that what was planned for in that Sprint is indeed completed within the same sprint. Everyone is present to tackle whatever situation is there at hand. Both in Rugby and in this Agile Methodology. Hence the name is shared in both the disciplines.


    Scrum is probably the most popular of all the Agile Methodologies in the software engineering world now. It is popular because it gives you as a team manager and as a team member a lot of freedom and expects you to fill only the minimum amount of documentation. It also offers both stakeholders and developers opportunities to reconsider and change their minds about requirements, architecture and other stuff that is usually set in stone in an upfront manner in other older methodologies. If you need to change any of these, you only have to wait till the end of the sprint. It also has periodic feedback built into it which is facilitated by Sprint Review & Retrospectives & the availability of a dedicated Product owner gives you the ability do a lot of experimentation with your feature set before arriving at a final one.


    And it is for these reasons that we chose scrum as our Agile Methodology of choice. And it made a lot of sense. After all, we had seen a lot of benefits of scrum in our previous organizations and have been able to make good use of the same here too. But the sailing was not smooth. At least not in the beginning. Here were the primary reasons.


    • Non Constant Tasks during a Sprint: pCloudy is essentially a SaaS offering and that too in a startup frame of working. So this usually meant that some issues that crop up, mid sprint which might be important for some (important) customer, and the priority therefore gets bumped up. This would mean that developers have to strategically pivot and fix those issues leading many times obviously to the issues that were originally planned getting sidelined. So the usual 2 week sprint got broken all too frequently and this meant we had unfinished tasks at the end of each sprint, which was definitely not desirable.

    • Sprint Length: The ideal sprint length is considered to be 2-3 weeks with the most popular length being 2 weeks. This is ideal because it is short enough for a feature to be completely done from end to end and yet be short enough for stakeholders to experiment with features and decide to pivot if needed. However with many customer related interruptions coming, we decided to reduce the length of a sprint to one week. The idea was that we would take in this kind of customer interruptions only in the next sprint, which never would be more than a week away, and with this whatever we planned for in the sprint would be completed. However what we say here was that a week was usually not enough time for a feature to be completely developed, let alone it being tested and deployed. This meant that at the end of the sprint, most of the features were not “done-done”. They would be in various stages of completion. Another issue we faced was the length of the review and retro meeting of one sprint and that of the planning meeting for the next one.

      So here is what we finally arrived at, which takes the best principles of Scrum but at the same time be able to be as Agile as possible. Remember, we are not here to be Agile Champions, So Agility is very highly desirable, but not indispensable. We did some modifications to our process, once small change at a time and kept doing those changes, here is what we look like now. But As our changes continue, I am pretty sure our methodology will not look like what it looks now even 6 months down the line. Here are the most salient items from our thought process.


    • Sacrosanct Backlog:
      • Backlog Storage: Every Feature that we need to pick up is stored in a backlog. We used JIRA for some time and have now migrated to Trello. But the point is that our Agile Backlog is stored in a automated tool. Tomorrow, if our team’s complexity changes, we may chose something else, but the point to note is that team members are able to access the backlog and are able to see all the items they are required to work on and report all changes in statuses. With both JIRA we had used the Kanban like board that the system provides and Trello by default comes with this board. This board was one of the most important artifacts used by the team.

      • Also we changed our methodology in such a way that while the Backlog itself is sacrosanct, but we allowed ourselves to change the backlog of a sprint to ensure that our customers are not waiting. But unless something earth shattering happens, we do not interrupt a particular task before it is finished. So strictly speaking, we are not doing Scrum, we are in fact doing something more in line with Kanban with some trappings of Scrum like Planning, Review, Retro and of course the Daily Scrum. While we continue to internally call the daily meeting a Scrum out of habit, we also do not pretend that our process is Scrum. It is now a form of what many people call the “Scrumban” where the best features of Scrum and Kanban are merged together to form a practice that looks like both. We have found that at this time, this suites our business and development needs best.

    • One Scrum / Many Scrums: We were once a smaller team and hence it made a lot of sense for the entire team to have a common scrum, but as the team became bigger, the scrums dragged longer and both heads and legs began to ache. We then divided the team based on the specific area that each of the team worked (Portal, Devices etc) and had each team have their own Scrum. Then all the Scrum Masters of each team had another “scrum of scrums” where the larger team could focus on larger goals. This made each scrum shorter and each scrum more relevant for each attendee.

    • Management View: Previously since the team was small, the management found it easy to sync with each team member and follow their pace of tasks with a single tool like JIRA or Trello. However as the team grew, the management needed something more robust and flexible to track their day to day tasks. We started with a shared Google sheet that managed the status of each work item which was always updated and visible to management. The shared Google sheet while easy seemed a bit flimsy. We then moved to something a bit more formal with Atlassian Confluence. Now broader level tasks are looked at in Confluence, which break down to smaller issues in Trello for each developer to work on. The scrum masters make sure that Confluence is updated based on the status of the tasks in Trello. Also the confluence report has links to the trello issues.


    So what is next and what is the way forward ? Well I do not want to answer that question. That question takes the fun out of the journey, the fun of not knowing what you will discover at the next bend, what you will invent at the next bend. However as I have kept saying, ours will be a journey where we continue to tweak our processes so that it fits us at every phase of our growth. We are still young as a company and still growing and we need to be able to continue tweaking, at least till we are in a few hundreds in terms of headcount. But that doesn’t mean we are blind about the future, and we have no idea what to expect. In fact on the contrary, every tweak we make also comes with the question, how long will this stay and what do we need to do when we outgrow this phase. This is a constant question that we put to ourselves and make sure we have answers. Whenever we don’t, we step back and replan.




    Before I sign off, let me also throw some light on the experiences we had with some of the tools that we used to track the development. Also a small tidbit about compliance.


    Plain Excel / Google Sheets: A Spreadsheet software is the simplest and most flexible mechanism to track virtually anything. In fact it is this simplicity that tempts a lot of people to Run their Software Agility through a series of shared Excel sheets. We too had the same experience, but the only problem is that if you have to manage complex calculations and deductions, then the number tasks that you have to perform to keep your sheet in control becomes difficult to manage. This is not a problem if this is the main thing you do or if you have people to do it for you, otherwise it soon becomes very cumbersome.


    JIRA: Jira is a globally popular Issue Management System which is very very helpful in tracking issues. It also deals well with dependencies and broken down tasks. It does what it does very well. But it has one issue that makes it a bit difficult for a fast paced startup. And that is it is very rigid and inflexible. And maybe it was designed that way and it was intentionally not made too flexible, so that there are not too many changes done. I wanted some changes in the workflow that was specific to the work that we were doing and I could not quickly do it. Remember altering JIRA was not the only or the most important work that we were doing. I tried a lot to understand the complexity of JIRA under the hood, but I could not achieve something as simple as adding as many more columns to the JIRA kanban board as I wanted. I know it could be done as I have seen something like what I wanted working elsewhere, but I simply did not have the patience to understand the arcane JIRA workflow editor and other such entities in it. I understand, this is probably a job for a JIRA admin, but we were not so big to recruit one to do the customization for us. So for now we went to another tool from the Atlassian stable. Probably we will revisit JIRA when we grow bigger. And that brings us to the tool we are using now.


    Trello: We have right now all but settled on Trello. Trello is another project tracker from Atlassian. It is built around the Kanban board and hence allows you to do a lot of changes to the Kanban Board, including custom columns(we view them as states). We liked it a lot, since I can now track the exact (and many times specific to pCloudy) state each item is in like Backlog, Requirements, Design, Test Planning, Coding, Testing, Code Review, Ready to Deploy, Post deployment Sanity and others.


    Compliance: One common thing with these tools is the amount of developer (and tester and devops engineer) compliance. The success of any of these tools depend on the readiness of the developer to actually update statuses in these or any tools. I have see this for the past 15 years that many developers, including me when I was a fresher, simply do not want to do this. Somehow they are ready to spend nights and weekends in office running behind an elusive bug, but spending 5 minutes updating the tool is many times anathema. You have to make your developers see that it is imperative to do the necessary status and other updates in these tools. If your developers do not do it, then none of these tools will be useful. In the end these tools as much for the developer as much as it is for a manager, but they will work only if they are used properly.


    Share with me the lessons you have learnt from your daily scrum in the comments section. Keep a watch on this space for my next blog in the #scalingup series.

    App Testing with AI and DevOps

    Are we not living in an amazing time? Technologically advanced, digitally sound!


    We thrive on all things digital. The world around us is becoming all digital with limitless possibilities. Today as a consumer, you can preorder your coffee, interact with augmented reality in the store, and skip the lines at store with alternative payment methods.


    To cut the story short, as a consumer, we have access to unlimited goods and services and connected around us. And mobile is at the center of all this change. It’s the tool that is bridging the gap between the digital and physical.


    And the availability of 5 million apps come as a proof of this explosion. In the first quarter of 2018, Apple had 2 million apps on App store. As of the same quarter, Android users were able to choose between 3.8 million apps. More and more businesses are adopting Mobile Apps as their primary channel for business growth. This explosion proves that mobile is at the core of customer experience.


    Before moving further into the topic, you can watch the entire webinar here or else you can skip the video and continue reading to get the gist of the webinar.


    As a business mobile Apps are not just another channel. More and more organization are realizing that it can be a means to create awesome customer experiences. There are numerous examples to illustrate.


    One such example is Starbucks.

    The secret to Starbucks’ app’s success is that it gives users an intuitive experience, making it as easy to find a store, order your coffee and make a payment through their wallet. Recently, Starbucks has also taken the mobile app experience one step further with an innovative conversational ordering system powered by Artificial Intelligence (AI). The explosion in mobile apps imply to speed. How quickly you can make a change and let the customer experience it? The mathematics of velocity matter here. Market speed has left companies with a simple problem: How do we go faster than we ever have before, without losing an eye on quality?

    The success stories like Facebook and Netflix tell us that we can
    It is an amazing fact that Facebook mobile app is updated and refreshed every two weeks like clockwork. That’s the new normal. We will talk about this example in detail a little later in the webinar.


    So in order to gain Quality@Speed, we reach to a point where experience and quality intersect and we name this convergence Quality@Speed. It’s a no brainer to say that Quality @ speed can be achieved with two fundamental principles.


    Agile: Agility allows teams to work closely with business and it Pulls quality forward. It’s also called Shift Left of Quality. You are delivering small chunks to end consumers on weekly or monthly basis. This allows teams to get feedback early on.


    DevOps: DevOps brings you speed. It’s a Shift left of operations.


    Shift left of operations


    DevOps practices allow you to create “ready to deploy code” on demand. In other words, it means deploying software and the environment on which it runs, automatically and on demand, at any stage of the software delivery lifecycle. You can truly have multiple deployment in a day.


    If we dig deeper, DevOps is enabled by two practices Continuous Integration and Continuous Delivery. These two will not work in sync until you have continuous testing in place. It’s also proven by many independent studies.


    Here, we have a look at the data extracted from World Quality report, 2017-18 showcasing the popular and the best practices followed in DevOps.


    World Quality report 2017-18


    If we have a closer look at the data, we will find that 87% of CIOs and senior tech professionals use or are planning to use cloud based test environment. Depending on choice of organization, it could a Private or public cloud but it’s a must to achieve speed.


    Second data point is about Continuous Testing, here as well more than 80% of respondents chose this as a preferred DevOps practice.

    Let’s look at what some of the success stories say

    Facebook follows Ship early and Ship often approach. They update their web app multiple times a day while their Mobile Apps with frequency of almost 2 weeks. This is possible with DevOps best practices they have been following from past few years.


    DevOps at Facebook


    If we analyze their DevOps story in short, we find that one of the biggest takeaway for Mobile Teams is their massive investment in device infrastructure. Every time they make a change to app, it gets tested on 2000 real devices. Imagine 2000 real devices! They have bypassed use of simulators or emulators.

    Mobile DevOps Challenges
    Now let us move on to have a look at some of the Mobile DevOps challenges that comes as an obstacle on the way of mobility teams.

    Multi-platform Support
    Mobile apps have multi environmental target. Mobile apps have to deal with device fragmentation as they need to be workable on multiple devices. This poses a test for Ops team to build an optimal device infrastructure. Moreover, it is difficult to keep pace with the ever changing device requirements.

    Mobile apps as an enterprise front end
    Mobile apps, that too, mostly the enterprise mobile apps catering to business-to-consumer (B2C) or business-to-employee (B2E) segment of apps, characteristically have very less trade logic on the mobile device itself. On the other hand, a B2C or a B2E mobile app
    serves as a front end to enterprise mobility already in use by the firm, such as transaction processing systems, employee HR systems, or customer acquisition systems.


    This implies that the mobile app, available on multiple platforms as a native or Mobile Web app, needs to be built and delivered aligned with the backend services. The biggest challenge for DevOps is to think about enterprise mobility holistically and manage their build and release processes and cycles.

    The App store
    The app store includes an extra asynchronous step to the deployment procedure since developers are not able to update apps on demand. Even for grave bug fixes, new app versions need to pass through an app store submission and review process. Continuous delivery here gets a roadblock and the instant delivery becomes “submit and wait.”

    Build Challenges
    Since apps today are supported on multiple platforms, numerous different builds of the app has to be triggered each time when a change is being deployed by a developer.


    The build system and configuration for each supported mobile environment is dissimilar from the others. You will probably require a small farm of build servers to be provisioned and available to manage these multiple operating system builds.

    A typical Mobile DevOps Architecture
    Let’s try to depict the Mobile DevOps cycle. Some of the tools mentioned here are a representative set of tools in the respective category.


    Mobile DevOps cycle


    It starts with a Dev checking in a code to Git/Versioning system. That triggers the CI server to build the App which could be Internal build server or a cloud system like Circle CI. Once the build is successful, Unit tests are runs on Real devices. If the Tests are pass, build is pushed to QA Env. Where Automated regression tests are triggered on real devices. If that’s a pass App compatibility tests for new features are done.

    The Evolution

    DevOps Tools


    We’ve by now witnessed quite a journey to reach Continuous Testing. “Classical” testing was intended for software delivery cycles spanning months or year. Agile has changed this norm to a 2-week development iterations—but now something extra is required to meet today’s insatiable demand for software. Attempts to fasten the process further, created a chasm between Development, Test, and Operations. That gap has been bridged with DevOps and Continuous Testing in order to move beyond that speeding up plateau. However, when we look into the future, it’s clear that even Continuous Testing will not be enough. We need “Digital Testing” to achieve extra acceleration and meet the quality needs of future. AI can help us get there.

    Mobile Testing and AI

    If you keep pace with the market buzz you will find there is an ongoing debate about what AI can do? When it comes to testing, lot of theories have started predicting that AI has the ability to replace testing. Well personally I don’t see this happening in near future. But we certainly are very excited about capabilities AI present in from of us.

    When we an organization think of using AI to sole testing problems we think on three lines
    a) Can it improve speed of current testing process?
    b) Can it help generate meaning full data for me to make intelligent decisions?
    c) Can it improve the test coverage and reduce cost?


    So, are you ready to adapt a personal assistant for testing. So are you ready to say? Certifaya, Can you run an App Test for me? pCloudy’s AI powered bot, can automatically test the mobile applications over hundreds of real mobile devices and gives its users real time insights into the app’s behaviour and performance. Do you want to explore more? Try Certifaya for free now and testify it yourself. You can also go through our webinar on the same topic to understand it in detail.


    App Testing

    If recent past has been any indication, then it is a certainty there are growing expectations from Testers and Developers alike, to take quality head on, as a joint feature. More so in the Mobile App Testing projects where changes are required faster than ever.


    As part of DevOps practices, it’s has become imperative for developers to run as many tests as possible with every code check-in. These tests could be automated functional, API or Unit Tests. Some of the popular tools to used by Developers to create their tests are Espresso, XCTest and Appium.


    Following are some the Challenges faced by developers:

    • Developers need access of right set of devices across different versions to be able to run their tests.
    • Debugging capability on those devices so that they can fix issues quickly.
    • Access to a specific model of devices to debug production issues.

    Try taking a look at a typical developer’s cubicle and you will see a series of mobile devices connected with several long USB cables running into computers. It does get frustrating to see others furiously plugging USB cables in and out of the mobile devices for App Testing on various devices.


    Many of the organizations are shifting to device cloud to provide their teams access of right Mobile Devices. Device cloud are solving the need of test teams but provide limited debugging capabilities and hence not preferred by Developers.


    To directly address need of Developers, pCloudy recently introduced DeviceTunnel, which fully allows developers to take complete control of the device in cloud. This unique solution provides access of cloud devices through the Android Studio or Eclipse IDE and the command line tool installed in your computer.


    It works as if Device is connected directly to your computer through a USB cable. From the point of view of tools like Android Studio or Eclipse, a cloud-based device appears physically attached. In reality, the Device Tunnel communicates with pCloudy’s servers over Internet.


    App Testing

    Access devices directly from your terminal


    Once a connection is established, the developers can perform the following actions on these devices:

    • Issuing a range of ADB commands for debugging, shell creations, port forwarding, and viewing general information about any cloud-based Android device
    • Copying and pushing files to connected cloud-based devices
    • Installing and uninstalling applications
    • Debugging apps during development or testing by adding breakpoints, inspecting variables, analyzing run-time metrics to optimize your app and more
    • Run their tests on the device directly from their IDE

    To know more on how to connect any device on pCloudy using Device Tunnel Click Here.

    It is undeniable that developers and testers need quicker access to diverse devices for the brisk evaluation of app and debugging. Device Tunnel enables both sets of engineers to instantly connect to any device hosted on cloud and run faster debug sessions and thereby, maximize the quality of their build cycles.

    Test Apps on Real Devices

    Using Eclipse or Android Studio to code your app? Now with just a few simple mouse clicks test apps directly and in parallel on multiple real mobile devices.

    Eclipse and Android Studio are two popular IDEs for mobile app development. The reason behind their popularity is, these are open source tools and have a great community of developers whom you can turn to for any support. Anyway, if you are one of those mobile app developers using these popular IDEs then there’s good news for you!

    What if you could extend the capability of your IDEs to improve the quality of your apps? What if you could test your app on hundreds of mobile devices right from your IDE? What if you could with the help of simple plugins take your mobile app development process to a whole new level?

    Well, you can – with a simple yet salient solution from With a cloud based device lab, pCloudy is contributing to the cause of redefining mobile app testing by providing remarkably useful platform and plugins to test your apps on real mobile devices. As mentioned in our previous articles, it is not enough if mobile apps are tested on Emulators alone. We need to ensure that the apps are tested on Real Devices as well. It is also important to test your mobile apps on different devices based on a carefully analysed device matrix to hit maximum downloads. To continuously develop, integrate and release mobile apps in your DevOps environment such solutions are crucial.

    Here’s how can our plugins benefit you



    Our Plugins act as a wizard that allows you to:

    • extend the ability of Eclipse to use real devices over a cloud platform
    • select and install an app from a Cloud Drive or from local
    • select multiple real devices from a cloud (Public, Private, On-premise) to test your app
    • run test scripts in parallel on multiple devices
    • perform Automation or Manual Testing

    How does it work?

    If you have already created Test Scripts ready for Test execution, then all you need to do is to select some real devices over the cloud platform and run the execution to test your app. To help you out with this, the Plugin generates a pseudo-code that can simply be copied into your existing test scripts using Android Studio or Eclipse. With simple changes in the test script, the app will get installed and test execution is performed on the selected mobile devices. In the end, a detailed automation report will also be generated through our platform.

    With these plugins app developers and testers can:

    • choose from hundreds of mobile devices to test your App
    • effortlessly test their apps directly on real mobile devices
    • can view or perform an activity on mobile screen from directly within on your IDE
    • perform automation runs in parallel on multiple mobile devices

    Download and install the plugin: