Tag

Test automation

Browsing

By: Sofía Palamarchuk for Abstracta

If you work in the software industry, you’ve most likely heard about the popular term, “shift-left testing.” With Agile practices like TDD, BDD, CI and DevOps becoming mainstream, “shift-left” is the answer to how testing fits in, and must be done in order for them to become a reality. Instead of taking a backseat during the development process, testing is planned in advance and begins earlier in the SDLC (therefore “shifts left”). It could even start before a single line of code is written! Making this shift changes the view of testing instead of traditional QA, it transforms into QE: Quality Engineering.

What Does Shift-Left Testing Look Like?

Thanks to the rise of automation, and the aid of tools that use AI and machine learning, testers have more time to dedicate to being more strategic about their work, instead of having their hands tied, running tests manually every day.

For testers to be successful today, they have to not only be great at testing, but also be engineers of the Agile testing process by collaborating with development and operations while analyzing quality during every stage of development:

Shift Left Testing

Shift-left testing activities include:

  • Testers helping developers implement unit testing
  • Planning, creating, and automating integration test cases
  • Planning, creating, and employing virtualized services at every stage and component level
  • Gathering, prioritizing, and processing feedback

Several process changes occur when teams shift left. Instead of a developer waiting weeks to add his or her code to the rest of the team’s code, it can be done every day, or even several times a day. Instead of manually performing all the tests, most are automated and run every day, or even several times a day. And, instead of detecting problems at the end, the team as a whole analyzes quality as the development progresses.

Not sure if it’s the right move for your organization? Here are some of the pros and cons of shift left testing.

PROS

LOWER THE COST OF TESTING & DEVELOPMENT

It’s well known that the sooner a bug is found, the cheaper it is to fix. One of the aims of Agile testing is detecting errors as soon as possible. With shift-left testing it’s possible to detect in real time, the exact moment in which an error was inserted into the system in order to resolve it in a timely manner. When testing is done with each build (especially during unit testing), the errors that are found are smaller, easier to detect and locate, and subsequently, less costly to fix.

INCREASE EFFICIENCY & QUALITY

With the increased levels of automation when shifting left, teams can benefit from:

  • Increased test coverage since more tests can be run in the same amount of time
  • More time for testers to focus on more challenging and rewarding tasks
  • Reduced human error rate
  • Monitoring performance over time
  • Code quality checks
  • Built-in security checks
  • Reducing issues in production that users may encounter

Beyond these benefits, being able to start testing sooner invariably results in a higher quality product, as testers are less rushed to find all the errors at the end, when there’s little time left to fix them.

COMPETE MORE FIERCELY

In today’s competitive technological landscape, the barriers to compete are minimal, so the best way to survive is to be able to move fast and defend one’s stature by innovating in iterations, which is possible thanks to Agile. As everyone can agree that it’s important to deliver software more quickly, it also mustn’t be rushed out the door (causing a possible backfire). Shift-left testing answers the problem of accelerating development without sacrificing quality.

Anotheryet less obviousbenefit of shifting left is that it can help businesses position themselves as an attractive employer to top talent. Because it is becoming more mainstream, with about two thirds of IT workers reportedly using Agile or leaning towards agile (according to a recent study by HP), it’s what the most forward thinking software professionals expect from their teams. Therefore, if you want to be an attractive employer or at least on-par with the rest, it is important to adopt the modern practices that both testers and developers want to master in order to stay relevant in today’s labor market.

Cons

EASIER SAID THAN DONE

For shift-left testing to be a success, an often drastic change in culture must occur first, which requires a team effort. Teams are usually set in their traditional ways of working, and when they consider shifting, they must consider how the methods, processes, skills, tooling, etc. will need to change. Even more important, what will need to happen to get all the roles within the organization to align properly?

RISK OF BOTTLENECKS

