Soft Skill是QA重要的武器
之前在討論Sr. QA要具備什麼skill時, 除了要做code review之外, 我們也提到了soft skill的部份. RD通常要做什麼, 自己決定了就去做. 可是QA的部份不是這樣, 他必須要說服別人, 為何這個bugs 要解, 為何加這個feature或error handling 很重要, 他是需要別人去buy in他的想法. 因此這是為什麼說QA比RD還要難當的原因,
可是一說到soft skill, 大家就開始搖頭, 因為科技人對這個東西都不熟. 即使是貴為manager, 也並沒有特別高明到哪裡去, 主要是因為大部分科技業的manager, 一開始大多是因為技術不錯而升上去的, 所以在soft skill上其實還是有很大的落差.
在網路上找到一篇文章, 在描述一個好的QA, 應該具備有怎樣的特質, 這裡有很多是soft skills的部份, 值得大家參考一下.
Characteristics of a Tester
http://creativetesters678.blogspot.com/2008/07/characteristics-of-tester.html
1. Communication skills - oral and written
- It has to be conveyed in the correct way so that the person(s) sitting across the table is/are able to understand clearly.
- It is very important that any defect that is written by you has to be understood clearly by the receiving team.
- Be clear/ concise in your oral and written communication skills.
2. Critical eye
- Look out for any implicit or unstated requirements that need clarification from the clients.
- Always check for "what if " scenarios and get the answers. Think in multi dimensional way about a problem/requirement.
- Have a critical eye for minor details though others might think them as insignificant.
3. Do not assume things
- You should not assume any of the requirement / issues / problems / defects.
- Test the software from the end-user's perspective and not just compliance with the requirements given by the client.
- Never assume anything. It may not be true as you think!
4. Convincing skills
- It is a skill to convince and explain to a person who has developed the software as to why a defect report written is indeed a defect.
- Avoid using accusing words, do not get into any arguments and do not rise to any bait a developer may throw at you.
- Concentrate on the issue and not on the person.
-Develop good convincing skills!
(這時候QA要有sales的功力, 要能把bug這個產品, 讓RD/manager願意去購買(fix)它. 若是你這時候嫌棄顧客沒有錢, 或是沒有氣質, 或水準, 那你認為會有人要買嗎?)
5. Be factual
- While reporting a defect or clarification of a requirement, be as factual as possible.
- Do not bring in your own suggestions / views into picture.
- Do not use words that describe the type of work or the person who developed the software.
- Be a good reporter of facts!
(通常QA都會把問題形容的很誇張, 久了以後RD或是其他manager, 就會對我們的話開始打折扣)
6. Effective listening
- While discussing a defect report / requirement clarification, give a good hearing to other person's view or perspective.
- Understand the limitations of the software and try to find ways to resolve such issues.
- Be flexible whenever required!
(通常我們會不自覺地, 一直要求對方接受我們的意見, 而忘記去傾聽對方的問題, 或是難處在哪裡. 還會一直覺得對方很不受教, 不重視quality. 這反而會引起反效果. 若是能當個好的好的傾聽者, 以同理心方式來位對方設身處地來著想, 我想這樣會比較好溝通)
7. Provide constructive criticism
- While discussing any issues / defects / requirements clarifications with developer / business analyst do not use words that are pointing to their personal characteristics.
- Be very tactful in describing issues / defects and try not to point fingers at the person who developed the software or who collected the requirements for the software.
- Be empathetic
- Listen to the developer / the business analyst who developed / collected the requirements carefully.
- Try to understand the reality and limitations.
- Do not argue over trivial issues. Try to resolve limitations / issues in different possible ways.
- Develop good rapport with other teams, it helps!
(有時候RD會覺得QA的話很刺耳, 處處挑剔他們的毛病, 可是又說不出什麼可行的方法. QA自己也老是認為找問題才是主要的任務, 想解法是RD的責任. 我想雙方如果一直這樣下去, 問題是不會有任何progress. QA自己本身要學著提出建設性的批評,不只中性描述, 並且要能幫忙想出適當的可行性解法, 或是替代方案. 這樣才會讓事情有進展)
8. Effective follow up of issues
- Many a times, defects are written and deferred to next release. At the start of next release not all of them are picked up and fixed.
- The status of defects that are left out from previous releases need to be discussed at the beginning of every release with the business analyst / development team.
- Also, any issue that has not been converted to defect needs to have a closer follow up. This needs to be documented as Open issues at the end of the testing activity.
- Be good at follow-ups!
9. Good reviewer
- Be a good reviewer and look out for inconsistencies of implementation of a particular requirement across different sections.
- Review all user documentation apart from testing the software.
- Check out for inconsistencies in the description of the software, look for glossary and an index.
- This enables for easy search on topics of user's choice.
- Sharpen your reviewing skills!
Conclusion
As a tester you need special set of interpersonal skills more than the technical and functional skills.
More importantly patience should be there.
Make a start, be aware and practice.
之前在討論Sr. QA要具備什麼skill時, 除了要做code review之外, 我們也提到了soft skill的部份. RD通常要做什麼, 自己決定了就去做. 可是QA的部份不是這樣, 他必須要說服別人, 為何這個bugs 要解, 為何加這個feature或error handling 很重要, 他是需要別人去buy in他的想法. 因此這是為什麼說QA比RD還要難當的原因,
可是一說到soft skill, 大家就開始搖頭, 因為科技人對這個東西都不熟. 即使是貴為manager, 也並沒有特別高明到哪裡去, 主要是因為大部分科技業的manager, 一開始大多是因為技術不錯而升上去的, 所以在soft skill上其實還是有很大的落差.
在網路上找到一篇文章, 在描述一個好的QA, 應該具備有怎樣的特質, 這裡有很多是soft skills的部份, 值得大家參考一下.
Characteristics of a Tester
http://creativetesters678.blogspot.com/2008/07/characteristics-of-tester.html
1. Communication skills - oral and written
- It has to be conveyed in the correct way so that the person(s) sitting across the table is/are able to understand clearly.
- It is very important that any defect that is written by you has to be understood clearly by the receiving team.
- Be clear/ concise in your oral and written communication skills.
2. Critical eye
- Look out for any implicit or unstated requirements that need clarification from the clients.
- Always check for "what if " scenarios and get the answers. Think in multi dimensional way about a problem/requirement.
- Have a critical eye for minor details though others might think them as insignificant.
3. Do not assume things
- You should not assume any of the requirement / issues / problems / defects.
- Test the software from the end-user's perspective and not just compliance with the requirements given by the client.
- Never assume anything. It may not be true as you think!
4. Convincing skills
- It is a skill to convince and explain to a person who has developed the software as to why a defect report written is indeed a defect.
- Avoid using accusing words, do not get into any arguments and do not rise to any bait a developer may throw at you.
- Concentrate on the issue and not on the person.
-Develop good convincing skills!
(這時候QA要有sales的功力, 要能把bug這個產品, 讓RD/manager願意去購買(fix)它. 若是你這時候嫌棄顧客沒有錢, 或是沒有氣質, 或水準, 那你認為會有人要買嗎?)
5. Be factual
- While reporting a defect or clarification of a requirement, be as factual as possible.
- Do not bring in your own suggestions / views into picture.
- Do not use words that describe the type of work or the person who developed the software.
- Be a good reporter of facts!
(通常QA都會把問題形容的很誇張, 久了以後RD或是其他manager, 就會對我們的話開始打折扣)
6. Effective listening
- While discussing a defect report / requirement clarification, give a good hearing to other person's view or perspective.
- Understand the limitations of the software and try to find ways to resolve such issues.
- Be flexible whenever required!
(通常我們會不自覺地, 一直要求對方接受我們的意見, 而忘記去傾聽對方的問題, 或是難處在哪裡. 還會一直覺得對方很不受教, 不重視quality. 這反而會引起反效果. 若是能當個好的好的傾聽者, 以同理心方式來位對方設身處地來著想, 我想這樣會比較好溝通)
7. Provide constructive criticism
- While discussing any issues / defects / requirements clarifications with developer / business analyst do not use words that are pointing to their personal characteristics.
- Be very tactful in describing issues / defects and try not to point fingers at the person who developed the software or who collected the requirements for the software.
- Be empathetic
- Listen to the developer / the business analyst who developed / collected the requirements carefully.
- Try to understand the reality and limitations.
- Do not argue over trivial issues. Try to resolve limitations / issues in different possible ways.
- Develop good rapport with other teams, it helps!
(有時候RD會覺得QA的話很刺耳, 處處挑剔他們的毛病, 可是又說不出什麼可行的方法. QA自己也老是認為找問題才是主要的任務, 想解法是RD的責任. 我想雙方如果一直這樣下去, 問題是不會有任何progress. QA自己本身要學著提出建設性的批評,不只中性描述, 並且要能幫忙想出適當的可行性解法, 或是替代方案. 這樣才會讓事情有進展)
8. Effective follow up of issues
- Many a times, defects are written and deferred to next release. At the start of next release not all of them are picked up and fixed.
- The status of defects that are left out from previous releases need to be discussed at the beginning of every release with the business analyst / development team.
- Also, any issue that has not been converted to defect needs to have a closer follow up. This needs to be documented as Open issues at the end of the testing activity.
- Be good at follow-ups!
9. Good reviewer
- Be a good reviewer and look out for inconsistencies of implementation of a particular requirement across different sections.
- Review all user documentation apart from testing the software.
- Check out for inconsistencies in the description of the software, look for glossary and an index.
- This enables for easy search on topics of user's choice.
- Sharpen your reviewing skills!
Conclusion
As a tester you need special set of interpersonal skills more than the technical and functional skills.
More importantly patience should be there.
Make a start, be aware and practice.
