There are threads about this in /r/QualityAssurance but the gist was for my job, I didn't need to prove any of that. Especially being just out of college. You won't know the paperwork involved until you get into a job and learn how they want traceability and planning done.
Sure, all that list will be things to do in a job. But fluff like following a timeline is as useful as "can work well in teams and independently". I'd easily say 99% of it is on the job since there aren't really structured QA curriculums. There are books and online study guides for QA cert exams, but that doesn't really make you a better person for the job (unless it's a trivia interview, I guess. "Boundry testing" is a fun phrase for that kind of tests)
Things to think about for job prep would be what to test. If there's an input field that takes a number, what happens if you give it a letter, an e (for exponent notation -- a lot of number fields accept it but hopefully the backend prevents it), a negative, a zero, a decimal, a stupidly large positive, and a smallish number (which should work). Maybe highlight some experience with having approached an assignment a different way than most people, since outside the box thinking is a good skill to have.
An actual code thing you can toy with is since you mentioned brushing up on coding skills, maybe look at unit testing and end-to-end testing your sample projects. Do a tutorial but treat it like a real product, mock out stuff and test just the little units of functionality but then also have a UI or API test that hits the thing as a user would. Then you can talk to how you've tested those things in interviews.
Thank you for your advice! Oh I forgot to mention that I actually managed to get an interview with the CTO and he tells me that being QA means more than testing, which shocked me because I always mention testing testing testing before that. Oh well more learning to do. Thank you Kayla!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are threads about this in /r/QualityAssurance but the gist was for my job, I didn't need to prove any of that. Especially being just out of college. You won't know the paperwork involved until you get into a job and learn how they want traceability and planning done.
Sure, all that list will be things to do in a job. But fluff like following a timeline is as useful as "can work well in teams and independently". I'd easily say 99% of it is on the job since there aren't really structured QA curriculums. There are books and online study guides for QA cert exams, but that doesn't really make you a better person for the job (unless it's a trivia interview, I guess. "Boundry testing" is a fun phrase for that kind of tests)
Things to think about for job prep would be what to test. If there's an input field that takes a number, what happens if you give it a letter, an e (for exponent notation -- a lot of number fields accept it but hopefully the backend prevents it), a negative, a zero, a decimal, a stupidly large positive, and a smallish number (which should work). Maybe highlight some experience with having approached an assignment a different way than most people, since outside the box thinking is a good skill to have.
An actual code thing you can toy with is since you mentioned brushing up on coding skills, maybe look at unit testing and end-to-end testing your sample projects. Do a tutorial but treat it like a real product, mock out stuff and test just the little units of functionality but then also have a UI or API test that hits the thing as a user would. Then you can talk to how you've tested those things in interviews.
Thank you for your advice! Oh I forgot to mention that I actually managed to get an interview with the CTO and he tells me that being QA means more than testing, which shocked me because I always mention testing testing testing before that. Oh well more learning to do. Thank you Kayla!