Something else, mechanization can’t generally take such a significant number of changes. Mechanization ought to likewise search for contents which have long haul life that produces more prominent ROI. As a general rule, we rely upon manual analyzers to get the contents. Which isn’t right as I would see it.
Whatever contents computerization group is robotizing ought to get approved by utilitarian specialists generally later it may toss loads of false positive report later move to genuine disappointments. Minor bugs with lower need is frequently a set back for designers. Yet, such sort of bugs may musk high need bugs.
Robotization will keep on coming up short at the minor bugs. High need bugs simply stow away in the shadow of carelessness. Overall not creating reusable assets contributes Challenges in Testing(DevOps Testing issues or Software Testing challenges).
What is Test Automation all about:
Test automation is a concept where the Automation experts uses a tool and try to simulate an user’s activity.In other word they put intelligence to computer through coding by which computer behaves like an user. By doing this method automation test engineers mainly reduce
- The pain of testing a same piece of application with different set of data in multiple time.
- Manual intervention to the system
- Regression effect due to a bug fix or new implementation
Process of Automation Testing:
- Record /code the required place(100% testing through automation is not possible)
- Change as per framework.
- Insert data in the data table in case test engineers need to test for multiple iterations.
- Execute the code
- Generate result
- Validate the result.
Problems of Traditional Automation Testing Process:
- Most of times the codes made by automation engineers become more of personal code. I mean very much test engineer’s specific code. Poor variable deceleration . I have seen people using girlfriend’s name as a variable.No comments!!! Due to these problems a test engineer do not want to update or debug some other test engineer’s code.
- Test engineers try to inject new code by simply click on record. Do all the transformation on recorded code to make it as per framework.(Some do not bother to transform also).This bring problem absolute no re usability of the existing code. The previous development cost becomes useless.
- Even if there is a review process defined,they are very much unstructured. They mainly checks the variable declaration,format of the script,entry and exit reporting.Inbuilt logic becomes untouched.This leads to script failure later part.
- Time is another factor which leads to poor review of automation test code .It is always given the least time and last priority.Most of the automation engineers are more interested to run a flow and complete it rather than review of the code.
- Managers are not open to find out a bug in the script code. Rather it is always a blame game with developer , manual QA process.
A test engineer’s performance can not be measured with how many defects he has caught and whose code run perfectly without any problem.When I said that scripts are executing perfectly, it is meant without manual intervention. But Manual intervention never means an automation test engineer is poor at coding,there can be n number of reasons behind that.Frequently these problems lead to poor performance appraisal for a test engineers.As a result test engineer is more interested to make a result pass rather investigating the root cause of the problem.
- GUI object change is also one more reason why testing process fails.Say in release x it was only drop down but in release y it became editable field.In our day to day life automation engineers never track an object. They only depend on tool to identify those cases.When failed , test engineers try to fix it.This reactive approach not only slow down the execution speed also can open a regression effect or can mess up everything.
- Improper tool selection is also a major contributor to the faulty process.I have seen tools which records the action itself and unable to run it back.I have seen a tool which when generate fresh code able to run. But if saved and run later always throws error “Object not found” even if the object is there.
- Insufficient knowledge about the tool also make process unhealthy.
- Too much of function learning while automating the flow may contributes a percentage to the wrong automation testing process .
How to solve the automation testing issues?
To make testing process more effective developer needs to understand the impact of their code change in automation.It is always better if developer team follow uniform approach. The uniform coding standard makes development code maintenance easy.
The main objective is to cooperate with developers and help each others. Maintain uniform and simple solution,rather having complex and unintelligible solution.
Always look for solution rather workaround.And solutions should not be too complicated. Keep it easier so that everyone can understand. Follow the path that will achieve easy maintenance. Well structured overview will be plus.
Always follow best practices if not keep a good reason ready.All derivation should be approved by test architect and other stakeholders.
Define standards but allow exceptions when needed.Oue application should derive the tools not the tool should derive the application.
Better create E2E script rather module based.Code the automated test whenever a new product approved or new piece of code is added into application.Learn the basic technique about how to add the component well.
Lets make the automated regression report visible to all.Make the team dependant on automation.
Development team must inform functionalities and GUI changes. So that automation knows what needs to be loaded or maintained.
What is the solution then?
To cope up with these Challenges in Testing any test team has to follow the below:
- Ensure the requirements are strong, clear, total, definite, durable, achievable and testable. All players ought to consent to prerequisites. Use models to enable nail to down prerequisites.
- Have timetables that are practical. Permit sufficient time for arranging, plan, testing, bug settling, re-testing, changes and documentation. It has to be in such a way that we do not need to burn the team members out.
- Do testing that is sufficient. Begin testing from the get-go, re-test after fixes or changes, and plan for adequate time for both testing and bug settling.
- Avoid new change requests. Stick to introductory prerequisites however much as could reasonably be expected. Be set up to safeguard plan against changes and augmentations, when improvement has started and be set up to clarify outcomes. On the off chance that changes are vital, guarantee they’re sufficiently reflected in related calendar changes. Use models right off the bat so clients’ desires are illuminated and clients can perceive what’s in store; this will limit changes later on.
Impart. Require walk-throughs and examinations when fitting; make broad utilization of email, bug tracking instruments, devices to track progress. Guarantee documentation is accessible and state-of-the-art. Use electronic documentation instead of paper. We make sure to collaborate and cooperate.
- if a bug is caught well advanced the cost to fix and retesting cost is less but if it is later stage the cost might go up exponentially.To mitigate such risk we have take a different approach. Most of test cases of earlier builds should be executed to detect the regression .Test engineers must check the new features.
- Sometimes it is incredibly frustrating to work in agile mode of testing. There are pressure to deliver and many times the QAs are the lone person to raise voice when everybody thinks the software will work well.QA needs to be very confident about their work should be able to backup their opinions with real facts.
In agile mode of development QA can not be frustrated if there is less requirements or no requirements or frequently changing requirements.In agile world, requirements are constantly being altered,added,redefined,refined or scrapped. There will be constant flux. We the QA need to be agile enough to cope up with the changes.Many start ups don’t even like to spend time and money in testing,even many times they think automation is the key to get success.To add to this they even call junior developers to test the application. But this strategy mostly fails as 100% automation is neither possible nor desirable. Again the developer can not test the application due to the mindset. They are creative by nature and QAs are destructive by nature.
- Lack of advertisement also makes QA fail. In start ups QA team tends to small and mostly hidden under development. To mitigate the risk about a software QA’s role is huge. They need to raise alarm on a faulty product at the same time need to pick the free software to make QA cost less. But overall they need to advertise for themselves. Only then the importance will be well understood.
- In today’s world people need good things at very minimal cost or in free. But at the same time they are ready to uninstall if there are bugs in the software. They may give negative comments about the product. Playstore -Android,Appworld-Apple etc are classic example of review comments. Few negative comments may slow down the selling or adapting new software. Think about real world,we always go by the rating and comments.
- The startups and companies are cleverly taking a approach called alpha and beta testing to reduce cost. This strategy creates hype but produces bad more rather than good.
- TDD-Test driven development is coming but in a very slow manner. Some also outsource the product to test. but the main problem is with the commitment level of the vendor company. They may not be as good a full timer.
Do not hesitate to give correct feedback. Sometimes,this may not be feasible as developer might be from same organization. But we need to bring the improvement points on the table.
Remember a happy customer experience is everybody’s objective.Hence we need to keep aside all the challenges and focus on delivery.