Como planejar uma estratégia de automação de testes?

To design automation strategy in your project, first you need to analyse the feasibility of test automation in your project. To do feasibility, you do the following: Check the characteristics of your application such as how is the application behaving, is it stable, how is it performing etc. You need to analyse the resource requirements and cost associated with it. Cost of test automation such as time,efforts and budget required to develop,design and execute your automation scripts. You should check the skills of your team and see what all tools are fulfilling the demand of your automation testing. Create a list of all open sourced tools and licensed versions to get a clear picture on what can fulfill the automation requirements

Draw a square and make 4 quadrants Q1. Tech facing tests that drives development Q2. Biz facing tests that support the team Q3. Biz facing tests that critique the product Q4. Tech facing tests that critique the product Now try to retrofit Unit, Integrtaion, System, Acceptance, Perf, Security, DR, Accessibility Next step is targeting to automate tech facing tests (Q1 & Q4) then priority to Q2 followed by Q3) Then consider following factors while priotization intra quadrants 1. Frequency of execution 2. Complexity 3. Less Flaky 4. Subject to human error 5. Significant downtime/dependency with other systems between the tests 6. Low risk, stable and unlikely to change.

Testing can not be automated, however several parts in testing can be automated. The context build up here has an organisational tone to it. Others have added perspective for this already. From a learning perspective and taking pleasure in small wins, it's almost always feasible to start automating some pieces in testing to start with. Think along the way rather than just thinking about doing something about automation.

Define Goals: Set clear objectives. Choose Tools: Select appropriate automation tools. Prioritise Test Cases: Decide which to automate. Test Environment: Create a dedicated setup. Test Data: Ensure reliable data availability. Script Design: Develop maintainable scripts. Version Control: Use a VCS for script management. CI Integration: Integrate with CI/CD pipeline. Execution Criteria: Define when & how to run tests. Monitoring & Reporting: Track results effectively. Maintain & Update: Keep scripts up to date. Collaborate & Communicate: Foster teamwork. Data Management: Handle test data wisely. Review & Adapt: Regularly assess your strategy. Scalability: Plan for growth. Test Focus: Include regression, security, performance.

Prepare your 360 degree functional testing strategies first, then plan all of those to be executed automatically with respect to deployments without manual intervention. Then consider, Automation tool, Programming language, CI integration, regular execution, re-execution for failed scripts, automated report publishing.

This is essential; test automation must generate value and consistently define the objectives. If this is just an activity without any matter, we must reconsider the rest of our automation strategy. Please make sure to plan accordingly with your OKRs and customer outcomes.

Start small. Start somewhere. Start now. PS: This second line is to complete an unnecessary limit of 125 characters. Ignore.

While defining the objective of automation, the major stuff is regression testing. Because we are investing the resources like human and capital so we'll able to use it to save our time in future.

This is a very important aspect. One should set the clear expectations with the whole team and every stakeholder of what is (or is not) going to be achieved via Test Automation. And one should be careful about not starting or targeting to have lots of things in place in a short span. One should start with the most important things (the things which will provide the most value once automated), and then gradually build from there to add more things.

When it comes to selecting a tool, do think about these pointers: -> Who (Tech/Non-Tech/SDET, etc.) will create and maintain these automation test suites? -> What is getting automated - APIs/Web/Responsive/Desktop/Mobile apps? -> How complex are the test cases and business situations to be automated? -> What is the skill set/expertise within the team for creating and maintaining this test automation suite? -> Is this a new or an existing project where we have already done some automation? -> Is the test automation suite meant to be integrated with other tools like Test Management, bug tracking, CI/CD, etc.? The test automation suite is meant to be executed at what size? What is the budget and time duration required to complete this project?

In my opinion selection criteria should be based on following 1. Testing tool should compliment DEV Stack 2. Easy integration with defect mgmt tool, repo, CI tool 3. Supports low code practices for greater productivity 4. Can be easily integrated with cloud based execution platforms 5. Low curve for new joiners

As a learner in automation, rather than off-the-shelf tools, begin basic experiments in a programming language of choice. Don't learn programming as a by-product of learning automation.

I like what was mentioned above in that pick a programming language that the developers are already using. Any downtime they have can be spent helping with automation tests. Pick tools that the developers might already be using. Again, they can jump in when needed.

