5 Tips for Getting Software Testing Done in the Scrum Sprint
It is always challenging to create a piece of a software system that fulfills a customer need, ready for use. Especially when it should be realized in an iteration of just three weeks, from an idea to a fully functional and tested piece of the application. Achieving the ‘Definition of Done’ as it is called in the Scrum approach.
Agile approaches embrace short iteration cycles where releasable pieces of the software system are created. Releasable means also tested. Unit tested, system tested, functional tested, acceptance tested and often also performance and load tested. Making the item ready for use should allow providing feedback for the development team. Feedback how they are doing and if it is what the customer really needed.
Many teams find this a troublesome challenge and aren’t successful in it. They deliver half-done products or a make workaround for the agile approach (in Scrum often called ‘Scrum but’). Many agile workarounds contradict the goal why a team adopted an agile approach. For example a standalone test team or a separate test iteration to get the testing done will result in less agility and less feedback loops.
This article will give you five tips how a clear practice with the support of tools will help teams be more successful in delivering done products when using an agile approach. Actually many tips will also be helpful for other methodologies and project approaches. This article uses Microsoft Application Lifecycle Management tools as an example, but the tips are valid for any other ALM tool suite.
Many readers will possibly think "tools, wasn’t that evil in agile? People, interactions versus tools and processes". This is half-correct: it isn’t evil and yes interactions are very important and solve miscommunications way better than tools and processes ever can. However, tools can help. Tools and practices can support a way of working. Application Lifecycle Management tools suites, integrated tools with a central repository for all involved roles support collaboration between roles. They support collaboration between artifacts these roles create and teamwork between the work these roles execute. A recent Gartner report says that "Driven by cloud and agile technologies, the ALM market is evolving and expanding." 
Tip 1: Get a team
This is actually not a tip, it is a must. This is a kind of obvious but not common and the hardest thing to accomplish. Get a team, get testing knowledge in your team. When you don't have it, you will fail. Teams and companies have failed to reach their agile software development goals only because it was impossible to get different disciplines together in a team.
For example, the code implementation is done in an agile way, with Scrum boards and daily standups together with the customer. This is done because the customer wanted to be more flexible in what is needed in the system. However, software testing is done in a separate iteration and cadence because this role is the responsibility of a different department. Bugs are found in functionality realized sprints ago, testers needs more detailed requirements descriptions because they don't understand the backlog items, pushing the customer in the corner to be more descriptive and fixed till testing was done. The customer loses all the flexibility he needed and gets frustrated. This is just a simple example how it could go wrong when you don’t have a team. And there are thousands more.
It isn’t easy to accomplish a collaborative environment where all roles work seamless together. Testers and developers are different, as a nice quote from this ‘test’blog  describes it:
In the D-world, the world of the Developers, we think Generalist Testers are pencil-pushing, nit-picky quality geeks. Mostly they are beside the point and are easily replaced. They seem to like making much noise about little defects, as if we made those errors deliberately....
In the T-world we don't hate the Developers for their perceptions. We are disappointed about the poor quality of the software. Bad assumptions on the part of Developers are more to blame for the problems than are software weaknesses.
We never (or seldom) get software what will work right the first time. No, in the T-world we think that developers forget for whom they are building software, it looks like they are building for themselves...
If you try to combine these two worlds in one team, you definitely need to come up with a Collaborative Culture:
The three most important concerns are:
* A topic closely associated with trust when it refers to people is Identity
* Collaborative culture.
* A collaborative culture consists of many things, including:
* Collaborative leadership;
* Shared goals;
* Shared model of the truth; and
* Rules or norms.
* A "reward" for successful collaboration is most often of a non-financial nature.
Show me the value, seems to be the magic word. Test adds knowledge, knowledge during the grooming of the backlog. They help the product owner with defining proper acceptance criteria. Testers can help find improper written backlog items, finding inconsistencies in the flow of a business case for example. A great test activity in the TMap testing approach can help, assessing the test base. TMap is a test management approach which structures the testing effort by providing different phases and tasks, see the TMap.NET web site for more details. Simply explained: tests find bugs in the requirement. In both ways the test role helps the product owner and the team to focus on value.
Tools can help. The Visual Studio 2010 TMap Testing Process template gives test activities a more important place, helping the tester to get on board.
Visual Studio Process Templates are supporting a way of working. They contain several work items types with a flow. For example, a bug work item type can go from the status ‘new’ to ‘assigned’ to ‘resolved’ and ‘verified’. Such a work item can hold a lot of information, supporting the work that needs to be done to bring the work item to the next status. A process template is easy to customize and work item type fields, flow, validation and rights can be edited. Creating a new type is also supported. For example the TMap Testing Process Template has an additional type "Test Base Finding", helping the management of problems found in the test base (backlog).
The ‘Testing’ Tab with test activities, next to the implementation tab.
... to read more articles, visit http://sqa.fyicenter.com/art/