Tech Tuesday-Harness the Power of Effective Resource Planning with OnePlan’s ...
Business awareness of testers and the quality of testing
1. Hier soll der Titel reinTest Organisation State of the Art
www.qs-tag.de
Organizer: imbus AG
www.qs-tag.de
Business awareness of testers and the
quality of testing
Karolina Zmitrowicz
Quale Magazine
5. To be a good tester
You need to know the discipline
Knowledge of development process
Knowledge of testing proces
Practical knowledge about test techniques
Experience in using tools supporting testing
Anything else?
6. To be a good tester
Your role can be considered as a
bridge between the business and the
development
You work with people:
Analysts
Developers
Customers
End users
You work with people representing
different background, knowledge,
sometimes culture
7. To be a good tester
Where are you on this picture?
8. To be a good tester
What else do you need?
Processes, techniques and tools are not enough
Working with people requires special skills
Therefore, the next step to be a good tester is gathering soft skills:
Communication
Negotiation
Patience
Understanding
9. To be a good tester
Test proces, techniques, tools + soft skills = ?
It is still not enough
You are responsible for providing objective information about the test object.
To be able to do it, you need to understand the object.
11. Why this topic?
Consider the following „typical” requirements
I want a cat.
The cat should have 4 legs, 2 eyes and 2 ears.
The cat should be provided in 2 weeks
12. Why this topic?
What features would you test for?
Why do you want to test it like that?
13. Why this topic?
What design based on these requirements could
development offer?
There are many options like:
15. Why this topic?
Coming back to our requirments…
The cat after development and some reworks coming from your feedback…
16. Why this topic?
Now, let’s assume that the customer has
specific requirements and wanted a cat
like this…
It seems you didn’t build the right
product…
19. Conclusion
How many of you are „cat experts”?
• Collect requirements
• Validate requirements
• Design the right product
• Test for the right product
You need to know the „domain” to be able to
20. The only thing more expensive than
writing software is writing bad
software
Douglas Adams
21. Business knowledge and testing
Your responsibility as a tester is not only to simply execute test cases
You also design tests and plan their execution
Because of this, you need to understand what are you going to test:
• You need to understand requirements
• You need to „see” the business context of the system and the whole project
• You need to understand the purpose of the products and its impact on testing
22. Ok, you may say – requirements
should clearly say what to test
23. Business knowledge and testing
The problem is:
The requirements are often poorly documented
The requirements are often missing
The requirements are often inconsistent
The second problem is that to claim requirements as not good, you must know the
business area
In other case, how can you know that you are testing „the right cat”?
The system should be usable
The system should be fast
24. Let me tell you a story
Once upon a time…
There was a test team in charge of testing a banking application
The problem was they had
no idea about banking…
25. Let me tell you a story
Their internal testing was very successful… no serious bugs!!
Then they came to the customer … and things changed
26. Let me tell you a story
Results:
Branch and till balancing not working correctly
Branch reporting not working correctly
Devices not working as supposed
Transactions taking too long
Business rules… what business rules???
Should it
balance??
Since when?!
Oh… does it
matter?
It looks
different than
the
simulators….
27. Let me tell you a story
Solution:
Involving the customer in testing
Working close with business analysts from the bank to
clarify requirements
Detailing all requirements documents
Updating almost all test cases and test scenarios
Total delay – 6 months
Additional cost – 30%
29. What can you do?
Get involved in requirements review and acceptance
QA signoff should be the „must have”
30. What can you do?
Improve the proces
Ask analysts for a presentation explaining the goals and vision of the product
31. What can you do?
Check the product/business in a real life
Apply field observation/interviews
Get familiar with similar products
Wath the users
32. What can you do?
Collaborate and cooperate
Work with the business representatives, users, analysts to clarify requirements, goals of
the product and its application
Apply some agile practices:
Demo
Inspect and adapt
33. What can you do?
Collaborate and cooperate
Ask business representatives, users, analysts to review your test cases
Are they complete?
Are they right?
Do they cover risks?
34. What can you do?
Read
ISTQB syllabi do not help. They explain the test proces and techniques only.
Sorry guys!
Read:
Domain standards
Business proces documentation
Business publications
Documentation of similar products
Regulations
35. What can you do?
Don’t be afraid to ask
There's no such thing as a stupid question
The art and science of asking questions is the source of all knowledge
Thomas Berger
36. Why should you do it?
Benefits for the organization:
Increased understanding of the project goals and customer’s expectation
Specialized test personnel
Focusing on
development of
the right product
Lean testing.
Better test
planing. No
waste!
Support for
change impact
analysis
Lowering project
risk – you are
building the
right product
Customer
satisfaction
Increased
realibility of the
IT company as a
solution provider
37. Why should you do it?
Benefits for you:
Self-development
Increased reliability of your professional judgement
Expertise
Ability to not only verify the product, but to validate it as well