Yes, agile and shift-left aim to eliminate testing as a bottleneck, but it is true that agile teams can find themselves stuck waiting in a queue once all of the pieces come together in the performance and user acceptance testing phases, due to the complexity of environments and composite applications. One way to overcome this is to to utilize service virtualization. Service virtualization emulates the behavior of essential components that will be present in production, enabling integration tests to take place much earlier in development. This is how you can eliminate that key bottleneck, while also benefiting from eliminating errors earlier on. Along with service virtualization, there are several tools to setup automated systems and CI such as Jenkins.

A Worthwhile Undertaking

In the end, shift left testing is certain to have pros that outweigh its cons. Testers will find themselves delegating some of their work to developers and assigning them more testing activities. In mature teams, the testers become “coaches,” training developers on how to write better code, avoid bugs, and own unit testing. The advantage of this is that the tester who used to be busy, bogged down by writing test cases, now has time to delve deeper into the product, working on business cases, penetration testing, performance testing, implementing smarter testing solutions that use artificial intelligence like Testim.io, and so on. This sharing of the responsibility over testing leads to a higher level of achieved quality, as more of the bases get covered, quicker!

What do you think? Still not on-board to shift left testing? Or have you managed to do so already?

About the Author: Sofía Palamarchuk

Sofia Palamarchuk

Sofía is the Chief Executive Officer and Chief Product Officer of software testing services company, Abstracta. With a B.S. in Computer Engineering, Sofía started working in application performance optimization, system monitoring and load testing for the corporate sector for many years. With a solid background in performance tuning and automation, Sofía has become a business development leader and is responsible for managing all aspects of Abstracta’s US operations as well as its mobile testing tool, Monkop.

Introduction

We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. This month we’re thrilled to release a few of your most requested features; Updated Exports Parameters, New Groups Tab. Check them out and let us know what you think.

Updated Exports Parameters

What is it?

Flexible Exports Parameters allow to pass variables within a group, test or collection of tests. Learn more

testim exports_parameters

Why should I care?  

When we use different exports parameters across tests for dynamic data validation, it often gets difficult to keep track of which user defined variables can be used in which groups or tests . For better user experience and control of variables, we now have 3 exports parameters-

  • Local export: Allows you to pass variables between steps in the same group.
  • Test export : Allows you to pass variables between steps and groups in the same test.
  • Global export: Allows you to pass variables between tests in the same test plan or test suite.

Each one has a clearly defined scope and it makes it a lot easier for user to understand the scope of different variables used within groups and tests.

Improved Toolbar Navigation Navigation

What is it?

A new Groups Tab has been added to the “+” menu. Learn more

Testim Groups Tab

Why should I care?

You now have  the ability to switch back and forth between test and the test runs via the tabs.

Customers have access to these new features now. Check it out and let us know what you think. If you’re not a customer, sign up for a free trial to experience autonomous testing. We’d love to hear what you think of the new features. Please share your thoughts on Twitter, LinkedIn or Facebook.

Introduction

We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. This month we’re thrilled to release a few of your most requested features; Result Labels, Test Run Navigation Icon, Grid Management. Check them out and let us know what you think.

Result Labels

What is it?

The “Result Labels” allows you to name each remote run. On the “Suite Runs” and “Test runs” pages, you can easily filter your runs by choosing a result label.

Testim Result Labels

Why should I care?  

You now have the ability to label your runs. This is especially useful when you need to drill down into specific runs based on environment, application version, sprint numbers etc. For example you can label your runs as “nightly-scheduler”, “v1.42.34”, “Jenkins”, “Troubleshooting”, “Staging”.

Result labels can be added to the CLI using the parameter –result-label “<user defined name of the run>”. Learn more

Test Run Navigation Icon

What is it?

The new navigation icon opens the results of a test in a new tab.

Testim test run navigation

Why should I care?

You now have  the ability to switch back and forth between test and the test runs via the tabs.

Grid Management

What is it?

To run your tests remotely, you need to integrate either with Testim grid, your own local grid or other 3rd party grids like Sauce Labs and Browserstack. Learn more

