Sunday, March 31, 2013

Role and responsibilities of QA/tester in scrum/Agile world; How Agile improves the testing of software.

In traditional software development model QA/testers were actively involved in only certain phases of the project. After development finishes the coding the entire project was handed over to QA. In many cases QA and developer wouldn’t even know each other. All the communication will be through email or bug tracking system. I remember one instance when my project manager relocated the entire QA team to another building!!! He didn’t want the QA and development team to communicate face to face. We had different competency centers for QA and development teams with different career objectives and career ladder.   The QA team had a separate identity, a feeling of ownership over an entire phase of product. They were called the gatekeepers of quality.


Don’t fear the change


But in scrum apart from the sprint cycles there are no definite phases. In scrum there is a big change in the way team operates and interacts. In scrum there is no differentiation between a QA and developer. Scrum just treats them as two separate individuals with specialized skills who work together to deliver a quality product after the sprint.

One team (mostly collocated)

In scrum QA and developer are part of the same team and collocated (mostly). This helps in a better communication and team bonding.  They learn from each other. More focus is given to communication and knowledge sharing.

Many say that in scrum there is no place for QA/testers. This is not reality. We still need QA; not the old QA but the smart agile QA. It’s not about the number of bugs anymore. It is all about the quality of application which is delivered to the customer.

A much bigger role


A tester in agile world has a much bigger role to play. He has to wear multiple hats and every day the old beliefs and practices will be challenged. Don’t oppose it, embrace the change, It is for good. A QA in no longer limited to writing test cases and creating bugs in bug tracking system.



Some Additional roles and responsibilities.


Requirements

Be an expert in the application domain. Testers should help the team and PO write COA’s for user stories. Testers should be able to challenge the existing COA’s and propose a better one. Help the team learn some industry standards like Gherkin for COA’s.

Pair Programming

Pair with other team members to discuss the PBI or bugs. Don’t expect the developers to fix a bug or finish a PBI and then provide a build to test. Don’t create a mini waterfall in sprints.
  • Talk/discuss upfront about the possible impact of the change
  • Create test cases & update your documentation
  • Create test data or scripts
Developers are poor testers; help them to improve the testing skills. With the close interaction of testers, the unit testing will be improved. If the build is delayed, pair with the developer and test the fix in dev. machine. If you find any issues, later on it will save a lot of time in writing and explaining the new bug.


Test first approach


When team starts a new feature development, a tester can wear the customer hat and create acceptance test cases. I have seen in few projects where a new feature was introduced in release cycle and another PBI/bug was created to remove that on next release cycle!!!.  A proper understanding of the customer requirement would have prevented this situation (PO and other stakeholders should have handled this but that’s another level of discussion)

 

Design product suites


In big products multiple teams work on same products which are in turn linked to many other dependent products. I have seen few cases where the lack of cross product knowledge in teams has caused serious problems and issues. Testers can take this role of designing the features across the suite. If a feature was proposed for X product does it makes sense to move that to Y for a better customer satisfaction?

Improve metrics


Ask questions about the quality of the application. What is the test coverage of the features? Are there any performance issues? If the product has issues, then the QA engineers should always bring this to Product Owners and Scrum Masters attention. Work with them closely to reduce this technical debt.

Automation

The manual testing should be less than 10 % of the total testing.If the team is spending more than that then testers should learn any automation tools to automate the test cases. Without automation the life will be miserable. There is no value in doing the repeated work day after day. By automating the test cases the velocity of the team will increase drastically.

Exploratory testing


All the bugs cannot be found by automation tool. Always be ready to do exploratory testing with the new interfaces and products.  The unique skills of the QA will help the team to find and fix hidden bugs. If there is a pattern in these bugs, update the unit test cases or automation scripts.
In short a tester in an agile world is much powerful. A tester needs a change in identity – need a change in mindset to release software with a high quality each sprint. There is no glory in creating bugs in tracking system. Only thing which matters is zero defects with customer (if you can).There are no we testers and you developers.


Get in touch
Are you a tester /QA in agile world? Write to me about your challenges and your experience. I would love to hear from you. .

Read the following also

Wednesday, March 20, 2013

Pick of the day : Article - Boy Scout Rule Applied to Every Day Coding


this is a thought provoking article by  James Grenning

Boy Scout Rule Applied to Every Day Coding



http://www.renaissancesoftware.net/blog/archives/90

Whitepaper - Scrum : Agile innovation @ FedEx


Lighting Corporate Passion: Everything you need to know about FedEx Day



Introduction 


A FedEx Day is a 24-hour event in which employees deliver innovation to the company they work for.
It is called FedEx Day, because you have to deliver overnight, like the parcel delivery company. A FedEx Day is a fixed time box in which people are not disturbed for regular work. Within this time box, employees have total autonomy over the project they are enthusiastic about. They decide for themselves what they will be working on, who they are going to work with, and how they are going to do it.

Only one rule applies: 

People who sign up show the results to the company at the end of the FedEx Day. In short, a FedEx Day is about boosting motivation and creativity overnight by getting out of people’s way.


Business Model

The traditional business model regarding motivation is built around external motivators, the carrot and-stick motivation scheme. For simple, mechanical tasks, punishments prevent bad performance and higher incentives lead to higher performance. However, in more complex work, the majority of tasks in business require conceptual, creative thinking.

