Category

QA

Category

Testim gives you the ability to playback tests in incognito mode. The reason you may want to use incognito mode is, to get the true behavior of the application without any cached data. This is similar to running tests on the grid, where in each test runs on a new browser instance without any cached data (same as running in incognito mode). The different tips to help you playback tests in incognito mode are as follows-

NOTE: Ensure you allow Testim to run in incognito, before playing the tests.

Tip 1: Running a single test in incognito

If you want to play a test you just created in incognito, follow the below steps

  • Click on the drop down arrow next to the play button
  • Click on “Run in Incognito mode”

Tip 2: Running multiple tests in Incognito

Multiple tests can be run in incognito mode by using the CLI. Each time a test is run on the grid a fresh browser instance opens up without any cached data. Follow the below steps to run multiple tests in incognito all at once-

NOTE: Tests cannot be run in incognito mode from the Test List view. The CLI needs to be used to run multiple tests in incognito.

We were recently at the STP Spring 2019 conference. Testim was one of the sponsors for the event. We were also there to give a talk and workshop on Implementing ATDD in large scale agile projects and doing Paired Session Based Exploratory Testing respectively. It was an amazing conference in terms of the content, speakers, attendees and the location.

The conference was held at the Hyatt Regency next to the SFO airport and San Francisco Bay. It was a beautiful location and was easily accessible to everyone. As for the conference, there were a great collection of talks and workshops for attendees to learn from and apply the concepts in their daily project activities. The content included different testing strategies/approaches that can be applied to manual/automated testing, applying AI in software testing, different leadership techniques and traits that can be applied in agile testing, testing in DevOps/Continuous Delivery and performance testing.

This is one of the reasons why we have continued to sponsor STP Conferences in the past couple of years; as they make testing inclusive by bringing people from different countries in one location to share their experiences and also learn from each other.

We met a lot of our friends from SauceLabs, Applitools and other companies at the conference. We also had our own sponsor booth.

NOTE: In case you are interested to test drive Testim yourself, just fill in your details here and we will hook you up with

  • Freebies for you and your team
  • Unlimited access to Testim for 14 days
  • 24/7 Customer Support
  • 1 Hour Free Test Design and Automation Consultation with me

As mentioned earlier, on behalf of Testim, I also gave a talk and a workshop. The talk was titled “ATDD (Acceptance Test Driven Development) Is A Whole Team Approach – A Real Case Study”. It was about my real life experiences implementing ATDD in a large scale agile project. I discussed the problems my team had before implementing ATDD and how I trained the entire team of 25 people on different practices to encourage collaboration, learning and reinstating the mindset of One Team, One Goal. I also discussed the process changes that happened due to ATDD, how my team could leverage test automation throughout this process and finally shared the lessons learned from the implementation.

The workshop I did was titled “Unwrapping the box of Paired Testing”. In this workshop, I shared different testing strategies to do quick tours on your applications based on my real life experiences. I discussed what is Session Based Exploratory Testing and used the template I formed to do paired exploratory testing on live applications.

Below are some articles I wrote covering some of the details discussed in my talk and workshop

The power of Session Based Exploratory Testing

A Quick Guild to Implementing ATDD

Finally, we took part in a 5 minute lightning talk series STP hosted called “Testing Stories”. People shared their real life testing stories that were really insightful within 5 minutes.


Overall, we had a great time at the conference and look forward to the next event to meet new people and make lasting relationships. Thanks again to the STP organizers for putting on a great show.

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; Email Validation, Advanced Scheduler, For Each Loop. Check them out and let us know what you think.

Email Validation

What is it?

You now have the ability to generate email addresses, send emails and validate the contents of an email within the Testim IDE itself.

Why should I care?

There is no longer a need to use 3rd party email vendors such as Guerilla Mail and Shark Lasers to do email validations. All this is handled within Testim and there is no need for any context switching. The validations can be done within a click of a button as shown below.

Advanced Scheduler

What is it?

You now have the ability to run tests in parallel, add results label, choose branches and set a timeout for a scheduler run with the Advanced Scheduler feature.

Why should I care?

With this new feature, you now have more control over you scheduled runs in terms of making it run faster by adding parallelism, labeling each scheduled run, pick and choose which branch you want to run the tests on and finally setting a timeout value to control when a test needs to be aborted.

For Each Loop

What is it?

You now have the ability to iterate over any list of similar items and perform repeated actions.

Why should I care?