testim grid management

Why should I care?  

Grid management now offers the ability to easily manage multiple grids providing an abstraction layer for your devops. The grid information is automatically added to the CLI based on the already configured grids and will appear in this format –grid “<grid name>”.

Customers have access to these new features now. Check it out and let us know what you think. If you’re not a customer, sign up for a free trial to experience autonomous testing. We’d love to hear what you think of the new features. Please share your thoughts on Twitter, LinkedIn or Facebook.

Introduction

We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. This month we’re thrilled to release a few of your most requested features; Hidden Parameters, Data Driven testing  via config files and Element Text condition. Check them out and let us know what you think.

Hidden Parameters

What is it?

When you use parameters in your tests, the values that are passed in during run time are saved and shown in the UI. Sometimes this information is sensitive and you may want the value to be hidden. This is now possible using the hidden parameters option available in the project settings page of the Testim editor. Learn more

Why should I care?  

You no longer have to worry about revealing sensitive information in your tests. This is especially true if your application is related to banking, security, insurance or any other domain that handles a large amount of sensitive data.

Data Driven testing now supports CSV, database and other external sources

What is it?

Now users have the ability to pass data sets at run time via config files. The newly added “overrideTestData” parameter in the beforeSuite hook will allow users to pass in multiple parameters to multiple tests at the same time. The same parameter can also be used to extract data from external sources such as CSV, Databases etc.

Why should I care?  

Data Driven testing is no longer just restricted to passing a json file within the tests. Now, you have the flexibility to pass this data at run time through a single config file. Also, you can extract data from external sources and use it within your tests. Everything happens automatically for you during run time. This makes test data setup much more extensible and reusable. Learn more

Talking about working with excel;  we already have detailed documentation of an alternate way to import excel data into Testim. You can learn more about here.

Element Text condition

What is it?

Testim provides several predefined conditions (“if statements”) to be used with steps.  For example, whether an element is visible or not. We just introduced a new condition which checks whether an element has a specific text. Just pass in a string, regex, or a js statement (you can use variables too!).

Why should I care?
Now you have the flexibility to add conditions based on element text instead of just checking for element being visible on the screen. Learn more

 

Customers have access to these new features now. Check it out and let us know what you think. If you’re not a customer, sign up for a free trial to experience autonomous testing. We’d love to hear what you think of the new features. Please share your thoughts on Twitter, LinkedIn or Facebook.

 

Artificial Intelligence (AI) and machine learning (ML) are advancing at a rapid pace. Companies like Apple, Tesla, Google, Amazon, Facebook and others have started investing more into AI to solve different technological problems in the areas of healthcare, autonomous cars, search engines, predictive modeling and much more. Applying AI is real. It’s coming fast. It’s going to affect every business, no matter how big or small. This being the case how are we as Testers going to adapt to this change and embrace AI? Here is the summary of different things you need to know about using AI in software testing.

Let’s summarize how the testing practice has evolved over the last 4 decades

  • In the 1980’s majority of software development was waterfall and testing was manual
  • In the 1990’s, we had bulky automation tools which were super expensive, unstable and had really primitive functionality. During the same time, there were different development approaches being experimented like Scrum, XP, RAD (Rapid Application Development)
  • From 2000, the era of open source frameworks began
    • People wanted to share their knowledge with the community
    • Started encouraging innovation and asking community of like minded people to help out in improving testing
    • Agile became a big thing, XP, Scrum, Kanban became a standard process in the SDLC
    • There were need for faster release cycles as people wanted more software features delivered faster
  • In the 2010’s, it was all about scale, how to write tests fast and find bugs faster
    • Crowdtesting started
      • Encouraging other people to give feedback on the application. Free and Paid services
    • Cloud testing started
      • People started realizing they need more
        • Server space
        • Faster processing
      • Started to realize the problem of maintenance. How expensive it is to buy hardware and software for maintaining your tests
      • Then we have
        • DevOps
        • Continuous Testing
        • CI/CD integration
  • I believe the Future will be about Autonomous Testing using Machine Learning and AI

 

