QA job Starting new process
Im starting a new QA position with a web based app.
I will need to start a new QA process there the co has never had one. Any suggestions? I will also be looking into bug tracking software and testing tools again any suggestions?
Well friend you can find n number of Test management software and automation tools in web.
you have to choose the best one suits you depends on the cost factor.
Refer below link posted by
Admin sometime back.
This might help. It's a checklist I used as I was entering my current position:
All Things Quality: QA Leader's Checklist
For test management, I would suggest you to have a look at 'Squash'. It is an open source tool, easy to set up and can be linked with "Mantis" for defect tracking
A few thoughts from someone in the same position (I'm the only tester at this point)
- Initially, anything you do will be better than the nothing that's already there. You can use the first few months to learn the company's internal systems and existing processes (because even if not documented, they WILL exist).
- Once you have an idea of how things are already working, you want the testing and QA process to be as seamless and trouble-free as possible. To that end, if you can find an open source bug tracking tool that integrates seamlessly with the developer environment, you'd probably want to choose that over one that doesn't.
- Similarly, if you can find a test management tool that integrates with the developer environment and bug tracking tool, you'll want to use that rather than an alternative.
- Be prepared to evangelize. It's not uncommon in companies that have never had any kind of dedicated testing process to find that developers don't unit test - or that the code they're working with isn't unit testable. This is where you show the value you can add to their work either by building unit tests around what is unit testable or by pointing them to references that will offer suggestions to make their job easier. After all, when they try to track down the bugs you find, if their application is a big ball of spaghetti code they'll find it horribly frustrating.
- Initially, don't worry too much about automation. You'll be spending at least the first three months getting to know the application and the company's internal processes. This introduction time frame will also give you an idea where the most fragile parts of the application are, where the most used modules are, and where you should ultimately target automation (I'm "there" right now - over at SQA Stack Exchange I posted this question test design - Good strategy for automated regression where initial state can't be guaranteed or predicted - Software Quality Assurance & Testing Stack Exchange - and this is after 6 months or thereabouts of working with the application and the dev team, including chasing through the application code to work out just which config flag is causing me problems this time)
- You probably don't need me to tell you this, but even when things get frustrating, remember the dev team are your allies. We're all in this to produce a good quality product that does what our customers want it to do and meets their needs (even when we think their needs are insane!).