Iterating over rows in a table, clicking on multiple checkboxes in a list of items or validating the order of a list of similar items; just got a lot easier with the for each loop functionality. You simply choose this option and select the element you want to repeatedly click to perform certain validations. It does not matter which element in the list of similar items is selected as the loop always starts from the first element and iterates over its siblings.

Click on this demo test to learn how the For Each Loop functionality works.

Testim gives you the ability to override timeouts within a test, outside a test and across a group of tests. This helps to control the amount of time tests need to wait before a particular condition is met; after which tests fail gracefully after the set timeout period expires. The different ways to handle timeouts are as follows-

Tip 1: Timeouts within a step

Every step you record in Testim has a default timeout value of 30 seconds. You can override this value by following the below steps

  • Navigate to the properties panel of the step
  • Select “Override timeout” option
  • Change the default timeout value from 30 seconds to the desired timeout value
  • Click on Save

Tip 2: Timeouts within Test Configs

You have the ability to change the timeout for all the tests using a particular test config. You can do this by following the below steps-

  • Navigate to the properties panel of the setup step (first step in the test)
  • Click on the edit config icon next to the exiting resolution
  • Change the default timeout value from 30 seconds to the desired timeout value
  • Click on Save

NOTE: You can also edit the Step delay value in the edit config screen

Tip 3: Setting timeout for test runs

To abort a test run after a certain timeout has elapsed, you can use the CLI –timeout command. The default value is set to 10 minutes.

Usage example:

npm i -g @testim/testim-cli && testim –token “eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ” –project “vZDyQTfE” –grid “Testim-grid” –timeout 120000.

This timeout value can also be set in the Advanced Scheduler screen as shown below


Exploratory Testing has been around for several decades now. Every tester has been knowingly or unknowingly practicing it in their daily testing activities. There are various definitions and methodologies surrounding this testing approach. One of which is session based exploratory testing (SBET). Some confuse this testing approach with Ad-hoc testing without realizing it is way more powerful and structured. Here is a formal introduction to this testing approach and how to use it in your daily testing activities.

What is SBET?

SBET are time boxed uninterrupted testing sessions focused on a particular goal (module, feature, scenario). There are different approaches and templates used for this approach.

Advantages of SBET

This can be used within any domain, project or application; where you can get quick feedback about the application instead of writing detailed test cases (scripted testing). You get more flexibility in exploring the product and get to use your creativity within the boundaries of the goal of the session.

How to do it?

I personally have had a lot of success pairing up with another tester/developer and we both execute the same scenario in different devices/environments and discuss our observations. For example – Say, I am testing a mobile web application; I will have my colleague test the web app on an Android Tablet and I may have an Apple phone. Then we both execute the same scenario and discuss the observations. Just by doing this you can uncover lots of rendering issues, inconsistencies and unexpected behavior.

Structure of SBET?

SBET usually follows the below structure. They are-

  • 45-90 minute Time Boxed sessions
  • Have Charter/Goal document to guide the session
  • Note down test ideas/scenarios
  • Paraphrase/Debrief the observations
  • Discuss Observations with a developer/business person
  • Log Defects based on the discussion

All the session notes are contained in what is called a Charter Document. This is a document that contains all the details about the session including the goal of the session, necessary resources used in the session, task breakdowns containing time spent on performing different tasks during the session, session notes containing helpful information along with the test ideas and observations, issues uncovered during the session and any screenshots (if necessary).

So everyone knows the details about the session and how much time was spent on it. The document can be attached to a story or any repository where you house your test artifacts.

Doing a number of SBET sessions helps to

  • Get a better idea about the product features
  • Uncover bugs that would be otherwise hard to find with scripted/automated testing
  • Identify high risk areas
  • Identify mundane tasks in manual testing which are time consuming, which are good candidates for automation

How it fits into automation?

Doing SBET helps to set the stage for automation. It helps to learn about the application and think about different scenarios to automate. It is good to have SBET and high level automated tests running in parallel as it gives you good coverage of the application. The time you invest in automation depends on your context i.e how many people are available to do automation, the skill sets, cost vs value of doing automation, timeline and what tools/framework you are using.

After a month or two of getting to know the product by doing SBET, you can start doing some time boxed experimentation with different tools that are available for automation. Then you can practically see what fits your needs. Once you identify the tool, you can start automating the different scenarios.

How SBET fits in Agile Projects?

Given the flexibility SBET provides, the next question that quite often comes to mind is – When is the right time to do SBET? The answer is it depends on the context of the project. If you are just the lone tester or have only 2-3 people in the testing team, you can start doing ET sessions on each user story. Once you get a fair understanding of the functionalities of the application, you can start writing high level test cases and pick out scenarios for test automation based on the knowledge gained from these sessions.