Basics of AI

Let’s start by de-mystifying some of the terminologies related to AI

  • Artificial Intelligence (AI) is an area of computer science that emphasizes the creation of intelligent machines that work and react like humans
  • Machine Learning (ML) evolved from the study of pattern recognition and computational learning theory (studying design and analysis of ML algorithms) in AI. It is a field of study that gives computers ability to learn without being explicitly programmed
  • Deep Learning(DL) is one of the many approaches to ML. Other approaches include decision tree learning, inductive logic programming, clustering and Bayesian networks. It is based on neural networks in the human body. Each neuron keeps learning and interconnects with other neurons to perform different actions based on different responses

 

There are 3 types of widely used ML algorithms

  • Supervised Learning – We are giving the right training data (input/output combinations) for the algorithm to learn
    • Examples
      • Give bunch of e-mails and identify spam e-mails
      • Extracting text from audio
      • Fill out a loan application and find the probability of the user repaying the loan
      • How to make user click on ads by learning their behavior
      • Recommendation engines on Amazon, Netflix where customer is recommended products and movies
      • Amazon uses AI for logistics
      • Car Optimization
      • Autonomous cars
  • Un-supervised learning – We give a bunch of data and see what we can find
    • Examples
      • Taking a single image and creating a 3D model
      • Market Segmentation
  • Reinforced learning – Based on concept of reward function. Rewarding Good/Bad behavior and making the algorithm learn from it. E.g. Training a Dog

 

Real life AI applications to visually see how it works

  • Quick Draw from Google
  • Weka is an open source project where they are using ML algorithms for data mining

 

What challenges can AI solve?

Let’s discuss the challenges the industry faced while transitioning to agile and what’s still remains a challenge:

How can we use AI to solve testing problems?

There are many companies taking multiple approaches to solve different problems related to software testing and automation. Testim.io is one such company

Testim.io uses Dynamic Locators, The Artificial Intelligence (AI) underneath the platform in real time, analyzes all the DOM objects of a page and extracts the objects and its properties. Finally, the AI decides the best location strategy to locate a particular element based on this analysis. Due to this, even if a developer changes the attribute of an element, the test still continues to run and this leads to more stable tests. As a result, the authoring and execution of automated tests are much faster and more stable.

 

Here is the detailed insight of how our AI works – https://www.softwaretestinghelp.com/testim-io-tool-tutorial/

Introduction

We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. This month we’re thrilled to release a few of your most requested features; Loops, Help Tooltip, and several tutorial videos. Check them out and let us know what you think.

Loops

What is it?
Adding conditions to your test lets you control if some steps will run or not. You can add conditions to any type of step, including a group step. Now, with Loops you can execute a group of steps until a condition returns false.

Want to run a set of steps continuously until a certain condition is met? Now you can. Loops give you the ability to run the same set of actions a predetermined number of times or as long as a condition isn’t met.

Why should I care?  
This allows you to reach a specific result directly from the group’s properties, or you can go over the different iterations from inside the group. If one of the iterations failed, when entering the group, you will be taken directly to the failed iteration. Learn more

loops

Help Tooltip

What is it?
Authoring tests is easy (well at least with Testim) but troubleshooting takes time. To help you troubleshoot faster we’ve added tooltips to steps that fail. These tooltips will guide you through what you should look at and how you might troubleshoot a failed step.  

Why should I care?
Now you can troubleshoot failed steps faster and independently.

Tutorial Videos

What is it?
Need help running Testim tests from IDE? Or how to do data driven testing from an Excel file? These 3 minute or less videos will show you how. Check them out.

Filter Suite Runs by Suite

What is it?
A new filter has been added to our Suite runs view. Now you can filter the list of runs according to the name of your suite.

Why should I care?
This will allow you to easily find a particular run you did and compare different runs of the same suite. Learn more

filter by test suite run

