Tag

continuous integration

Browsing

Today I had the pleasure of sitting down with Jake Kaldenbaugh, Strategic Exit (M&A) Advisor at GrowthPoint Technology Partners to discuss the state of the software development industry. As a senior banking leader Jake helps growing technology companies with great technology create strategic value.

In this interview Jake covers:

About GrowthPoint Technology Partners

GrowthPoint Technology Partners is an emerging growth investment banking boutique that helps growing technology firms with great technology create strategic value. Our team identifies leading companies in the areas of data, analytics, infrastructure, virtualization, security and systems management and helps lead them through successful value realization strategies that enable entrepreneurs and investors to achieve their best results.

Our client is the market leading data authority for the hybrid cloud. They provide a full range of hybrid cloud data services that simplify application management and data across cloud and on-site environment to accelerate digital transformation. Their solution empowers global organizations to unleash the full potential of their data to expand customer engagement, foster greater innovation, and optimize their operations.

The Challenge – Achieve CI/CD

Their application was complex and included many user flows, requiring the creation of thousands of functional tests with the goal of shifting left. In addition, they needed to test as close to development as possible.

Selenium was their first choice and a team of over a dozen testers was assembled to begin the task. After a few months it became apparent that it was going to take more time and man power to achieve their goal of CI/CD. The tests were complex and took three days to author. To make things worse, the tests would often break, leading the team to spend extra time maintaining and fixing the tests. Shifting left would require teaching the developers Selenium as well.

The lack of tools to troubleshoot a failed test (e.g screenshots to compare, details error messages pointing to the right step, test history or the parameters over the flows) led to long time-to-resolution involving a number of team members. A lot of time was wasted, not only trying to figure out why the test failed, but to also explain the discoveries to the developers.

Maintaining tests took a lot of my time. When developers run tests that fail it becomes more of a
distraction
than confidence in bug prevention.Both groups had to stop what they are doing to figure
out if its the functionality or if it’s the test. We found ourselves spending more time trying to stabilize
the tests than actually testing.
” – Company QA Manager

The Solution

Testim’s solution that uses machine learning for the authoring, execution and maintenance of automated test cases was implemented. With Testim they were able to capture the scenarios in minutes, as well as complement that with JavaScript syntaxes. The team was able to spend more time creating new tests, and validating the status of their application.

Today we have hundreds of tests running on every pull, giving the developers feedback to their code
within minutes. The developers themselves easily update test scenarios so QA can focus on increasing
coverage. We also significantly reduced our cost of quality: The rich information we get allows us to
reduce the time to troubleshoot by 80%.

The Results

As a rapidly growing enterprise, they needed a way to optimize processes through automation. This plays a significant role in their move to agile development. Within a couple months of using Testim, The team was able to create hundreds of their UI tests scenarios. Today, they are proud to say that they are authoring tests in under an hour compared to the three days it was originally taking.

Before Testim it would take 3 days to author a single test in Selenium, now even for the less
experiencedtester, writing tests takes under an hour, developers can update tests on the fly and
figure out where the tests are failing without any additional help.

Now, troubleshooting a failed tests takes a fraction of the time. There is an indication on which step failed, including JS syntaxes, screenshots comparing prior runs, and access to the DOM with detailed error messages.

However, the biggest impact was the reduction on maintenance. Tests are stable and trustworthy so when a test fails the user knows it is either due to a bug or the test requires a change in the flow. The team focused most of its time on increasing coverage knowing that the tests adapt to UI changes by the development team.

Today, we are proud to say that they are fully CI/CD, testing on every code push, and running thousands of tests every day.

Thank you to everyone who participated in our round table discussion on Cracking Your Test Automation Code: The Path to CI/CD. We had a great turnout with lots of solid questions from the audience. If you missed the live event, don’t worry… Just click here to watch the recorded session. There were several questions that we were not able to answer during the live event so I followed up with the panelist afterwards to get their answers.

Q: How do you implement CI/CD without using any tools?
Bas Dijkstra: Without any tools at all it will not be possible to do CI/CD. Maybe technically there are ways to do it, but it will be massively inefficient. You will need tools that help you do version control, building software and deploying it on a specific environment. If we just look at doing CI/CD without testing  tools, that is possible in theory, but you will need to do the required amount of checking by hand anyway to make sure that the software you delivered has a certain level of quality. Doing that manually will very likely be less efficient and act as a bottleneck in the process.