If you are working in large scale agile projects and have a big test team, then you could follow the below approach-

  • For each story, discuss the acceptance criteria. Based on that discussion, identify scenarios that can/cannot be automated
  • For those scenarios that have to be tested manually, figure out the risk and impact associated with the story. For example – If the story is about implementing the payment functionality of a banking system, then there are high risks and huge impact to the customer and the organization, if the feature is not implemented correctly and we do not get proper test coverage. On the other end, if a story is about increasing the font size on the web page from 12 points to 15 points, the risks and impact to the customer are lot lesser. Do customers really care if the font size was not changed correctly? The answer could be Yes; but the impact is minimum as the customers would still be able to perform the required transactions in the application. But if the payment system is not working, then customers cannot make a payment which is a huge deal
  • Once we identified the story as high risk and impact, we can write high level test cases covering the acceptance criteria and some edge cases. This can then be supplemented by one or more ET sessions to explore certain aspects of the functionality in more detail

Once an ET session is complete, all the documentation generated from the session (which usually would be ET charters filled with information) can be attached to the specific story for better traceability and letting stakeholders know the details about the ET session including the different issues uncovered. This way, everything is documented and available for future reference.

During regression testing phase, one or more of these ET charters could be reused to perform additional sessions. Some of the scenarios from the ET session can be converted into high level test cases or automated test cases. Thus, ET sessions can start right from the story testing phase and can extend all the way till acceptance testing phase.

Remember, SBET is NOT a replacement for scripted test case execution but is performed COMPLEMENTARY to it. It is an approach that helps in exercising the creativity and experience of the tester to get more information about the product. As a result, stakeholders can make informed decisions.

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; Advanced Analytics, Results Export Feature. Check them out and let us know what you think.

Advanced Analytics

What is it?

You will now be able to see an aggregated failure summary report inside a suite runs page. The report will contain a snapshot of the test failures and a pie chart. To help with debugging; clicking any error group or one of the pie chart segments will filter the view to show only the tests that failed on the selected error. This speeds up the troubleshooting of failed tests by pinpointing the root cause of run failures.

Why should I care?

Sometimes, a single problem in one shared step (for example, a “login” group) can cause many tests to fail. With the release of this feature, you will now be able to quickly hone in on those high-impact problems and dramatically reduce the time it takes to stabilize the suite.

 

Results Export Feature

What is it?

You will now see an export button in the results page (suite runs, test runs and single suite view). Clicking this button will download the results data as a CSV file, which can then be imported into excel or Google sheets.

NOTE: Only the data that is currently presented in the UI will be put into the CSV file. For example, if “Last 24 hours” is selected and the status filter is set to “Failed”, the CSV file will only include failed tests from the last 24 hours.

Why should I care?

We now have the ability to easily share the test results across teams with people who use and do not use Testim. This also gives the flexibility to feed the generated CSV file to any external tool or framework for more customized reporting. The possibilities are endless.

Testim gives users the flexibility to run tests on different screen resolutions. But sometimes this can get confusing where in; some tests run on a certain resolution and the newly created tests run on a different resolution. Below, are two simple tips to set screen resolution for a particular test and also apply it globally to all the tests in the project.

Tip 1: To ensure a test runs on a particular screen resolution each time you run it, follow the below steps

  • Navigate to the properties panel of the setup step (first step in the test)
  • Click on “Choose Other” option to select a resolution from the already existing config list OR
  • Click on the edit config icon next to the exiting resolution
  • Set the desired screen resolution you want
  • Give a name for the newly created resolution
  • Then click “Save”

 

Tip 2: To apply an existing/new resolution to all the tests in your Test List, follow the below steps

  • Navigate to the Test List view
  • Click on “Select All”
  • Click on the “Set configuration for selected tests” icon
  • Choose the required resolution you want to be applied to all the tests

NOTE: Test configs can also be overridden during runtime via the –test-config parameter in the CLI and the Override default configurations option in the Scheduler.

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; Auto Scroll, Scheduler Failure Notifications. Check them out and let us know what you think.

Auto Scroll

What is it?

When an element on the page is moved around, finding the target element may require scrolling even though it wasn’t required when the test was initially recorded. Testim does this automatically with auto scroll.  

NOTE: User also has the option to disable this feature, if required.

Why should I care?

You no longer have to worry about tests failing because of element not visible/found when the element location is changed in the page; thereby needing to scroll.  With auto scroll, you can scroll automatically to the element that is outside the viewport.

Scheduler Failure Notifications

What is it?

