开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《头像生成 avatar-generator》
今日推荐英文原文：《What if the Customer Can’t Reproduce Your Bug?》

---

今日推荐开源项目：《头像生成 avatar-generator》传送门：项目链接
推荐理由：这个项目可以让你根据需要快速定制一个卡通人头像用在各种社交媒体等地方作为账户头像，允许用户调整诸如嘴型与鼻子等这样的面部细节以及肤色等，如果觉得麻烦也可以使用全部随机来让运气决定会得出什么搭配来。

---

今日推荐英文原文：《What if the Customer Can’t Reproduce Your Bug?》作者：Sandra Parker
原文链接：https://medium.com/better-programming/what-if-the-customer-cant-reproduce-your-bug-7ddb2b1dc276
推荐理由：在其他人无法重现可能存在的 bug 时寻找原因的方法

What if the Customer Can’t Reproduce Your Bug?

“What are we doing wrong?”

Software quality assurance and testing are complicated procedures that require dedication, technical expertise, an eye for detail, and hours of work. Testers are people who dive deep into your product and have a major impact on the final project’s outcomes. That’s why it is so important that the product owners understand well not only the importance of software testing but its pain points from within for more effective communication.

Today’s article focuses on bug reproduction issues that usually remain behind the scenes for everyone but testers, which isn’t always good for the whole software project’s quality.

“Can’t Reproduce” — What Are We Doing Wrong?

Many software testers sooner or later face a problem where a customer/their team can’t reproduce a reported bug. A bug that you spent time and effort investigating. You tried so hard to report it back in a clear and concise manner, and yet they throw the “can’t reproduce” verdict in your face.

Trouble communicating is the top reason why anyone on the team fails to reproduce a bug. Either a vague bug summary was provided or it was a great one that no one wants to read.

Someone might experience troubles reproducing a bug because of a tester’s actions as well. For example, they might have provided a vague bug summary, listed uncertain steps to reproduce it, or enclosed a useless attachment that either doesn’t demonstrate the bug correctly or doesn’t want to open at all. It’s even worse if you didn’t check the bug reproduction before getting to the report and it stopped reproducing after the cache was cleared.

In case you are sure that the bug was reported correctly and can be found by the application end users, you have no other choice but to defend it. This is achieved through communication with all stakeholders who can investigate and fix that bug in the future.

Questions You Should Ask Your QA Team to Find Out Why They Can’t Reproduce Your Bug

• Do you use the same testing environments (platform, browser, browser version, device, OS, screen resolution)?
• What type of internet connection did you and the testing team use?
• Has the team accounted for all the preconditions and steps for bug reproduction that you specified?
• Does your expected result of software behavior match those of the team as well as the expected testing outcomes stated in the project requirements?
• Do you or your team use any third-party apps or browser extensions that could affect the software’s performance?

Let’s Look at All These Questions in More Detail

First of all, in most cases, the team doesn’t finish reading your bug. In the best-case scenario, a person trying to reproduce your bug has read more than the bug summary and its attachment. That’s why it is no wonder some of the bug report attributes often get missed. Yes, it is as unfortunate as it sounds.

Do your testing environments match?

You have to specify which exact environment the team checked your bug in.

It is assumed that the environment of a reproducing bug was stated in the description of it. Therefore, you have to double-check whether your colleague who’s trying to reproduce the bug is using the same platform to do it (browser, device, operating system, screen resolution) as you did.

As an example, we once had a case where our tester reported a bug that could only be reproduced on iPhone 6 but no other versions. That’s why they specified the particular environment in the bug report description. A developer who had to process that bug report didn’t pay attention to the fact that the bug can only be seen on a specified device. Since they only had an iPhone 7 on hand, they couldn’t reproduce the reported issue. Only after we double-checked everything was the misunderstanding finally solved. The bug that used to occur on iPhone 6 exclusively was found and fixed.

What type of internet connection did you and the testing team use?

For the most part, such a question should be asked about device-associated bugs because the type of internet connection (wifi, 3G, 4G, etc.) can affect the performance of an application or site, so this information is really important and has to be clarified.

Although, it turned out this issue is not only relevant for mobile. On one of our projects, we found an interesting bug: The online store did not display a map of post offices available for certain delivery methods. We discovered it when everyone was working from home due to the quarantine. The customer team could not reproduce the bug. For them, it seemed as if everything was perfectly displayed. After a few discussions, we decided to put the bug under investigation. After a part of our team got back to the office, we found that the bug could no longer be reproduced.

Since some of the employees continued working remotely, we managed to discover a fascinating fact. With a home internet connection, the bug kept reproducing. Meanwhile, in our office, where the connection was more stable, the post office map was displayed successfully — just like on the customer’s side. That’s when we decided to include the information on the internet connection type and its speed in the bug report.

As you can see, the internet connection itself can be a reason for a bug. In our case, it led to certain customers being unable to place their orders in that online store.

Has the team accounted for all the preconditions and steps for bug reproduction that you specified?

Getting back to the issue of the team not paying enough attention to the bug summary and its attachment, sometimes the team misses some important information — namely how to reproduce a particular bug.

Frequently, qualified employees tend to think they have mastered a project’s functionality to the point where they don’t need to examine the steps to reproduce the bug and its preconditions thoroughly. That’s why it’s worth double-checking how exactly developers tried to reproduce your bug and whether they missed a step or didn’t take into account any preconditions.

We had a case where a bug was reproducing only after we marked one out of four checkboxes for one country in the settings of software under testing. We added all this information to the bug description, which our colleague didn’t finish reading, and as a result, they could not reproduce the bug since they were following the usual steps to reproduce one.

Does your expected result of software behavior match those of the team as well as the expected testing outcomes stated in the project requirements?

It happens. You reported a bug because it didn’t match the expected result specified in the requirements or even ones that weren’t specified, but you know exactly how the functionality should perform based on your experience, general standards, or just common sense. You should discuss this issue with your colleagues. Maybe someone on the team is relying on inaccurate information about the expected result of the software behavior. Do you or your team use any third-party apps or browser extensions that could affect the software’s performance?

And the last question to discuss is the one that could be asked by the bug report author. Sometimes, certain apps can conflict with each other. Naturally, this provokes software errors that QA analysts classify as bugs. Even VPNs can affect the work. Therefore, you have to make sure during the bug reproduction that there are no third-party applications installed that are able to affect the performance of the tested product and mislead the entire team. For example, you’re using a virtual machine for testing that can be less stable than the original platform or a browser itself. This also has to be clarified.

Our colleague once reported a bug displaying unnecessary web elements on a page. No one else on the team could reproduce that bug. As it was later revealed, the bug author used a spelling assistant application that was reacting to certain web elements.

Wrapping Up

The aim of a software tester is to assure stable and error-free software functionality and prevent users from spotting bugs. That’s why we examine and classify all the bugs you may ever encounter. We take full responsibility for the quality of a tested product, a high-quality bug report if necessary, and the high-quality processing of it.

If you find a bug that seems like a serious reason to cancel the product release and the team cannot reproduce it, you should definitely find out the reasons why by asking the questions listed above. This will not only shape your professional reputation but also affect the image of the entire QA department in the eyes of the development team. A company’s position in front of its end users is a fragile thing that is so hard to get yet so easy to lose through a single serious mistake.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《奇怪人头 avatar-generator》
今日推荐英文原文：《It’s time to start writing useful User Stories!》

---

今日推荐开源项目：《奇怪人头 avatar-generator》传送门：项目链接
推荐理由：在各种社交平台帐号上都提供了头像更换的功能，为了达到不和别人撞头像的目的，这个项目提供的各种自定义头像就很适合解决问题。它提供了类似于捏脸一样的头像生成方式，通过自定义各个部位来完成属于自己的独特头像——或是丢开一切，按一下全部随机按钮来享受缘分与艺术结合的创作成果。