How can I improve backend testing of a mobile app beyond unit testing?
Oren Rubin: You can expand beyond the unit tests by adding API testing. This is also considered integrations tests, as you testing several units as one big unit. Consider that one big state that you need to initial, and the API calls (either REST, SOAP, etc) are like function calls, some getters, some setters which modify the state.

Q: What are the things we need to cover during API tests?
Bas Dijkstra: In short: connectivity (can I talk to the API at all?), syntax (is the data returned formatted correctly, are headers and status codes OK?), semantics (is the data returned the data I expected?), functionality (does the API call have the required side effects (data stored, processes triggered, etc.), as well as no unintended side effects), performance and security (authorization, authentication).

How should one avoid overlapping in functional and unit test automation?
Oren Rubin: It’s easy to overlap the two, but it’s almost unavoidable as each unit is tested on it’s own. They are all tested via the integration tests, which usually doesn’t care about a specific unit but mostly on part of a user story/flow. Each action (e.g. click) can drive a lot of units and check them and the integrations. Remember that E2E tests come at a high price, so choose them wisely.

Is it good to separate manual test cases from automated test cases?
Bas Dijkstra: Yes. Especially since translating your ‘manual’ test cases (where you’ll likely check a number of things in the process) to automated test cases (which should ideally check one thing only) 1-to-1 will likely lead to inefficient automation. Determining what to automate and what to leave for testers is an art in itself, and simply handing someone a batch of manual test cases to automate isn’t likely to give you good results. 

What is the difference between unit test vs. integration tests in regards to front end testing?
Oren Rubin: There is no difference. Unit tests allow you to test a single unit (e.g. a controller of a component) and mock everything else; use spies, stubs, and mocks. An integration test, which might test the entire UI, where you can check unit loading order works the CSS (which is global by definition, if you exclude future shadow dom), and integrations between the different units. If you don’t mock the servers, then it’s actually End-to-End testing. 

About the panelists 

Bas Dijkstra
Bas is an independent test automation professional who has been in the test automation and service virtualization field for over 10 years now, designing and developing test automation and service virtualization solutions that enhance and improve test teams and test processes. Find out more information about Bas on his LinkedIn profile. For questions and more information you can always send him an email at bas@ontestautomation.com or give me a nudge via @_basdijkstra on Twitter.

Oren Rubin
Oren has over 20 years of experience in the software industry, building mostly test-related products for developers at IBM, Wix, Cadence, Applitools, and Testim.io. In addition to being a busy entrepreneur, Oren is a community activist and and the co-organizer of the Selenium-Israel meetup and the Israeli Google Developer Group meetup. He has taught at Technion University, and mentored at the Google Launchpad Accelerator.

Struggling to get answers to these Test Automation questions? Watch the Recorded  Webinar

  • What constitutes an adequate degree of test automation coverage?
  • Does every single function in the application need a corresponding test associated with it or just the core functionality?
  • Does every application need a full end to end automation suite built out or just enough to satisfy QAs and the business? 

Then register for this webinar: Cracking Your Test Automation Code: The path to CI/CD where Bas Dijkstra, Test Automation Consultant, On Test Automation and Oren Rubin, CEO of Testim discuss the Do’s, Don’ts and misconceptions of test automation.

Bring your questions to get answers to:

  • Why your code impacts your approach to testing?
  • What’s the right mix of unit, functional, end-to-end, UI and other types of testing?
  • How to create your test automation strategy and tactical execution plan?
  • What pitfalls to avoid that will increase your cost of quality?

This round-table discussion will include insights from these industry experts:

  • Bas Dijkstra, On Test Automation
  • Oren Rubin, CEO of Testim

About the presenters:

Bas Dijkstra
Bas is an independent test automation professional who has been in the test automation and service virtualization field for over 10 years now, designing and developing test automation and service virtualization solutions that enhance and improve test teams and test processes. Find out more information about Bas on his LinkedIn profile. For questions and more information you can always send him an email at bas@ontestautomation.com or give me a nudge via @_basdijkstra on Twitter.

Oren Rubin
Oren has over 20 years of experience in the software industry, building mostly test-related products for developers at IBM, Wix, Cadence, Applitools, and Testim.io. In addition to being a busy entrepreneur, Oren is a community activist and and the co-organizer of the Selenium-Israel meetup and the Israeli Google Developer Group meetup. He has taught at Technion University, and mentored at the Google Launchpad Accelerator.

Be smart & save time...
Simply automate.

Get Started Free