Customers have access to these features and videos now. Check it out and let us know what you think. If you’re not a customer, sign up for a free trial to experience autonomous testing. We’d love to hear what you think of the new features. Please share your thoughts on Twitter or Facebook.

When we hear the phrase “Record and Playback”, a majority of the people cringe with fear and skepticism as they relate it to primitive, unstable and flaky tests. Organizations have viewed it as a sign of vulnerability in automation and have continued to discourage teams from doing record and playback tests for many years now. The main reason for this is, it leads to-

  • Higher maintenance of tests
  • Lesser stability of tests as it breaks if any element changes
  • Unclear test coverage
  • Tests are highly coupled

This is not a new phenomenon, this has been the case for the past 20 years within which the state of automation has evolved by leaps and bounds.

I am not going to refute the above points as it is true in some cases but people fail to realize there is a time and place for everything which includes “record and playback tests”. These type of tests are valuable to-

  • Do fuzz testing (a.k.a monkey testing), which involves recording large amounts of random data through vast number of valid and invalid actions/assertions and observe the application under test. This helps to uncover issues like memory leaks, unexpected crashes and helps to evaluate the system under extreme conditions that otherwise may be hard to do with normal structured automated tests.

Monkey Testing

  • Perform automated exploratory testing, where the user tries out multiple scenarios and records multiple actions while simultaneously learning about the application and the tool used for automated testing.

a b testing

  • Help in load testing, by quickly recording a bunch of tests and simulate thousands of users concurrently performing the same set of recorded actions on the application.

load testing

  • It helps to get the whole team involved in test automation irrespective of their skillsets.

Now, you may think, “Why am I highlighting the advantages and disadvantages of Record and Playback tests”? The answer is, we at Testim.io, recognized these factors and came up with a hybrid approach to solve the problems with record and playback, by building a platform based on Artificial Intelligence (AI).

Testim.io follows a hybrid approach where we give organizations and users the ability to record and playback tests; while at the same time giving the users flexibility to programmatically manipulate these recorded tests. These tasks can be performed easily using inbuilt functionalities of the platform. It also gives teams the freedom to add their own wrappers around the platform (if needed) by using Javascript and HTML.

hybrid testing approach

To increase stability of tests irrespective of the way the tests are written, Testim.io uses Dynamic Locators. The AI underneath the platform in real time, analyzes all the DOM objects of a page and extracts the object trees and its properties. Finally, it decides on the best location strategy to locate a particular element based on this analysis. The more tests you run, the smarter the AI becomes in increasing the stability of the automated tests. So, even if your strategy for automation is only record and playback, re-running the recorded tests multiple times helps to make those tests stable even if the attribute of an element changes in the future. As a result, the authoring and execution of tests are much faster.

In summary, there are various approaches to test automation. Each approach has its own merits/demerits. Understanding and using the approach that makes more sense in the context of the project is crucial to help in better testing using automation tools, platforms and frameworks. As these options continue to mature, it will become all the more important to follow the hybrid approach to cater to different type of skill sets, needs and expectations of teams and organizations. Hybrid approach to testing is the new era of test automation.

Curious to see how we implement the hybrid approach? Sign up for our free trial.

Introduction

We work hard to improve the functionality and usability of our autonomous testing platform to support your software quality initiatives. With that said, we’re thrilled to release a few of your most requested features; negative validation, extract value, and integration to test management. Check them out and let us know what you think.

Negative Validation

What is it?

Validations are the most important steps we need in our tests. Validations allow us to see if our app does what we expect it to do. Testim provides a wide range of validation options so you can choose the ones that best suit your needs. Now you can choose a negative validation.

  • Element Not Visible – Make sure an element is not visible to the user.

Why should I care?  
Use the element not visible validation to check whether your element does not exist/visible in the page.  Use this validation to make sure an element disappeared from the screen or wasn’t shown in the first place. Learn more

negative validation

Extract Value

What is it?

