Quick Tips for the Testing Phase
From the The Money Files Blog
by Elizabeth Harrin
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts.
Written by Elizabeth Harrin from RebelsGuideToPM.com.
Recent Posts
The benefits process
Benefits brainstorm!
What to look for in project management software: Data privacy edition
Training teams on data privacy best practices
Data considerations for your project
Categories
accounting,
agile,
ai,
appraisals,
Artificial Intelligence,
audit,
Backlog,
Benchmarking,
benefits,
Benefits Management,
Benefits Realization,
Bias,
books,
budget,
Business Case,
business case,
Career Development,
Career Development,
carnival,
case study,
Change Management,
checklist,
collaboration tools,
Communication,
communication,
competition,
complex projects,
Conferences,
config management,
consultancy,
contingency,
contracts,
corporate finance,
Cost,
cost,
cost management,
credit crunch,
CRM,
data,
data security,
debate,
Decision Making,
delegating,
digite,
earned value,
Education,
Energy and Utilities,
Estimating,
events,
FAQ,
financial management,
forecasting,
future,
GDPR,
general,
Goals,
Governance,
green,
Human Resources PM,
Innovation,
insurance,
interviews,
it,
IT Project Management,
IT Strategy,
Knowledge Management,
Leadership,
Lessons Learned,
measuring performance,
Mentoring,
merger,
methods,
metrics,
multiple projects,
negotiating,
Networking,
news,
Olympics,
organization,
Organizational Culture,
outsourcing,
personal finance,
Planning,
pmi,
PMO,
portfolio management,
Portfolios (PPM),
presentations,
privacy policy,
process,
procurement,
productivity,
Program Management,
Programs (PMO),
project closure,
project data,
project delivery,
Project Success,
project testing,
prototyping,
qualifications,
Quality,
quality,
Quarterly Review,
records,
recruitment,
reports,
requirements,
research,
resilience,
resources,
Risk,
risk,
ROI,
salaries,
Scheduling,
Scope,
scope,
security,
small projects,
social media,
software,
Stakeholder,
stakeholders,
success factors,
supplier management,
team,
Teams,
Time,
timesheets,
tips,
training,
transparency,
trends,
value management,
vendors,
video,
virtual teams,
workflow
Date
I have lost count of the number of times my project testing phase has been squeezed. When you are up against a deadline, your carefully planned 3-rounds of testing with time for bug fixes and validation suddenly slide out the door.
And yet, no one wants to put out a product that hasn’t been robustly tested. That’s just asking for trouble from the customer. I know iterative methods allow for rounds of improvements, but they should be functional, incremental improvements, not fixing bugs you let slip through because the testing wasn’t good, or long, enough. That’s my view, anyway.
It is tricky to schedule time for testing, because you don’t know what you’ll find. Perhaps the solution is so brilliantly coded that nothing buggy will be found. (Ha!) I think this is where some of the pressure comes from: sometimes managers disconnected from the process of creating something new feel that as each component of the software works fine, together the whole will work just perfectly. “If the build has been good enough, there won’t be much to fix.” If only.
Testing goes beyond simply making sure the code is good enough. We test the processes, integration, training materials, communication approach and more. Here are 5 quick tips that I’ve picked up over the years for testing. Perhaps they will be helpful to you too.
1. Keep notes
I know, keeping a note of exactly what you pressed and what happened is boring. Users don’t always understand the rationale of following the script and noting down what happened. Detailed notes help other people replicate the error so they can see it, understand it and fix it.
Get into the habit of documenting everything. You’ll be grateful later.
2. Try to break it
This is the part of testing I enjoy the most! And it kind of contradicts with following the script – except you should have test scripts for trying to break the product too.
Encourage testers to do things in the wrong order, use the product incorrectly and see what happens. You need to make sure it is adequately developed to deal with those use cases ‘in the wild’ as well as for the users who have read the instruction manual!
3. Test with real users
Talking of users reading the instruction manual, ideally testing should be done with the involvement of users. I have been on projects where testing has been done by a professional test team, in our test lab. That was great. The level of detail and accuracy and information provided was awesome and elevated our confidence in the product. Testers are brilliant.
But you should also involve some end users. They may find the test process regimented and a bit difficult to get on with, but a little training should help with that. That community will provide a different insight into how the product works and can give you feedback on usability and process that a testing professional might not know, not being an expert in their job function with the wider business context around that.
4. Test what you can’t see
A lot of testing in my experience has been around what buttons do on the screen, functionality, do you get the data you expect. But when working with professional testers (as opposed to subject matter experts and team members we’ve drafted in to help check the software meets their requirements) they have always focused on what you can’t see as well.
Those are the non-functional requirements. Does it meet the company security guidelines? Is it fast? Can we back it up and do those back ups work? You should have non-functional requirements in the product spec or as use cases, so make sure the testing doesn’t overlook those.
5. Plan the testing
Finally, and I know it sounds obvious, but all of those things above should be in a test plan. Sometimes the test team has written this on my projects, sometimes I’ve had to write it (and probably didn’t do that great a job). But whatever you do, to whatever level of quality, the important thing is that a test plan exists so you have some idea of what is expected, who is going to do it, what you are looking for and how the test results will be fed back to the people who can make the improvements.
Make sure a test plan is included in your overall project plan, and if you aren’t sure how to put one together, get some support from people who have done it before.
I’m not a tester, so I’m sure there is more to it than what I’ve written above from the point of view of a project manager. What would you add? Leave a comment below to tell me!
Posted on: April 19, 2022 04:00 AM |
Permalink
Comments (7)
Please login or join to subscribe to this item
Tiago Romao
Project Manager - PfMP | PgMP | PMP | ACP | PBA | CBAP | CSM | MSc.| Altice Portugal | Meo
Sobreda, Setubal/Almada, Portugal
Hello,
Thanks for the tips. Would add
Put the test plan on the project repository accessible for everybody, involved, interested.
Put the test notes on the project repository, accessible for the people involved.
Report the progress with the frequency agreed.
Automate the tests (execution)
Tools such MSTeams and Confluence/Jira are becoming better to handle test phase.
Frank Einhorn
Dr| Independent Consultant
Johannesburg, South Africa
Many thanks for a useful article about a topic that should be discussed more.
My experience is that testing is difficult to plan, even if one adopts the valid suggestions made. We may have a good idea of the duration of each iteration, but it’s hard to estimate how many iterations it will take. Testing can also be disrupted if a particular problem holds up all the testing. We used to bring business people in at the end of systems testing (user acceptance test). Maybe this could be introduced in parallel, towards the end of system test?
I don’t see mention of automated regression testing (assuming that we are enhancing an existing system). That said, my experience has been that automating regression testing requires suitable software and technical skill, as well as being time consuming to set up and maintain. It will also not catch all the potential bugs introduced. Maybe that’s why it is not one of your tips.
Susanne Kaps
PM I| Hewlett Packard Enterprise
Bracknell, United Kingdom
The Test Plan is vital indeed and I think there needs to be more information out there of what a good plan should look like, as many times we've found that the roles and responsibilities were not defined of who will be testing what, the acceptance criteria was too high level and not enough time planned in to fix any issues.
My tip to every project manager is to get a good test manager into the project and let him carry out the test together with a test team. The test manager works like a second project manager in the project and forms a team with the project manager.
Stéphane Parent
Self Employed / Semi-retired| Leader Maker
Prince Edward Island, Canada
My tip for test leads is to never let the developer create the test scripts for their own work, not even the unit tests!
Great tips everyone! Thanks for sharing your suggestions.
Latha Thamma reddi
Sr Product and Portfolio Management (Automation Innovation)| DXC Technology
Mckinney, Tx, United States
Thanks for sharing your suggestions.
Please Login/Register to leave a comment.
|
"I choose a block of marble and chop off whatever I don't need."
- Rodin
|
