Tag Archives: Divya Madaan

Design Patterns in Test Automation World

Software development has lot of methodologies and standardized approaches to make the development process efficient such as object oriented programming, domain-driven design, test-driven design and behaviour driven design etc. Automation testing, since the very beginning, has been relatively new when it comes to processes and standards. But now it has gained lot of exposure in terms of standardization and has been under the process of continuous improvement and evolvement through design patterns. Automation testing is a process of developing software to test software. Hence, the test patterns are loosely similar to design patterns that are used in software development.

Design patterns show how to design the test automation testware so that it will be efficient and easy to maintain. The most challenging part in test automation has always been the code maintenance. A lot of test automation projects have drowned or were scrapped due to the inability of the frameworks to cope up with the growing codebases. In order to keep the maintenance cost low, the automation engineers should strive to minimize the code that they reinvent or create from scratch by using existing functionality for common, generic, or repeated operations.


What are the types of Design Patterns in test automation?

1. Design Patterns in Test implementation
From the test implementation perspective, different design patterns can be understood as types of automation frameworks (illustrated in Figure 1):

Patterns2. Architectural Design Patterns




3. Functional Design Patterns




What are the advantages of using Design Patterns?

The use of design patterns offers below advantages:
– Low maintenance effort and time
– Low maintenance cost
– Enhanced code reusability
– Enhanced reliability
– Structured codebase which is easy to fix and extend
–  Improved communication


The design patterns contribute to a major chunk in defining the test automation best practices. The bene- fits of test automation cannot be reaped effectively without implementing the required design patterns specific to a test automation project.

About the Author

Divya Madaan is a test automation specialist with 11 years of experience in quality control. She has extensive experience in various automation tools, frameworks and latest technology. She is currently working with Aspire Systems.

Point of Sale Testing

What is a POS?
A POS (point of sale) is a computer which is connected to a receipt printer, cash drawer, credit/debit card reader and a bar code scanner etc. Retailers use an automated retail system where
the store cash registers are linked to computer processing systems.
Merchandise is ticketed with colored bar code tags, which are read with wand readers at the checkout counter. The computer accumulates sales transaction information on magnetic tape for daily input into the computer memory bank or storage system. It is input into the sales journal, which is rolled up into the stock ledger.

Why is ensuring quality of POS system through rigorous testing so important?
In competitive business such as retail, a POS can be a key differentiator. Good POS software package increases efficiency by eliminating redundant, manual labour and can manage the entire business.

Listed below are a few concerns among others if testing is not in practice for POS.

  • More man power might be needed due to unreliability and slowness of checkouts.
  • Risks of incorrect inventory records and thefts by employees.
  • Erroneous Sales reports would not provide correct inventory levels and hence controlling cost would become a challenge.
  • Extremely difficult to track promotions, discounts, and coupons.
  • Incorrect loyalty member data and hence loss of business due to non-repeating customers

Clearly it is very important for POS applications to be reliable, scalable, easily maintainable, highly secure, and easily customizable by the customer and hence it demands a lot of focus on effectively testing the solution before it gets deployed.

How to test POS?
As mentioned earlier, to ensure quality of POS software, proper testing of the application is very crucial. Just like any other application, to test a POS a good test plan should be developed too. To test POS one has to focus on a lot of things, few are listed below:

  1. Cashier activity: This includes customer transactions such as the entry of items, tender, Store Value Cards, discounts and layaway. It also includes non-customer transactions such as cash drawer loans, petty cash, totals and closings.
  2. Store Server and Back Office Integration: Verification of POS interaction with store servers and back office systems. Register transactions can be verified against the Electronic Journal for accuracy.
  3. Platform check: If the POS supports multiple- platforms then verification of the functionality on the all the platforms should be part of testing
  4. Sales: Regular sale, Sale with credit/debit/gift card, return, exchange, loyalty member purchase, items, quantities and prices
  5. Manage return and exchange: Return and exchange of an item with different tenders (cash, credit etc), with and without receipt
  6. Discounts and Promotions: Item % discount, military discount (applicable in US), line item discount etc.
  7. Loyalty Members Data: The system keeps track of what your customers are buying and who they are. It keeps track of what’s selling, at what times of day or week, to which types of customers and by which sales people. The data collected from POS terminals is useful in planning of long term strategies. A good POS System will also have reminder dates for each customer so you can call or e-mail them prior to an anniversary or birthday.
  8. Ability to Read a Card: There are various types of cards in the industry today. (Magnetic Stripe, CAV, etc)
  9. Performance: Speed or the time taken to send a request (read) and receive response and applying the transaction based rules (ex Rebates/Discounts/Tax etc)
  10. Negative Scenarios: Various transaction declined scenarios (Invalid Card/PIN/Expired Card etc.)

