Hi! I graduated from Informatics Engineering degree and right now looking for a job while brushing up my coding skills. Here found a lot of QA job vacancies and actually curious about what actually need to be learned. This is the job desc of Junior QA from the vacancies :
- Conduct preparation for SIT and UAT (prepare test plan/strategy, test scenario including negative and positive flow, test data, test environment, sign off, closure and all related documents)
- Liaise with relevant stakeholders (user and other CoE team member) for testing related activities
- Ensure testing activities is executed according timeline
- Ensure quality of delivered process (zero failure) based on defined requirement
- Actively monitor and report testing progress to stakeholders and defects/issues found during the execution of the automated test
How to prove that I can do all of this?
Top comments (2)
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!