Email: Git best practice - break up Pull Requests into smallish commits

Hi All,

We have talked about the size of commits, the size of PRs, etc. and here is an example where I’m creating a small/medium sized feature which touches a lot of parts of the code

• environment data
• test data
• helper methods
• extending existing classes
• the test method itself

My goal here is to show an example of breaking a PR up into small, related commits so that it’s easier to code review.  The whole feature has to go in 1 PR because all the parts of this PR depends on all the other parts, and together it’s several hundred lines of code.  But if you look at the individual commits, it’s easier to see what I was trying to do.  I did an ok job with this but surely could have done better, especially the last commit, which is pretty big.

An important thing here is that just because you have changed lot of files or even if you have changed several parts of a single file, you do not have to commit everything you have changed.  Sourcetree makes it easy to “stage” files or parts of a file which will get committed when you call commit (for more on staging, see here).  This way, even if you have a lot of changes, you can still make commits that group related pieces of code together to make life easier for the code reviewer – and hopefully for all of us since the reviewer is more likely to catch any issues with your code.

QA Basics: How to Write a Defect Report

Generally, a bug/defect report should be self-contained and include all information required to reproduce and triage the bug.

Clarity and reproducibility are key.  The better bugs you write, the happier the devs will be.  Happy devs write happy code.  Happy code means less bugs!

The key components of a bug/defect report are:

• Title
• A concise summary, don't include reproduction steps (at some point you'll be tempted to)
• Description
• A discussion of what is wrong, possibly how it affects the user.  If you are familiar with the issue or the code, give that information.
• If there is a history with this issue or this type of issue, include it here.
• Environment
• version or build #
• platform or server
• browser (Chrome, FireFox, etc.)
• data such as user info (could also just be in Steps to Reproduce)
• Can include other things (on mobile you could include things like connection type of WiFi or Cellular)
• Steps to reproduce
• Actual result
• Expected result
• Evidence
• screenshots, logs, stack traces, etc.
• for search ability: copy/paste key parts of logs, error msgs, and the top several lines of stack traces.  Screenshots of logs or err msgs are fine but ALSO paste the text in the description or a comment
• Priority
• How urgent should we fix this?
• Severity
• How severe are the consequences of this bug when it does happen?

I like to format my Steps to Reproduce as shown below, to allow for a discussion after each step (numbers = actions, dashes = how the app behaves).

Most companies don't have strict formats, this is just my personal style guide (just as dev teams have style guides for coding).

1.login to www.xyz.com as user01 password abcd1234

2.put any item > $100 in the cart

-cart shows the item but not the tax

3.go to settings page, then go back to the cart page

-cart now shows item AND the tax

I've included multiple actions in step 3.  Personally I think this is ok as long as it's unmistakably clear.

Priority vs severity:

See this post.

Email: The easy way to remember how to write a test plan

Team,

Something you’ll probably have to do at some point is to write a test plan.  There is an IEEE standard for writing test plans but no one follows it (maybe the military).  Test plans vary wildly from company to company.  Too small and it won’t be enough information, too big and no one will ever read it.

It can be hard to remember what goes in a test plan but it’s a common practice and interview question, so I think of it like this:

• Who
• Who are the stakeholders
• Stakeholders can be loosely defined as “people with an interest in the project” such as project managers, product managers, key customers, your boss, etc.
• If needed, write a RACI chart
• Who will be doing the testing
• Who is on the team, do we have enough people, do we have the right people
• What
• What will we test (what is the scope of testing)
• Include a list of high-level areas we will test.  How specific you get will depend on the project. 
• What will we NOT test
• Include a list of what you will NOT test.  Sounds weird but this is very important to include.  This will include things like
• the customer’s servers
• security
• When
• Do we have a delivery date or a list of milestones (phases)?
• If we need to deliver by date X, development must deliver to us by date Y
• Where
• Environmental factors
• “we need a server with version 1.2 as well as version 1.4”
• How
• A discussion of tools we’ll use, testing types we’ll do (and maybe processes)
• We’ll use the API
• We’ll use Selenium
• We’ll do load testing
• We’ll test directly in the database
• We’ll use processes X, Y, Z 
• Why
• …doesn’t really work in this who/what/when way of thinking

On top of all of this, a few things to include are

• Risks
• the dates are tight here, any shift in development will push us back
• some environment goes down a lot or is out of our control (maybe it relies on the client or someone 3rd party)
• Dependencies
• we need credentials for X to complete testing
• we need better specifications for Y part of the system
• Results
• How will you measure your success
• How will you deliver that data