打破雙親委派么,怎么打破

by Derwin

由Derwin

質量保證被打破。這就是我們如何使其像其他所有東西一樣敏捷。 (Quality Assurance is broken. Here’s how we can make it as agile as everything else.)

Process is the key to great software.

過程是出色軟件的關鍵。

In general, the industry has made leaps and bounds in software development processes. But testing processes still remain archaic.

總的來說，該行業在軟件開發過程中取得了跨越式的發展。但是測試過程仍然過時。

Test engineers are forced to manually crunch through tests and bugs at the end of each development cycle.

在每個開發周期結束時，測試工程師被迫手動處理測試和錯誤。

The result? A ton of wasted time and energy throughout the entire process.

結果？在整個過程中浪費了大量的時間和精力。

Agile development is dramatically different from waterfall, which is an older, more rigid software development methodology.

敏捷開發與瀑布式截然不同，瀑布式瀑布式是一種較舊的，更嚴格的軟件開發方法。

Our team practices agile. But as the leader of a team of test engineers, I’ve noticed that our QA process is much more similar to waterfall.

我們的團隊練習敏捷。但是，作為測試工程師團隊的負責人，我注意到我們的質量檢查流程與瀑布圖非常相似。

QA瀑布 (The QA Waterfall)

We start testing at the end of the development process. This leaves test engineers cramped and short on time. You could say that QA testing in agile is a compressed version of waterfall.

我們在開發過程結束時開始測試。這使測試工程師局促，時間緊迫。您可以說敏捷中的QA測試是Waterfall的壓縮版本。

While there’s less testing per session in agile than in waterfall, the process could be a lot more effective. For starters, when testing is lumped in at the end, it’s often very urgent and time sensitive. This forces test engineers to optimize for speed, which generally means testing products manually.

盡管敏捷中每個會話的測試要比瀑布中的測試少，但該過程可能會更加有效。對于初學者來說，當最后進行測試時，這通常非常緊急且對時間敏感。這迫使測試工程師優化速度，這通常意味著手動測試產品。

Obviously, manual testing works. But there are so many aspects of these tests that could be automated if test engineers had more time to write scripts that test software.

顯然，手動測試有效。但是，如果測試工程師有更多時間編寫測試軟件的腳本，則這些測試的許多方面可以自動化。

The time cost of manual testing adds up in subsequent weeks, as QA manually tests new builds of the same software. Instead, they could’ve built automated scripts to test more of the software, which would take it off test engineers’ plate and provide faster feedback for software engineers.

由于QA會手動測試同一軟件的新版本，因此手動測試的時間成本在接下來的幾周內會增加。相反，他們可以構建自動化腳本來測試更多軟件，這將使它脫離測試工程師的視野，并為軟件工程師提供更快的反饋。

At Flipp, we’ve tried testing software the manual, old fashioned, way. But we ran into our own discomforts and challenges.

在Flipp，我們嘗試以老式的方式嘗試測試軟件。但是我們遇到了自己的不適和挑戰。

For example, any delay in the system or releasing the feature would impact the QA team the week after. These types of delays would compound, to the point where the software engineering team would be extremely far ahead of QA, and QA would be desperately trying to catch up.

例如，系統中的任何延遲或發布功能都會在下周影響質量檢查團隊。這些類型的延遲將變得更加復雜，以至于軟件工程團隊將遠遠超出質量保證，并且質量保證將拼命追趕。

One common solution to the problem of the development team getting too far ahead of the testing team is to throw a bug bash. This way, the development team can all test bugs to help the QA team catch up before the end of the sprint.

解決開發團隊與測試團隊相距太遠的問題的一種常見解決方案是拋出bug。這樣，開發團隊可以測試所有錯誤，以幫助質量保證團隊在沖刺結束之前趕上來。

We implemented an even simpler solution: dev teams include test engineers from the beginning.

我們實施了一個更簡單的解決方案： 開發團隊從一開始就包括測試工程師。

This way test engineers can identify scenarios and write scripts to test with which to test the dev team’s new code. As developers build the actual software, test engineers can build the scripts to test this software with, which can be used over and over again each week. Most importantly, it collectively saves a ton of time, attention, and energy in subsequent testing.

通過這種方式，測試工程師可以識別方案并編寫腳本來測試開發團隊的新代碼。在開發人員構建實際軟件時，測試工程師可以構建腳本以對其進行測試，并且可以每周多次使用該腳本。最重要的是，它共同節省了后續測試所需的大量時間，精力和精力。

At Flipp, our QA team asks a lot of precision questions and design testability aspects early on, so that we don’t have to go through the cycle of QA to find out there’s bugs in the system. We question it right from the start. Some standard examples of our precision questions:

