feature_image_what_is_QA_and_responsibility
feature_image_what_is_QA_and_responsibility

เคยสงสัยกันมั้ยว่า QA ทําหน้าที่อะไรใน Software Development Cycle เรามาเพื่อจิ้มๆๆ กดๆๆโปรแกรมที่ถูกพัฒนาขึ้นมาจาก Dev. จริงหรอ? แล้วเราต้องเป็นพลเมืองชั้นสองของเวลาทํางานจริงหรอ? เราต้องนั่ง test โปรแกรมที่เมื่อ Dev. เสร็จเท่านั้น ก่อนหน้านั้นก็นั่งรอไปหรอ? นั่งกดโปรแกรมจนดึกดื่นไปเรื่อยๆ เวลาแก้ไขที ต้องมานั่งกดกันจนมือหงิกหรอ?

ไม่ใช่เลยน่ะ งาน QA ไม่ใช่งานไร้สาระอะไรแบบนั้น QA ย่อมาจากคําว่า Quality Assurance ซึ่งมันก็บอกน่ะ คือเราเน้นเรื่องคุณภาพ เราสนใจที่ quality ล้วนๆเลย การมีเราอยู่เพื่อให้ผลลัพธ์ของ software ที่เราผลิต ส่งออกไปให้ได้ดีที่สุด 🙂

แล้วจริงๆแล้ว QA คือใคร?

ถ้าเปรียบการ software development team เป็นกีฬาฟุตบอลน่ะ QA น่ะเปรียบเสมือน กองกลาง นั้นแหละ เราเปรียบเสมือนกองกลางตัวจ่าย คืออยู่เป็นจุดศูนย์กลางคอย รับ และ รุก ให้กับทีม เวลาบอลรุก เราก็คอยจ่ายบอลให้กองหน้าสนับสนุน Dev. ในแง่มุมที่ไม่ใช้แค่เรื่อง functional ส่วน เวลารับเราก็คอยรวบรวมข้อมูลในแง่มุมที่มันไม่ควรเข้าทีม และให้ได้ quality ที่ดีที่สุด (กองหลังกับผู้รักษาประตู คงเป็น Automation test บน CI นั้นแหละ ที่คอยป้องกันระบบอีกที)

ทําไมเปรียบงั้นล่ะ?

ในฐานะที่เคยเป็น Dev. มาก่อน แล้วจึงย้ายมาเป็น QA จึงทําให้รู้หลายๆอย่าง เช่น Mindset ของคนทั้งสองฝั่งไม่เหมือนกันเลยจริงๆ สิ่งที่ Dev. สนใจคือ เรื่องของ Functional ถ้าใน Jira มันเขียนไว้ว่า “ให้กดปุ่ม A แล้วจะได้ผลลัพธ์ B” Dev. ก็จะสนใจแค่นั้นจริงๆ ถ้าดีหน่อยส่วนใหญ่จะสนเรื่องของการทํา Performance tuning ในระบบมากกว่า เช่น เราใช้ Pattern ในการเขียนแบบไหน? Factory? Command? Chain? แล้วได้ผลลัพธ์ที่ Manage ง่ายรึเปล่า?

แต่ในทางกลับกัน QA. เมื่อมี features “ให้กดปุ่ม A แล้วจะได้ผลลัพธ์ B” มันกลับต้องคิดมากกว่านั้นเยอะมากๆ เช่น ถ้ากดปุ่ม A แล้วผลลัพธ์เป็น B มันจะมีผลกระทบกับ ระบบ C ที่อยู่หลัง B และความเร็วของการ response จาก C ไปเพื่อให้เกิดผลลัพธ์ B เป็นเท่าไร? ด้วยความเร็วขนาดนี้จะ impact ลูกค้ามั้ย? แล้วการกดปุ่ม A ได้ผลลัพธ์ B นี้มันควรอยู่ในนี้มั้ย? หรือจริงๆแล้ว การจะได้ผลลัพธ์ B ควรจะไปกดจาก D เอา? หรือทําไมเราต้องกดปุ่ม A เพื่อให้ได้ B ล่ะ? ทําไมกดปุ่ม E แล้วได้ B ไม่ได้?

อย่างที่บอก QA ไม่ใช่เรื่องง่าย…. ไม่ใช่แค่คิด test cases แล้วจิ้มๆไปให้ได้ผลลัพธ์ แล้วไปกรอกข้อมูลลง excel แล้วส่งให้ลูกค้าดูว่ามันผ่านไม่ผ่าน ด้วยแง่มุมของความคิดแบบนี้จะช่วยให้เราสามารถรักษา quality ได้ ไม่ใช่แค่ทํา features สําเร็จ

QA ต้องมีสกิลไรบ้าง?

