打破双亲委派么,怎么打破_质量保证被打破。 这就是我们如何使其像其他所有东西一样敏捷。...
打破雙親委派么,怎么打破
by Derwin
由Derwin
質(zhì)量保證被打破。 這就是我們?nèi)绾问蛊湎衿渌袞|西一樣敏捷。 (Quality Assurance is broken. Here’s how we can make it as agile as everything else.)
Process is the key to great software.
過程是出色軟件的關(guān)鍵。
In general, the industry has made leaps and bounds in software development processes. But testing processes still remain archaic.
總的來說，該行業(yè)在軟件開發(fā)過程中取得了跨越式的發(fā)展。 但是測(cè)試過程仍然過時(shí)。
Test engineers are forced to manually crunch through tests and bugs at the end of each development cycle.
在每個(gè)開發(fā)周期結(jié)束時(shí)，測(cè)試工程師被迫手動(dòng)處理測(cè)試和錯(cuò)誤。
The result? A ton of wasted time and energy throughout the entire process.
結(jié)果？ 在整個(gè)過程中浪費(fèi)了大量的時(shí)間和精力。
Agile development is dramatically different from waterfall, which is an older, more rigid software development methodology.
敏捷開發(fā)與瀑布式截然不同，瀑布式瀑布式是一種較舊的，更嚴(yán)格的軟件開發(fā)方法。
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.
我們的團(tuán)隊(duì)練習(xí)敏捷。 但是，作為測(cè)試工程師團(tuán)隊(duì)的負(fù)責(zé)人，我注意到我們的質(zhì)量檢查流程與瀑布圖非常相似。
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.
我們?cè)陂_發(fā)過程結(jié)束時(shí)開始測(cè)試。 這使測(cè)試工程師局促，時(shí)間緊迫。 您可以說敏捷中的QA測(cè)試是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.
盡管敏捷中每個(gè)會(huì)話的測(cè)試要比瀑布中的測(cè)試少，但該過程可能會(huì)更加有效。 對(duì)于初學(xué)者來說，當(dāng)最后進(jìn)行測(cè)試時(shí)，這通常非常緊急且對(duì)時(shí)間敏感。 這迫使測(cè)試工程師優(yōu)化速度，這通常意味著手動(dòng)測(cè)試產(chǎn)品。
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.
顯然，手動(dòng)測(cè)試有效。 但是，如果測(cè)試工程師有更多時(shí)間編寫測(cè)試軟件的腳本，則這些測(cè)試的許多方面可以自動(dòng)化。
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會(huì)手動(dòng)測(cè)試同一軟件的新版本，因此手動(dòng)測(cè)試的時(shí)間成本在接下來的幾周內(nèi)會(huì)增加。 相反，他們可以構(gòu)建自動(dòng)化腳本來測(cè)試更多軟件，這將使它脫離測(cè)試工程師的視野，并為軟件工程師提供更快的反饋。
At Flipp, we’ve tried testing software the manual, old fashioned, way. But we ran into our own discomforts and challenges.
在Flipp，我們嘗試以老式的方式嘗試測(cè)試軟件。 但是我們遇到了自己的不適和挑戰(zhàn)。
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.
例如，系統(tǒng)中的任何延遲或發(fā)布功能都會(huì)在下周影響質(zhì)量檢查團(tuán)隊(duì)。 這些類型的延遲將變得更加復(fù)雜，以至于軟件工程團(tuán)隊(duì)將遠(yuǎn)遠(yuǎn)超出質(zhì)量保證，并且質(zhì)量保證將拼命追趕。
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.
解決開發(fā)團(tuán)隊(duì)與測(cè)試團(tuán)隊(duì)相距太遠(yuǎn)的問題的一種常見解決方案是拋出bug。 這樣，開發(fā)團(tuán)隊(duì)可以測(cè)試所有錯(cuò)誤，以幫助質(zhì)量保證團(tuán)隊(duì)在沖刺結(jié)束之前趕上來。
We implemented an even simpler solution: dev teams include test engineers from the beginning.
我們實(shí)施了一個(gè)更簡(jiǎn)單的解決方案： 開發(fā)團(tuán)隊(duì)從一開始就包括測(cè)試工程師。
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.
通過這種方式，測(cè)試工程師可以識(shí)別方案并編寫腳本來測(cè)試開發(fā)團(tuán)隊(duì)的新代碼。 在開發(fā)人員構(gòu)建實(shí)際軟件時(shí)，測(cè)試工程師可以構(gòu)建腳本以對(duì)其進(jìn)行測(cè)試，并且可以每周多次使用該腳本。 最重要的是，它共同節(jié)省了后續(xù)測(cè)試所需的大量時(shí)間，精力和精力。
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，我們的質(zhì)量保證團(tuán)隊(duì)會(huì)在早期就詢問許多精度問題和設(shè)計(jì)可測(cè)試性方面，因此我們不必經(jīng)歷質(zhì)量保證周期即可發(fā)現(xiàn)系統(tǒng)中的錯(cuò)誤。 我們從一開始就質(zhì)疑它。 我們的精度問題的一些標(biāo)準(zhǔn)示例：
- “How much load are we expecting?” “我們期望多少負(fù)載？”
- “What type of analytic beacons are we relying on so we can measure success for the project?” “我們依賴哪種類型的分析信標(biāo)，以便我們可以衡量項(xiàng)目的成功？”
- “How are we going to make it testable so we can easily deploy?” “我們?nèi)绾问蛊淇蓽y(cè)試，以便我們輕松部署？”
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.
這是我們?cè)趯?shí)施此解決方案時(shí)注意到的好處，以及為什么我們認(rèn)為每個(gè)公司都需要重新考慮他們?nèi)绾螠y(cè)試質(zhì)量。
反饋比敏捷更快 (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.
通常，沖刺周期的持續(xù)時(shí)間因項(xiàng)目而異。 但是，例如，假設(shè)每個(gè)沖刺由五天組成。
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.
在最初的三天內(nèi)，軟件工程師將通過票務(wù)系統(tǒng)-構(gòu)建功能并完成票證。 一旦完成，他們便將其構(gòu)建傳遞給質(zhì)量檢查。 QA的測(cè)試工程師將在最后幾天檢查這些票證。
This would be a typical sprint cycle in both agile and waterfall: Plan, develop, code, and test.
這將是敏捷和瀑布式開發(fā)中的典型沖刺周期：計(jì)劃，開發(fā)，編碼和測(cè)試。
I mentioned this earlier, but I really want to hammer the point home:
我在前面提到了這一點(diǎn)，但我真的很想指出這一點(diǎn)：
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.
我們應(yīng)該從頭開始(在“計(jì)劃”階段)實(shí)施測(cè)試，而不是在測(cè)試結(jié)束時(shí)離開測(cè)試，并開始提出問題。 作為測(cè)試工程師，我們需要弄清楚如何進(jìn)行測(cè)試以及需要構(gòu)建哪些系統(tǒng)，因此我們可以從一開始就對(duì)其進(jìn)行測(cè)試。
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:
傳統(tǒng)上，軟件工程師會(huì)將構(gòu)建版本發(fā)送給測(cè)試工程師，然后由他們手動(dòng)進(jìn)行測(cè)試，如果代碼有任何問題或錯(cuò)誤，則將其發(fā)送回軟件工程師。 由于QA可能在處理先前的票證，因此會(huì)有1-2天的延遲。 軟件工程師必須等到該票證完成為止。 因此，如果手動(dòng)進(jìn)行質(zhì)量檢查測(cè)試：
Pretty clunky, right? Let’s look at how an automated test might work:
很笨，對(duì)嗎？ 讓我們看一下自動(dòng)測(cè)試的工作方式：
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.
測(cè)試工程師構(gòu)建一個(gè)腳本，每次有人進(jìn)行更改并將其部署到服務(wù)器時(shí)，該測(cè)試將確保不會(huì)出現(xiàn)500個(gè)錯(cuò)誤或JavaScript錯(cuò)誤。 如果測(cè)試發(fā)現(xiàn)這些錯(cuò)誤中的任何一個(gè)，則表明該構(gòu)建版本無法通過該測(cè)試，并且?guī)追昼娭畠?nèi)就會(huì)通知軟件工程師。 無需等待2-3天，它就會(huì)自動(dòng)發(fā)生。 這種極其快速的反饋使軟件團(tuán)隊(duì)可以更快地移動(dòng)。
The fast feedback compounds into significant savings, particularly for simple and obvious errors. It also minimizes context switching, an overlooked cost.
快速反饋可以節(jié)省大量資金，尤其是對(duì)于簡(jiǎn)單明顯的錯(cuò)誤。 它還最大程度地減少了上下文切換，這是被忽略的成本。
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?”
當(dāng)軟件工程師不得不返回構(gòu)建時(shí)，請(qǐng)考慮一下軟件工程師的想法。 “那個(gè)功能又是什么？ 那是什么錯(cuò)誤？ 我如何解決它？”
Here, within five minutes, they would know that the phase of testing is complete, and whether it requires more work.
在這里，五分鐘之內(nèi)，他們就會(huì)知道測(cè)試階段已經(jīng)完成，以及是否需要更多工作。
Naturally, as the software becomes more complex, so do the tests.
自然，隨著軟件變得更加復(fù)雜，測(cè)試也將變得更加復(fù)雜。
最少的緊急情況 (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從軟件開發(fā)過程的開始就考慮情況-不會(huì)等到結(jié)束時(shí)才手動(dòng)測(cè)試情況和情況-他們將有更多的時(shí)間來預(yù)測(cè)緊急情況或考慮更廣泛的情況。
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.
正如軟件和測(cè)試工程師所能得到的那樣，緊急事件幾乎為零。 顯然，仍然出現(xiàn)意外錯(cuò)誤。 但是現(xiàn)在，團(tuán)隊(duì)對(duì)如何收集和理解數(shù)據(jù)以及錯(cuò)誤對(duì)用戶的影響有了更好的了解。
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.
例如，假設(shè)用戶使用Flipp應(yīng)用程序中的折扣滑塊報(bào)告錯(cuò)誤。 測(cè)試工程師將考慮必要的分析信標(biāo)，以快速檢查錯(cuò)誤的范圍和重要性。 由于采取了這些措施，他們可能會(huì)查看數(shù)據(jù)并通知團(tuán)隊(duì)：“這只會(huì)影響我們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.
一個(gè)標(biāo)準(zhǔn)的質(zhì)量檢查團(tuán)隊(duì)是不靈活的，不會(huì)允許任何錯(cuò)誤通過。 這是允許較小的錯(cuò)誤通過的容忍度，以便測(cè)試工程師專注于更高優(yōu)先級(jí)，范圍更廣的錯(cuò)誤。 他們可以更準(zhǔn)確地評(píng)估錯(cuò)誤的風(fēng)險(xiǎn)以及正在發(fā)生的事情。 如果影響很小，則測(cè)試工程師可以對(duì)其進(jìn)行標(biāo)記，并讓軟件工程師在下一個(gè)沖刺中對(duì)其進(jìn)行修復(fù)。
重塑軟件團(tuán)隊(duì)的文化 (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.
歸根結(jié)底，將測(cè)試工程師納入軟件開發(fā)過程是文化轉(zhuǎn)變的一個(gè)征兆。 現(xiàn)在將在過程的早期考慮測(cè)試工程師的觀點(diǎn)。
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.
在測(cè)試工程方面，測(cè)試工程師需要更加好奇，以了解如何更好地改善系統(tǒng)并提高其質(zhì)量。
The shift would be in everyone — product owners, scrum masters, testing engineers, and software engineers — accepting these questions earlier on and considering them.
這種轉(zhuǎn)變將出現(xiàn)在每個(gè)人(產(chǎn)品所有者，scrum管理員，測(cè)試工程師和軟件工程師)中，他們?cè)缛战邮懿⒖紤]了這些問題。
This will unify the team and create a better understanding of what feature success looks like.
這將統(tǒng)一團(tuán)隊(duì)，并更好地了解成功的功能。
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.
通常，工程負(fù)責(zé)人和產(chǎn)品負(fù)責(zé)人需要花費(fèi)x天的時(shí)間才能完成工作。 但是他們對(duì)“完成”的定義與質(zhì)量檢查的定義不同。 他們對(duì)“完成”的定義是將軟件發(fā)送給質(zhì)量檢查人員。 相比之下，質(zhì)量檢查(QA)對(duì)“完成”的定義是用戶可以發(fā)布軟件的時(shí)間。
關(guān)于Flipp如何進(jìn)行質(zhì)量檢查的一擊 (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.
最后，我將為您提供一個(gè)具體示例，說明您的軟件團(tuán)隊(duì)構(gòu)建和測(cè)試功能時(shí)的外觀。 讓我們逐步進(jìn)行為期兩周的沖刺的各個(gè)階段，以及每個(gè)階段中測(cè)試工程師的角色，目標(biāo)和優(yōu)先級(jí)應(yīng)該是什么。
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.
請(qǐng)注意，在Flipp，我們將測(cè)試工程師稱為“測(cè)試中的軟件工程師”。 為了清楚起見，在本文中我們將他們稱為測(cè)試工程師，但是我們組織中措辭的這種變化反映出嵌入式QA真正成為軟件工程團(tuán)隊(duì)的方式。
階段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.
這個(gè)階段發(fā)生在第一天，那時(shí)功能僅是一個(gè)想法。 團(tuán)隊(duì)對(duì)此功能的了解不多(大約10％)。 他們知道它，但不確切知道它將如何構(gòu)建。
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.”
在此階段，測(cè)試工程師最重要的工作是徹底了解并可能幫助定義成功對(duì)產(chǎn)品所有者而言意味著什么。 一些公司將這些定義稱為“接受標(biāo)準(zhǔn)”。
In any case, I prefer using the guiding question: “What is winning?”
無論如何，我更喜歡使用指導(dǎo)性問題：“什么是勝利？”
Figuring out the answer — and corresponding key metrics — will be the whole team’s main focus of the concept stage.
找出答案和相應(yīng)的關(guān)鍵指標(biāo)將是整個(gè)團(tuán)隊(duì)在概念階段的主要重點(diǎn)。
階段2：模擬和設(shè)計(jì) (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.
此階段也發(fā)生在沖刺的早期(通常在第一天)，此時(shí)對(duì)該功能的定義更加清晰(大約30％)。 測(cè)試工程師對(duì)功能的理解將改變他們對(duì)其進(jìn)行測(cè)試的方式，而了解所需的用戶行為將為測(cè)試流程提供依據(jù)。
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.
產(chǎn)品負(fù)責(zé)人可能將獲勝定義為讓用戶采取特定行動(dòng)。 如果是這樣，測(cè)試工程師必須幫助確定如何將用戶帶到那里。 隨著團(tuán)隊(duì)開始準(zhǔn)備模型，某些流程或概念可能沒有意義。 召集不遵循用戶流量或不會(huì)導(dǎo)致獲勝的模型是測(cè)試工程師和團(tuán)隊(duì)的工作。
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.
測(cè)試工程師不一定在這里發(fā)揮質(zhì)量保證的作用，但仍可以作為團(tuán)隊(duì)成員做出貢獻(xiàn)。 他們必須幫助識(shí)別不同的用戶個(gè)人資料和應(yīng)用程序的不同使用方式(即角色)。 對(duì)于測(cè)試工程師來說，在此階段最重要的事情仍然是一種理解：從整體上而不是單個(gè)票證要素上掌握功能。
第三階段：門票 (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%).
軟件票構(gòu)成了沖刺的大部分。 它可能從第1天到第10天發(fā)生。 門票使功能更加清晰(約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.
當(dāng)軟件工程師研究該功能并解決故障單時(shí)，測(cè)試工程師會(huì)進(jìn)行一些小型測(cè)試，以確保正確構(gòu)建該功能。 門票使該功能更加具體。 隨著功能變得更加確定，測(cè)試方法變得更加清晰。 測(cè)試工程師還應(yīng)該構(gòu)建管道以實(shí)現(xiàn)更快的反饋。
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.
這是很多信息，所以我建議測(cè)試工程師首先從字面上構(gòu)建一個(gè)將在每次提交或進(jìn)行任何更改后運(yùn)行的測(cè)試。 我建議先構(gòu)建幸福的道路場(chǎng)景，然后再進(jìn)行更詳細(xì)的測(cè)試。
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).
當(dāng)測(cè)試工程師處理這些其他更詳細(xì)的測(cè)試時(shí)，他們還應(yīng)該確定其他路徑：如果用戶旋轉(zhuǎn)屏幕會(huì)發(fā)生什么？ 如果取消，會(huì)發(fā)生什么？ 如果他們具有奇怪的功能組合會(huì)怎樣？ 該功能的潛在嚴(yán)重故障該怎么辦(例如，確保頁面加載并避免可怕的500錯(cuò)誤，或者確保網(wǎng)頁上的操作已準(zhǔn)確記錄在數(shù)據(jù)庫(kù)中)。
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:
這些其他路徑中的某些路徑將很常見，而另一些則不太常見。 測(cè)試工程師應(yīng)優(yōu)先考慮要測(cè)試的對(duì)象。 我建議根據(jù)以下兩個(gè)標(biāo)準(zhǔn)進(jìn)行評(píng)估：
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.
對(duì)收入或關(guān)鍵業(yè)務(wù)指標(biāo)有什么影響？ 測(cè)試工程師應(yīng)該使人們易于到達(dá)他們想要去的地方。 例如，在Flipp中，我們希望使用戶盡可能容易地獲得所需的傳單。 任何障礙都離不開質(zhì)量。
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.
它會(huì)影響保留率嗎？ 測(cè)試工程師必須確保該應(yīng)用不會(huì)崩潰，或者用戶不會(huì)由于任何計(jì)劃外的原因而退出。 他們還應(yīng)該考慮使用戶重新進(jìn)入或鼓勵(lì)他們重新打開應(yīng)用程序的方法。
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?
對(duì)于測(cè)試工程師而言，最重要的事情是，根據(jù)他們對(duì)獲勝的定義，他們優(yōu)先考慮發(fā)現(xiàn)的內(nèi)容。 他們還必須根據(jù)使用情況，影響和發(fā)生這種情況的可能性來確定整個(gè)功能的風(fēng)險(xiǎn)。 門票會(huì)影響多少人？ 問題有多深？ 如果應(yīng)用程序確實(shí)失敗了，將很難恢復(fù)嗎？
階段4：質(zhì)量保證和測(cè)試 (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.
質(zhì)量保證和測(cè)試從第5天到第10天(一直到發(fā)布)進(jìn)行。 此時(shí)，該特征應(yīng)為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.
隨著故障單的解決，測(cè)試工程師應(yīng)該查看他們?cè)谙惹半A段中制定的策略，并開始執(zhí)行他們的計(jì)劃。 他們將與軟件工程師合作，以提高清晰度或解決錯(cuò)誤。
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.
對(duì)于測(cè)試工程師而言，最重要的是確保與獲勝相關(guān)的功能清晰易懂。 除非有額外的時(shí)間，否則要固定好或應(yīng)該做的事情不會(huì)固定。
階段5：發(fā)布/部署 (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.
發(fā)布在最后一天(假設(shè)的第10天)進(jìn)行。 測(cè)試工程師的工作必須確保發(fā)布順利。 在發(fā)布之前，他們應(yīng)該在生產(chǎn)系統(tǒng)的副本上測(cè)試功能。 我們有一個(gè)特定的發(fā)布后檢查清單，用于使內(nèi)容保持一致。 我不會(huì)告訴你細(xì)節(jié)。
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.
該功能啟動(dòng)時(shí)，測(cè)試工程師應(yīng)密切關(guān)注數(shù)據(jù)以查看其是否處于健康狀態(tài)，并查看崩潰日志。 我們是人類，所以即使經(jīng)過測(cè)試，我們都會(huì)在某個(gè)時(shí)候錯(cuò)過一切。 即使是最仔細(xì)的測(cè)試工程師也可能不會(huì)想到的事情。
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.
更加智能的質(zhì)量保證始于在軟件開發(fā)過程的開始就考慮進(jìn)行測(cè)試。 這意味著在測(cè)試周期開始時(shí)將測(cè)試工程師與軟件工程師聯(lián)系起來，并從一開始就考慮各種場(chǎng)景和可能性。 這將使開發(fā)過程更智能，最重要的是，可以帶來更好的軟件。
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測(cè)試工程總監(jiān)Derwin 。 我在Flipp博客上發(fā)布了部分內(nèi)容。 如果您有興趣重塑人們的購(gòu)買方式，請(qǐng)查看我們當(dāng)前的職位發(fā)布 。
翻譯自: https://www.freecodecamp.org/news/quality-assurance-is-broken-heres-how-we-can-make-it-as-agile-as-everything-else-64bd19d5e426/
打破雙親委派么,怎么打破
總結(jié)
以上是生活随笔為你收集整理的打破双亲委派么,怎么打破_质量保证被打破。 这就是我们如何使其像其他所有东西一样敏捷。...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 梦到狗咬我手出血什么意思
- 下一篇： 小程序服务器域名5次_为什么您不应该在1