在Flipp，我們的質量保證團隊會在早期就詢問許多精度問題和設計可測試性方面，因此我們不必經歷質量保證周期即可發現系統中的錯誤。我們從一開始就質疑它。我們的精度問題的一些標準示例：

“How much load are we expecting?”
“我們期望多少負載？”
“What type of analytic beacons are we relying on so we can measure success for the project?”
“我們依賴哪種類型的分析信標，以便我們可以衡量項目的成功？”
“How are we going to make it testable so we can easily deploy?”
“我們如何使其可測試，以便我們輕松部署？”

Here are the benefits we’d noticed as we implemented this solution, and why we think every company needs to rethink how they test for quality.

這是我們在實施此解決方案時注意到的好處，以及為什么我們認為每個公司都需要重新考慮他們如何測試質量。

反饋比敏捷更快 (Faster feedback than agile)

In general, sprint cycle duration varies from project to project. But for example, let’s say each sprint consists of five days.

通常，沖刺周期的持續時間因項目而異。但是，例如，假設每個沖刺由五天組成。

In the first three days, software engineers will go through ticketing system — building features and completing tickets. Once they’re done, they then pass their build off to QA. QA’s test engineers have the final couple of days to examine these tickets.

在最初的三天內，軟件工程師將通過票務系統-構建功能并完成票證。一旦完成，他們便將其構建傳遞給質量檢查。 QA的測試工程師將在最后幾天檢查這些票證。

This would be a typical sprint cycle in both agile and waterfall: Plan, develop, code, and test.

這將是敏捷和瀑布式開發中的典型沖刺周期：計劃，開發，編碼和測試。

I mentioned this earlier, but I really want to hammer the point home:

我在前面提到了這一點，但我真的很想指出這一點：

Instead of leaving testing at the end, we should implement testing right from the beginning (during the “plan” phase) and start asking questions. As test engineers, we would need to figure out how to test, and what systems we need to build, so we can test it right from the start.

我們應該從頭開始(在“計劃”階段)實施測試，而不是在測試結束時離開測試，并開始提出問題。作為測試工程師，我們需要弄清楚如何進行測試以及需要構建哪些系統，因此我們可以從一開始就對其進行測試。

Traditionally, software engineers would send a build to test engineers, who would then manually conduct a test, and send it back to the software engineers if there were any issues or bugs with the code. There would be a 1–2 day lag as QA might be working on previous tickets. Software engineers would have to wait until that ticket is complete. So, if QA testing is done manually:

傳統上，軟件工程師會將構建版本發送給測試工程師，然后由他們手動進行測試，如果代碼有任何問題或錯誤，則將其發送回軟件工程師。由于QA可能在處理先前的票證，因此會有1-2天的延遲。軟件工程師必須等到該票證完成為止。因此，如果手動進行質量檢查測試：

Test engineers set up time to do tests
測試工程師設置時間進行測試
Software engineers lose time and energy to context switching between different tickets
軟件工程師浪費時間和精力進行不同票證之間的上下文切換
Test engineers spend time to do tests
測試工程師花時間做測試

Pretty clunky, right? Let’s look at how an automated test might work:

很笨，對嗎？讓我們看一下自動測試的工作方式：

A test engineer builds a script where each time someone makes a change and deploys it to the servers, the test ensures that there would be no 500 errors or JavaScript errors. If the test finds any of those errors, the build failed this test, and software engineers will be notified in minutes. Nobody has to wait 2–3 days, it happens automatically. This extremely fast feedback allows the software team to move a lot faster.

測試工程師構建一個腳本，每次有人進行更改并將其部署到服務器時，該測試將確保不會出現500個錯誤或JavaScript錯誤。如果測試發現這些錯誤中的任何一個，則表明該構建版本無法通過該測試，并且幾分鐘之內就會通知軟件工程師。無需等待2-3天，它就會自動發生。這種極其快速的反饋使軟件團隊可以更快地移動。

The fast feedback compounds into significant savings, particularly for simple and obvious errors. It also minimizes context switching, an overlooked cost.

快速反饋可以節省大量資金，尤其是對于簡單明顯的錯誤。它還最大程度地減少了上下文切換，這是被忽略的成本。

Consider the software engineers’ mind when they have to return to the build a test engineer just sent back. “What was that feature again? What was that bug? How do I fix it?”

當軟件工程師不得不返回構建時，請考慮一下軟件工程師的想法。 “那個功能又是什么？那是什么錯誤？我如何解決它？”

Here, within five minutes, they would know that the phase of testing is complete, and whether it requires more work.

