Components of a good bug report

A good bug report can improve over all communication of an Agile process. For e.g. A good bug report can help:

    • Managers in triaging bugs faster
    • Developers in reproducing the bugs faster
    • QA in verification of fixed bugs faster
    • Business Analyst in providing bug/feature clarification faster
    • Technical support in updating the customer about the open bugs faster

To submit a good report is quite tedious. It takes discipline experience and a solid checklist to write a good bug report every time a bug is found. Here is a quick checklist what a good bug report may contain: 

    • A summary/header
    • A clear description
    • Step by step recreation instructions
    • What error the steps produced
    • What were the actual results
    • Screen captures
    • Error and debugging logs
    • Setting a priority
    • Setting a critical status
    • Assigning the issue to the proper person or group
    • The area of the application/system where the issue was found.
    • The type of issue found
    • Linking to other relevant issues

And the list can go on depending on unique requirements of the company or application under test.

Author – Madhu Jain


Agile Test Automation is Incomplete Without Continuous Integration

Test Automation and Continuous Integration (CI) go hand in hand. In Agile world quick feedback is critical. Test Automation provides feedback about the quality of developed code and CI can accelerate that feedback!

What is Continuous Integration?

Continuous Integration is a software development practice where members of a team integrate their work frequently; usually each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. Martin Fowler

Continuous integration is an ongoing and rapid process. This means that teams need to be able to react quickly when a build breaks or new tests need to be built. In order to integrate a quality code into existing features, it is important to validate it against existing tests. If the tests fail, the code (build) should be rejected until either the bugs are fixed or the test cases are updated.

Below are the steps to deploy a quality code using automated tests and CI:

1. Use source code repository (Version Control System) – It is the first and required step to start using continuous integration. For e.g. Github, CVS, Perforce, SVN

  • Introduce check-in policy – Check in policy may be introduced after establishing source code repository. This depends on the team and length of the sprints. Firstly it involves storing all necessary files in repository. Secondly, each developer should check-in as often as possible completed part of work. Frequently integration show problem early and either solution is easy or rollback is necessary for only small part of solution.

2. Automate build – Next step is to perform build automatically – no more than one action should be required to start it. Either developer should start it manually or the build is automatically triggered after each code check-in (commit). The build process could be scripted using Ant, CruiseControl etc.

3. Create auto-deployable test environment and use automated test suite – After each build new version of binaries should be automatically deployed to test server. After each deployment, kick off automated tests to validate the committed code against existing features. The automated tests act as gate keeper for new code before it is integrated. It is time consuming to run source code validation but saves time during manual/regression testing and improves over all code quality. A solid automation test suite acts as a safety net and filters out the buggy code to some level.

4. Report and integrate – Report the status of automated testing. Having a pass/fail label can help in rejecting the buggy code.

  • Introduce re-submission policy: Developers need to investigate the failures with the highest priority. They either should fix the bugs or update the test cases and go back to step 1 for re-submission. Once all the tests pass, the quality code should be integrated to the master repository and deployed to staging for further testing.

Take charge and be curious!

Do you wait for the feature to be delivered before testing or test a product when it is being developed?

If a Quality Assurance Analyst wants to contribute to quality, they can do more than testing a product when it is delivered. QAs have many other duties during software development. They know the product very well from regression testing. They are aware of the various test input data sets. They understand the changing business needs and the requirements. They facilitate in environment and data preparation. They challenge the architecture and analysis, coach developers and define acceptance criteria to check their delivered product effectively on standards.  A tester understands and contributes to the release and deployment mechanisms. Over all more than anyone ‘testers are aware of products’ risks’.

So, DO NOT under estimate your position in flagging risky feature developments! Contribute in delivering high quality products by participating right from the beginning.

Product Development Phase

How can a QA rise and shine?
Sprint Planning
  • Take part in sprint planning, challenge it
  • Provide feedback about testing timeline
  • Flag risky estimations.
  • Set  code completion day
  • Set code blitzing day
Product Design  
  • Understand the design needs and its alignment with legacy code
  • Test the design or do walk through with the developer
  • Ask the rationale behind their decision.
  • Ask for prototype completion estimate
  • Validate your testing checklist
Delivery (Local deployment)  
  • Test, test and automate test cases
  • Involve team in testing
  • Create clean bug reports
  • Verify bugs quickly
  • Update testing infrastructure
Staging Deployment  
  • Facilitate UAT
  • Prepare test results report
  • Flag NO GO releases
  • Become a virtual documentation of the product.
  • Stay enthusiastic

From Agile Manifest – Direct Communication is the key!

Every team operates differently when it comes to software development using Agile process. However these two sentences directly from Agile manifest can help team work together effectively and enable QAs to shorten product feedback loop:

1. “Business people, developers and QAs must work together daily throughout the project.”
2. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

Does continuous testing feedback slow the software development progress?

I guess it depends whom you ask this question. Here is QAs take on this subject:

  • When testing provides continuous feedback, developers understand what is good, what is unreliable, and also what is important.
  • Continuous corrections towards the goal speed up the time to completion.
  • Testing isn’t a role with its own goal, QAs are there to help; and the most important help is speed, and the second one is quality (acceptable quality can be met in many ways, with testing it is faster.)

Someone might object and say “on the contrary, with all their phases and complaints, testing makes
things much slower!” however this might stand true for some.

“Good testing makes software projects go faster”

See original post