จริงๆส่วนลึกก็ยังคิดว่าคนที่เป็น QA ควรจะเป็น Dev. มาก่อนน่ะ 🙂 เพราะว่าคนที่จะเป็น QA ที่ดีได้เนี่ย ภาระค่อนข้างหนักอยู่เลย เพราะสิ่งที่ QA ต้องมีน่ะ มันมีตั้งแต่เรื่องของ

  1. Technology Skills
    • Programming Basic นี้ต้องได้อะ ต้องไล่โค้ดเป็น เขียนโค้ดได้ ทํา automation scripts ได้ ไม่งั้นจะให้เรา manual ทุกอย่าง รับรองตาย และหมดไฟไปก่อนแน่ๆ
    • แปลว่าไร? แปลว่าเราต้องเข้าใจถึง Git, Jenkins/TeamCity หรือ Programming Pattern บางตัวเลยด้วยซํ้าเพื่อที่จะเวลาคุยกับ Dev. จะได้เข้าใจ (สาย Dev. จะมี Pattern คืออธิบายได้ไม่เก่งอยู่ล่ะด้วย)
  2. Business Mindset
    • อย่างที่รู้อ่ะน่ะ Software ที่เราทําออกไปเพื่อให้ลูกค้าใช้ ให้ลูกค้าใช้เพราะเราอยากได้ Margin เราอยากได้ Margin เยอะๆ เพราะเราอยากได้โบนัส 4 เดือนเป็นต้น! ประเด็นเรื่องที่อยากพูดคือ เราต้องรู้ว่า features ที่เราทําเนี่ย ทําเพื่ออะไร? และจะได้ผลลัพธ์อะไรกลับมา? ในบางส่วนที่เราทํางานอยู่เนี่ย มันต้องรู้กระทั่งว่า Business Logic ที่ทําให้เราได้เงินคืออะไร?
    • ถ้าเราไม่มีหัว Business หรือ ไม่เข้าใจ Logic ของรายได้ที่จะเกิดขึ้น หรือมองภาพรวมของระบบไม่ออก เราก็จะไม่สามารถ quality ที่ควรจะเป็นของระบบได้
    • เช่น ถ้าเราเป็น QA ที่ดูและระบบคิดเงินของ software ร้านอาหารแห่งหนึ่ง แต่เราไม่เข้าใจของ Business Model ของร้านอาหาร แล้วเราจะเข้าใจได้ไงว่า Quality ที่ดีที่สุด ที่เราจะส่งมอบให้กับ ร้านอาาหรนั้นๆได้ ควรจะเป็นยังไง
    • เราต้องมองภาพรวมของธุรกิจให้ออก เข้าใจคู่แข่งด้วยยิ่งดี และถึงจะเข้าใจระบบได้ง่าย
  3. People Skills
    • QA เป็นงานที่ต้องเข้าถึงคนเยอะกว่า Dev. มาก
    • เช่น สมมุติระบบ A ที่สร้างขึ้นมาเป็นตัวกลางเรื่องคิดเงิน ลองคิดดูสิว่ามันจะต่อกับ Microservices ตัวไหนอีกบ้าง (ระบบบัญชี ระบบสต๊อค ระบบจาก front-end บลาๆๆ) ด้วยการที่มันต่อมากมายหลายระบบ แปลว่าเราต้องเข้าไปคุยกับอีกหลายคน ต้องไปเรียน Business อีกหลากหลายส่วน
    • เพราะฉะนั้นการพูด การสรุป การอธิบายต้องเป็น ภาษาก็ต้องพอได้เลยล่ะ

เห็นมั้ยว่า QA ที่ดีน่ะ ต้องการ Skills หลากหลายอย่างมาก ไม่ใช่แค่ไปนั่งโง่ๆคิด test cases โดยการกดๆๆบนหน้าจอของ Application นั้นๆน่ะ

นี้ยังไม่รวมถึงการเข้าไปช่วยคิดเรื่องการทํา automation test อีกน่ะ …. เช่นการช่วยวาง flow ของ automation เราจะเขียน automation เพื่อจัดการ regression test ยังไง หรือ จะทํา performance ยังไงให้มันลื่นไหลที่สุด 🙂

Technology Skills พื้นฐานที่ QA ควรจะมี

สิ่งหลักๆที่ QA ต้องทําเป็นชีวิตจิตใจเลยน่ะ คือการ investigate และ provide concern กับ Dev. เพราะฉะนั้นอย่างแรกของ investigate เนี่ย สิ่งที่เราต้องมีเลยก็

  1. Database Skills (SQL,Stored Procedure)
  2. Unix Skills (Unix 101, VIM ของเล่นใกล้ตัว QA)
  3. Automaion Framework Skills (ถ้าฮิตๆตอนนี้ก็ Robot Framework 101, Specflow, Appium 101) หรือ ถ้าเป็นพวก Performance ก็ Postman, Gatling, jMeter  ไม่ก็น้อยสุดอย่างน้อยก็เขียนโปรแกรมเป็นบ้างก็ดีครัช
  4. Trend Technolgy (Jenkins, GIT, CI, CD, docker, etc แต่อาจจะไม่ต้องลงลึก)

