Wednesday, January 2, 2013

Friday, October 5, 2012

Feedback Loops in SCRUM

What is a "feedback loop"? Put simply, a process has a feedback loop when the results of running the process are allowed to influence how the process itself works in the future.

Following are a list of feedback loops:
  • Pair programming
  • Unit tests
  • Continuous integration
  • Daily Scrums
  • Sprints
  • Code reviews
  • Static code analysis
  • Automated integration tests
  • Automated acceptance tests
  • Having the customer and business experts work closely with you throughout the process
  • Increasing the frequency of releases tenfold (at least to test environments)
The article I found below very nicely explains the importance of feedback loops in Agile projects:

Thursday, October 4, 2012

Metrics in Agile development

Interesting Read:

  • Total number of new defects found in each iteration
  • New features added to backlog in each iteration
  • New tasks discovered in each iteration
  • Number of resolved defects in iteration, etc

Monday, July 9, 2012

Automate if it adds value

"Automate if it adds value" is the driving force behind the creation if this short and simple shell script.


Though this script seems trivial but if we consider the task it is achieving, it is becomes important and its creation joyful. In our team we recently received hardware boxes to setup QA environment for testing. Usually the development environment and production releases something called release tool which is pretty much standard way of deployments. But for QA environment, since it is setup phase we have some constraints to setup the release tool. But we had decided in our retrospective that for every release from now on, we will complete QA testing using QA environment. Thus leading to QA environment setup gradually and leading to the requirement of QA deployments and this script. We plan for this with in our sprints. The DEV and QA, working on the story both take the ownership of setting up this QA environment bit for their release.


Now with this context, we had to make a temporary arrangement for deploying stuff to QA box. And I had already listed down a few sequential unix commands to achieve this. Eventually it became cumbersome, error prone and boring to repeat the same commands many times. So I thought of quickly writing a simple shell script to get this task done and make it interesting.


Three keywords:


1.       Simple

2.       Quick

3.       Interesting


I had seen many shell scripts in the past and executed them, opened them in VI and edited them but had never written them from scratch. So learning something new and of course achieving some automation makes it interesting. Initially when I started with the task, the simple requirements were; accept the application name, version and user details from command line and deploy to a standard path. As I progressed I added parameterization, error handling and positive and negative logging.


[Standard start of a shell script, shell and usage]



if [ $# -lt 3 ];then

echo "Usage: ./qadeploy /appMainFolderName /appVersion userLogin";




[Printing some messages indicating the start and making clear the input values]


echo "Starting QA deployment for $1$2"

echo "App to be deployed is $1"

echo "App version to be deployed = $2"

echo "User = $3"


[Creating a temp directory because it is required to change the owner of files before final deployment]


echo "Creating temp directory /home/$3$1$2"

`mkdir -p /home/$3$1$2`


[Using the Secure Copy command for copying from remote location, it prompts for password]


echo "Starting to copy to temp location..."

`scp -r $$1$2 /home/$3$1`

if [ $? -ne 0 ]; then

  echo "Error executing: scp"




[Change the permissions of the copied contents so that the next copy or move command will change the owner of the files]


echo "Changing permission to 777"

`chmod -R 777 /home/$3$1`

if [ $? -ne 0 ]; then

  echo "Error executing: chmod"




[Clear the already existing application contents]


echo "Removing previous entry for the app at location: /app/credit$1$2"

`rm -rf /app/credit$1$2`

if [ $? -ne 0 ]; then

  echo "Error executing: rm -rf /app/credit$1$2"




[Make the final move towards the deployment and clearing the temporary contents]


echo "Moving the app from temp (/home/$3$1$2) to real location: /app/credit$1"

`mv /home/$3$1$2 /app/credit$1`

if [ $? -ne 0 ]; then

  echo "Error executing: mv /home/$3$1$2 /app/credit$1"




[Deployment complete]


echo "Deployment complete for $1!"

Monday, June 4, 2012

Amazing Team Composition!

There are rare people in this world who get ideas.
It is rarer to find people in this world who get ideas and also are able to implement them.
It is still rarer to find people in this world who get ideas, able to implement them and remain organized to be efficient.
It is most rare to find people in this world who get ideas, able to implement them, remain organized to be efficient and continue to be like that for long.

So we need to be part of a team which has:
  •        An entrepreneur –  who  has idea(s)
  •       An implementer – with excellent implementation skills
  •        An administrator – who is organized and add efficiency
  •        An integrator – who keeps the team together
Most important thing: Mutual Respect amongst all the above. 

How? Read the book below:

I blog with BE Write

Monday, February 6, 2012

QA role in scrum team

The QA/Tester must definitely be part of the SCRUM Team. Given below are the reasons as to why I believe so:-

-QA in SCRUM is not an external entity. In traditional model, QA is someone who doesn't knows anything about the product, until he receives it for testing. And once he receives it for testing he is expected to read the (mostly incomplete) SRS/Requirements Document and then test the product against the same. In SCRUM, QA must breathe the stuff being developed along with the team. He is very much involved right from the requirement gathering, elicitation, and documentation. The programmers can walk up to him and clarify any of the doubts they might have, related to the current story/feature they are working on.

-QA helps developers in coming up with the list of Unit Test cases, which the developer can then automate. This relieves the QA from the burden of testing the routine or mundane test cases and instead concentrate on other forms of testing (Usability, Acceptance, Exploratory etc.), thereby ensuring the quality of the product.

-QA plays an active role in Product Backlog expansion and elaboration and is part of most of the meeting between ScrumMaster, and Product Owner.
SCRUM expects you to deliver potentially shippable code at the end of every sprint and this is primarily what is meant when the Team proclaims a story to be done. In other words, when the team proclaims the story to be done, then it means that story or feature is potentially shippable. IMHO, you can't achieve potentially shippable status unless and until its artifacts have been tested. I strongly believe that an external QA will never be able to keep pace with the speed of the SCRUM team. On the contrary, an external QA will negatively impact the velocity of the SCRUM team.

-QA participates in Daily SCRUM Meeting, Sprint Review, and Sprint Retrospective. BlogBooster-The most productive way for mobile blogging. BlogBooster is a multi-service blog editor for iPhone, Android, WebOs and your desktop