Extract value lets you copy values directly from your application to be used in later steps. For example, if you have text in your application such as username, name or account number use extract value to validate that it appears on another page. You can also use it to extract a value for future calculation at a later step.

Why should I care?
Now, you can use the new parameter in a validation step, set text, custom steps, etc. So if you want to change the element you selected, now you don’t have to re-record this step. Learn more

extract value

Integrate Test Management

What is it?

Testim can now sync your test results with TestRail so you can get a side by side view of your manual and automated tests.

Why should I care?

If your doing exploratory testing, now you can link your manual and automated tests to your requirements and defects for end to end traceability. Learn more

integrate test management

Customers have access to these features now. Check it out and let us know what you think. If you’re not a customer, sign up for a free trial to experience autonomous testing. We’d love to hear what you think of the new features. Please share your thoughts on Twitter or Facebook.

Engagio is a two year old marketing software startup that helps marketers land and expand their target accounts. The company is rapidly growing with more than 150 customers and 45 employees. Based in San Mateo, Engagio was founded by Jon Miller who was previously the Co-Founder of Marketo.  

Today, I had the pleasure of speaking with Helge Scheil, VP of Engineering for Engagio who shared why he selected Testim, his overall development philosophy and the results his team was able to achieve.  Checkout the series of videos or read the Q&A from our conversation below.

Q: Can you tell us a little about what your software does?

A: We help B2B marketers drive new business and expand relationships with high-value accounts. Our marketing orchestration software helps marketers create and measure engagement in one tool, drive ongoing success, and measure impact easily. Engagio orchestrates integrated account-based programs, providing the scale benefits of automation with the personalization benefits of the human touch. Our software complements Salesforce and existing marketing automation solutions.

Q: What does your development process look like?
A: Our developers work in 2-week sprints, developing features rapidly and deploying to production daily without any production downtime. We’re running on AWS and have the entire develop-test-build-deploy process fully automated. Each developer can deploy at any time, assuming all quality criteria have been met.

Q: What tools do you use to support your development efforts?

A: We are using Atlassian JIRA and Confluence for product strategy, roadmaps, requirements management, work breakdown, sprint planning and release management. We’re using a combination of Codeship, Python (buildbot), Docker, Slack, JUnit and Testim for our continuous build/test/deploy. We have integrated Testim into our deployment bot (which is integrated into Slack).

Q: Prior to Testim, how were you testing your software? What were some of the challenges?

A: Our backend had great coverage with unit and integration tests, including the API level. On the front-end we had very little coverage and the small amount we had was written in Selenium, which was very time-consuming with little fault-tolerance and many “flaky” failures.

Q: What were some things you tried to do to solve these challenges?

A: We were trying to simply allocate more time for Selenium tests to engineers. We considered hiring automation engineers but weren’t too fond of the idea because we believe in engineers being responsible for quality out of the gate, including the regression tests creation and maintenance.

Q: Where there other solutions you evaluated? Why did you select Testim?

A: We didn’t really consider any other solutions after we started evaluating Testim, which was our first vendor to evaluate. Despite some skepticism around the “record and play” concept, we found that Testim’s tolerance (meaning “tests don’t fail”) to UI and feature changes is much greater than we had expected. Other solutions that we considered are relying on pixels/images/coordinates which are inherently sensitive and non-tolerant to changes. We also found that non-engineers (i.e. product manager, functional QA engineers) can write tests, which is unlike Selenium.

Q: After selecting Testim, can you walk me through your getting started experience?

A: During the first week of implementation the team got together to learn the tool and started creating guinea pig tests which evolved into much deeper tests with more intricate feature testing. Those test ended up in our regression test suite which are ran nightly. Rather than allocating two days per sprint, we decided to crank up the coverage with a one day blitz.

Q: After using Testim, what were some the benefits you experienced?