Users now have the ability to get email notifications on every failed test that ran on the grid using the scheduler.

Why should I care?

With the new “Send notifications on every failure” feature, users will receive notifications on failures every time a scheduler run fails. Now, you have instant feedback on failed scheduler runs. This is unlike the “Notify on error” option, where uses gets notifications only once; when a scheduler run fails. No new email is sent out until the failed scheduler run is fixed.

 

What are Loops?

Loops are one of the most powerful concepts in programming and sometimes could be a little hard to understand. At Testim, we made it easier for users to use Loops in their tests; by building it within the framework itself. This means, the user does not need to write code to repeat a group of steps a certain number of times.

Why do we need Loops?

Loops are useful when we need to repeat an action several times in our test.

For example –  Say we want to check whether the “Post” button on Twitter works consistently. We could have a scenario where we want to click the button 50 times to ensure it works consistently without any problems. In this scenario, are we going to record 50 steps to click the button 50 times or just record the step once and repeat it 50 times?

This is where Loops can be our best friend. It helps in repeating an action several times without needing to repeat the steps again and again. As a result, we save a lot of time in test authoring and execution.

How to use Loops?

Loops could still be a little hard concept to grasp. So here is a quick tip on how to easily use loops within Testim.

Let’ say we have the below code

for(i = 1; i < 4; i++) {

//Steps to repeat 3 times

}

What we are doing here is –

  • We are initializing a variable “i” to be equal to 1 before the loop starts. This is our Iterator.
  • We are specifying a condition to repeat the steps a certain number of times by giving “i<4”. In this case we want to repeat a set of actions 3 times.
  • Each time we exit a loop we need to increment our Iterator. In this case, we are doing “i++” which will increment the variable i from 1 to 2, 2 to 3 and 3 to 4. Then, eventually we exit the loop when i = 4, as we have a condition which checks to see if i<4 (Remember 4 is NOT LESS than 4 but EQUAL)

The same logic applies to Loops in Testim as well. Where we have 3 steps –

Step 1 – Initialize the Iterator

Step 2 – Specify a condition to repeat the steps a number of times

Step 3 – Increment the Iterator

This is what we do in this Demo Example, where we-

 

STEP 1Initialize the Iterator

 

STEP 2Specify a condition to repeat the steps a number of times

  • Group the steps to be repeated in one single reusable component
  • Go to the Properties Panel and add Custom code
  • Give condition to repeat the group a certain number of times

 

STEP 3Increment the Iterator

  • Add a custom action as the last step inside the newly created group
  • Increment the Iterator

 

The same steps applies to any set of actions you may want to repeat using our Loops functionality. You can also use do…while loops which follows similar concepts.

Also remember, Testim supports loops based on element conditions apart from just custom code.

We recently hosted a webinar on Real Use Cases for using AI in Enterprise Testing with an awesome panel consisting of Angie Jones and Shawn Knight and me being the moderator. There were lot of great discussions on this topic and we wanted to share it with the community as well.

Below you will find the video recording, answers to questions that we couldn’t get to during the webinar (will be updated as and when we get more answers) and some useful resources mentioned in the webinar as well. Please feel free to share these resources with other testers in the community via email, twitter, linkedin and other social channels. Also, reach out to me in case of any questions at raj@testim.io or any of the panel members.

Video Recording

 

Q&A

Any pointers to the existing AI tools for testing?

@Raj: I am assuming this question is about things to know with existing AI tools in the market. If this is the case, then first and foremost, we need to figure out what problems we are trying to solve with an AI based tool that cannot already been done with other possible solutions. If you are looking for decreasing time spent on maintenance, getting non-technical folks involved in automation and making your authoring and execution of UI tests much faster, then AI tools could be a good solution. I may be biased in this but it is definitely worth checking out Testim and Applitools if any of the points I mentioned is your area of interest/pain point as well.

As discussed in the webinar, currently there are a lot of vendors (including us) who use all these AI buzzwords. This may result in you getting confused or overwhelmed in choosing a great solution for your problems. My recommendation is-

  • Identify the problem you are trying to solve
  • Pick different AI tools, frameworks to help solve that problem
  • Select the one that meets the needs of your project
  • Then, proceed with that tool

 

As a tester working with Automation, what should I do to not lose my job?

@Raj: First of all, I believe manual testing can never be replaced. We still need human mind to think out of the box and explore the application to find different vulnerabilities in our product. AI will be used complementary to manual testing.

Secondly, we need humans to train these AI bots to try to simulate human behavior and thinking. AI is still in its initial stages and is going to take another 10 -15 years to completely mature.

