對標蘋果的靈動島 華為帶來實況窗功能
繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據今天鴻蒙OS 4.0的現場演示顯示，華為的實況窗可以更高效的展現出實時通知，比如鎖屏上就能看到外賣、打車、銀行
作者 | 劉冉
當前業界對于軟件測試和質量相關的討論非常廣泛，各種不同的聲音此起彼伏。其中包括質疑測試人員的必要性、去測試人員化、強調測試技術化和工程化、探討測試與質量的協同作用、討論敏捷測試、持續測試以及全程自動化測試等等。
這些討論表明，測試工作和專業測試人員已經陷入一個廣泛而深入的漩渦中。
然而，只要一個項目追求高質量，就需要實施大量系統化的專業測試和質量工作。這些大量系統化的測試與質量工作需要專業知識的人員來完成。
盡管一些互聯網公司或某些項目聲稱在沒有專業QA的情況下成功交付，但這是建立在特定前提條件下的。例如：
然而，對于追求高質量的項目，如果業務和開發人員沒有測試與質量相關的專業技能，或者業務和開發人員沒有時間或不愿意進行測試與質量相關的工作，那么團隊就需要專業的QA來幫助解決這些約束條件。
在項目交付過程中，主要的參與人員通常包括項目經理（PM）、用戶體驗設計師（UX）、業務分析師（BA）、開發人員（DEV）、質量保證人員（QA）等核心角色。在某些特殊項目中，還可能會涉及到其他角色如DevOps等。
敏捷測試和質量內建方法論決定了團隊中每個角色都對質量負有責任。然而，具體到實際的交付工作中，每個角色都有其專業性和側重點。例如，某些專業技能（如測試分析與設計、性能測試等）在短時間內其他角色很難學習和掌握，甚至他們可能不愿意學習；而某些具體工作（如編寫測試用例、執行測試、編寫自動化測試等）可能是其他角色不愿意承擔的。
在團隊協作中，合理分配任務和角色的專業性是至關重要的。每個角色應發揮其專業技能，以確保交付的質量和可靠性。通過充分利用各個角色的專長，可以實現協同合作和有效的交付過程。團隊成員應相互理解和尊重彼此的專業領域，并在合適的情況下進行協作和知識分享，以提高整體交付質量。
如果一個項目希望建立良好的團隊氛圍并提高產出，每個角色都應愿意并能夠高效地運用自己所掌握的技能。然而，不同的技能都需要足夠的時間來學習和磨練，因此一個角色很難有效地掌握大量不同角色所需的技能。
畢竟，大家的時間都是有限的，一般人都會在不同技能之間做出權衡。并且每個人應專注于自己的領域，并在該領域內精益求精。通過發揮各個角色的專業性，團隊能夠形成互補，從而提高整體的效能和成果。團隊成員應該相互支持和合作，尊重彼此的專業領域，并在需要時進行知識共享和協作。
對于QA這個角色來說，我們很多項目都在嘗試減少或去掉QA，因為這些項目滿足之前提到的條件。然而，如果一個項目不符合這些條件，我建議一定要配備專業的QA人員。
根據團隊成員的能力、項目類型、規模和質量要求的不同，需要的QA人員的能力級別和數量會有所變化。
考慮到問題的復雜性，我們可以簡化條件，以一個中等規模的團隊（約10-20人）、全新開發的保險項目為例。該項目無法在交付前進行線上真實用戶測試，質量要求高，開發周期為1年，需求在開發過程中持續確定并略有變化。項目涉及各種角色，包括項目經理（PM）、產品負責人（PO）、用戶體驗設計師（UX）、業務分析師（BA）、開發人員（DEV）和質量保證人員（QA）。其中，QA角色至少需要一名高級QA或領導級QA，其他QA可以是普通級別的。
在這樣的約束條件下，如果希望QA能夠全面實施敏捷測試和質量內建的相關工作，包括高覆蓋率的功能自動化測試，QA與Dev的比例應大致為1:3。隨著比例的減少，即QA資源的減少，相關工作的內容也需要相應減少，或由其他角色承擔。可減少的工作包括全面深入的探索性測試、性能測試、安全測試以及一些不重要的自動化測試開發等。
當比例達到大約1:5時，就達到了自動化功能測試的極限。隨著比例進一步減少，自動化功能測試的開發工作也將減少。當比例降至1:10時，QA人員幾乎沒有時間來進行自動化功能測試，因為常規測試和與質量相關的工作已占據了絕大部分時間。基本上所有自動化功能測試相關的工作都需要由開發人員來實施。然而，某些特定測試如性能測試仍需要QA人員來執行，盡管只能實施主要的性能測試用例，無法全面執行全量的性能測試。（以上比例是基于多年工作經驗總結得出的）
日常工作中，主要且工作量最大的任務包括測試策略和測試架構的設計和實施、測試流程的實施和管理、測試分析與測試設計、測試用例的執行（包括手動和自動化）。對于大型團隊，還需要為團隊提供測試賦能，甚至建立質量體系。其中我們共同編寫的《Thoughtworks 質量體系白皮書》以及我寫的《Thoughtworks的敏捷測試實踐》都非常全面地介紹了敏捷團隊中QA所需的技能和日常的工作內容）
對于一個以復雜度為主的業務系統，如果團隊沒有足夠的人力資源來實施自動化測試，可以考慮引入外部資源來執行手動功能測試。然而，測試分析和測試設計的工作通常需要由內部員工來完成。在一般團隊中，最好由QA承擔該角色，也可以由具備相同能力的BA和DEV來擔任。例如，在某大型通信廠商中，許多項目的測試分析和測試用例設計工作由高級系統工程師完成，而不是測試與質量人員。
如果更改這些限制條件，需要對QA人員的比例進行一定的調整，但是最重要的是項目的質量要求。只要項目的質量要求高，就必須擁有足夠的時間和專業工作來進行測試和質量相關的工作，最好是由專業的QA人員來實施。如果沒有專業的QA人員，則需要具備足夠專業技能的其他角色兼職，但是兼職的這個人其實就是一個QA。
在沒有專門的QA部門但實施敏捷測試的公司中，培養初級QA人員一直是一個重要的挑戰。由于沒有獨立的QA團隊，每個QA成員分散在不同的團隊中工作。如果這些QA已經具備足夠的專業技能和獨立工作能力，他們通常能夠很好地完成任務。然而，對于初級QA人員來說，他們往往缺乏足夠的專業技能和獨立工作的能力。這樣的工作環境常常使他們感到沮喪和面臨困境，甚至可能放棄從事QA工作。
如果我們能夠對這些初級QA人員進行全面系統化的持續專業技能培訓、工作方法指導以及解答困惑，就能極大地降低他們面臨的阻力和困惑，并給予他們完成工作所需的足夠能力和信心。
要實現這樣的培訓和持續指導，需要建立一個部門的概念來負責執行。例如，設立一個虛擬的QA部門，由該部門統一實施培訓，并由公司內部經驗最豐富的QA人員擔任講師。此外，除了系統化的培訓，QA人員的成長還需要專業人士提供持續的輔導和幫助，并進行職業生涯規劃。
這項工作的重要性直接影響著QA人員的發展和職業生涯，甚至有可能改變對QA工作的看法，從而讓原本打算放棄的QA人員喜歡上這份工作。在我所見過的許多公司中，這個工作一般由部門的QA經理或項目組合經理負責。其次，公司應該設立相應的標桿職位和晉升通道，為QA人員提供明確的目標，從而激發他們更強的自我驅動力，學習、成長和工作。
對于管理QA人員而言，如果他們是公司內部員工，可以通過建立系統化的培養計劃，將他們培養成為符合我們要求的合格QA，并通過持續的輔導和指導確保他們能夠很好地完成相應的工作。然而，管理外部QA人員會面臨一些困難。首先，通常情況下，外部QA人員都是臨時加入的，且可能存在較大的變動性，導致難以持續系統地培養他們，使他們能夠勝任符合我們要求的QA工作。其次，如果他們的能力無法滿足工作需求，那么只能將一些基礎的測試工作交給他們，比如一些簡單的手動測試執行工作。
然而，在標準的敏捷測試體系中，手動測試并不是主要的工作內容，這使得能力不足的外部QA人員很難發揮作用。除非項目的自動化測試覆蓋率極低或者不足，同時項目對質量的要求很高，此時大量的外部QA人員才可能在大規模的功能驗證測試和回歸手動測試中發揮高效的作用。如果他們的能力足夠，經過直接或系統化的培訓后，他們也可以勝任與公司內部QA相同的工作。
因此，根據不同的項目情況和外部QA人員的能力水平，是否選擇外部QA人員可能會得到不同的答案。在項目人力資源嚴重不足的情況下，無法招聘到足夠的QA人員，只能選擇使用外部QA人員。這時可以將外部QA人員分為兩類：第一類只負責手動測試的執行，特別是在項目有大量手動測試需要執行時；第二類具備較好的測試和質量技能，通過系統化的培訓使其能夠完成敏捷測試和質量內建體系中一個QA所需完成的工作，從而解決人力資源問題。
Senior QA負責用例分析和設計工作，然后招聘外部QA來執行手動測試用例，或者要求初級開發人員來實現自動化測試用例。這種工作模型在不少大型企業中被廣泛采用，但效率較低，同時存在用例管理和傳遞的問題。
對于大量測試用例，如果編寫得非常詳細，甚至到操作步驟級別，一旦流程發生變更就會變成一場噩夢。但如果只寫測試點，缺乏更詳細的業務或用戶流程描述，知識傳遞可能存在遺漏和誤解，導致大量遺漏和誤測，降低測試的有效性。
為了解決這個問題，可以嘗試結合敏捷測試中的測試左移和活文檔的方法提出建議和改進方案。在敏捷測試中，我們建議基于業務流程或用戶行為來描述測試用例（參見我的文章測試用例的編寫和管理和播客質量三人行之測試用例），以降低維護成本。然而，基于用戶行為的方式也存在一個問題，即執行測試或進行自動化測試需要對項目背景和業務知識有一定的了解才能理解測試用例。
因此，這種工作模式能夠有效執行的前提條件是：對于需要外部手動測試的情況，首先需要項目投入大量人力和時間編寫基于詳細測試步驟的測試用例以實現足夠的覆蓋率，并且沒有人從事自動化測試，全部依靠人工測試。項目需要允許長時間的測試，并且在項目變更時能夠投入足夠的人力資源和時間來維護測試用例，最終項目能夠接受這種低效率的工作模式。
對于需要初級開發人員編寫自動化測試用例的情況，首先需要編寫基于領域語言和業務行為的測試用例，以實現足夠的覆蓋率。其次，需要對這些開發人員進行項目業務和技術相關的培訓，使他們基本掌握項目的業務知識、領域語言和技術棧等。編寫用例的人員還需要與開發人員保持經常溝通，只有這樣，開發人員才能有效地開發自動化測試。
對于第一種模式，它需要大量時間和資源投入，不適合敏捷項目，更適合人力和時間資源豐富的大型產品項目。對于第二種模式，資源投入也較大，但只要項目的人力資源足夠，對于敏捷項目也是可行的。而這兩種模式的共同前提是，公司、部門和團隊都認識到測試分析和設計的重要性，并認可測試用例與產品代碼一樣重要、有價值的產出，從而讓QA人員能夠感受到他們工作產出的價值，獲得足夠的成就感。
對于QA角色而言，其主要目的是幫助項目提升和保證質量，以滿足項目的質量要求。一個QA引以為傲的是能夠幫助項目取得高質量的成果。
如果一個項目本身對質量要求很低，不愿在測試、質量工作和QA資源上投入足夠，那么少量的QA在工作中多半會感到困難重重，缺乏安全感和成就感。因此，對于質量要求低的項目來說，可以不需要QA。但對于質量要求高的項目，要么提供足夠的QA資源，無論是內部員工還是承包商；要么如果無法提供足夠的QA資源，就需要提供足夠的時間和其他角色的人力資源，實施高度的質量內建實踐，并讓所有角色分擔所有必要的測試和質量工作，只有這樣才能有效保證項目以高質量的結果呈現。
專業事務需要專業人士來處理，這不僅能獲得更好的結果，還能節約時間。
本文鏈接：http://www.www897cc.com/showinfo-26-56599-0.html去測試化真的可行嗎？
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 11個優秀開源TTS引擎
下一篇： 12個NLP學習創意項目（附源碼）
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號