System Theory

 I found that the system theory has produced a great influence in my thinking but I may not aware.

Use Flyway to manage the schema change

Upgrade the database is challenging.  Data may be already there while you are introducing the schema change.

The base schema may be different.  New customers start from scratch with an empty database.
Existing customers may be at the different patching levels and thus require different "ALTER script" to change the schema.

Flyway is not the most advanced system I have seen and it does meet all my expectations, but it is a helpful tool to manage this schema migration problem.

Test Failure and Test Blocker

Test Blocker

Blocking QA from testing may just require a small code fix or may just need a fix to the QA env configuration.

It affects the QA testing and affects the QA testing schedule and productivity.  Unblocking QA is critical and needs to be treated as an urgent issue.

Separate Environments Needed for Development

When I worked in a big company, these things are so obvious and I never really paid much attentions.

Having separate environment is so basic.  However, it requires some efforts to make people understand these requirements.

Here are the environments required for different purposes:

1. Development Env

• Dev team owns this. Ops may create it for Dev
• Developers have full access.
• Dev perform unit testing in this env
• Backup may be required so when Dev does something that may affect each other, we can restore to a clean env
• Creating such env from and old QA env, or refresh from QA env, so Dev can have some testing data is a good practice.

2. QA Environments

• Ops team creates it for QA
• Builds are applied to QA env for testing

There are various QA environments:

2.1 Feature development
Apply the latest builds for QA testing

Pickup a ticket from the backup

It is nice that a developer to pick up a prioritized ticket from JIRA without anyone assigning the ticket to him or her.

However, we also need to think about impacts of this approach.

Best Practice: Use JIRA for tracking your tests

Zephyr for JIRA is a nice tool for doing this job.

Best Practice: JIRA, source code, and build integrations

1. When a developer is closing a JIRA ticket, the checkin to the Git should be mentioned.

QA would typically like to know which build the fix is in.  However, it is hard to get the build number yet when the build has not yet done.  So the checkin number should be mentioned in the JIRA, and later we can use the checkin to locate the build.

Some systems can update the JIRA ticket automatically from the source control system or even from the build tool.  It will be ideal.

Monitor recently changed JIRA

To get notifications on the new issues created recently:

Build Automation: jenkins

1. Provide a view on the browser

This is similar to what Github can do.

2. Automate the build

Traditionally, after developers check in codes, we build the package for deploying to various environments for testing.  QA executes the tests against the env and log bugs if they find anything.

Jenkins is for automating these processes.

Bug Filing and Closing by QA

Here are the notes from today. Some useful guidelines:


When we file a bug, we need to ensure that there is an instruction of how to reproduce the issue.

We should refer the bug to a test case.

--

When we close a bug, we should also ensure that the issue is described properly in the bug.  This is including how to verify it.

If we do not already have a test case, we should consider creating one.  This is for regression testing to ensure the issue won't come back again.

In the end, all bugs, regardless that they are filed by QA or not will be covered in QA test cases.

--

No need to worry about too many test cases.  We still need to prioritize them.  Not all of them will be tested over again.

Also, some of them can be automated, while others not.  It is not a criteria for not creating a test case based on whether it can be automated.

Review: Aha

Aha demonstrates how a cloud apps works.  It is a requirement tracking software.  It has the integration to JIRA.

It manages the lifecycle before the requirements come to development in JIRA as a user story.



Releases are created for managing the target delivery for a specific deadline.  A release has a start date and an end date.
 https://support.aha.io/hc/en-us/articles/201226575

Releases are draw in a Gantt chart, called Releases Roadmap. The visualization using a Gantt chart is very powerful tool.  
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are created as containers of user stories.
https://support.aha.io/hc/en-us/articles/115001477463

Master Features are added to Releases.  Or more specifically, User stories from master features are added to releases.  When you view the user stories, you can optionally view the major features of that release, before drilling into the details to view individual user stories.

How to describe User Requirements

Persona

User Stories

User Scenarios

Handling bugs in scrum process

This is an interesting topic about how to manage and prioritize the maintenance efforts in the scrum process.

Identify testing scenarios as part of defining the requirement

When defining the requirement, it is also the time to define the acceptance criteria.  The requirement is about "I want the system to be able to do...".   When I started writing requirements, I also try to start with the sentence "You should be able to ...".

For example, the requirement is "You should be able use the same password to login to BI as the password used to login to Apps".  The testing scenario will be:

Doc Plan

Doc Planning is as important as the Dev/Feature Planning.
The Doc Plan should be part of the overall release plan.

Without documentation, the client may not know how to use your product.  The client may not even know that a feature exists.

Convert tweets to tickets

A modern service should allow your company to proactively monitor the issues and provide the services / clarifications without asking customers to open tickets.



Most of time, the first reaction when a customer run into an issue is to Google, not to contact you.

QA Test Plan Review and Sign Off

QA should come up the test plan that describes what will be tested and when the test execution will be started and will be done.

The Dev team should review and sign off the test plan.

Managing a Programming Project

I found this book in a library used book sales.

http://amzn.com/0135507723

This book first published in 1973 and the book I got is the 1981 version.

This book is still relevant.

It describe the SDLC as six phases: