QA best practices
1.0.0
這是Futurice用途的質量檢查實踐的摘要，並建議使用。它不應該是詳細的描述，有時無法完全使用所有任務，而是最重要的質量質量檢查過程和應使用的良好實踐列表的概述。
為了清楚起見，本文檔無法描述錯誤或事件過程（即從生產中找到新的錯誤）。
Futurice團隊中的每個人都有質量保證的責任，即使有命名的QA經理或質量保證專家。對於未來的質量保證意味著三件事。
在高級別的質量檢查和實踐中，可以分為兩個過程。
此外，還有其他質量檢查。
適用時，Futurice使用TDD和ATDD（接受測試驅動開發）方法。
方法迫使實現遵循體系結構並考慮所使用的模塊。實現首先編寫自動測試，然後實現通過測試的功能。
Futurice適用時使用對編程方法。這是分享有關正在開發的項目和軟件的知識和經驗的非常方便的方法。
審查代碼可以幫助其他團隊成員獲取某些功能的信息，並有可能向負責人提供反饋，並確保團隊成員之間的知識共享。
手動測試主要是使用探索性測試方法進行的，發現的錯誤是立即解決的，要么優先考慮並記錄到任務/故事/錯誤管理工具。探索應用程序或服務可以在功能“準備就緒”之後立即啟動。
探索性測試是最終測試的非常強大的工具，其中整個系統被測試涵蓋。在方法中，測試儀超出了測試案例中可以定義的內容，應用類似用戶的思維以及試圖通過各種錯誤方案破壞系統，並且從未通過測試“完成”。
圍繞功能要求和測試，通常有非功能性要求，可以測試應用本地化，可用性，性能和負載測試。需求和工具是特定於項目的。為了可用性測試，Futurice具有一個移動可用性實驗室供使用。對於性能測試，Futurice已使用基於Web的服務（例如Browsermob）命名一個。對於負載測試，LoadUI和J儀表正在積極使用，以驗證流量高的服務功能並找到可能的服務瓶頸。
將發現的問題記錄到特定工具或董事會，其中包含優先級，環境（軟件和設備信息），複製步驟，預期結果，時間和日期以及屏幕截圖等信息。 Jira，Trello，PivoTalTracker，請求跟踪器等工具也被積極用於錯誤跟踪。
敏捷的原則之一是總體代碼分支應該始終具有可能的托運。這意味著它應該始終是生產質量。這是通過以下方式實現的：
每個用戶故事（或功能）都是在自己的功能分支中單獨開發的。這樣做的目的是確保主分支的每個更新同時均為1）盡可能小，2）有可能發揮的完整故事。
在將功能分支合併到主分支之前，它必須通過稱為DONE（DOD）定義的動作，要求和實踐列表。這是與客戶PO和開發團隊一起定義的，如果項目需要更改，則可以在項目期間修改。
提議的國防部中的以下物品已被大膽
部署過程是如何將新版本（或主分支中的版本）部署到生產中的過程。對於此過程，有三個相關環境。
連續集成（CI）服務器用於自動測試，並將代碼部署到環境中。自動化測試始終是在更新這些環境時運行的。
每當已更新主分支時，CI會自動更新測試環境。這意味著在更新主分支時，自動測試用例也會自動運行。
測試環境是Futurice的主要測試服務器。預計此處已測試的任何版本都可以將其推向質量檢查或生產（這取決於項目中使用的術語和集成）。
更新測試時，無需運行手動回歸測試用例。在探索性測試上花費的時間經常更有益。但是，最好每次沖刺至少一次進行這些測試是一個好習慣。
質量檢查環境應用作接受測試，演示或任何第三方測試或審核（安全，本地化，加載，可用性等）的環境。這不是Futurice的主要測試服務器（測試是）。客戶和未來的PM之間始終商定質量檢查的更新。
擁有兩個測試環境（測試和質量請士）的主要原因是遵守安全和集成要求。測試允許Futurice使用敏捷原理開發服務。 QA允許客戶運行其當前質量檢查流程的時間和控制。
除非發佈在測試環境中通過測試，否則不應更新質量檢查。
產品環境是實時現場（生產）的環境。
良好的做法是至少在推送更新之前，至少在QA中部署和運行自動測試。但是，每次部署後都需要檢查主要功能。
建議PO還有權將更新推向產品，而無需在QA中進行任何測試（如果在測試中傳遞版本）。這很重要，更新很小或簡單。
最終，在敏捷開發中，當服務正在進行持續開發時，目標是對產品也有許多小型更新。即，部署過程比防彈更苗條，更重要。能夠快速進行修復比擁有無錯誤服務更重要（顯然在DOD和自動測試質量時也應該很高）。 Futurice不建議立即從這種方法開始。但是，這應該是兩個組織想要去的方向。
每個移動平台都有其特定的SDK，工具集和Futurice的最佳實踐。
對於Android https://github.com/futurice/android-best-practices
對於iOS https://github.com/futurice/ios-good-practices
Windows Phone https://github.com/futurice/windows-app-development-best-practices
移動平台在其SDK中提供模擬器。
在實施階段，開發人員可以使用模擬 /仿真設備來驗證更改，但是沒有什麼可以比實際設備測試來擊敗整個系統從觸摸屏和集成內存到移動處理器的整個系統。
移動瀏覽器也可以通過Browserstack（例如Browserstack）進行測試。
Futurice在設備庫中具有各種不同的設備和操作系統版本，從基本電話到高級平板電腦。
對於大型數據流量應用程序測試和性能驗證，Futurice一直使用ELISA測試實驗室（ELISA是芬蘭移動服務提供商）。在實驗室環境中，可以在受控 /隔離的環境中測試不同的負載和速度，而無需安排昂貴的，而不是有效的現場測試。
通常，移動應用程序通過移動網絡連接到後端服務。為了充分利用測試，測試儀需要完全控制移動應用程序連接到的後端，以準備和執行不同的端到端測試方案。
在移動設備中，可以完成測試構建安裝：通過電纜在本地使用開發SDK工具在本地通過構建配電工具（例如TestFlight或HockeyApp）進行控制。釋放框架通常支持崩潰日誌收集和版本數據。還可以提供DEV，Alpha和Beta版本，以便在將申請發佈到商店之前收集反饋。 Google Play商店可以選擇設置Alpha和Beta測試組，其中僅適用於組成員的特定應用
在現代移動應用程序中，分析和數據收集代表了需要測試的關鍵功能。 Futurice認為這是功能測試的重要組成部分。
由於移動應用程序更新過程與Web應用程序ONE有所不同，因此分析設置需要從第一次嘗試中正確或丟失有價值的數據。更新過程是通過應用程序存儲過程完成的，但是是否要進行更新取決於用戶設置和活動。因此，如果第一個版本錯過了一些關鍵的分析功能，而某些用戶從不更新應用程序，那麼該數據將被丟失。該解決方案可能會被迫升級，在該應用程序將無法使用，直到用戶更新到可用的最新版本，但可能為時已晚。