Software testing can be broadly divided into manual and automation testing. Each of which has its own pros and cons, however software testers are becoming well versed with latest technical advancements and are up- skilling to test better both ways.

What are the challenges in manual testing of POS? Testing a POS software package manually can lead to many challenges:-

  1. Multiple Configurations: Testing a POS application with different settings and configurations is a cumbersome task. Test cases should be designed covering each and every scenario (positive or negative) in detail. Therefore significant budget should be put in testing of such applications to prevent any major issues at the customer end.
  2. Peripheral issues: The peripheral issues may be related to devices which are connected to POS like bar-code scanners, scales, printers, towers and cash drawers.
  3. Complex interfaces: Integration of POS System involves numerous interconnected systems and third party elements. Systematic test design techniques are followed to reduce the complexity of interfaces.
  4.  Test Lab Maintenance: As a significant amount of hardware is normally connected to POS, it thus requires a large amount of space to house this hardware. We also have to put some effort and expense in to keeping the hardware in good condition.
  5. Upgrades: Rapid technological advancements necessitate frequent hardware and software upgrades.
  6. PCI Compliance: Care must be taken to adopt PCI-compliant, tamper-proof infrastructure at all POS terminals to protect cardholder data and identity.

How can Automation Testing help?

To save manual testing time, a test automation strategy can be developed. Test automation frameworks reduce time to market and testing costs while increasing and improving test coverage, product quality, and end-user acceptance. Companies that increase the proportion of automated testing have a decisive advantage over their competitors. Automation testing provides enhanced test coverage, saves testing time and cost, gives objective testing evidence in the form of customized reports, easy defect tracking for faster troubleshooting.

Having said this, before proposing automation testing as a solution, it is important to carefully analyze the ROI on the whole effort. Test automation is a strategy to reduce timelines, cut costs and improve quality. But before we reap the benefits of automation we have to make significant investments. It is also possible to calculate the possible returns of the test automation investment. Based on the inputs (such as releases planned per year, number of regression test cases, size of manual testing team etc), an ROI report can be generated which:

  • Analyzes the cost involved in automation
  • Compares the effort and cost for both manual testing and test
  • Provides the break‐even period
  • Presents the saving in percentage

How to select an automation testing tool?

For automating the test cases of POS software, a test automation tool is required which can recognize the UI controls of the application. Selecting an appropriate automation testing tool for a given application involves a step-by-step process. Without a proper process being followed, one might end up with either wastage of effort or selecting an inappropriate tool for the application under test (AUT). There are plenty of commercial and open source automation test tools available in the market. A proof-of-concept (PoC) exercise should be performed to select the best-suited tool for the POS application. In a typical PoC, evaluation of two or three shortlisted tools is carried out to judge the capability and fitment of the tool for an AUT. Also, a framework design based upon the requirements is suggested. As a result of PoC, one is able to select the test automation tool along-with the test framework design.

What are the challenges in automation of POS?

We should consider the fact that 100% automation may not achievable. While developing test automation strategy for POS one might face few challenges:

1. Interaction with Peripheral devices: The scenarios covering scanning a bar-code, swiping a card, pin-pad-entry, opening and closing cash- drawer etc involve peripheral devices which require human intervention. Such scenarios are difficult to automate.

2. Custom UI Objects: The UI of POS applications might contain non-standard objects which are difficult to be recognized by an automation tool.

3. Dynamic UI: The UI is often highly dynamic to allow it to cater to the changing business needs. Also, business processes are frequently modified and the cost and time required maintaining an automated regression test suite increases and in some cases becomes difficult to maintain.

