Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
13 things your QA team wants you to know
1. 13 THINGS YOUR QA TEAM
WANTS YOU TO KNOW
by the team of qa on request
http://qaonrequest.com
2. Open communication between
stakeholders, developers and the QA
team is key to a successful software
project.
Constant communication is required for all parties
to be on the same page. It prevents
inefficiencies and frustration!
“
1
3. Testing should only begin once
the functionality and design of a
project have been finalized.
Otherwise some of our work
will be invalidated as the project evolves.
“
2
4. Up to date project documentation
is needed to understand how
features are supposed to work
and prevent invalid issues.
It saves us time and saves you money.
“
3
5. Plan some time for exploratory
testing.
While test plans are important, exploratory testing always yields
important issues that may impact the quality and value of your product.
“
4
6. Meetings are expensive and take
us away from what we should be
doing as testers.
Use them wisely and with a plan.
“
5
7. Testing provides important
quality related information to
help you make good business
decisions.
Use this information to assist you in your decisions.
“
6
8. Embrace all bug reports.
You want to have as much information
as possible and then decide what to fix.
“
7
9. Use both Severity and Priority in
your bug tracker.
Having severity and priority is helpful because
an issue might be minor in terms of severity
but critical in terms of business priority.
“
8
10. 1 product =
1 project in your bug tracker.
Enough said.
“
9
11. Custom statuses can be very
confusing for external team
members.
Consider sticking to the default statuses for more efficiency.
New -> In progress -> Resolved -> Closed is enough.
“
10
12. Nobody uses Internet Explorer 8
or BlackBerrys anymore.
The benefits of supporting them are slim to none.
Spend your time and money on other platforms.
“
11
13. Don't rush publication.
An extra day or two of testing can make a big difference
in your users’ perception of the application or site.
“
12
14. Don’t make changes to the code
until the very last minute.
New issues may be introduced during the final rush.
It is best to enforce a "code freeze” prior to the final round of testing.
“
13