Feedback – I have seen that word literally raise a brick wall between 2 or more individuals and I am thinking both parties the one giving/receiving need to think about what is the actual purpose of feedback.
Feedback – information about reactions to a product, a person’s performance of a task, etc. which is used as a basis for improvement.
Case study 1.
I requested a QA tester to peer review my test scripts created for manual testing. After a day she came back to me informally and mentioned she had noticed something that might need attention. I was using a word that was grammatically incorrect for the description of the step and she would like me to update it. When I asked what word she would like me to replace it with I was informed I needed to sort that out.
Case study 2.
I received a email from a stakeholder who did not understand the release documentation. After a discussion it made aware the language was too technical and they required a simpler format. I rewrote a portion and resubmitted it for their review to ensure I had understood the business requirements. They accepted with update with some minor adjustments.
Both are real life examples of feedback and I’m sure you can see out of the two which was more effective than the other. With effective feedback it needs to provide reasons (which may not be obvious to the other party) about why XYZ isn’t working/suitable/just don’t like it so there is an exchange of knowledge.
Day 12 – ‘What test documentation does your team have? How can you improve it?’
I am very keen on Agile methodology about documentation where it looks at applying the following principals:
- Just enough
- It depends
- It’s up to the team
If it’s a new system, there may need to be more documentation over a simple modification to an existing robust system. Or if the team is split on/off shore which may add to communication issues over a team that sits together on site.
What may result from too much documentation? Outdated documents are still referenced to but never updated or the iteration is slowed down as resources are spent documenting inside of producing what the business needs.
Transversely when there is not enough documentation is may display in misunderstanding of the requirements or products are not being accepted by the PO at the showcase meeting. These a just a couple of ways too much or too little documentation affects SDLC.
There are a few things to consider as a team when deciding on how much is enough:
- Resourcing > if your writing documentation then you’re not writing code
- Well written User Stories that define specifically the requirements of the business
- Whose role is it to document it? Should it be the business, development or technical team?
- User Requirements include post-development specification
- Team agrees on archive time
- Team agrees on when we document the system at the beginning or during the cycle. Either way it’s a living document which should be updated when needed – who’s role is that?
- Who is going to be accessing this? Development team possible it will all be in code or the business then it might need to be stored in a collaborative platform like SharePoint or Confluence
‘Learn to use a tool your developers use’
I have set up on my home computer the following:
- GitHub account
You might ask why am I doing this? Simple in one word ‘Portfolio’. I would like to provide future stakeholders with a snap shot of what and how I test. Hopefully this might stop the questions I had asked in a phone interview by the Lead Tester. Is regression and re-testing the same? I was caught off balance and very confused by someone asking such a fundamental question that if I didn’t know clearly the difference I wouldn’t hire me as a test resource. Needless to say, the interview stage didn’t go any further which I was grateful for but my estimation of this company suffered and I won’t apply for any future opportunities with them. Once I get this completed I will upload it here.
Yay for free tools thank you to all the developers/testers before me.