QA มีกี่แบบ?

โดยปกติเวลาเราทํางาน QA จริงๆก็แบ่งเหมือน Developer นั้นแหละ จะแบ่งเป็น

  1. QA Front End
  2. QA Back End

เพื่อทําหน้าที่ในการรับผิดชอบในจุดต่างๆกัน ซึ่งทั้งสองส่วนก็มีความสนุกแตกต่างกันไป ความใส่ใจในส่วนของการทํางานก็จะแตกต่างกันไปเป็นจุดๆลงไปด้วยเหมือนกัน เช่น

ถ้าเป็นเรื่องของ Technology น่ะ แน่นอนเลย QA Front End ก็คงจะไม่พ้น Selenium นั้นเอง โดยอาจจะมี tools น่ารักๆเข้ามาช่วยในการทําเยอะแยะไปหมดเช่น Robot Framework  หรืออื่นๆๆอีกมากมาย ที่เหล่า QA นิยมใช้กัน

ซึ่งถ้าถามใครๆก็จะเข้าใจหมดแหละว่า QA จะใช้เทคโนโลยีแค่นี้ แต่จะไม่มีใครนึกถึงเรื่องของการจัดการด้าน Backend แน่ๆ ซึ่งถ้าจะให้หลักๆเลยของ QA Backend ก็คือ Postman, Gatling, jMeter ซึ่งหลักๆที่ใช้เลยก็คือเรื่องของการส่งข้อมูลผ่าน Protocol ไปมา (แน่สิก็ Backend นิ :))

QA ทํางานยังไง?

จริงๆแล้วเราไม่ใช่พวกปลายนํ้าน่ะ! ไม่ใช่ว่ารอทุกคนทํางานเสร็จก่อน Dev. เสร็จแล้วโยนงานมาให้เรากดๆๆๆๆทั้งวันทั้งคืนน่ะ 🙂

สมมุติน่ะเราทํางานใน scrum ทีม ซึ่งมี 6-7 คนได้ ทีนี้เวลาเราทํางานน่ะ QA จะเฉิดฉายที่สุดตอน Grooming เนี่ยแหละ 🙂 เพราะจะเป็นจุดที่เราจะ provide concern of features ต่างๆๆก่อนเริ่ม sprint planning นั้นแหละ เพราะเวลา planning ที่จะให้ Points/hours กัน จะทําให้เราต้องเตือนเหล่า Dev. ว่า อย่าลืม test ด้วย…. แล้วจะ test แบบไหน? Performance testing จําเป็นมั้ย? test data จะเป็นยังไง ที่จะต้องเตรียม? จุดนี้ควรจะมีใน sprint นี้หรือไม่ หรือ ควรจะไม่เข้าทีมเพราะจะผิดหลัก single responsibility principle !!!

แล้วหลังจากนั้นผ่าน Grooming ไป สิ่งที่เราทําก็ไม่มากล่ะ เราก็ไปตกลงกันภายในทีม หรือ test architecture ต่างๆว่าจะทํายังไง บ้างที่ PO ก็อยากได้เป็น ATDD บางที่ก็อยากได้ BDD แล้วก็รวมกับ jenkins flow ยังไง บลาๆๆไป

ที่เหลือเราก็แค่เขียน automation scripts ตาม cases ที่เราคิดขึ้นมาเพื่อ verify business logic นั้นเอง 🙂 หรือบางทีถ้าอัตตาส่วนของ Dev ต่อ QA สูงมากๆอย่าง 5:1 แปลว่าเราจะไม่สามารถ test ได้ทันแน่ๆๆ เราก็จะตกลงกันว่า test เป็นส่วนนึงที่ Dev. ต้องเขียนน่ะ แล้วเราจะ provide business rules ให้เช่น feature files ใน specflow นั้นเอง แล้วให้ Dev. implement ตาม features file นั้นๆ (ถ้าบางที่ไม่ทํางั้นก็เขียน scripts เองทั้งหมดเลยล่ะ ชิวๆ)

สรุปแล้ว QA คือ

กองกลางตัวจ่าย 😀 ช่วยเหลือทีม ค่อยคิดจัดการในแง่ของ Business perspective, Functional และ Non Functional ทั้งหลาย ตลอดไปถึง investigate, analytical thinking ในแต่ละ microservices ต่างๆ

มองในอีกแง่มุมนึง มันก็สนุกไปอีกแบบไม่เหมือน Developer น่ะ 🙂

 

 

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.