In Summary, I think this is the same conversations we had 10 years ago when there were automated tools coming into the market. Then, we concluded that automated tools helps to complement manual testing BUT NOT replace it. I think it is the same analogy here where AI is going to complement manual testing BUT NOT replace it.

As long as people are open to constantly learning and acquiring different skillsets, automation is only going to be make our lives easier while we can pivot and focus on other aspects that cannot be accomplished with automation. This mainly involves things related to creativity, critical thinking, emotion, communication and other things that are hard to automate. The same thing holds through for Artificial Intelligence. While we use AI to automate some of the processes to save us time, we can use this saved time in focusing on acquiring other skills and stay abreast with the latest in technology.

So the question here is, not more about automation/AI replacing humans but about how do we stay creative and relevant in today’s society? That is done by constant learning, development and training.

 

Do we have some open source tool on the market for AI testing?

@Raj: Not really, we do have a small library which was added to the Appium project to give a glimpse of how AI can be using in testing — https://medium.com/testdotai/adding-ai-to-appium-f8db38ea4fac?sk. This is just a small sample of the overall capabilities.

 

What should be possible in testing with ai, in 3 years time? And how do you think testing has changed (or not)?

@Raj: We live in this golden age of testing, Where there are so many new tools, frameworks and libraries that are available to us, to help make testing more effective, easier and collaborative. We are already seeing the effects of AI based testing tools in our daily projects with introduction of new concepts in the areas of location strategies of elements, visual validation, app crawling and much more.

In 3 years, I can see the following possibilities in testing-

  • Autonomous Testing

I think autonomous testing will be more matured and a lot of tools will include AI in their toolset. This means we can create tests based on actual flows done by the user in production. Also, the AI can observe and find repeated steps and cluster them to make reusable components in your tests. For Example – Login, Logout scenarios. So now we have scenarios that are actually created based on real production data instead of us assuming what the user will do in production. In this way, we also get good test coverage based on real data. Testim already does this and we are trying to make it better.

  • UI Based TDD

We have heard of ATDD, BDD, TDD and also my favorite SDD (StackOverflow Driven Development) 🙂 . In 3 years, we will have UITDD. What this means is, when the developers get mockups to develop a new feature; the AI potentially could scan through the images in the mockups and start creating tests, while the developer is building the feature in parallel. Eventually, by the time the developer has finished implementing the feature, the AI would have already written tests for it based on these mockups using the power of image recognition. We just need to run the tests against the new feature and see whether it passes/fails.

  • AI for Mocking Responses

Currently we mock server requests/responses for testing functionalities that depend on other functionalities which haven’t been implemented yet or for making our tests faster by decreasing response time of API requests. Potentially, AI can be used to save commonly used API requests/responses and prevent unnecessary communication to servers when the same test is repeated again and again. As a result, your UI tests will be much faster as the response time has been drastically improved with the help of AI managing the interaction between the application and the servers.

 

Will our jobs be replaced?

@Raj: Over the past decade, technologies have evolved drastically. There have been so many changes happening in the technology space but one thing constant is human testers’ interaction with them and how we use them for our needs. The same holds true for AI as well. Secondly, to train the AI, we need good data combinations (which we call a training dataset). So to work with modern software we need to choose this training dataset carefully as the AI starts learning from this and starts creating relationships based on what we give to it. Also, it is important to monitor how the AI is learning as we give different training datasets. This is going to be vital to how the software is going to be tested as well. We would still need human involvement in training the AI.

Finally, it is important to ensure while working with AI the security, privacy and ethical aspects of the software are not compromised. All these factors contribute to better testability of the software. We need humans for this too.

In summary, we will continue to do exploratory testing manually but will use AI to automate processes while we do this exploration. It is just like automation tools which do not replace manual testing but complement it. So, contrary to popular belief, the outlook is not all ‘doom-and-gloom;’ being a real, live human does have its advantages. For instance, human testers can improvise and test without written specifications, differentiate clarity from confusion, and sense when the ‘look and feel’ of an on-screen component is ‘off’ or wrong. Complete replacement of manual testers will only happen when AI exceeds those unique qualities of human intellect. There are a myriad of areas that will require in-depth testing to ensure safety, security, and accuracy of all the data-driven technology and apps being created on a daily basis. In this regard, utilizing AI for software testing is still in its infancy with the potential for monumental impact.

 

Did you have to maintain several base images for each device size and type?

Has anyone implemented MBT to automate regression when code is checked in?

 

Resources relevant to discussions in the webinar

Be smart & save time...
Simply automate.

Get Started Free