The idea to write this post stems from reading some interesting bug reports from various OSS on Github issues. Instead of prescribing what should be considered the right or the wrong bug reporting, this post takes a different turn, and focus on asking basic questions, we should be able to answer when filing a new bug report.

At the end of the reading, you will have inspirations on how to make key daily improvements when filing bug reports, to direct developers in the right direction when reading and resolving issues being reported.

In this article we will talk about:

• Bug report based on GivenWhenThen user story formula
• Bug report for new and regression cases
  

Even though this blog post was designed to offer complementary materials to those who bought my Testing nodejs Applications book, the content can help any software developer to tuneup working environment. You use this link to buy the book.

What to expect from a bug report

When writing a bug report blueprint, we will have to answer thoroughly following questions in plain English.

The final product has is mold bug reports that have to fit in or blueprint our bug reports have to built around.

To start this exercise, let's take our typical bug report, and verify if it answers the questions below.

• How much does a typical bug costs
• Is it a bad idea to have developers do their own QA
• Is it a good idea to have developers do their own QA
• What is the optimal QA to Dev ratio
• What developers love to read in a bug report
• What makes developers hate reading a bug report
• What should go into a bug report
• What should not go into a bug report
• Why good bug reporting communication matters
• Can linking bugs to relevant user story acceptance criteria help fix bugs faster
• How can linking bugs to relevant user story acceptance criteria be done
  
• Should bug reports to have templates à l'instar of user stories
• What a functional bug report template should like

Answers to the question stated above, provide a starting point to create a blueprint of a bug report for your organization.

Conclusion

In this article, we revisited how to write bug reports that convey a clear message on what is wrong with the system, in a way that developers may re-use the bug report as a test case in their regression automated test cases. There are additional complimentary materials in the “Testing nodejs applications” book.

References

• Testing nodejs Applications book
• Bug Report Template ~ Marker Blog
• Bug and Issue Tracker ~ AirTable blog

tags: #bugs #bug-report #QA

How to write test cases developers will love reading

This blog is a followup to How to write a bug report developers will love reading. It stems from mixed experience reading bug reports, unit test messages, and feature requests on various OSS on Github and developers' blog posts.

Following in the footsteps of other blogs in these series, we will focus on asking basic questions, as opposed to prescribing some magic solution, in a way that triggers a rethink on state of test cases and/or user story(JTBD).

If you haven't already, read the “How to write User Stories developers will love”

The idea is to challenge our thinking into discovering improvements on the messaging, to make test cases actually validates, and ideally, prevent bugs from happening in the first place.

In this article we will talk about:

• Choosing the right wording when writing test cases, requires getting into how developers think and approach problem-solving.
• The best test case depending on the best user stories. For that, the reports are based on GivenWhenThen, in case user stories are.
• Choosing the right template for test cases, for new and regression cases
  
• Writing a testing message that aligns with features
• Writing informative testing message(on reports and logs)
• Case > Feature > Expectations

Even though this blog post was designed to offer complementary materials to those who bought my Testing nodejs Applications book, the content can help any software developer to tuneup working environment. You use this link to buy the book.

What to expect from test cases

It has been said that the best way to document any code block, is via its test cases. However, it is also true that some test cases do not provide a clear messaging around what the code blocks the are about to test do, or supposed to do. That is where the reflections in this blog are supposed to address. Moreover, there is little to no convention around writing such messages, which sometimes makes reading test reports quite futile if not un-readable.

This article tends to suggest the kind of message format to follow when we need our test message to make sense for us in the future, and for first-time readers. The message is based on observations found in popular open-source frameworks. To limit the scope, our observations are going to be based on the following frameworks: mochajs, sinonjs, expressjs and nodejs.

When writing the test case blueprint, we will have to answer thoroughly following questions in plain English. Our final product has is a mold test case that has to fit in, or blueprints our bug reports have to built around.

To start this exercise, let's take our typical test case, and verify if it satisfies the questions below.

• How much does a bug costs
• How do you define a test case
• What should go into a test case
• What should NOT go into a test case
• How can my testing messaging aligns with feature requests under test
• How can I evaluate if my testing message is informative enough for those needing to read test reports or assertion logs
• How to link test cases to acceptance criteria- How to model test cases around: (Use Case > Feature > Expectations)
• How to model test cases: (Given > When > Then)
• How to model test cases after JTDB (Jobs to be done)
• How to model test cases after user stories
• Is it OK to refactor test cases
• How do go about refactoring test cases
• Why messaging matters when crafting test cases
• What are the pros and cons of TDD vis à vis BDD test case
  
• Is it possible to use both TDD and BDD approaches in the same project

Answers to this kind of question provide a starting point to create a blueprint of test cases other developers will love.

Conclusion

In this article, we revisited how to write test cases that convey a clear message on what is wrong with the system, in a way that developers may correct the course with effective tests. As always, there are additional complementary materials in the “Testing nodejs applications” book, about how to write test in a nodejs environment.

References

• Testing nodejs Applications book
• BDD-TDD

tags: #bugs #bug-report #QA

The idea to write this post stems from reading not-to-clear user stories from various sources and projects. Instead of prescribing what is right, or wrong, we will take a different turn and focus on asking questions about the nature of user stories.

If you don't already know, this article complements “How to write Test Cases developers will love”

At the end of the reading, you will have inspirations on how to make key improvements on existing user stories, or how to make them readable and easy to digest by developers who will be reading and implementing them.

In this article we will talk about:

• Choosing the right user story based on ” As —, I want to —, so that —”
• Choosing the right user story template based on GivenWhenThen
• Choosing between user story and job story
• The only template job story will need “When —, I want to —, So I can —”
• Choosing verifiable acceptance criteria by developers and stakeholders
  

Even though this blog post was designed to offer complementary materials to those who bought my Testing nodejs Applications book, the content can help any software developer to tuneup working environment. You use this link to buy the book.

What to expect from a user story

When writing a user story, we will have to answer thoroughly following questions, yet in simple terms. The final product has to be mold our user stories have to fit in or template our user stories have to follow.

• Why would developers hate reading our User Stories (hint: they don't, they hate the way user stories are written)
• What should go into a User Story
• What should not go into a User Story
• Why does good messaging matter in our particular case. What is the definition of good messaging in our context?
  
• How can we leverage acceptance criteria as a vector to reduce the bug count
  
• What format are User Stories going to adopt
• Or, in known User Story formats(JTBD/etc) which format makes sense for our use case
• Why it is a good idea to give a say to developers when crafting a User Story
• Why is it a bad idea to give developers a say when crafting or validating User Stories
• How do we measure the performance of our new User Story template.

There is always a starting point. Instead of starting from nothing to answer these questions, It would make more sense to craft a typical user story(real user story), and test and answer questions based on a tangible example.

All criticism, or answers, should be targeted at making the user story at hand a little better.

Conclusion

In this article, we revisited how to write user stories that convey a clear message on what has to be done, in a way that developers may re-use the acceptance criteria as their test cases. As always, there are additional complementary materials in the “Testing nodejs applications” book that may be of your interest to.

References

• Testing nodejs Applications book
• Bug Report Template ~ Marker Blog
• Bug and Issue Tracker ~ AirTable blog
• Replacing the User Story with Job Story

#user-stories #bugs #bug-report #QA