What usually works best for me, mainly in small test teams with tight schedules, is developing test automation and manual testing together.
You start by testing exploratory in a not-very-scripted way as a way to learn the product, as you go you start taking notes and build a more scripted approach (or at least more organized).
At the same time you start ...
There is no specific rule for it, as the eventual decision (manual test first or automation script) boils down to the situation. As a guideline for software testing services, one can say that for a newly feature, the manual tests comes first, even before the development happens. This is in accordance with TDD. These tests usually act as metric for the ...
In testign everything is context depended . Its hard to suggest merits and demerits unless you states the following things like :
What methodology you work in (Agile or waterfall ?)
What is your sprint length
How much time you gets for testing
What is your responsibility ( Is it only manual , is it automation or is it both)
What is the Team size
What is the ...
There's no one answer to this. It's highly dependent on the context in which you are working.
For example, I've worked in fields with varying degrees of regulation, where traceability from requirement and change through test case execution is vital. In these cases, having a test case documented in a test case management tool and selecting appropriate test ...
I don't use any tooling for this, just a combination of the following:
reading testing materials (blogs, books, ...)
reading job ads for testing positions
participating in testing communities (locally in my country, here)
following some other testers on LinkedIn and reading what they share about testing
reading (and learning) about what devs, devops, ... ...