嘿哈布爾！
我們有了一個新的重要課題—資訊科技產品高品質發展。在 HighLoad++ 上，我們經常討論如何讓繁忙的服務更快，而在 Frontend Conf 上，我們談論一個不會減慢速度的酷炫使用者介面。我們定期舉辦有關測試的主題，以及有關組合不同流程（包括測試）的 DevOpsConf。但關於什麼可以稱為一般質量，以及如何全面提高品質——沒有。
讓我們透過以下方式解決這個問題 — 我們將培養一種在開發的每個階段為使用者考慮最終產品品質的文化。不專注於自己的職責範圍，並且不僅僅將品質與測試人員聯繫在一起的習慣。
以下我們將與程序委員會負責人、Tinkoff.Business 測試負責人、俄語 QA 社群的創建者進行交談 阿納斯塔西婭·阿西耶娃-阮 關於品質保證行業的現狀和新會議的使命。
- 納斯蒂亞你好。請向我們介紹一下您自己。
阿納斯塔西婭：我在一家銀行管理測試，我負責一個非常大的團隊 - 我們有 90 多人。我們有一條重要的業務線；我們負責法人實體的生態系統。
我學習了機械和數學，最初想成為一名程式設計師。但當我收到一份有趣的offer時，我決定嘗試自己擔任測試員。奇怪的是，這竟然是我的使命。現在我看到我所有的工作都在這個行業。
我是品質保證紀律的熱心擁護者。我對創造什麼產品、公司、團隊以及原則上開發過程中如何對待品質並不漠不關心。
對我來說很明顯 這個方向的社區還不夠成熟，至少在俄羅斯。我們並不總是明白品質保證不僅僅是測試應用程式是否符合要求。我想改變這種現狀。
— 您使用了「品質保證」和「測試」這兩個字。在一般人看來，這兩個術語經常重疊。如果你深入挖掘，它們有何不同？
阿納斯塔西婭： 相反，它們並沒有什麼不同。測試是品質保證學科的一部分；它是一項直接活動——事實上我正在測試某些東西。實際上測試有很多種類型，不同的人負責不同類型的測試。但在俄羅斯，當一波向公司提供測試儀的外包商出現時，測試被簡化為單一類型。
在大多數情況下，它們僅限於功能測試：它們檢查開發人員編寫的程式碼是否符合規範，僅此而已。
— 請告訴我們還有哪些品質保證學科？除了測試之外，這裡還包括什麼？
阿納斯塔西婭：品質保證首先是創造優質產品。也就是說，我們問自己我們的產品應該具有哪些品質屬性。因此，如果我們理解這一點，我們就可以比較誰影響這些品質屬性。沒關係， 開發人員、專案經理或產品專家 是影響產品開發、積壓工作和策略的人。
測試人員更清楚自己的角色。他明白，他的任務不僅是測試是否符合要求，還要測試要求，質疑產品專家的配方，並揭示客戶所有隱含的要求和期望。當我們向客戶提供新功能時，我們必須真正滿足他們的期望並解決他們的痛苦。如果我們考慮到品質的所有屬性，客戶就會感到滿意，並且會理解他使用產品的公司真正關心他的利益，而不是按照「只是為了發布功能」的原則工作。
——看來你剛才描述的是產品專家的任務。原則上，這與測試無關，也與品質無關——它通常與產品管理有關，不是嗎？
阿納斯塔西婭： 包括。品質保證不是一門由特定人員負責的學科。現在測試有一個流行的方向，一種方法叫做 敏捷測試。他的定義明確指出，這是一種團隊測試方法，其中包括一組特定的實踐。整個團隊負責實作這種方法；團隊中甚至不需要有測試人員。整個團隊專注於為客戶提供價值並確保價值滿足客戶的期望。
— 事實證明，品質幾乎與周圍的所有學科都有交叉，給周圍的一切強加了一個框架？
阿納斯塔西婭： 正確的。當我們思考如何創造優質產品時，我們開始思考品質的各種屬性。例如，如何檢查我們是否真的做出了客戶需要的功能。
這就是此類測試的用武之地： UAT （用戶驗收測試）。不幸的是，它在俄羅斯很少被實踐，但有時會作為最終客戶端的演示出現在 SCRUM 團隊中。這是國外公司相當常見的測試類型。在向所有客戶開放功能之前，我們首先要做UAT，也就是我們邀請最終用戶進行測試並立即給予回饋——產品是否真的滿足期望並解決痛點。只有在此之後，才會擴展到所有其他客戶端。
也就是說，我們專注於業務、最終客戶，但同時 不要忘記技術。產品的品質很大程度取決於技術。如果我們的架構不好，我們將無法快速發布功能並滿足客戶的期望。當嘗試擴充時可能會出現很多錯誤，或者當嘗試重構時我們可能會破壞某些東西。所有這些都會影響客戶滿意度。
從這個角度來看，架構應該使我們能夠編寫乾淨的程式碼，使我們能夠快速進行更改，而不必擔心我們會破壞一切。因此，修訂迭代不會因為我們有太多遺留問題而持續幾個月，而且我們需要進行長時間的測試階段。
— 總的來說，開發人員、架構師、產品科學家、產品經理和測試人員本身已經參與其中。還有誰參與品質保證流程？
阿納斯塔西婭：現在假設我們已經將該功能交付給客戶。顯然，即使產品已經投入生產，也需要對其品質進行監控。在這個階段，可能會出現一些不明顯的情況，也就是所謂的錯誤。
第一個問題是我們發布產品後如何處理這些bug？例如，我們如何應對壓力？如果頁面載入時間超過 30 秒，客戶將不會很高興。
這就是剝削發揮作用的地方，或者正如他們現在所說的那樣， DevOps的。事實上，這些人就是在產品投入生產時負責操作產品的人。這包括各種類型的監控。甚至還有一種測試子類型 - 生產測試，我們允許自己在推出之前不進行測試，並立即在生產中進行測試。這是從組織基礎設施的角度來看的一系列措施，使您能夠快速回應事件、影響事件並糾正事件。
基礎設施也很重要。在測試過程中，經常會出現這樣的情況：我們無法確保我們確實擁有我們想要提供給客戶的一切。我們將其投入生產並開始發現不明顯的情況。這都是因為測試中的基礎設施與生產中的基礎設施不對應。這導致了一種新的測試類型 - 基礎設施測試。這些是各種配置、設定、資料庫遷移等。
這就提出了一個問題——也許團隊需要使用基礎設施即程式碼。
我認為基礎設施直接影響產品的品質。
希望會議上能有一個真實案例的報告。如果您準備好根據自己的經驗告訴我們基礎設施即程式碼如何影響質量，請寫信給我們。基礎設施即程式碼可以更輕鬆地檢查所有設定並測試否則根本不可能的事情。因此，開發優質產品的過程中也涉及營運。
— 分析和文件怎麼樣？
阿納斯塔西婭：這更適用於企業系統。當我們談論企業時，我們立即想到分析師和系統分析師等人。他們有時被稱為技術作家。他們收到一項編寫規格並完成的任務，例如一個月。
已經反覆證明，編寫此類文件會導致非常長的開發迭代和漫長的修訂迭代，因為在測試過程中會發現錯誤並開始返回。這樣一來，就會出現很多循環，增加開發成本。此外，這可能會引入漏洞。我們似乎已經編寫了參考程式碼，但隨後我們進行了一些更改，破壞了經過深思熟慮的完美架構。
最終的結果是一個不完全高品質的產品，因為架構中已經出現了補丁，某些地方的程式碼沒有被測試充分覆蓋，因為截止日期即將到來，所有錯誤都需要快速關閉。這都是因為原始規範沒有考慮到所有需要實現的點。
開發人員不是害蟲，不會故意寫有錯誤的程式碼。
如果我們最初考慮了一個涵蓋所有必要要點的規範，那麼一切都將完全按照需要實現。但這是一個烏托邦。
編寫一份完美的 100 頁規格可能是不可能的。這就是為什麼 需要考慮編寫文件的替代方法、規格、設定任務，這將使我們更接近確保開發人員完全按照需要進行操作。
這裡我想到了敏捷方法——有驗收標準的使用者故事。這更適用於小迭代開發的團隊。
— 可用性測試、產品可用性、設計怎麼樣？
阿納斯塔西婭：這是非常重要的一點，因為團隊裡有設計師。大多數情況下，設計師被用作一種服務——無論是由設計部門還是由外包設計師。在很多情況下，設計師似乎聽取了產品專家的意見並做了他所理解的事情。但當我們開始迭代時，事實證明實際所做的並不是預期的：設計師忘記了一些東西，沒有充分思考行為，因為他不在團隊中，不在上下文中，也不在前端-最終開發人員沒有完全理解它的佈局。僅僅因為前端開發人員對設計的理解有問題，可能需要多次迭代。
另外還有一個問題。設計系統現在越來越受歡迎。它們正在大肆宣傳，但它們的好處並不完全明顯。
我認為設計系統一方面簡化了開發，但另一方面，它們對介面施加了許多限制。
結果，我們沒有製作客戶想要的功能，而是製作對我們來說方便的功能，因為我們已經擁有可以製作它的某些立方體。
我認為這是一個值得關注的話題，並想知道在努力讓設計變得更容易的過程中，我們是否真的在解決客戶的痛點。
— 與品質保證相關的主題數量驚人。俄羅斯是否有一個會議可以討論所有這些問題？
阿納斯塔西婭：有一個最古老的測試會議，今年將舉行第25屆，稱為SQA Days品質保證會議。它主要討論功能測試人員的工具和具體測試方法。通常，SQA Days 的報告會深入檢查測試人員本身責任領域的特定領域，但不會檢查複雜的活動。
這對於理解不同的工具和方法、如何測試資料庫、API 等有很大幫助。但同時，一方面，它並沒有促使人們在創造更好的產品時不僅僅進行測試。另一方面，測試人員不會更參與思考產品及其業務組件的全球目標的過程。
我管理著一個大部門並進行了大量採訪，這些採訪確實提供了對整個行業狀況的深入了解。一般來說，我們的人在企業工作，他們有明確的職責範圍。在國外專案工作的同事使用不同類型的測試：他們自己可以做負載測試、效能測試，甚至有時還可以進行安全測試，因為它們確實幫助團隊保證了產品的品質。
我希望俄羅斯的人們也開始認為這個產業不會隨著功能測試而結束。
— 為此，我們正在組織一個新的會議，QualityConf，致力於將品質作為一個完整的學科。請告訴我們更多關於這個想法的信息，會議的主要目標是什麼？
阿納斯塔西婭：我們希望創造一個對製造優質產品感興趣的人們的社群。提供一個平台，讓他們可以來聽報告並在會議結束後離開，具體了解需要改變哪些內容以提高品質。
如今，我經常聽到諮詢人員詢問當測試和品質出現問題時該怎麼辦。當您開始與團隊溝通時，您會發現問題不在於測試人員本身，而是流程的建構方式。例如，當開發人員認為他們只負責編寫程式碼時，他們的責任在他們將任務移交給測試的那一刻就結束了。
並不是每個人都考慮到這樣一個事實：編寫糟糕、品質低下的程式碼和糟糕的架構會為專案帶來大問題。他們沒有考慮錯誤的成本，最終出現在生產中的錯誤可能會為公司和團隊帶來巨大的成本。沒有文化可以思考這個問題。我希望我們開始在會議上分發它。
我知道這不是一項創新，《品質 14 條原則》的作者愛德華‧戴明 (Edward Deming) 在上個世紀就曾寫過有關錯誤成本的文章。品質保證作為一門學科是以這本書為基礎的，但不幸的是，現代發展忘記了它。
— 您打算直接討論有關測試和工具的話題嗎？
阿納斯塔西婭：我承認會有關於工具的報道。公司和團隊可以使用相當通用的工具來影響產品。
所有報告都將在全球範圍內由一個共同的使命統一起來：向受眾傳達這樣的訊息：借助這種方法、工具、方法、流程、測試類型，我們影響了產品的品質並改善了客戶的生活。
我們絕對不會為了工具而報告工具。該計劃中包含的所有報告都將由一個共同目標統一起來。
— 誰會對您所談論的內容感興趣？
阿納斯塔西婭：我們將為關心專案、產品、系統命運的開發人員提供報告。同樣，測試人員也會對此感興趣，在我看來，尤其是管理者。我所說的管理者是指那些做出決策並且能夠影響產品、系統、團隊的命運和發展的人。
這些人想知道如何提高產品或系統的品質。在我們的會議上，他們將了解各種措施，並能夠了解他們現在的問題所在以及需要改變的地方。
我認為主要標準是了解品質有問題並想要對其施加影響。我們可能無法接觸到那些認為第一次就能成功的人。
— 您認為整個產業是否已經成熟，不僅可以談論測試，還可以談論品質文化？
阿納斯塔西婭: 我覺得我已經成熟了。現在，許多公司正在從傳統的瀑布方法轉向敏捷方法。以客戶為中心，團隊中的人們真正開始思考如何創造優質產品。甚至企業公司也開始重新專注於提高品質。
從社區中提出的請求數量來看，我認為是時候了。當然，我不確定這是否會是一場大規模的革命，但我希望這場意識革命能夠發生。
- 同意！我們將灌輸文化並改變意識。
資訊科技產品高品質發展大會 將會發生 7月XNUMX日在莫斯科。您知道高品質產品由哪些階段組成，我們有成功解決生產中錯誤的案例，我們在實踐中測試了流行的方法 - 我們需要您的經驗。 他們的 1月XNUMX日前申請，程序委員會將幫助聚焦主題，以確保會議的整體完整性。
連接到 ，我們在其中討論品質問題和會議，訂閱 了解最新的節目新聞。
來源： www.habr.com