---

今日推荐英文原文：《It’s time to start writing useful User Stories!》作者：David Pereira
原文链接：https://medium.com/serious-scrum/its-time-to-start-writing-useful-user-stories-29445eb83405
推荐理由：在开发需求过程中的一种方法：用户故事

It’s time to start writing useful User Stories!

Five simple tips for turning User Stories around from pointless to great!

“Can we break the user story up into the front-end and back-end?” a developer asked during the backlog refinement session.

The first time I got this question, I said, “No, because the user story needs to deliver value to the end-user.” However, I always got the same question during the backlog refinements. I wondered, “Maybe I am doing something wrong with the User Stories.”

I couldn’t understand what was going on. The User Stories were well written with precise acceptance criteria. I reflected over it for a while, and then, suddenly, I had the A-ha moment! The User Stories were more than an invitation for a good conversation. They were requirements!

Individuals and interactions over processes and tools — Agile Manifesto

During my journey as a Product Owner, I came across some typical issues with user stories. When I solved these misunderstandings the results skyrocketed. I would like to share the misunderstandings and their solutions so you can do the same.

What are User Stories

Let’s first understand what User Stories are. In bold, you can read the essential aspects.

• User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality. — Mike Cohn, User Stories

In the beginning, I didn’t believe in User Stories. I was a Business Analyst, which means I was used to writing extensive requirements. Moving to User Stories was challenging for me. I couldn’t understand how we could reach the goals without every minor detail written down.

The changing point happened once I understood the purpose of User Stories; collaboration. Everything is about conversations around the desired functionality.

“A great Product Backlog Item starts a conversation. The goal of this conversation is to establish a common understanding.” — Maarten Dalmijn, Great Product Owners write awful backlog items

1 — One step at a time

User Stories should have one single goal. Therefore, the word “and” is not welcome while writing User Stories. Imagine a platform like Airbnb, let’s prepare a User Story for the filters:

As a traveller

I want to filter accommodations by price, category and size

So that I can find precisely what fits my wishes

Great Product Owners aim to increase value as soon as possible, when adding multiple goals into a User Story, we do the opposite. So always ask: Does this User Story represent a single objective? If the answer is no, then divide it!

Considering our example, we could write three User Stories instead of one. Each filter can deliver value alone, and they have no dependencies, which gives the Product Owner the chance of prioritizing each item in a different moment.

“Big achievements come one small advantage at a time, one step at a time, one day at a time.” — Jim Rohn

2 — Use clear words within the acceptance criteria

Product Owner: I think the search needs some rework. It is not fast enough, in my opinion.

Developer: I don’t think so. For me, it is fast. It loads in less than three seconds.

In a discussion like this, “fast” has different meanings for the Product Owner and the Developer. Therefore, User Stories should have precise words. Avoid unclear terms as much as you can, when you notice you are falling into this trap, ask, “How can I measure the result?”

Let’s consider our previous User Story. The following acceptance criteria is an example of what not to do.

• The search result is quickly presented to the user

The word “quickly” leads to different understandings. For example, it can be three seconds for one person or any other time for another. So a better approach is to write the Acceptance Criteria measurably! For example:

• The search result is presented to the user in no more than 3 seconds

Photo by David Travis on Unsplash

3 — Don’t forget the invisible part

The crucial part of User Stories is never written; it’s the conversation with the team that matters the most. Without exchanges within the development team, User Stories are pointless.

Keep in mind that User Stories are not requirements; they are an invitation to a good conversation. Therefore, Product Owners should not describe solutions, but rather present problems to the Development Team. Then, a pleasant conversation flows, which leads to collaboration and a meaningful solution.

