When I worked on military projects, on day one I would always be shown a project chain-of-command, detailing everyone on the project, their relationship to other roles, pecking-order, job title, responsibility.
In New Zealand, departments tend not to be quite as hierarchical, which can be both a good and bad thing. Good because employees are a lot more empowered than in other parts of the world, and there's no limit of “that's not your place”. Bad because sometimes things got missed and became “I thought you were doing that”, because no two departments did things the same way and so a lot of time everyone just assumed thing's be done the way they were on the last project they'd worked on … even though the team had worked on different prior projects (and so unspoken different expectations).
In some places it's even confusing when it comes to job title. Previously, I was senior tester for my department, and I'd hire "test managers" for projects who'd report to me. I would in turn report to another "test manager" for the whole company.
I decided to deal with this I'd need to write up a list of everything I could conceive we'd need to do for testing, and allocate them to positions – yes roles and responsibities 101. I also decided for simplicity that “manager” was overused, so maybe only the project manager should have this title …
The problem with smaller and newer companies is they might not have mapped out the needs of testing before. They might have previously used only developers or brought in contract staff. If you find yourself in this position, this is an ideal opportunity to take a real leadership role and set out some testing policy and practise. If you're an experienced tester, mentally touch upon every project you've been involved in, and just brainstorm and write all the things you need to happen to make testing succeed.
Here's my list of the key responsibilities within testing. Within New Zealand most of these are “up for grabs” with our looser structure and “all muck in” mentality, although I'm told in America people are much more rigid. Basically I feel someone should be clearly identified in your project to take responsibility each of these actions.
Mentoring of other staff
Not everyone is experienced in the challenges and limitations of testing. That there be a centre of knowledge which should be passed on where possible to more junior staff members, but also needs to be shared with other non-testing staff members such as project managers, developers, business analysts and market managers. This might just take the form of letting other members in the department know what is achievable or not within testing, as well as being the subject matter expert for testing.
Initial estimates for testing
Usually a project will be initially fleshed out by both business analysts and market management to address a business need or opportunity. Looking at the proposed solution, an initial estimate will need to be made of expected effort to test based upon experience of testing similar projects.
This is important, as these estimates will be used to define testing budget. Too small and you risk pushing the project over-budget. But too large and the cost of delivering this solution with testing might just kill the project as “too costly for the benefits it will bring”.
Secure testing budget
This is normally a project manager task, but important to testers, as you need to have this budget secured before you can get on and test. People generally like to be paid.
Resourcing of test staff
Whether staff come from within an organisation, or are brought in as contractors, someone needs to organise the resourcing of test staff. They need to have suitable start and end dates, and any access or permissions set up for when they start.
[As an ex-testing consultant/contract resource who is now bringing such people into his organisation, I pride myself in always having a login and security pass set-up for anyone we're bringing in for their first day. Something I'd often only get after week two.]
Managing delivery of software builds
As a tester it's very hard to test without software. It's got to be in a suitable state and delivered for testing to occur. This is one of those tasks I feel really fall on the project managers shoulder – they're responsible for managing the developers who're delivering this after all.
However it's possible those developers are external and might actually deliver the software via DVD or email “to the guy/gal in charge of testing”.
Organise test environments
Increasingly the software we develop isn't designed to work on just a standalone machine, but has some connection to a larger system. We need to ensure we have a test environment which is representative of the final production system we're going to be using. Someone has to take ownership of organising everything so the testing that occurs can be representative of the end production system. Perhaps you have an environments team in-house, and you just need to book a slot. Maybe you need to actually organise a test server with an external supplier … but someone needs to take charge of this and drive it.
Authoring
Testing has a number of documents which should be created and developed during testing – test strategy, test plans, test requirements, test scripts, test exit reports. Someone needs to write them, meaning ...
Reviewing
Pretty much every document produced by testing needs to be reviewed by those above or at least on a peer level. Otherwise you miss things. This includes test strategies, test plans, test requirements, test scripts, test exit reports …
Progress
You've brought in a contract tester and he's been sitting at his desk on his computer being very busy. But has he actually delivered value this week? Are you making progress?
Junior testers need to be keeping senior testers up to date of what they're achieving and just as important, anything which is slowing them down. The senior testers report up to the project manager. This is how the project knows the status of things withing testing - what's going well and what needs intervention and assistance.
Booking time
Remember that test budget? The more time you spend on testing, the more that budget gets used up. So it's kind of important that everyone on the project books their time at least every week, so the project manager knows where they stand on terms of budget used.
Execute test scripts
Yes indeed, someone has to actually run the tests you've planned. Maybe you've decided to go in more of a exploratory testing direction for test execution – in which you can perhaps reword this. But all the same, someone has to actually test the system.
Defects
If we're going to execute tests, we're likely to raise defects. These have a whole lifecycle of their own, they need to be raised, managed, reviewed (and possibly changed)
Potential test phases for a project
With all that set out, lets try and divide the work over a number of roles. For any project, there are likely to be a number of test phases. Typically they include,
- Hardware testing
- Unit testing
- System testing
- Acceptance testing
- Usability testing (if required)
Across all projects
- Resourcing of testing staff
- Mentoring in testing for project staff , managers and test resources
For a project
- Initial estimates for projects
- Authors test strategy document, including determining the types of test phases required
- Review testing plans from projects
Responsibilities for project (regarding testing)
- Management of delivery of software (and patches) for testing to occur
- Secure budget for testing
- Executing the agreed test strategy
- Reviews and feedbacks regarding
o Test Strategy and Plan
o Defects
Responsibilities for all test phases for a single project
- Authors high-level test plan for all phases (or delegates to Lead Tester)
- Coordinating between phases of testing – including getting weekly reports from Lead Testers
- Arrange organisation of test environment
- Records time against project through timesheet
- Reports progress to project manager
On some projects this role will not be required, or else duties delegated between project manager and Lead Tester.
Responsibilities for a single test phase of a project;
- Authors detailed test plan – based on Test Strategy Document. Includes revising initial estimates.
- Requests test environment
- Reports progress to Project Manager and Testing Chief (if available)
- Manages defects (assessment, communication, tracking, retest, closure)
- Authors and manages requirements for testing (review, enhance, assign) based on design and business requirements
- Review test scripts
- Authors test exit report
- Records time against project through timesheet
Responsibilities,
- Authors test scripts
- Execute test scripts
- Raises defects
- Retests defects
- Communicates new defects and issues to Project Manager, Lead Tester, Development in a timely manner, determined by defect severity.
- Reports progress to Lead Tester
- Records time against project through timesheet
These roles are pretty scalable to any size of project. If you have a small project needing only one tester, the Lead Tester and Tester role will both be taken by one person. The Testing Chief role will vanish, with those duties either taken by the project manager or Lead Tester.
The most important thing is though to have something like this written, and talk it through with your project manager. All the things on the list need to be done, but they are also to an extent negotiable. It doesn't so much matter who does each item, as long as it has an owner who knows they's supposed to be doing it.
No comments:
Post a Comment