QA != Tester — Which mindset should QA have? (มายด์เซทแบบไหนที่ QA ควรมี) — EN/TH
English version
When I was in my fourth year, I had the wrong mindset that I would apply for a QA job to be a bug hunter. However, after my interview ended, I realized that indeed QA wasn’t a bug hunter but the person who prevented a bug! I have to say thank you to my interviewer, who gave me this feedback after the interview, and this made me understand more about QA’s work.
Even though I understood the concept of what QA does, I felt this was the only thing I knew if I didn’t learn from the real project, feel pain, and get real experience. As such, after attending ThoughtWorks University, I could see why we should put more time and effort into preventing bugs at the beginning rather than finding a bug at the end after finishing the code or developing each feature.
To illustrate, I will give an example from my real experience during my training (It is the project simulation for trainees to learn from the real project implementation not the project from the real client).
QA received a defect from the PO that her technical team could detect a security issue, in which users’ passwords are stored as plain text in the database.
This defect was a high priority, which should be solved quickly, and of course it was easy to solve…..but! wait…the point is this feature (Register/Login) had already deployed to the production!
This meant even if we encrypted passwords from new users and stored them in the database and implemented authentication encryption, which allowed new users were able to log in, we still got a problem, which was existing users couldn’t log in to the website anyway.
Luckily, it was a happy ending at last, but I will skip talking about this part since it is out of scope hahaha.
Come back to the QA mindset. Why do I have to give this example? How can we as a QA help to prevent this kind of issue or make it happen at least as possible?
The answer is… what if QA told this to the developer before they started coding this Register/Login feature?
‘ I thought this acceptance criteria should have users’ passwords stored as encryption.’
Could you see the clear picture? The developer would implement an encryption password at the beginning before deploying it to other environments until production, and we no longer received this kind of security issue or solved the defect that made us waste our time developing other features.
After we understand why “ Prevent a bug more than Finding a bug ”,
the question is what QA should work to achieve the ‘ Prevent a bug goal ’?
The answer is we have to be a QA who works in Agile world.
To make it clearer, see the picture below.
We can see QA can work at the initial stage like the analysis phase. QA can pair with BA to check if there is anything that can be added to the acceptance criteria to make sure there will be no future bugs or issues, as the example of writing ‘encrypted passwords storage’ in the acceptance criteria, which allows developers can code based on it.
This is why QA isn’t a tester because not only does it find a bug we also analyze it to see the whole view and know what is a big hole, which can have a negative impact on our team later. By doing so, we can prevent those issues early.
Apart from that, QA can also pair with the developer in the development phase to check whether test cases in unit tests or functional tests are covered enough or not.
Lastly, I would like to give my lesson learned from training at ThoughtWorks University about QA responsibility as follows.
Quality analyst → Do we know the right things?
That is we have to always ask ourselves what we should do to ensure every product or software will be delivered to the client or user’s hands with the best quality.
เวอร์ชั่นไทย
ต้องบอกไว้ก่อนเลยว่า ช่วงเป็นนักศึกษาปี 4 ระหว่างสมัครงานตำแหน่ง QA เราก็เคยมี mindset แบบผิดๆ ว่าเราจะสมัครงานไปเพื่อเป็นนักหาบั๊ก แต่เมื่อการสัมภาษณ์งานจบ เราถึงค่อยๆเริ่มเปลี่ยนความคิดว่า แท้จริงแล้ว QA ไม่ใช่นักหาบั๊ก แต่เป็นคนที่ช่วยไม่ให้เกิดบั๊กต่างหากล่ะ! ทั้งนี้ทั้งนั้น ต้องขอบคุณพี่ๆที่ให้ฟีดแบ๊คหลังสัมภาษณ์ ที่ทำให้เด็ก(ใกล้จะ)จบใหม่(ณ เวลานั้น) เข้าใจการทำงานของ QA มากขึ้น
แต่ถึงจะเข้าใจว่า QA คือคนที่ช่วยไม่ให้เกิดบั๊กมากกว่าเป็นคนหาบั๊กก็ตาม เราก็ยังรู้สึกเหมือนว่าจะเข้าใจแค่คอนเซปต์ ถ้าไม่ได้ลองไปเจอในหน้างานจริง เจ็บจริง และเรียนรู้จากประสบการณ์จริง ทีนี้แหละ…พอเราได้เข้าไปเทรนที่ ThoughtWorks University ก็ได้เข้าใจแบบแจ่มแจ้งเลยว่า ทำไมเราควรใช้เวลาและความพยายามไปกับการกันบั๊กไม่ให้เกิดตั้งแต่ต้นน้ำมากกว่าไปหาบั๊กที่ปลายน้ำ ตอนที่เราโค้ดดิ้งหรือ develop ฟีเจอร์นั้นๆเสร็จแล้ว
เพื่อให้เห็นภาพมากขึ้น เราอยากจะยกตัวอย่างประสบการณ์ที่เราเจอระหว่างเทรนนิ่ง (ต้องบอกก่อนว่าเป็นโปรเจคจำลองที่สร้างมาเพื่อให้ Trainees ลองฝึกทำโปรเจคจริง และเรียนรู้การทำงานแบบ Agile ไม่ใช้โปรเจคจากลูกค้าจริงๆนะจ๊ะ)
QA ได้รับ defect มาจาก PO ว่าทาง Technical team ของเขาตรวจพบเจอ security issue ที่ password ของผู้ใช้งานถูกเก็บไว้เป็น Plain text ใน database
ฟังดูแล้วเป็น defect ที่จัดอยู่ใน high prioirty เชียวล่ะ นั่นก็คือควรได้รับการแก้ไขอย่างทันที! แต่ถ้าถามว่าหาวิธีแก้ไขปัญหานี้ยากมั้ย ก็ตอบได้ว่า ‘ไม่ยาก’ หรอก (Developer ยิ้มหวาน)….แต่! เดี๋ยวก่อน ประเด็นคือ ฟีเจอร์นี้ (Register/Login) ได้ deploy ไปไว้ที่ production แล้วนี้สิ!
นั่นก็คือ ต่อให้เราทำการ encrypt password ของผู้ใช้งานใหม่เก็บไว้ใน database แล้วทำการ authentication encryption ที่ช่วยให้ผู้ใช้งานใหม่สามารถ login เข้าเว็บไซต์ได้ เราก็ยังมีปัญหาตรงที่ผู้ใช้งานเก่าที่ password เก็บไว้ในรูปแบบ Plain text จะไม่สามารถ login เข้าเว็บไซต์ได้…
แต่อย่างไรก็ตาม ผลสรุปของปัญหานี้ก็จบลงด้วยดี หลังจากที่หาทางแก้ไขปัญหามาได้สักพัก แต่เราจะข้ามประเด็นนี้ไป เพราะไม่ได้อยู่ในขอบเขตของบทความครั้งนี้ 555
วกกลับมาที่ QA mindset ทำไมเราถึงยกตัวอย่างนี้มา แล้ว QA อย่างเราจะช่วยให้ปัญหาเหล่านี้ไม่เกิดขึ้น หรือเกิดขึ้นน้อยที่สุดได้อย่างไร?
คำตอบก็คือ เราลองจินตนาการว่า ก่อนที่ Developer จะลงมือโค้ดฟีเจอร์ Register/Login นี้ เราในฐานะ QA ได้ไปบอกกับทีมทั้ง BA กับ Developer ว่า
‘เราคิดว่า Acceptance criteria นี้ password ของผู้ใช้งานควรจะเก็บแบบ encryption ไว้ด้วยนะ’
พอเห็นภาพมั้ยคะ ทีนี้ Developer ก็จะโค้ดดิ้งด้วยการเก็บ password แบบ encryption ไว้แต่แรก ก่อนที่ฟีเจอร์นี้จะ Deploy ไป environment อื่นๆ จนกระทั่ง deploy ไป production ในลำดับสุดท้าย ซึ่งจะทำให้เราไม่ต้องได้รับ security issue ในภายหลัง จนต้องมานั่งแก้ defect ทำให้เสียเวลาพัฒนาฟีเจอร์อื่น ๆ อีก
ทีนี้หลังจากที่เราเข้าใจแล้วว่าทำไม
“ Prevent a bug more than Finding a bug ”
คำถามคือ แล้วเราในฐานะ QA ควรจะทำงานอย่างไร? ที่จะทำให้เราบรรลุเป้าหมาย
‘ Prevent a bug ’
คำตอบคือ เราต้องเป็น QA ที่ทำงานแบบ Agile นั่นเอง
เพื่อให้เข้าใจมากขึ้นลองดูตามรูปข้างล่างนี้เลย
เราจะเห็นได้ว่า QA สามารถเริ่มทำงานได้ตั้งแต่ขั้น Analysis เลย นั่นก็คือ pair กับ BA เพื่อเช็คดูว่ามีส่วนไหนสามารถเพิ่มเติมใน Acceptance criteria ได้ ที่จะทำให้แน่ใจจะว่าไม่เกิดบั๊กหรือ issue ในอนาคต อย่างที่ยกตัวอย่างว่าให้เขียน Password ต้องเก็บแบบ encryption ไว้ใน Acceptance criteria โดยที่ Developer ก็จะโค้ดตาม Acceptance criteria เหล่านี้
ซึ่งนี่เป็นสาเหตุว่าทำไม QA ถึงไม่ใช่ Tester เพราะเราไม่ใช่นักหาบั๊กเพียงเท่านั้น แต่เรายังใช้การวิเคราะห์ เพื่อมองภาพรวมแบบกว้าง ๆ แล้วรู้ว่าจุดไหนที่อาจเป็นช่องโหว่ย้อนกลับมาทำลายเรากับทีมทีหลัง ก็ให้อุดช่องโหว่นั้นไว้ตั้งแต่เนิ่น ๆ
นอกจากนี้ QA สามารถ pair กับ Developer ในขั้นตอน Development ด้วยเช่นกัน เพื่อช่วยดูว่า test case ใน unit test หรือ functional test นั้นคลอบคลุมเพียงพอหรือไม่
สุดท้ายนี้ ขอฝากสิ่งที่เราได้เรียนรู้มาจากการเทรนนิ่งที่ ThoughtWorks University เกี่ยวกับหน้าที่ของ QA ตามนี้
Quality analyst → Do we know the right things?
นั่นก็คือเราต้องถามคำถามกับตัวเองเสมอ ๆ ว่า เราอะไรที่เราควรจะทำ เพื่อให้ product หรือ software ส่งถึงมือลูกค้าหรือผู้ใช้งานได้มีคุณภาพ (Quality) มากที่สุด
