0

You are assigned to a one time project that has few test cases, those test cases will not be repeated on other projects.

What would you suggest automation testing or manual testing? Why? Mention three points that will encourage you to automate tests for an application.

Improve this question
4
  • A question from some certification test? Interview?
    – Peter M. - stands for Monica
    Commented May 25, 2017 at 19:29
  • What is a one time project? Most projects build a product and then it takes off with a life of its own.
    – Niels van Reijmersdal
    Commented May 25, 2017 at 19:32
  • I had one-time projects to generate data for academic publication. Run the program few times to debug it, generate data, and forget it. Funny part is that as exercise, I decided to code the utilities/helper classes for such data manipulations as "test-first", with a great success.
    – Peter M. - stands for Monica
    Commented May 25, 2017 at 19:38
  • Also cross posted, please delete one. stackoverflow.com/questions/44188221/…
    – Niels van Reijmersdal
    Commented May 26, 2017 at 6:57

2 Answers 2

Reset to default
3

The problem with any project is that once it becomes a success you need to maintain it. Often this also leads to more funding and a lot of extra features. Now to stay ahead of competitors the product needs to iterate fast and release features every day or week. Test automation lets you do this.

You need test automation to:

  • let developers refactor safely which is essential to keeping the code-base clean and extendable. If the developers do not have the confidence to refactor, the code will become a mess. Manual tests are to slow to refactor in small steps, leading to big refactorings with lots of bugs and long test-dev-ping-pong-cycles.
  • trust in your product enough so you can continuously deploy automatically. Releasing often is key to staying ahead in a modern world.

Third, I would say humans make mistakes and take shortcuts, certainly with manual testing as it is at the end of the process. Most things on the end of the process are optional, certainly if they are boring. Manual testing at the end of the cycle is boring. If you practise TDD or BDD and test-first automation you might prevent most human issues here as well.

As an Agile tester and Agile coach, I would always advise to automate most if not all of the testing efforts. Sure you should critique the product manually with exploratory testing for example, but any testing that is repeated should be automated.

Also read these pages about technical excellence for a project.

Improve this answer
3

If test cases are repeatable in different project is irrelevant (they may have separate change, drift in different direction, etc).

What is relevant: How many times we can expect test to be ran repeatedly with no or little change. Unless you are sure you will repeat the test many times (dozens or hundreds), it is simpler to just perform test manually. Tests are code too: they need to be designed, debugged and maintained. Do not underestimate that work.

For tests which you will run just few dozen times, having a test as a text document interpreted by a thinking human is much easier: human can interpret errors in the script and notice changes which test script might ignore (unless specifically coded). Of course this does not scale well, but has very low startup cost, unlike coded automated tests.

Obligatory XKCD cartoons:

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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