Skip to main content

Well, the answer lies in creating an effective automation testing plan.

 

Join us online on March 16th at 3:00 Israel time, and we’ll show you how to create an efficient plan to prepare your wizards for production.

 

Our wizards will break down important scenarios like:

 

- How to create a functional and integrated testing plan

- How to carry out performance and load testing

- How to design and run a UAT (user acceptance test) to push your automation to production

 

Grab a seat here: https://bit.ly/3bvCyXC

Thank you for all those who joined! In case you lost us after a while, don't worry, the recording will be uploaded shortly. In the meantime, I am sharing some of the questions asked during the webinar.

Feel free to comment or add additional questions here, @Ziv Ilan​  and @Marcus Hochgürtel​  are here for you.


Question: In my experience is better to develop directly in a Production environment, because in the transition normally we should do all the recording again, how do you handle it ??

 

Answer:

Developing in the production environment is not recommended but cannot always be avoided. It is important to ensure that no production data is affected (especially negatively) during development and testing in the production environment. This can be achieved by implementing artificial stops in the process flow, so that data is not finally saved or sent, etc.

In addition, in some cases it is possible to test with fictitious test data in the production environment - this is recommended in any case. However, whenever possible, it is recommended to set up a test environment analogous to the production environment and to use it for development and testing. System settings, applications, screen resolution, permissions, etc. should be identical in both environments. In addition to security aspects, this also has the advantage that the production environment and associated applications are not blocked by the development and test processes and the production processes remain fully available.


Question: Sometimes the language and terminology used between developers and the business can be a huge constrain on projects? In your experience what are some ways you explain solutions that the business can understand without bombarding them with too much information? What is the fine line explaining RPA to everyday business users?

 

Answer:

The main idea is to bring RPA developers closer to the business and bring the business closer to RPA. This can create an engaging environment where the two sides can collaborate and bring more value and scale to the RPA organization. There are several execution areas – Citizen developer is one model that can bring both sides together and bring more RPA knowledge and tools to the business units while having a centralized team of developers that mentors and takes the more complex implementations. Sharing successful case studies and playbooks so business units will better understand what value RPA can bring to the business and what it can’t bring.


Question: Hi, How do you deal with the UAT and Prod environment differences?

 

Answer:

If there are differences between the test and production environments, the UAT should be performed under controlled conditions in the production environment.

It’s recommended to start with a limited scope of UAT in a test environment and have additional scoped tested in the production environment.


Question: How can RPA Developers give Project Managers a status on issues found about testing? Does this differ between Waterfall and Agile?

 

Answer:

As part of the preparation before a developer starts to implement the solution, a detailed project plan with milestones and deliverables should be shared with the project managers/business owners. This should be tracked on a daily / weekly basis (agile vs waterfall/other approaches) and since RPA development can be impacted by external factors or operational bottlenecks, the project manager should be updated with the progress and any hurdles that should be resolved. If a developer runs an integration test and identifies an issue with a specific application/component/business flow, the project manager needs to understand the potential impact of this issue and help resolve it with the relevant stakeholder.


Question: Please comment. My experience has been that many coders do not like doing Alpha testing! Many problems are created because some coders do only very cursory testing that is not comprehensive enough, causing lots of re-work. Many even resist developing and implementing even a very simple testing script for developers to use, saying it is a waste of valuable coding time.

 

Answer:

That’s very true and one of the main issues why initial estimations of RPA development are usually overpromising and has a direct impact on the scalability and stability of RPA within the organization. Getting to the notion that testing is critical to the proper progress of the development and essential to guarantee stability in production is part of the learning curve of every organization/developer, and this should be emphasized as part of the onboarding plan/education plan of the development organization. This can also be tracked with code reviews and proactive collaboration sessions between developers to share best practices and approaches to testing.

 


Question: Good morning, how can we control the errors that occur in production after one or two months of have deployed

 

Answer:

Based on the type of error, this should be classified as a bug, change or feature request - these should be documented, prioritized, and scheduled in terms of development. All adjustments or enhancements to existing processes should be carried out in the development and test environment and run through the complete cycle (planning, development, testing) before being transferred to the production environment. The process documentation and test protocols should be updated to include the change/enhancement.


And here is a UAT template shared by @Marcus Hochgürtel​ 


Reply