schedule 12:15 PM - 01:00 PM place Esquire

Building a Test Automation Framework is easy - there are so many resources / guides / blogs / etc. available to help you get started and help solve the issues you get along the journey.

However, building a "good" Test Automation Framework is not very easy. There are a lot of principles and practices you need to use, in the right context, with a good set of skills required to make the Test Automation Framework maintainable, scalable and reusable.

Design Patterns play a big role in helping achieve this goal of building a good and robust framework. 

In this talk, we will talk about, and see examples of various types of patterns you can use for:

  1. Build your Test Automation Framework
  2. Test Data Management
  3. Locators / IDs (for finding / interacting with elements in the browser / app)

Using these patterns you will be able to build a good framework, that will help keep your tests running fast, and reliably in your CI / CD setup!

 
2 favorite thumb_down thumb_up 10 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • What is a pattern? - 1 min
  • Patterns for building a good, robust, scalable, maintainable Test Automation Framework - with examples, Advantages and Disadvantages - 10 min
  • Patterns for Test Data Management - with examples, Advantages and Disadvantages - 20 min
  • Patterns for Locators / IDs (for finding / interacting with elements in the browser / app) - with examples, Advantages and Disadvantages - 5 min

Q&A all along the way, and in the remaining time

Learning Outcome

  • Patterns for building Test Automation Framework
  • Patterns for Test Data Management, with pros and cons of each
  • Patterns for managing locators / IDs for interaction with UI

 

Target Audience

Developers, Testers, Everyone involved in Test Automation

schedule Submitted 2 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Vivek Ganesan
    By Vivek Ganesan  ~  1 year ago
    reply Reply

    Thanks for the submission, Anand :)

    In my opinion, this is a topic which many people will certainly appreciate and learn from.

    Also, it would be very helpful if we define the term "Locators" in the proposal, as not many people can understand the term at the first look.

    • Anand Bagmar
      By Anand Bagmar  ~  2 years ago
      reply Reply

      Thanks Vivek! Good point about the locators. I have updated the same in the proposal. Do let me know if that is sufficient.

      • Vivek Ganesan
        By Vivek Ganesan  ~  1 year ago
        reply Reply

        Great! Does this talk cover UI test automation predominantly?

        • Anand Bagmar
          By Anand Bagmar  ~  2 years ago
          reply Reply

          The Test Automation Framework patterns and locators / ID part will be focussed on the UI testing aspect. The Test Data Management aspect can be applied to any type of Test Automation.

  • Joel Tosi
    By Joel Tosi  ~  1 year ago
    reply Reply

    Hi Anand,

        If an attendee is not building their own test automation framework, what would they take away from your session?

    Best,

    Joel

    • Anand Bagmar
      By Anand Bagmar  ~  1 year ago
      reply Reply

      Hi Joel,

      I don't really understand what you mean by "own test automation framework". 

      If you mean - its an existing framework that has already been built - Patterns are something that can always be applied on existing codebase as well - using refactoring techniques. So the information shared in this talk will still be very applicable - as a test automation framework should also be constantly evolving.

      If you mean - its some commercial tool based automation framework that does not allow lot of flexibility to write code using good practices - then this session is general learning material that can be used when one gets an opportunity for work on a proper automation framework.

      If I have still not answered your question, can you please clarify it for me?

      Thanks. Regards, Anand

       

      • Joel Tosi
        By Joel Tosi  ~  1 year ago
        reply Reply

        Hi Anand,

           Thanks for the quick response.  Quite a few times in your submission you say 'build your test automation framework' - which leads me to believe that this session is about building a test automation framework (i.e. how to build your own Selenium).  While I agree, the rest of the information doesn't seem to be about building your own framework, I am just confused by your use of it. 

        Could you help me understand what you mean by 'build your test automation framework'?  Are you suggesting people create their own nUnit / Selenium / etc?  I don't believe you are but want to understand

        Best,

        Joel

        • Anand Bagmar
          By Anand Bagmar  ~  1 year ago
          reply Reply

          Hi Joel,

          A Test automation framework is more than using just a test runner (ex: nunit) or a library / framework which helps automate interactions with browsers (ex: selenium). You need to think of how the test intent is specified, what libraries / tools / utilities you need to have, reporting, how to manage test data, etc.

          As the number of tests to be automated increases, the test automation framework also grows in its complexity!

          Like for Product Development, developers apply various different practices and patterns in building code, test automation is also a similar development activity, which requires the team members to apply various different practices and patterns to make this test framework more robust, maintainable and scalable. This talk focusses on that aspect.

          I will be focussing on patterns for building the Test Framework, and how to manage test data and locators (for elements / controls) in the web pages.

          See an example of the Test Automation Framework architecture here (http://www.slideshare.net/abagmar/perils-of-pageobject-pattern) - more specifically - slide #26

          Regards,

          Anand

  • Joel Tosi
    By Joel Tosi  ~  2 years ago
    reply Reply

    Thanks much for the submission Anand.  Looking at your session and the samples, it looks like you are not focusing heavily on tools which I appreciate.  Could you please confirm that for me?  I would rather ask than assume ;)

     

    Best,

    Joel

    • Anand Bagmar
      By Anand Bagmar  ~  2 years ago
      reply Reply

      Hi Joel,

      You are right. This is not about tools, but more about the programming aspects and usage of design pattern in the same to build a good robust framework. The examples I will use will be a mixture from different programming languages - again mainly to stress upon the concept - which can be implemented in different ways, and potentially better ways by individuals / teams.


  • Liked Tony Xavier
    keyboard_arrow_down

    Tony Xavier - Challenges and Best Practices: Creating Customer Focused Documentation in an Agile Framework

    45 mins
    Talk
    Advanced

    Agile is an increasingly popular development method primarily used by software companies. In Agile software development, work is confined to a regular, repeatable work cycle, known as Sprint. A sprint typically lasts for two to three weeks. In Agile, development teams strive to deliver a fully functioning, high quality, and potentially shippable product increment at the end of each sprint. Hence, product documentation becomes an essential part of the sprint deliverable to meet stakeholder requirement. Since, the primary focus of Agile development is to deliver products with high quality, technical communicators are expected to create customer focused documentation with high quality.

    Creating Customer focused documents involves paying great attention to needs and opinions of customers, and creating documents with a purpose. As writers we must ensure that the documents we create focus on the needs of the actual customers of the document and provides value. As writers we must identify who the potential customer(s) for our documentation are, what they require, and create minimal documentation that they actually need. By understanding the needs of our customers we will be able to deliver customer focused documentation with high quality. However, the combination of Agile’s high speed of development, short delivery cycles, and limited requirements documentation presents a unique set of challenges in creating customer-focused documentation.

    This paper highlights some of the challenges writers face and provides best practices that can be used in creating customer-focused documentation in an Agile framework.