A common misunderstanding is to write detailed User Stories, which discourages the Development Team from starting a conversation. I used to write precise User Stories. Surprisingly, the only question I got was about breaking User Stories into technical boundaries. Avoid this pitfall, write just enough to encourage the team to have a great conversation.

I spent a lot of time writing User Stories. It made me feel great when all tickets were clear and the Development Team did not ask questions. I thought my developers should be happy with my effort and detailed explanations.

Except that I was all wrong. I would now consider my backlog items to both be bad and wasteful at the same time. — Maarten Dalmijn, Great Product Owners write awful backlog items

4 — User Stories are written from the user perspective

Many teams forget a vital part of User Stories. It’s written from the end-user perspective. I guess the end-user doesn’t care about front-end, back-end, and so on. Yet, many teams insist on breaking User Stories into technical boundaries.

• It’s time to shift our focus from delivering tasks to maximize the value.

Our focus is to deliver value instead of tasks that bring nothing. Once we accept splitting User Stories into technical boundaries, they only deliver value once integrated. Each part separated will not bring anything to the end-user. We should always ask how the end-user gets benefits from the User Story? No benefit means we are doing something wrong.

Photo by Kelly Sikkema on Unsplash

Why do the teams want to split User Stories into tech boundaries? Generally, because some Developers like having the User Stories assigned to them. Thus, being able to reach the status of “done,” then burning the story points. Be careful with this scenario. Scrum Teams should focus on collaborating. Individual performance does not matter; what matters is the result of the team.

A good story is one that goes through an entire technology stack. Or at least as much of that technology stack as is needed to deliver the feature. Stories split along technical boundaries gives us stories that don’t deliver any value to users on their own. A frontend (say, a web interface) does users no good until it is paired with a backend (a middle tier and/or database).

To avoid falling into the trap of splitting a story along technical boundaries, see if you can instead split the story based on the paths through the story. — Mike Cohn, Five Story-Splitting Mistakes and How to Stop Making Them

5 — Forcing everything into User Stories

A common mistake is: writing everything as User Stories. The backlog should be comprised only of User Stories is a myth. Let’s take a look at what the Scrum Guide says about the Product Backlog:

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering. — The Scrum Guide, November 2017

As you can see, the Scrum Guide does not mention how the Product Owner should maintain the Product Backlog. Which means we are on our own. We have the flexibility to define as it works best in our context.

I am a supporter of User Stories. However, it doesn’t mean we should write every single Product Backlog Item as a User Story. Some tasks just don’t go with the User Story format. Great Product Owners don’t lose the focus of maximizing the value. The point is, the Product Backlog should contain items that are understandable by the team.

Let’s explore one example of what not to do:

“As the Development Team, we want to have a backup routine for our database, so that in case of failure, we can recover the data.” Let’s be honest. This User Story is pointless. We can keep it simple: “Configure the backup routine for every 30 minutes.”. Be careful with too much focus on User Stories. Sometimes just some keywords would be enough.

The forced nature of ‘User Stories’ is especially obvious in non-IT environments. Meant to capture functional requirements in applications, the template isn’t all that useful outside of IT. It often leads to weirdly phrased or vague internally-oriented items, like “As marketeer I want to send a mailing to group X so that they are aware of new products” or “As team member I want to write a plan to see how Y can be done”. We prefer to ask non-IT teams to focus on putting the outcomes they want to achieve on the Product Backlog, not what they are going to do, e.g. “Notify group X of new products” and “Strategy for achieving Y”; — Barry Overeem, Myth 4: In Scrum, the Product Backlog has to consist out of User Stories

Wrap-up

User Stories are amazing once we understand the essence of it. Remember, it’s no more than an invitation to a good conversation. Some tips that will help you to benefit the most from User Stories.

• Write measurable acceptance criteria
• The conversation with the team is the most important part
• Write from the user perspective. Do not break into tech boundaries
• Do not force everything into User Stories, understand where it makes sense and where it doesn’t

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/