I have created a test case that was created via automation. The testing type for this Test case is Automated. Now I make some changes to the steps of this Test case by adding some more or removing some. This will create a new version of the Test case. The question is what should be the testing Type of this new version as the original was created via automation and the new version was edited manually to create a version.

  • 4
    Why does it matter? What does the testing type mean to you or your organization?
    – Mate Mrše
    Commented Oct 28, 2020 at 10:32
  • As Mate said, it's highly contextual. A written test case is only a communication tool - and how to communicate with other people will depend on your and other people preferred ways of talking to each other. Commented Oct 28, 2020 at 11:20

2 Answers 2


It depends.

Some of the factors I would consider are:

  • If the new version of the test case will primarily be executed by automation, the type should probably be Automated.
  • If the new version of the test case will primarily be executed manually, the type should probably be Manual.
  • If the new version of the test case is going to be executed both manually and by automation, and your tool has an option of "Manual and Automated" for test type, that should probably be the choice.
  • If your organization has a policy that requires any test case executed by automation to be labeled as an Automated test case, then test type should be Automated.

Factors I don't consider relevant:

  • Whether the test case was generated automatically or manually. How a test case is created matters less than how it is executed, which in turn matters less than the results it reports.
  • Whether the test case was edited. What matters about the edit is that it is either tied to a version of your product - which happens if you are working with desktop software and need to maintain different versions for your customers because you may need to run the old version if a customer is receiving an update to an older version (such as a patch fix for a serious bug) - or is tied to a feature update or other change. If the edit was simply improving the flow or the stability of the test then it doesn't matter that it was edited.

In short, if the information saved with the test case accurately describes its purpose and execution, then it does what it needs to.


This is almost certainly going to depend on your team's or organization's process.

Some teams and organizations that I have worked with require that new or modified test cases be executed manually before the automation results can be accepted. That is, the series of test steps are documented as a test case, the test case is executed manually, and if it passes, the test is scheduled for automation. Once it is automated, the results are acceptable.

Sometimes, teams and organizations require a review of the changes. Once the test case and associated automation code or scripts are updated, the automation is run in a way that can be observed by a human. This can be capturing screenshots or watching in real-time as the test scripts interact with the application. A code review of the automation code and the observation of the way the code interacts with the application is sufficient to call the test case automated.

Other times, teams may opt to deprecate test cases and create new ones, especially if the changes are significant. This may help with tracing test executions to test cases via a unique identifier. It would be up to the team or organization to define what it means to make significant changes to a test case.

Without knowing the valid "testing types" for a test case, what those testing types mean, and the context in which the organization works, it's difficult to say what you should do.

Not the answer you're looking for? Browse other questions tagged or ask your own question.