在這里，五分鐘之內，他們就會知道測試階段已經完成，以及是否需要更多工作。

Naturally, as the software becomes more complex, so do the tests.

自然，隨著軟件變得更加復雜，測試也將變得更加復雜。

最少的緊急情況 (Minimal emergencies)

Because QA considers situations from the beginning of the software development process — and doesn’t wait till the end to manually test scenarios and situations — they will have more time to predict emergencies or consider a wider range of circumstances.

由于QA從軟件開發過程的開始就考慮情況-不會等到結束時才手動測試情況和情況-他們將有更多的時間來預測緊急情況或考慮更廣泛的情況。

It’s as close to zero emergencies as a software and test engineers will get. Obviously, unanticipated errors still come up. But now, the team has a better idea of how to gather and understand the data, and a bug’s impact on users.

正如軟件和測試工程師所能得到的那樣，緊急事件幾乎為零。顯然，仍然出現意外錯誤。但是現在，團隊對如何收集和理解數據以及錯誤對用戶的影響有了更好的了解。

For example, let’s say users are reporting an error with the discount slider in the Flipp app. The test engineer will have considered the analytic beacons necessary to quickly check on the reach and significance of the bug. Because of these measures, they might look at the data and notify the team, “This is only impacting 1% of our users.” They can determine that what appeared to be an emergency isn’t really.

例如，假設用戶使用Flipp應用程序中的折扣滑塊報告錯誤。測試工程師將考慮必要的分析信標，以快速檢查錯誤的范圍和重要性。由于采取了這些措施，他們可能會查看數據并通知團隊：“這只會影響我們1％的用戶。” 他們可以確定似乎緊急的情況并非如此。

A standard QA team is inflexible and won’t allow any bugs to go through. Here there’s tolerance to allow smaller bugs to go through — in order for test engineers to focus on higher priority, wider reaching, bugs. They can more accurately assess the risk of bugs and what’s going through. If impact is minimal, then the test engineers can flag it and have software engineers fix it in the next sprint.

一個標準的質量檢查團隊是不靈活的，不會允許任何錯誤通過。這是允許較小的錯誤通過的容忍度，以便測試工程師專注于更高優先級，范圍更廣的錯誤。他們可以更準確地評估錯誤的風險以及正在發生的事情。如果影響很小，則測試工程師可以對其進行標記，并讓軟件工程師在下一個沖刺中對其進行修復。

重塑軟件團隊的文化 (Reinventing your software team’s culture)

Ultimately, incorporating test engineers into the software development process is one symptom of a greater culture shift. Test engineers’ perspectives will now be considered earlier in the process.

歸根結底，將測試工程師納入軟件開發過程是文化轉變的一個征兆。現在將在過程的早期考慮測試工程師的觀點。

On the test engineering side, test engineers need to be more curious to see how they can make the system better and improve its quality.

在測試工程方面，測試工程師需要更加好奇，以了解如何更好地改善系統并提高其質量。

The shift would be in everyone — product owners, scrum masters, testing engineers, and software engineers — accepting these questions earlier on and considering them.

這種轉變將出現在每個人(產品所有者，scrum管理員，測試工程師和軟件工程師)中，他們早日接受并考慮了這些問題。

This will unify the team and create a better understanding of what feature success looks like.

這將統一團隊，并更好地了解成功的功能。

Typically, engineering leads and product owners take x amount of days to bring something to completion. But their definition of “done” is different from QA’s. Their definition of “done” is sending software over to QA. In contrast, QA’s definition of “done” is when software is releasable to users.

通常，工程負責人和產品負責人需要花費x天的時間才能完成工作。但是他們對“完成”的定義與質量檢查的定義不同。他們對“完成”的定義是將軟件發送給質量檢查人員。相比之下，質量檢查(QA)對“完成”的定義是用戶可以發布軟件的時間。

關于Flipp如何進行質量檢查的一擊 (A blow-by-blow of how we do QA at Flipp)

In closing, I’m going to give you a specific example of how this might look when your software team builds and tests a feature. Let’s walk through the various stages of a two week sprint, and what the test engineer’s role, aims, and priorities should be in each of them.

最后，我將為您提供一個具體示例，說明您的軟件團隊構建和測試功能時的外觀。讓我們逐步進行為期兩周的沖刺的各個階段，以及每個階段中測試工程師的角色，目標和優先級應該是什么。

Note that at Flipp, we call our test engineers, “software engineers in test.” For clarity, we referred to them as test engineers in this piece, but this shift in wording in our organization reflects how embedded QA truly is into the software engineering team.

