An Internal Test Grid Solution vs. Third Party Cloud Services

Like many software testing service companies, we often subscribe to several of the leading cloud based infrastructure test automation services to meet our clients specific multiplatform/multi device regression testing requirements.  These solutions provide us with the ability to perform software testing using various scenarios and platforms while eliminating the investment in buying and maintaining actual equipment. The associated cost for these services vary – but an example of a recent quote from one of the leading platforms was, “$200 per month for 2 parallel executions for approximately 33 hours of automation.” In addition to comprehensive feature/device testing, our clients require solutions that reduce the test execution time as much as possible. Having delayed execution is the one specific challenge we have encountered with these cloud services, because although they provide a rich number of features and flexibility – the execution time often increases from 2x to 4x of the local execution time (for the same script). This standard seems to be acceptable from one of the leading providers, with this response provided to our inquiry: “Yes, that is pretty ideal.  You should expect your tests to take ~2x – 4x longer to run in the cloud.  In the case you described below they are running better than 2x slower, which is great. If your tests start taking more than 4x local execution let us know and we will investigate.” –support group answer to execution time inquiry. Of course, there are understandable reasons for this longer processing time – but the time extension is unacceptable for several of our projects – which require greater speed for execution of smoke test....

Accelerating Software QA Automation ROI with Templates

It’s been a while since I started working in QA Automation.  I began  in 2007 and since that time I have been part of a variety of teams, with different methodologies and objectives that included some type of an automation initiative.  Of course they were all striving for more stable code and a more effective way to find and fix bugs – but they had something else in common: they all wanted to have the automation framework deployed as soon as possible. Desiring the rapid deployment of automation is common, but it is not always achievable for a multitude of reasons. A couple of common issues: The Automation engineer is simultaneously working as manual tester limiting their ability to focus on the implementation and maintenance of the framework. Or the software under test is not yet prepared for automation because it is unstable and the Automation engineer spends a lot of time doing rework and workarounds. Based on the above types of challenges, we developed a Testing Automation Framework Template.  This template has helped us to reduce the time required to deliver on client’s projects. We realized that almost every Selenium project has a similar nature and common functionality that can be reused.  For example –  the Driver Utility associated with the actions that simulates the user behavior within the application. Or the manipulation and creation of the repository of elements that keeps all the components that will be used in the framework. At a high-level, it is also very likely that some methods will be reused across projects, such as the login or creation of a user. These...

Innovation – by a QA team?

We often hear how innovation is now one of the key considerations to building and maintaining a successful business.   I don’t consider myself very creative, especially when it comes to designing and developing technical solutions.  So, it’s always rewarding (and impressive to me) when I see our team members innovate for their clients – taking an idea (based on need) through to developing a tangible solution, that generates actual tangible results. There is no doubt that necessity is still the mother of invention. We have two recent examples from our QA team.  Alex Chaves – our Nearshore QA manager and Senior QA Engineer, created a simple but effective application that allows our clients to get a “jump start” on automation.  We’re calling it our QA Accelerator for the time being.   Alex recognized that many Selenium QA projects require similar activities to establish the framework, which resulted in time and material cost for our clients.  Alex built the tool, and recently applied it to one of his client’s environments.   The reaction from the client CIO was – “Wow, I can’t believe we actually saw automation results so quickly! Outstanding”. As we know, that type of client feedback is worth its weight in gold. Meanwhile, one of our other Senior Automation Engineers, Daniel Guzman, was faced with designing and implementing a framework for a client using NodeJS for a Mobile automation project.   This was not only something new for Daniel, but there seemed to be a lack of examples of third party solutions to draw from.   Consequently, Daniel developed a solution that he knew would not only perform well, but be...

WebdriverIO and Sauce Labs for Mobile Ecosystem

By: Daniel Guzman – GlobalNow Senior QA Automation Engineer I previously shared my experience of integrating WebdriverIO and Sauce Labs for a new NodeJS web test framework. I’ve now implemented the same framework for the mobile portion of the project, and as promised in my last blog, below is a brief summary of my findings and experience: Why use the same tools? One of the most important considerations when architecting web and mobile solutions is to reuse the same stack of tools as much as possible. Although often web apps/tools don’t easily integrate with mobile solutions, in this case we were successful which resulted in significant time savings. In addition to saving time, I had two other reasons for reusing the code from my web framework. First, I’m often frustrated by projects that do not follow any kind of standard architecture. A standard framework helps programmers from different projects get up to speed quickly for enhancement development and ongoing application support. Second reason is that by using a standard test framework across projects, I am better able to support hybrid test cases: to cover scenarios where I need to perform some action in the mobile app, then check or do some other action on web side, or the other way around. Cucumber and Chai! Using Behavior Driven (BDD) Cucumber and Chai frameworks was a natural fit for Appium and Sauce Labs. BDD is something I learned to appreciate quite some time ago. It’s not only an approach that we developers like, but also Business Analysts and supporting team members. When I started my current project, most of test cases...

Using NodeJS with WebdriverIO as a test framework for automation

By: Daniel Guzman – GlobalNow Senior QA Automation Engineer Whether you are a developer or the architect responsible for deciding the stack of tools and languages to build your functional test framework, the following may motivate you to write your UI automated framework in NodeJS with WebdriverIO – by outlining the benefits of using a full stack approach. My introduction from my “0 out of 2” experience! I will never forget that moment, when I realized I knew “0 out of 2”, instead “1 out of 2”. Let me explain it: As a QA Automation Engineer, I was told to develop a testing framework for web and mobile platforms as part of my first project at my new position at GlobalNow IT. I wanted to quickly build the basis of a web system, in order to have it running, and then analyze deeper the best mobile language and tools to use based on current technology. I initially understood that .NET would be the selected framework for this, so after putting together a simple test with Selenium, C# and Visual Studio, and showing it to the team, the project architect gently tells me I am not allowed to develop on C# or Java (which were the two main programming languages for which I am most experienced).  Instead, I was asked to write our test framework in NodeJS. Yes, I was in that spot when had to start using and analyzing new technologies not only for mobile, but now for the web as well. I was a bit discouraged and nervous, since I wasn’t really a JavaScript guru prior to my...

Common Sense Tips for Talent Integration

  As a provider of Nearshore IT and QA services, we are often asked by prospects and others a very important question: How do we accomplish knowledge transfer in a fashion that quickly integrates your resources into our operating model? Many times these companies have urgent needs, such as more programming capacity to meet product delivery requirements, a need to increase the speed of product feature delivery to meet market commitments, or the desire to quickly improve overall software quality due to customer service impacts.  The last thing a business needs is to spend money and time on extended team members that do not help solve these issues within the expected time frames. There is no magic bullet that guarantees rapid and maximum return from a new resource. However, from our experience, there are a number of common sense considerations that can be implemented to best meet the needs of the business: Create a simple knowledge transfer plan based on mutual expectations. This is basically a timeline that identifies the important steps for resource “ramp up”. To be included are items such as collaboration procedures, documentation review, work assignment, and joint assessment of the resource performance based on previously established expectations. Assign the “right people” at the “right time”. It’s incumbent upon the service provider to provide talent that meets or exceeds client expectations.   This means providing people that not only have the correct technical skills but also fit culturally into the clients extended teams.  Having mutually candid and detailed discussions regarding the project needs and team behavior can be highly useful to long term success. Create Incremental work...
Share This Page
Share on FacebookTweet about this on TwitterPin on PinterestShare on LinkedInShare on Google+Email this to someone