How-to: Combining Manual And Automated Testing For Enterprise Software UI Assessment
On our blog we’ve already discussed such topics as enterprise software development and implementation. However, we haven’t covered one crucial topic: the testing process, which is key for getting high-quality software capable of solving business-critical tasks. Today we will talk about our approach to the testing of the user interface of 1Ci products.
Step #1: Understanding manual and automated tests; best use cases
Nowadays almost every company who is into software development is using a blend of two methods: manual and automated testing. However, to achieve the best synergy between these two approaches, it is crucial to understand when each of them can be used with maximum efficiency.
Manual testing’s main goal is to discover issues from the user’s perspective, or to identify unexpected bugs. Here at 1Ci we use manual testing based on user stories to assess new features released by developers. After the piece of software is ready for testing, we prepare the checklist of things to check, and then run through them manually. This helps to understand what the user will experience when interacting with the product.
Sometimes there are software configurations that can’t be tested automatically or are used and tested very rarely (i.e., once in a quarter) so there is no need to waste resources on automation. Also, there can be the opposite situation when the configuration is used and changed so often that it is impossible to constantly update tests as well. In such cases, it is much easier and cheaper to spend some time on manual testing.
This approach can also be used in projects that require integration with third-party libraries and services. These resources are not usually updated that often, so it is better to create the approval test-case which is run manually.
In turn, autotests are good for assessing the current functionality and ensure that changes that were introduced by developers did not cause interface errors in previously released features.
Also, autotesting is a perfect tool to polish up the overall assessment. In our case, after all manual tests are finished a document detailing all comments and descriptions of mistakes found is prepared. This document then goes to a developer who fixes the bugs and returns the feature for the second round of tests. After all such issues are fixed, and all test scenarios are successfully passed, the automated tests are written.
Important note: autotests can be used not only for assessing the product itself, but for checking the environment where the software is meant to be used. This might speed up the overall development process.
Step #2: identifying your UI testing toolkit
To successfully combine manual and automated testing you will need to think through your testing toolkit. The number one rule here is to try to keep it simple and cost-effective. For example, it is much better when there is a way to create manual tests with no programming skills needed — this will speed up the overall process, as simple tests may be created by software analysts and junior testing team members.
This is why we use Gherkin language for writing test scenarios. It has a simple syntax which can be mastered very fast. Also, the same test case can be used both for a thin client and server.
Here is an example test written in Gherkin language:
Purchase order:
When I click command interface button “Purchases”
When I click command interface button “Purchase orders”
Then “Purchase orders” window is opened
And I click the button named “FormCreate”
Then “Purchase order (create)” window is opened
And I input “In progress” text in the field named “OrderState”
And I input “Delta computers” text in the field named “Counterparty”
And I move to the next attribute
And I input “Best computers” text in the field named “Company”
And I input “#002, dated 01.01.2019 (EUR)” text in the field named “Contract”
And I input “ 9/10/2019” text in the field named “ReceiptDate”
And I input “ 9/ 2/2019 12:00:00 AM” text in the field named “Date”
And I move to the next attribute
When developing the software based on a certain platform, such as 1C:Enterprise, it is a good idea to use built-in testing features. This avoids wasting resources on integration with third-party testing apps. For example, we use 1C:Vanessa Automation and 1C:Scenario testing tools that are built into the platform.
Step #3: Calculating ROI
Software development and testing is an ongoing process which can’t be successful without proper analytics. This is why you should constantly evaluate whether the profit from automation of the certain test case is worth the resources spent on it.
For example, the set of automated tests we use to assess a new feature is executed in around 2.5 hours. If we tested all these scenarios manually, we would spend at least several days, and the possibility of mistakes would be much higher.
Moreover, these autotests also deliver additional profit. After they are finished, we will not only be sure there are no mistakes, but create a demo database for new feature demonstration as well. This means that when the user first sees the feature live, we will be able to fill all the necessary fields with the test data to make it easier to understand how things work. Preparation of such a demo database from scratch would also be time-consuming.
Final thoughts
As can be clearly seen, the right blend of manual and automated testing can save you tons of resources and effort. However, to properly create such a blend, you will need to create a set of rules regulating what type of testing and when to use it, pick up the tools that provide cost-efficiency and effectiveness, and constantly evaluate ROI of this work.
Also, internal team communication is crucial to such a synergetic QA process as there will be a lot of teamwork involved. Programmers should not only write code, but help to create test case descriptions and answer questions, while QA engineers should clearly describe their findings in reports and comments to make it easier for programmers to fix bugs.