A: We were able to increase our coverage by 4-5x within 6 weeks of using Testim. We can write more tests in less time and maintenance is not as time consuming. We integrated Testim via its CLI and made “run test <label>” commands available in our “deployment” Slack channel as well as a newly created “regression_test” channel. Any deployment that involves our web app now automatically runs our smoke tests. In addition to that we run nightly full regression tests. Running four cloud/grid Testim VMs in parallel we’re able to run our full regression test suite in roughly 10 minutes.

Q: How was your experience working with Testim’s support team?

A: Testim’s responsiveness was extraordinary. We found ourselves asking questions late in the evenings and over the weekends and the team was there to help us familiarize ourselves with the product. If it wasn’t immediately in the middle of the night, we would have the answer by the time we got started the next day.

Guide: Evaluating UI and Mobile Automated Testing Solutions

Thank you to everyone who participated in our round table discussion on The Future of Test Automation: How to prepare for it? We had a fantastic turnout with lots of solid questions from the audience. If you missed the live event, don’t worry…

You can watch the recorded session any time:

Alan Page, QA Director at Unity Technologies and Oren Rubin, CEO of Testim shared their thoughts on:
  • The current state of test automation
  • Today’s test automation challenges
  • Trends that are shaping the future
  • The future of test automation
  • How to create your test automation destiny
In this session they also covered:
  • Tips and techniques for balancing end to end vs. unit testing
  • How testing is moving from the back end to the front end
  • How to overcome mobile and cloud testing challenges
  • Insights into how the roles of developers and testers are evolving
  • Skills you should start developing now to be ready for the future of testing

Some of the audience questions they answered:

  • How do we know what is the right amount of test coverage to live with a reasonable amount of risk?
  • What is the best way to get developers to do more of the testing?
  • How do you deal with dynamic data, is the best practice to read a DB and compare the results to the front end?
  • Does test automation mark the end of manual testing as we know it?

There were several questions that we were not able to address during the live event so I followed up with the panelist afterwards to get their answers.

Q: What is Alan’s idea of what an automated UI test should be?

As much as I rant about UI Automation, I wrote some a few weeks ago. The Unity Developer Dashboard provides quick access to a lot of Unity services for game developers. I wrote a few tests that walk through workflows and ensure that the cross-service integration is working correctly.

The important bit is, that I wrote tests to find issues that could only be found with UI automation. If validation of the application can be done at any lower level, that’s where the test should be written.

Q: The team I work on complex machines with Android UI and separate backend. What layer would you suggest to concentrate more testing effort on?

I’d weight my testing heavily on the backend and push as much logic as possible out of the Android UI and into the backend, where I can test more, and test faster.

Q: Some legacy applications are really difficult to unit test.  What are your suggestions in handling these kind of applications?

Read Working Effectively with Legacy Code by Michael Feathers, and you’ll find that adding unit tests to legacy code isn’t as hard as you thought it was.

Q: How do you implement modern testing to compliment automation efforts?

My mantra in Modern Testing is, Accelerate the Achievement of Shippable Quality. As “modern” testers, we sometimes do that by writing automated tests, but more often, we look at the system we use to make software – everything from the developer desktop all the way to deployment and beyond (like getting customer feedback), and look for ways we can optimize the system.

For example, as a modern tester, I make sure that we are running the right tools (e.g. static analysis) as part of the build process, that we are taking unit testing seriously and finding all the bugs that can be found by unit tests during unit testing. I try to find things to make it easier for the developers I work with to create high quality and high value tests (e.g. wrappers for templates, or tools to help automate their workflow). I make sure we have reliable and efficient methods for getting feedback from our customers, and that we have a tight loop of build-measure-learn based on that feedback.

Q: Alan Page could you give an example of a test that would be better tested (validated) at a lower level (unit) as opposed to UI level?

It would be easier to think of a test that would not be better validated at that level. Let’s say your application has a sign-in page. One could write UI automation to try different combinations of user names, email addresses, and passwords, but you could write tests faster (and run them massively faster) if you just wrote API tests to sign up users.

