Advice for a new tester

I think everyone is aware that you may not know the system as well. They also probably know the coverage that their application is given and know deeply themselves that it is not well formulated and documented. They may just be using you to get the QA 'formalities' out of the way.

 

Obviously this isn't the way to go. For your career and integrity as a QA.

 

So what I would do is first is pound them with questions so you can understand the system. Be straightforward. For example "I'm flying blind testing this new feature. When you have a sec can you please walk me through ___" 

 

Second, *everyone* knows a new resource is an initial time investment. Kindly remind them if they want to pretend otherwise. Be straightforward. "I want to contribute some value to testing this application but I'd need some time learning the application." Just be upfront and state the truth - which is you can better contribute if you know more so they need to suck it up and teach you everything first. Just don't say anything cheesy like 'help me help you' or anything not really sincere haha...

 

Third, addressing the elephant in the room is a QA pre-req. So not having the comfort to do the above is a negative for a QA. Being comfortable with what you don't know makes a great QA. Being pigeon-holed and silo'd in any 'fear' of any form of bureaucracy is not an env a QA can thrive in. In reality if that is the culture of the company - then they are not ready for a real QA resource :P

 

 

 

 

We use TFS for managing test cases, work, tasks, etc. I think Jira/Atlassian has similar tools and such but I can't be sure. SmartBear has a tool called QA Complete that you can investigate.  You could simply document test cases in Word documents and/or Excel Spreadsheets and keep them on a file server somewhere.  Whatever system has to work for you.  Since you're the one tasked with setting up the system, you can pick what will work best.

 

As for getting started, I'd take a look at the materials available for the ISTQB Foundation Level tester.  That's probably the best material available out there.

 

Additionally... before you start thinking about automated testing, definitely work on manual testing strategies.  Honestly, too many companies, businesses, etc., try to replace manual testing with automation.  The truth is, automated testing will only do what you code it to do... it cannot, without a LOT of coding, "anticipate" stuff.  That's where you, as a human being, do the exploration, the "monkey testing", etc.  Document what you do, make test cases out of it, and then, once you have a decent body of manual testing documented, THAT'S when you start automating... because the BEST ROI for automated testing is to repeat what you've done at least once... regression testing.  Do the automation of the stuff you've already tested so that, as the application is developed, you can make sure that what used to work continues to work.

 

So, since you're an "Agile" shop, part of the "work" that you do before something is "done" is to test... YOU are the QA guy... YOU determine what needs to be tested.  You are the "person" who does it and who has that feed back.  Remember the manifesto: people over procedure.  So, if someone is asking you to test something, you determine what it is, when it gets done, how it gets done, etc.  Anything else is not Agile.