請注意，在Flipp，我們將測試工程師稱為“測試中的軟件工程師”。為了清楚起見，在本文中我們將他們稱為測試工程師，但是我們組織中措辭的這種變化反映出嵌入式QA真正成為軟件工程團隊的方式。

階段1：概念 (Stage 1: Concept)

This stage takes place on day one, when the feature is still little more than an idea. The team doesn’t have much clarity on the feature (around 10%). They know about it, but don’t know exactly how it’ll be built.

這個階段發生在第一天，那時功能僅是一個想法。團隊對此功能的了解不多(大約10％)。他們知道它，但不確切知道它將如何構建。

The test engineer’s most important job in this stage is to thoroughly understand, and potentially help define, what success means to the product owner. Some companies call these definitions the “acceptance criteria.”

在此階段，測試工程師最重要的工作是徹底了解并可能幫助定義成功對產品所有者而言意味著什么。一些公司將這些定義稱為“接受標準”。

In any case, I prefer using the guiding question: “What is winning?”

無論如何，我更喜歡使用指導性問題：“什么是勝利？”

Figuring out the answer — and corresponding key metrics — will be the whole team’s main focus of the concept stage.

找出答案和相應的關鍵指標將是整個團隊在概念階段的主要重點。

階段2：模擬和設計 (Stage 2: Mocks and designs)

This stage also happens early in the sprint (usually on day one), when the feature has been defined a bit more clearly (around 30%). The test engineer’s understanding of the feature will change how they test it, and understanding the desired user behavior will inform the testing flow.

此階段也發生在沖刺的早期(通常在第一天)，此時對該功能的定義更加清晰(大約30％)。測試工程師對功能的理解將改變他們對其進行測試的方式，而了解所需的用戶行為將為測試流程提供依據。

The product owner might define winning as having the user take a certain action. If that’s the case, the test engineer must help determine how to take the user there. As the team starts preparing mockups, some flows or concepts might not make sense. It’s the test engineer’s and team’s job to call out mockups that does not follow user flow or doesn’t lead to winning.

產品負責人可能將獲勝定義為讓用戶采取特定行動。如果是這樣，測試工程師必須幫助確定如何將用戶帶到那里。隨著團隊開始準備模型，某些流程或概念可能沒有意義。召集不遵循用戶流量或不會導致獲勝的模型是測試工程師和團隊的工作。

The test engineer doesn’t necessarily act in a quality assurance capacity here, but still contributes as a team member. They must help identify different user profiles and different ways the app will be used (i.e., personas). The most important thing for the test engineer in this phase is still one of understanding: to grasp the feature as a whole rather than individual ticket elements.

測試工程師不一定在這里發揮質量保證的作用，但仍可以作為團隊成員做出貢獻。他們必須幫助識別不同的用戶個人資料和應用程序的不同使用方式(即角色)。對于測試工程師來說，在此階段最重要的事情仍然是一種理解：從整體上而不是單個票證要素上掌握功能。

第三階段：門票 (Stage 3: Tickets)

Software tickets make up the bulk of the sprint. It could potentially take place from day 1–10. The tickets make the feature much clearer (at around 60%).

軟件票構成了沖刺的大部分。它可能從第1天到第10天發生。門票使功能更加清晰(約60％)。

As software engineers work on the feature and resolve tickets, test engineers build small tests to ensure the feature will be built properly. Tickets make the feature more concrete. As the feature becomes more certain, the testing methods become clearer. The test engineer should also build pipelines to enable faster feedback.

當軟件工程師研究該功能并解決故障單時，測試工程師會進行一些小型測試，以確保正確構建該功能。門票使該功能更加具體。隨著功能變得更加確定，測試方法變得更加清晰。測試工程師還應該構建管道以實現更快的反饋。

That’s a lot of information, so I recommend that the test engineer start off by literally building one test that would be running after every commit or any change. I’d recommend building the happy path scenario first, then moving into the more detailed tests.

這是很多信息，所以我建議測試工程師首先從字面上構建一個將在每次提交或進行任何更改后運行的測試。我建議先構建幸福的道路場景，然后再進行更詳細的測試。

When the test engineer tackles these other more detailed tests, they should also identify other paths: What happens if the user rotates the screen? What happens if they cancel? What happens if they have a strange feature combination? What about the potential critical failures of the feature (e.g., making sure the page loads and avoiding the dreaded 500 error, or ensuring the action on the web page gets recorded accurately in the database).

當測試工程師處理這些其他更詳細的測試時，他們還應該確定其他路徑：如果用戶旋轉屏幕會發生什么？如果取消，會發生什么？如果他們具有奇怪的功能組合會怎樣？該功能的潛在嚴重故障該怎么辦(例如，確保頁面加載并避免可怕的500錯誤，或者確保網頁上的操作已準確記錄在數據庫中)。

