This is valid for all types of Testers/QA Analysts regardless of skill set and experience. The following 5 steps will help you get started on a project. This could be the first ever project you've worked on or it could be your tenth. It doesn't matter. If you join a new project team or are starting a new project within the same team then give these 5 steps a go.
1. Set up an individual contracting session with the project leader.
Establish the following:
- What you expect of the project leader
- What you are prepared to give
- What the project leader expects of you
- What the project leader is prepared to give
If you have the time, do this with every member of the project team.
Why do this?
Contracting establishes a fair working relationship and sets expectations between two individuals. It attempts to alleviate any assumptions and ambiguities which can often happen as a project moves forward.
2. Get the project team to agree on the following 'Hows':
- How will we define responsibilities?
- How often will we meet as a project team?
- How will we estimate our work?
- How will we keep each other in the loop?
- How do we manage last minute changes?
- How will we keep our issue tracking tool up to date?
- How are we going to review each iteration?
- How are we going to review the project?
- How are the test scripts reviewed?
- How are automated tests written and how are they reviewed?
- How will sign offs work?
- How will we manage bugs?
- How will we bond as a team?
- How will we mitigate risks?
- How will we know we have finished the Project?
- How will we be kept on schedule?
- How do we know we're working with the most up to date set of requirements?
Why do this?
There are so many unanswered questions when starting a new project. Its important to agree on how they will be dealt with as a team. Each project team can have its own way of working and the team needs to agree on what works best for them as a whole.
3. Set yourself realistic targets
Think about how you'll set yourself targets. They have to be both realistic and achievable. Do you work better with daily or weekly targets? Or do you have some other method of keeping track of your targets? Estimating is difficult but is the most important part of any project. Think about how you'll estimate for the following:
Test Planning which can include:
- talking to Business Analysts about the project requirements
- talking to Developers about what they have developed
- talking to Designers about mock ups
- writing test scripts
- reviewing other test scripts
- updating the regression suite
- prioritising order of tests
- working out dependencies
Test Execution which can include:
- running your scripts
- raising bugs
- retesting bug fixes
- reviewing automated tests
There will be times when something out of your control stops you from testing. How will you factor in time for this?
Why do this?
Planning takes time when you could be just getting on with stuff. However, putting time aside to plan effectively will allow you to be clear on what you can achieve on a daily basis and will help the project leader to estimate and schedule more effectively. This will keep you focused and will allow you to prioritise your work if there's not enough time to test everything, which is often the case.
4. Get yourself a test environment
Can you use an existing test environment or do you need a new one set up? How will you keep yourself aware of key project dates and how will these dates impact the environment you are testing on? How will you identify bugs that are caused by new code or by the environment itself? Is the environment reliable?
Why do this?
Testing on a developer's sandbox is not good. There is no change control and your environment will be constantly changing and will invalidate your tests. Testing on a test environment ensures that there is change control. If your changes are going live with the next release then you have to test in an environment which matches that release. If your changes are not going out in the next release then you don't necessarily need to test in an environment which matches that release.
5. Learn from other QA/ test team members
Probably the most important step. There is a wealth of project experience out there and this should be shared. This is not about the technical detail of the issues you came across. It's certainly not about name dropping. Let's just share some project level issues and explain how you dealt with them.
Why do this?
Sharing knowledge is good and healthy for all Testers/QA Analysts.
Describe the issue that you were faced with and then describe how you and your project team dealt with it. Here are some:
- I found that the project was going off in different directions and I didn't know where we were heading. I asked the project team to have daily stand up meetings and had to make sure this happened. We ended up setting daily targets and reviewing these each day.
- I wanted to know if anyone could give me any feedback to improve the way I worked on a Project. I pushed for regular retrospectives to highlight what we as a team, or as individuals, could do better next time.
- Managing multiple bugs and issues sometimes got messy. I started saving all my bugs on one spreadsheet that was colour coded and printable. These would be cut up and stuck on the board ready to be scheduled, this meant all the team were aware of the amount of bugs we had and discussions could be held them in stand ups
- I struggled for time to write test scripts when deadlines got tighter and the scope changed. This meant getting stressed and having to work after the cleaners had gone home. Start as you mean to go on...find out asap what will be going in each iteration and ensure you have enough time to realistically test it all. A small change may take a developer half a day but will mean 3 days of testing for you. Highlight this to the Project leader and if things are really not going well then maybe some extra resource could help, deadline can be renegioated or the scope readjusted.
- I got left out of some of the vital meetings. Make it known from the start that you want to be invited to everything....even if others feel it wouldn't be useful you may still be able to pick up something relevant to testing. If they still don't get the point and you see them creeping off then just follow them and find yourself a seat, they'll soon get the point!
- Hold your hands up to things you could have done better. I find that I received really useful feedback during and after a Project when I was forthcoming in admitting I would have rather done something another way. I also found that this encouraged others to reflect and change some of their habits.
- Always link your criteria to the test steps within a script. If you are strict with yourself to do this from the start it is much easier to refer back to what tests cover what. When writing a test script I always put the number of the criteria next to the relevant test step, then once the script is written I can use a simple filter on the spreadsheet to select all steps relevant to each criteria.
- I had to implement a new process that not everyone was happy about. I found that meeting on middle ground was the best way to get this new process rolling...instead of saying this is a new way we are going to do things I put forward the idea of doing a trial run for a couple of iterations and then reflecting on what worked well, what didn't, is it worth doing...etc. Surprisingly enough it wasn't as painful as some people thought and we had the chance to tailor it to meet the teams needs.
Please add your feedback and share your experiences.
