I've just started at a Web Development company that does websites/mobile apps. I've done QA for 5-6 years now and they wanted someone that had QA experience but wasn't set in their ways to be their QA lead for their new QA dept. (Which just consists of me).
In the past, the company had kinda taken an ad-hoc approach, no real standardized approach to collecting requirements etc... However, now they are doing a normal Scrum approach, tracking user stories in Jira (Which I think personally is a good start).
In my previous job, we had very strict requirements defined at the beginning of a project (Like a LOT of requirements) based off an FSD (Functional Spec Document). I would write my test cases based on these.
However, User Stories tend to be a little more generic and vague while still identifying the requirement.
What's the best process for really creating test cases/test plan based off of this. I feel like conventional test cases (IE: User clicks this button: Steps: Expected Result: etc...) seems a little...slow and cumbersome? and requires a lot of maintenance especially if things change?
Obviously automating everything is impossible...but is there like a halfway point maybe? My idea is to create acceptance tests based on the user story, I've read about cucumber and Gherkin...which seems cool because you can write a High-level Acceptance test that can be automated later. This kinda covers the Front Acceptance Test end while making automated tests later not be such a hassle.
Am I missing anything? I guess I wonder about all the "conventional" test cases...and if/when they are needed. After my experience with doing them and spending more hours than I'd like to admit writing STEPS/EXPECTED OUTCOME/Etc.... x10000 they just don't seem as needed...is this wrong? I just wanna make sure what I said doesn't sound....well stupid.