Some of these other paths will be frequent, others will be less common. The test engineer should prioritize the ones they should be testing. I recommend evaluating based on these two criteria:

這些其他路徑中的某些路徑將很常見，而另一些則不太常見。測試工程師應優先考慮要測試的對象。我建議根據以下兩個標準進行評估：

What is the impact on revenue or key business metrics? The test engineer should make it easy for people to get where they want to go. For example, in Flipp, we want to make it as easy as possible for the users to get to their desired flyer. Any obstacle takes away from quality.

對收入或關鍵業務指標有什么影響？測試工程師應該使人們易于到達他們想要去的地方。例如，在Flipp中，我們希望使用戶盡可能容易地獲得所需的傳單。任何障礙都離不開質量。

Does it affect retention? The test engineer must ensure the app doesn’t crash, or users don’t exit for any unplanned reason. They should also consider ways of bringing users back in, or encouraging them to re-open the app.

它會影響保留率嗎？測試工程師必須確保該應用不會崩潰，或者用戶不會由于任何計劃外的原因而退出。他們還應該考慮使用戶重新進入或鼓勵他們重新打開應用程序的方法。

The most important thing for test engineers is for them to prioritize what is being found, based on their definition of winning. They must also identify risks throughout the feature based on the usage, impact, and probability of that scenario occurring. How many people will the ticket influence? How deep is the problem? If the app does fail, will it be difficult to recover?

對于測試工程師而言，最重要的事情是，根據他們對獲勝的定義，他們優先考慮發現的內容。他們還必須根據使用情況，影響和發生這種情況的可能性來確定整個功能的風險。門票會影響多少人？問題有多深？如果應用程序確實失敗了，將很難恢復嗎？

階段4：質量保證和測試 (Stage 4: Quality assurance and testing)

Quality assurance and testing takes place from days 5–10 (all the way up to release). The feature should be be 90–100% clear at this point.

質量保證和測試從第5天到第10天(一直到發布)進行。此時，該特征應為90–100％清晰。

As tickets become resolved, test engineers should look at their strategy, which they developed in the previous stages, and start executing on their plan. They will work with software engineers to build more clarity or to resolve bugs.

隨著故障單的解決，測試工程師應該查看他們在先前階段中制定的策略，并開始執行他們的計劃。他們將與軟件工程師合作，以提高清晰度或解決錯誤。

The most important thing here is for test engineers to ensure the features that are related to winning are clear. Nice-to-haves or should do’s aren’t going to be fixed unless there’s extra time.

對于測試工程師而言，最重要的是確保與獲勝相關的功能清晰易懂。除非有額外的時間，否則要固定好或應該做的事情不會固定。

階段5：發布/部署 (Stage 5: Release/deployment)

Release takes place on the final day (hypothetical Day 10). The test engineer’s job must ensure the release is smooth. Prior to release, they should test the feature on a replica of production system. We have a specific post-release checklist we use to keep things consistent. I won’t bore you with the details.

發布在最后一天(假設的第10天)進行。測試工程師的工作必須確保發布順利。在發布之前，他們應該在生產系統的副本上測試功能。我們有一個特定的發布后檢查清單，用于使內容保持一致。我不會告訴你細節。

As the feature launches, test engineers should keep a close eye on the data to see if it’s in a healthy state, and look at crash logs. We’re humans, so we all miss things sometime even after testing. There might be events even the most careful testing engineers don’t anticipate.

該功能啟動時，測試工程師應密切關注數據以查看其是否處于健康狀態，并查看崩潰日志。我們是人類，所以即使經過測試，我們都會在某個時候錯過一切。即使是最仔細的測試工程師也可能不會想到的事情。

Smarter quality assurance starts with considering testing at the beginning of the software development process. It means bringing test engineers in with software engineers at the beginning of the test cycle, and considering scenarios and possibilities from the get go. It’ll make the development process smarter and, most importantly, lead to better software.

更加智能的質量保證始于在軟件開發過程的開始就考慮進行測試。這意味著在測試周期開始時將測試工程師與軟件工程師聯系起來，并從一開始就考慮各種場景和可能性。這將使開發過程更智能，最重要的是，可以帶來更好的軟件。

I’m Derwin, the director of test engineering at Flipp. I published a partial version of this at the Flipp blog. If you’re interested in reinventing the way people buy things, check out our current job postings.

我是Flipp測試工程總監Derwin 。 我在Flipp博客上發布了部分內容。 如果您有興趣重塑人們的購買方式，請查看我們當前的職位發布。