4. Multiple Configuration and Interaction with other interfaces: POS application generally interfaces with the external systems such as Sales Audit, CRM, E-Commerce etc. The test cases require interacting with such applications as well which increases the challenge and the complexity. Also, POS vendors might have multiple versions/formats of POS hardware and software. So, maintaining the scripts for different versions and configurations becomes difficult and needs prior planning.

However, these are not roadblocks, solution providers having good experience in automation testing have devised ways to overcome these known constraints. We can conclude by saying that for complicated and business critical system like POS, test strategy can be a combination of both automation and manual testing. Also one should understand that testing of POS systems is different from other software and requires in-depth understanding of POS-specific challenges. To overcome such challenges and mitigate risks, the subject matter expert should carefully design the test strategy and approach in order to achieve the quality goal.

About the Author

Divya Madaan is a test automation specialist with 11 years of experience in quality control. She has extensive experience in various automation tools, frameworks and latest technology. She is currently working with Aspire Systems.

Behaviour Driven Testing – An Introduction

What is Behaviour Driven Testing (BDT)?

Behaviour Driven Tests focuses on the behaviour rather than the technical implementation of the software. If you want to emphasize on business point of view and requirements then BDT is the way to go. BDT are Given-when-then style tests written in natural language which are easily understandable to non-technical individuals. Hence these tests allow business analysts and management people to actively participate in test creation and review process.

Why BDT originated?

Since the time test automation started, it has evolved tremendously with new concepts, framework design and tools. The low usability, rigidity and high maintenance cost has been the reason of evolution of automation frameworks.









The one common disadvantage of using any of these frameworks is the difficulty in understanding the automated test cases by the non-technical people such as business analysts and management.

BDT has helped to plug-in this gap. It has helped to bridge the communication gap by writing human readable test cases. It is a relatively new agile software development approach that focuses on communication; encouraging collaboration between developers, QA and business participants; to help bridge the Business-IT alignment gap. The scenarios are written to build up a clear understanding of the desired behaviour and this happens through discussion with stakeholders.

How is BDT implemented?

There is a plethora of open source BDT frameworks available in many programming languages and supporting different platforms. For instance, Cucumber (preferably with Ruby), JBehave for Java, NBehave and specflow for .Net, Behat for PHP and Twist for Groovy etc. The BDT layer is implemented on top of customized framework so it’s about building up layer upon layer only. The behaviour driven tests are given- when-then style steps written in natural language. Ofcourse, the implementation of these steps has to be done in a programming language of one’s choice.

Advantages and challenges of BDT

•  Collaboration: It engages product teams, business analysts,
QA   team and developers onto the same page and provides a
platform to resolve the differences in point of view. Thus,
ensuring that all stakeholders have the same expectations.
This co- operation between stakeholders in-turn results in
good and clear set of Acceptance Criteria

    • Easy Review and Feedback: No development skills are required for creating tests as tests are written in ubiquitous language. Business Analysts can actively participate in automated test cases review process and give their feedback to enhance them.
    • Right Focus: BDT helps to focus on the user’s needs and the system’s expected behaviour rather than focusing too much on testing the implementation.
    • Greater ROI: It has been observed that the behavior of the software stays for longer than the implementation. So, behavior driven tests are easier to modify and hence results in greater ROI. Also, the BDT tools are open source which further reduces the investment.
    • Easy Maintenance: With BDT code redundancy can be minimized due to ‘step reusability’ feature. Hence, these tests are less costly to maintain.
    • Availability of skilled resources: The BDT tools and framework development approach are different from other popular automation tools in the market like QTP, SilkTest, TestComplete. So, skilled resources are required to build and maintain the BDT framework.
    • Re-engineering: In some cases, the tests written by the manual tester/client/ business analysts are not good enough for automation. So, some rework may be required to make them suitable for automation.
    • Support Community – The concept of BDT is relatively new that is why the support community is yet not large enough. So currently, it might take a little longer to resolve the technical issues or queries.


BDT is gaining momentum as lot of organizations are looking at it as a solution to their automation and collaboration challenges. BDT framework has been successfully implemented by various QA teams in various domains. Implementing BDT with automation best practices and integrating it with CI & test case management tool produces all the benefits of automation. BDT for sure is here to stay

About the Author

Divya Madaan is a test automation specialist with 11 years of experience in quality control. She has extensive experience in various automation tools, frameworks and latest technology. She is currently working with Aspire Systems.