Of course, you’d still want to test the UI in this case, but I’d prefer to write a bunch of API tests to verify the system, and then exploratory test the UI to make sure it’s working well with the back end, has a proper look and feel, etc.

Q: How critical is today for a QA person to be able to code? In other words, if you are a QA analyst with strong testing/automation skills, but really have not had much coding experience, what would be the best way to incorporate some coding into his or her profile? Where would you start?

Technology is evolving in a rapid pace and the same applies to tools and programming languages as well. This being said, it would be good for testers to know the basics of some programming language in order to keep up with this pace. I would not say this is critical but it will definitely be good to have and with so many online resources available, it is even easier for testers to gain technical knowledge.

Some of the best ways I have known to incorporate coding into his/her profile would be via:

  • Online Tutorials and courses (Udemy, Coursera, Youtube videos)
  • Pairing with developers when they are programming. You can ask them basic questions of how things work, as and when they are coding. This is a nice way to learn
  • Attending code reviews helps to gain some insight into how the programming language works
  • Reading solutions to different problems on Stack Overflow and other forums
  • Volunteering to implement a simple feature in your system/tool/project by pairing with another developer
  • Organizing/Attending meetups and lunch ‘n’ learns focused on a particular programming language and topic
  • Choose a mentor who could guide you and give you weekly assignments to complete. Set clear goals and deadlines for deliverables

Q: My developers really like reusing cucumber steps, but I couldn’t make them write these steps. The adoption problem is getting the budget reallocated. Any advice for what I should do?

Reusing cucumber steps may not be necessarily a bad thing. It could also mean that the steps you may have written are really good and people can use them for other scenarios. In fact, this is a good thing in BDD (Behavior Driven Development) and helps in easier automation of these steps.

But if the developers are lazy and then reusing steps which do not make sense in a scenario, then we have a problem. In this case, what I would do is try to make developers understand why a particular step may not make sense for a scenario and discuss how you would re-write them. This continuous practice of spot feedback would help to instill the habit of writing good cucumber steps. Also, I would raise this point in retrospective and team meetings, and discuss it with the entire team. This will help to come to a common understanding of the expectations.

In terms of budget reallocation, I would talk to your business folks and project manager on the value of writing cucumber steps and how it helps to bring clarity in requirements, helps to catch defects early and saves a lot of time and effort which would otherwise be spent on re-work of stories due to unclear requirements and expectations for a feature.

Q: Can we quickly Capture Baseline Images using AI?

What exactly do you want the AI part to do? Currently, it’s not there are tools (e.g. Applitools and Percy.io) which can create a baseline very fast. I would expect AI to help in the future with setting the regions that must be ignored (e.g. field showing today’s date), and the closest thing I know is Applitools’ layout comparison (looking and comparing the layout of a page rather than the exact pixels, so the text can differ and the number of lines change, but still have a match).

Q: What are your thoughts on Automatic/live static code analysis?

Code analysis is great! It can help prevent bugs and add to code consistency inside the organization. The important thing to remember is that it never replaces functional testing and it’s merely another (orthogonal) layer which also helps.

Q: When we say ‘Automated Acceptance tests’, do they mean REST API automated tests which automation tool is good to learn?

No. They usually mean E2E (functional) tests, though acceptance tests should include anything related to approving a new release, and in some cases, this includes load/stress testing and even security testing.

Regarding good tools, For functional testing, I’m very biased toward Testim.io, but many prefer to code and choose Selenium or its mobile version Appium (though Espresso and Earl grey are catching on in popularity).

For API testing, there are too many, from the giant HP (Stormrunner) to medium sized Blazemeter, to small and cool solutions like APIfortress, Postman, Loadmill, and of course Testim.io.

Why not to call it full stack tests instead of e2e?

Mostly because e2e is used more often in the industry – but I actually prefer to use the google naming conventions, and just call tests small, medium, or large. Full stack / end-to-end tests fall in the large category.

Be smart & save time...
Simply automate.

Get Started Free