The traditional motivation scheme does not apply to these types of tasks. If you promise people higher rewards for better performance, scientific evidence shows that the results are worse. A FedEx Day can result in a boost of motivation and performance of your employees in only 24 hours (12 business hours).

Additionally many employees have great ideas for improving their work and the products of the company. Traditional management often does not provide the autonomy for employees to implement these ideas. Business is often hectic and the pressure on delivery is always there.
However, these employees often have the best innovative ideas, since they are the ones closest to the work. Organizing a FedEx Day provides a short time box of high-intensity work in which employees implement their ideas and present them to the company.



Read More  

Monday, March 18, 2013

Agile/Scrum - Continuous delivery - how to mange quality?


Scrum/Agile demands frequent delivery of software. Most of the companies develop software in a sprint of two weeks. (How to choose Sprint duration?) But many companies don’t release software that frequently. According to scrum principles software at the sprint end should be of shippable quality. But really is this the case?  Many teams who diligently deliver the software periodically complain that because of frequent release they are not able to fix all the bugs. Because of the number of bugs they have an affinity for longer sprint cycles. But in reality there is no co-relation between the sprint duration or release duration and the quality of the software produced after each sprint.

Slow down to move fast

If you or your team is in a vicious cycle of releasing software with bugs release after release – then stop what you are doing, review the process you are following


  1. Review the definition of “done” – Schedule a meeting with all stakeholders, decide on a definition of done. Only thing you have to remember is that after the sprint cycle customer should be able to use the software
  2. Too much content – If you deliver about average of 5 user stories per sprint cycle reduce it to 4 or 3. Then apply the definition of done. 
  3. Responsible for quality - Ultimately it is the PO who is responsible for the quality of the application but then that don’t mean that others can’t question the bad practices. There is no value in delivering a software with low quality, be if bug or performance issues. If you allow such practices to continue one day you will realize that you have more than 100 bugs to fix or application is performing so badly that customers have stopped using it altogether. Such drastic results or consequences don’t happen in one day they occur because of the continuous negligence of the good practices day after day, sprint after sprint. 
  4. Existing technical debts – There will be many cases when you inherit an old legacy application with lot of bugs and performance issues. You may be asked to deliver new features in every sprint. This is a very tricky situation which needs some careful analysis and thoughts. 
  • Talk to the customers and stakeholders – identify the most important issues for them and create (& implement) a plan to solve them
  • If a new feature is requested in the “problem” area inform the stakeholders about the dangers of making changes in those parts. Get a commitment from them to improve the areas. Try to convince them with figures. Few weeks back I produced an excel sheet with the hours spend in bug fixing one area of our application. The hours spend in bugs fixing was very high. It required only a fraction of that time to clean up the entire area. 




Some Additional links worth reading.



Sunday, March 17, 2013

What powers does a Scrum Master need to have



I have seen this conflict in many organizations which are new to Scrum/Agile. Most of them are transitioning to agile methodologies from the traditional methods. It’s very difficult for that management to let go the power hierarchy. They still want one single neck to catch. They never believed in collective thinking. Rather than motivation , their believe in pressure to get the work done.

Such dysfunctions exists in most of the organizations, scrum just exposes it.

ScrumMaster doesn’t run the scrum. He/She should help build a team, bring out the leaders in every member of your team. ScrumMaster helps the team to self-organize so that they can move forward without the classic “delay” of waiting for decisions. ScrumMaster is not a person who can be used as a single neck to catch or blame. Scrum is a collective team approach. If it succeeds everyone succeeds if it fails everyone fails.

ScrumMasters in such an environment have to do a critical job in the transition. You will have to use all your patience & wisdom to convince the management about the true power of collective thinking and working towards a common goal. Take them into confidence. Inform the stakeholders about the perils of not doing the things in scrum way. Show them the benefits of this lean thinking. Once the management observes the success, once that trust is established you will get more help from management and other stakeholders.


Advice based on my experience.

If the team is unable to meet the commitment, do a retrospective to find the root cause, once the root cause is identified make the necessary changes so that it is not repeated. Provide this analysis to the management also.
Keep the communication channel open to educate the PO, team & other stakeholders about the technical debts. Have discussions about the cost of not doing the right thing

Most important focus

  • Create a self-organizing team 
  • Remove the impediments of the team
  • Teach the team & company the values & principles of scrum
  • Work the stakeholders to reduce the technical debts
  • Be a coach & mentor for your team, help them take the correct decision 

Check the following article for more 
ScrumMaster’s Checklist - roles & responsibilities - http://www.theagileschool.com/2012/03/scrummasters-checklist-roles.html

If you take a pro-active approach then sure management will support you.

To do all these , as a ScrumMaster you might need the three most important powers :)

  1. Patience
  2. Strength & courage to take tough decisions & convince others.
  3. Scrum Process knowledge & passion to improve every day. ( remember learning never stops)
  4. Passion & commitment to improve the team & deliver value to the customers.



Wednesday, March 13, 2013

The Benefits of Regular Deployment



When developing software, it makes sense to 'fail early, fail often'; to become aware of mistakes quickly and to learn from them. This means being able to deliver software as early in development as possible. This makes it easier to gather opinions and promote discussions with the people who would want to use the application; and then respond to the feedback.

A nice article by James Moore


Read the full article @
https://www.simple-talk.com/opinion/opinion-pieces/the-benefits-of-regular-deployment/

The Benefits of Regular Deployment