Test case optimization involves achieving a maximum test coverage with the minimum number of test cases.
This may involve using various test techniques such as:

1. Equivalence Partitioning
2. Boundary value Analysis
3. Genetic Algorithms

There are two strategies when it comes down to writing reusable test cases:

• Modularization

Modularization is a function-based method of test design where testers categorize functionality to be tested into reusable modules. Testers break down test caes into logical, manageable functions, or modules. These modules are isolated to create independent tests that can then be recombined or reused to make larger master test cases to achieve complex end-to-end testing scenarios.

source: https://dzone.com/articles/adopt-a-modular-approach-to-test-case-design-in-ji

• Parameterization

Parameterization is when you replace hard-coded input values that are hard to change with paramters. Test parameterization allows you to use modules to run the same test over and over again using different values, making it easy to share modules between multiple test cases.

source: https://dzone.com/articles/adopt-a-modular-approach-to-test-case-design-in-ji

Many things could go wrong when a new feature or functionality is being developed. It may turn out that the business may change their mind and this feature will be no longer needed. If tests are being automated while the feature is also being developed then the tests may need to be updated many times. Automation tests should be developed only when the build is stable i.e. after sanity tests have been performed.

Once the automated test is created, it is then added to the regression test suite to be run as next features are being developed.

Note that the test automation process is exactly the same as the test process.
This means that test cases will be selected for automation and test scripts will be created during the test design activity. And those tests will be executed during the test execution activity.

When

As per the Test Process (STLC), test cases are developed during the Test Design activity. Once all the requirements have been gathered, analysed and the test cases have been developed. This is exactly the time to decide on which test cases to be automated.

How

Not all test cases will be automated. The following criteria will be used in determining which test cases to be automated:

1. Features/Functionalities or flows that are critical to business.
2. Tests that need to be run repeatedly e.g. smoke, sanity and regression tests.
3. Tests that need to run against multiple configurations — different OS & Browser combinations.
4. Tests that execute the same workflow but use different data for its inputs for each test run e.g. data-driven.
5. Tests that involve entering large volumes of data i.e. very tedious
6. Tests that can be used for performance testing.
7. Tests that take a long time to perform i.e. complex test cases that may take overnight or days.

Simply put, automated testing is the automatic execution of tests and comparing expected and actual results without testers having to manually perform them.

Continuous integration is a software development practice where developers regularly merge their code changes into the central repository (VCS). This activity triggers automated builds and tests to be run. The goal is to find bugs earlier, improve software quality and reduce time to validate and release new software updates.

Continuous delivery automates the entire software release process. Continuous delivery expands upon continuous integration by deploying all code changes to a testing environment and/or a production environment (only with approval) after the build stage.

Continuous Deployment – Very similar to Continuous delivery but there is an automatic deployment to production environment without any approval.

Continuous Testing is the process of executing automated tests as part of the software delivery pipeline in order to obtain feedback on the business risks associated with a software release candidate as rapidly as possible

DevOps is a set of practices that combines the processes that are normally carried out by two different teams i.e. software development and IT (operations) teams. The purpose of the DevOps is to build, test and release software faster and more reliably.

1. One fundamental practice is to perform very frequent but small updates. This makes each deployment less risky as teams can easily identify the last deployment that caused the error leading to quicker defect resolution.
2. Organizations might also use a microservices architecture to make their applications more flexible and enable quicker innovation. This architecture reduces the coordination overhead of updating applications, and when each service is paired with small, agile teams who take ownership of each service, organizations can move more quickly.
3. Continuous integration and continuous delivery allow organisations deliver rapidly in a safe and reliable manner.
4. Version control – Version control is the practice of managing code in versions, tracking revisions and change history to make code easy to review and recover.
5. Communication and collaboration by adopting agile software development approach.
6. Infrastructure as code – this is a practice to configure and manage physical and virtual machines programmatically. Engineers can interface with infrastructure using code-based tools and treat infrastructure in a manner similar to how they treat application code. This helps to keep infrastructure resources responsive to frequent changes
7. Continuous monitoring – This practice involves monitoring the health and performance of the application and the infrastructure. The purpose of this practice is to mitigate issues proactively and identify any process improvements. This can be achieved by creating and setting up meaningful alerts and collect various data usually through monitoring tools like Nagios.

Agile scrum is an iterative and incremental software development model. This means that they are building smaller blocks of software and involve stakeholders for earlier feedbacks/reviews. This means that they can reduce the delivery time as well as ensure a high customer satisfaction due to higher software quality. There is no lengthy documentation process which adds to quicker delivery.
If there are any changes to the requirements especially during the testing phase, it will be quicker and cheaper to implement the change in agile scrum. The changes can be easily incorporated into the next sprint or the current sprint if it is a high priority item.
The development team (scrum) is more collaborative and because they are involved from the planning stage, the team is more comfortable with the estimation of the tasks that they are working on, thus increasing the likelihood of delivering the software on time compared to waterfall model. This is because the team was not involved in the planning and estimation phase and some of the risks were not thought of by the Dev and QA lead at the time.

For scrum, there is a fixed sprint length of 1 – 4 weeks but on the other hand, kanban aims to achieve continuous flow i.e. there is no set time. This also means that at the end of the sprint, a scrum team would have developed a working software that could be shipped. For kanban, there is no predetermined release dates.
There are also 3 prescribed roles in scrum (scrum master, product owner and scrum team) whereas in kanban there are none.
For scrum, the team tries to not change the scope of the sprint unless there has been a feedback from the stakeholder(s) that what they are working on is wrong or not as important. Compared to scrum, the kanban workflow is very flexible to changes i.e. any new work can be added in.

Scrum master – Most similar to a project manager in other software development model, scrum master is responsible for supporting the development team, clearing organizational roadblocks, facilitate scrum team meetings and check in with the team and ensuring that the tasks are completed on time.
Product owner – Product owner represents the stakeholders of the project. Product owner understands the customer requirements and has a sense of vision/direction of the end product. Product owner is responsible for various things such as backlog management, release management (when to release the product) as well as ensuring that the product being developed satisfies the customer.
Development Team – Usually consists of BAs, developers, QAs.