有人說若是QA早一點開始加入項目, 應(yīng)該可以幫助項目質(zhì)量變好, 可以幫忙厘清需求, 可以縮短
測試時間. 聽起來真的好處多多.
可是真的是這樣嗎? 我想以各位看倌多年的經(jīng)驗, 應(yīng)該會覺得不會這么容易. 是的, 是不容易, 但是原因是什么呢?
就我個人觀感第一個原因是mindset, 是的, 是mindset.
像我現(xiàn)在在run Agile, 如果大家對Agile有所認(rèn)識, 應(yīng)該知道Agile強調(diào)就是mindset的轉(zhuǎn)變, 如果心態(tài)沒有轉(zhuǎn)變成, 要因應(yīng)變化而積極作調(diào)整, 那你在執(zhí)行的任何practice都因而事倍功半, 最常見的就是便成mini waterfall. 因為我們只是把一個大的, 長的開發(fā)時程, 便成一個為期2 weeks 或4 weeks的小型項目. 事實上幫助會有限.
同樣的, 如果你認(rèn)為QA早一點進(jìn)去就會有幫助, 那同樣也是不切實際的. 因為這要work, 需要很多人的mindset都要改變, RD, QA, manager都要做修正.
在傳統(tǒng)開發(fā)流程時, 測試是最后一個階段, 因此QA養(yǎng)成一個習(xí)慣, 那就是需求要ready, design要ready, 程序要ready, 否則就無法開始. 因此不打破這個想法, QA早點進(jìn)去是沒有用的, 因為他會認(rèn)為這些東西都還沒有好, 他什么事也不能作. 所以還是得等到design or code ready, QA才會開始動作.
所以QA需要轉(zhuǎn)換做事的想法, 不要再認(rèn)為你只需要被動接受RD或是manager給你東西, 你需要真的積極加入, 自己去創(chuàng)造或是找出你要的東西. 也就是說早點跟manager討論需求, 和UI designer討論UI行為的運作, 和RD討論design的細(xì)節(jié), error handling的細(xì)節(jié)等等. QA是可以領(lǐng)導(dǎo)或是驅(qū)動項目的進(jìn)行, 而不是單純的被動接受者.
在開立測試個案時, 心態(tài)上也要和以前不同. 你的重點不是要去逮到RD的小辮子, 去沖高bug的數(shù)量. 你應(yīng)該要做的是和RD一國, 一起去提升軟件的質(zhì)量. 也就是說事前就要和RD再三確認(rèn), 是否你開的這些case, RD已經(jīng)加以考慮, 不管是細(xì)部功能的運作, 或是例外處理的部份, 都要一一確認(rèn)清楚. 如果這些東西一開始都設(shè)計進(jìn)去, 都考慮進(jìn)去, 之后就不會
有冗長的bug fixing時間. 需知道有很多bug通常, 都是因為事前沒有人說要考慮或是要處理, 導(dǎo)致于最后要花更多時間去修復(fù), 甚至還要在那邊討價還價. 若是這些事前能談清楚, 那將會節(jié)省之后很多時間的.
此外若是早點請RD review 過測試個案, 說不定可以知道有些測試個案可以不需要開立, 或是需要再加以補充. 像是有地方, 可能你開的case是在測到3 party或是別的team的code, 但是并沒有打到自己要測的部份, 像這些可能就可以不要測. 或者, 有時候因為QA對于實作細(xì)節(jié)不了解, 或是缺乏coding skill, 有些個案便會開不到, RD這時候的建議便可以幫助你補足你不夠的部份.
另外在設(shè)計測試自動化的時候, 更是需要和RD早點討論. 一方面可以讓他考慮testaability, 一方面你不會多走一些冤枉路. 有些QA因為怕麻煩RD, 獨立自行去開發(fā)測試程序, 或是來作performance
test program, 結(jié)果事后卻被RD指出, 有容易做到的方法, 或是這樣的行為可能和受測軟件架構(gòu)不同. 這時候啟不是很冤嗎?
當(dāng)然啦, 一個巴掌是拍不響的, 同樣的RD的心態(tài)也要轉(zhuǎn)變. 在設(shè)計時不要認(rèn)為QA聽不懂, 或是無法貢獻(xiàn)意見, 就不找他. 至少他加減聽的狀況下(注1), 當(dāng)你不完整的文件出來后, 他也比較容易看的懂. 當(dāng)然啦, 若是他也有coding的基礎(chǔ), 便可以很快知道你內(nèi)部運作的行為, 對于之后測試個案的開立, 或是bug trouble shooting, 會有很大的幫助.
(注1: 之前有post篇 "招募SDET來當(dāng)QA是必要的嗎? 正確的嗎?" , QA你能加強這篇所說的能力, 否則RD看不起你, 你的
工作也有可能被所謂的SDET所取代.)
另外當(dāng)QA找RD作test case review時, RD也不要認(rèn)為這跟你沒有什么關(guān)系, 你需要好好看看這些scenario你是否都已經(jīng)考慮到了, 你可以趁此機(jī)會和QA一起brainstorm, 找出是否需求面或是設(shè)計面上是否有考慮不足的地方, 我想這時候花時間, 讓之后你程序沒有bug,或是bug較少, 這不是件很劃算的事情嗎?
最后, 當(dāng)然是manager也要改變心態(tài), 需知道前面這些事情要發(fā)生, 要開花結(jié)果, 都是需要時間. 若是你缺乏耐心, 覺得怎么大家前面花的時間變長了, schedule怎么delay了, 因此而責(zé)怪, 責(zé)罵, 那只會讓這件事情毀掉而已. 這時候你需要的就是穩(wěn)住, 要信任大家, 也要讓大家信任你是愿意要這改變發(fā)生.
看到這里, 我想大家應(yīng)該了解, 不是單純讓QA早點加入就好, mindset也是同時要做轉(zhuǎn)變的.管理, 讓大家能夠真正以起合作.