Here are some factors to consider: 1. Application Type (Web,Desktop,Mobile,PaaS,etc) 2. The tech stack of the application (some tools either don't support entirely or aren't that efficient with apps created with specific tech stack) 3. Teams Skillsets (low code or non-low code, which language based automation tech stack to use, etc can be decided based on this) 4. Software Development Approach (One should go for Cucumber or any other equivalent BDD implementation in the language chosen only if the BDD approach is being followed, otherwise it's an overhead) 5. Tool Budget (Paid v/s Free) 6. Integration with Test/Defect Management Tools 7. Integration with CI/CD Tools 8. Integration with Communication Tools (Email, Slack, Teams, etc)

Here are things to keep in mind when designing the framework: - Start with what you want to achieve while also having the scope for extensibility in future - Make it as modular as possible Design framework in such a way that if needed other teams/projects can re-use it easily. There should be as much de-coupling as possible between the test data and test scripts. - Make use of design patterns - Try not to violate SOLID principles - Ensure that the framework code is not against the clean coding practices as much as possible (use Linters to help you) - Have CI/CD support from the start (even though actual enablement is planned for later) - Use the latest libraries & language versions to reduce maintenance in the initial phase

Keep your framework simple and don't overengineer. What I typically see is that a lot of testers add a lot of abstractions to their framework to make it "future-proofed". Don't fall into this trap. Design your framework to your current needs. Don't abstract. Frameworks for software developers are typically abstracted because they tend to solve problems in different domains. A test automation framework doesn't need to do that. It is meant to automate an application or API. The problem you try to solve is always the same. In one sentence: Design your framework simple and make sure that it is easy to refactor. Minimize abstraction.

Don't force yourself into framework thinking when you start with automation. This results in poorly written code labeled as a framework, as it ticks various checkboxes. Learn programming and design in a proper way - once your coding patterns evolve, so will the framework. Don't shy away from deleting code which you think is bad. Refactor often. Respect external interfacing.

On one of my projects, a fellow developer and I implemented Test Driven Development, and the result was amazing in the first iteration! We have significantly reduced the development time for a feature due to the fact that the number of bugs has decreased. In addition, we began to conduct preliminary feature analytics in more detail in order to write decent test cases, and this also reduced the number of requests for improvements. A nice side effect was that we cross-reviewed the test cases so they were as ergonomic and useful as possible, easy to maintain, and a great way to onboard new employees.

As a beginner, this should have been the beginning. The thought of a framework before the script is expensive and a long-term goal, not a first thought. This would save you from a lot of effort spent on feasibility studies and what not, and get you started on the path of automation. Taking the first steps, even if wrong, is crucial.

More important than the test result itself is what produced that result. Assertions are the weakest part in tester's code in automation. A habit of being serious of putting appropriate and correct assertions helps in the long run in framework thinking. A result is not just a pass/fail outcome. There is much more information to be captured, before the game of numbers begins.

Plan to present profits: "What if your planned scenarios are automated completely? " "what is that you were doing without automation, which automation is now doing for you ?" I have seen many of such teams where they have done scripting for all cases needed and Jenkins jobs are executing them but what they are saving actually is unexplainable to them because they didn't plan to present the "data/numbers" (that too in dollars) to show SLT. If your efforts, this big effort is not hitting the bottom of their budget (in positive way) what actually is profit? Doing automation just for the sack of following fashion is harmful. Plan your "why" as part of strategy and showcase effectively when you achieve it.

Some things to consider: - How can we make our deployments fast and safe, how can automation support this? - Consider in your strategy what data, stubs and mocks you'll need, bake in asking for these as ACs to stories. - Not *everything* can be automated, so think about how you'd test these things too. - How will you get the results of testing back to the project / for audibility? What tools will you need?

It is important to consider revamping or rather upgrading your test beds , test data used in automation to get clear idea of pass percentage and kind of tests to be made obsolete. Revisiting the test data on a regular basis is good practice and helps uncover or add more use cases via automation Most important of all , good product knowledge is indispensable for writing automated tests . Generally we automation engineers ignore this aspect

By following these guidelines and continuously assessing and modifying your automation approach, you can create a robust and efficient framework for test automation that promotes quicker development cycles and higher-quality products. 1. Define objectives and scope. 2. Assess team readiness for automation. 3. Select the right automation tools. 4. Identify test cases for automation. 5. Plan test data generation or provisioning. 6. Design test automation architecture and framework. 7. Establish coding standards and naming conventions. 8. Implement version control for code management. 9. Integrate with CI/CD pipelines. 10. Create maintainable and readable test scripts.

My suggestion: Re-read this article with one change: Think who you are, in what context are you thinking about automation and in what context the suggested contents are written by various contributors like me. E.g. if you are looking at it from a manager's angle with an established framework already in place, ignore my content.