Software the Agile Way....

http://scn.sap.com/community/design-thinking/blog/2013/05/10/design-thinking--so-what http://forty.co/value-balancing-desirability-feasibility-viability

- Programmers write more automated testes and focus on higher automated testing  - Manual testers are more focused on exploratory testing  - Documentation of BRS, FRS, Test Plans are totally reduced to a simple list of features with scenarios; i.e. BDD. This provides a common language that business users, programmers, testers can all understand share and collaborate on.  - Development Team is structured that programmer and testing skills are in the team.Instead team members pair up to both do development and testing in a highly iterative and incremental nature.  - Culturally the team succeeds when the work is done and meets the quality standards defined by the "Definition of Done". If something is wrong, all fail.  - Defects found in Sprint are actually not logged, but the developer / tester pair simply chat and fix it on the spot as the work to the Product Owner is not "Done" yet.  - Missing requirements are not bugs, but simply new requireme...

A good TCM application should contain those fields and if not should allow for customization of fields.  It's a good idea to categorize the test cases down by Feature/Function  Test Case Template  Test Case ID:  Unique number that identifies the test. Allows to build library of unique test cases  Test Title/Summary:  A sentence summarizing the Test case  Objective/Goal:  What we expect to achieve with this test case  Description:  Multiline paragraph field that explains what the test case does and will perform in detail  Setup :  What is required to setup the test scenario? Could be bulleted list of setup steps, hardware/software required, lab resources required etc.?  Test Steps:   Bulleted Test steps; each step detailing exactly what step needs to be performed and how. Some companies have to comply with some Govt. regulations etc., in that instance each test step should have an expected result (Pass/Fail...

When to use Waterfall Methodology: Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform. Weakness of Waterfall: All requirements must be fully specified upfront Deliverables created for each phase are considered frozen – inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)

Strategy First  it should be clear about what your strategy for automation is. (And don't say Automate everything. The people who think you can automate everything are just as wrong as the people who think you can manually test everything. Automation can help, but you need to know its strengths and weaknesses.) Plan Secondly, you should decide what success might look like. Most teams will do a lot better if they try to achieve something close to the testing pyramid , that being where developers write a lot of unit tests and specific integration tests with dependencies, and then a combination of devs/testers write service level, and API tests, but in a smaller proportion. lastly any UI should probably be kept small and focused on critical areas of the software (because they are so slow). Implement Another thing you should consider, is that automation efforts slow down, the further from the code it actually tests it is to develop. This means that while your testers may be pur...

What is a User Story?  Simply put, written from the context of the user as a simple statement about their feature need. They should generally have this format. "As a -role-, I want -goal/desire- so that -benefit-" How is a User Story different than a Use Case?  While a use case is highly structured and tells a story, the User Story sets the stage by stating the need. A User Story is the prelude to the use case by stating the need before the use case tells the story. How does the User Story fit into the process?   User Stories are great as an activity in collecting and prioritizing the high level features. Getting this initial feedback from the customer is a simple way of trying to get all of their needs identified and prioritized. The User Stories will then morph themselves into the   business requirements   and use cases. USE CASE Template-  Use Case Element Description Use Case Number ID to represent your use case Application Wha...

Listen deeply. " Consider what it feels like when you’re trying to convey something important to a person who has many things on his mind. Contrast that familiar experience with the more luxurious and deeply validating one of communicating with someone who is completely focused on you and actively listening to what you have to say with an open mind and an open heart." Ask, don’t tell.- " Open-ended questions, not answers, are the tools of coaching. You succeed as a coach by helping your team members articulate their goals and challenges and find their own answers. " Create and sustain a developmental alliance. " Follow-up is critical to build trust and to make your coaching more effective. The more you follow through on supporting your employees’ developmental plans, the more productive your coaching becomes, the greater your employees’ trust in you, and the more engaged you all become. It’s a virtuous cycle." Focus on moving forward positively....

http://www.softwaretestinghelp.com/bug-life-cycle/

● They are self-organizing rather than role- or title-based. ● They are empowered to make decisions. ● They truly believe that as a team they can solve any problem. ● They are committed to team success vs. success at any cost. ● The team owns its decisions and commitments. ● Trust, vs. fear or anger, motivates them. ● They are consensus-driven, with full divergence and then convergence. ' ● And they live in a world of constant constructive disagreement. —the characteristics of high collaboration and, thus, high performance (adapted from Tabaka 2006): 

A tester on an Agile team should not just be doing testing after implementation, but should be actively involved all the way through development.  They can spot testability problems and other gaps from the very beginning, help the developers design the implementation with testability in mind, and define the tests before and during development to help the developers hit the right target.  As this is the case, the tester really needs to understand the whole story, not just the testing aspects. Quality is the responsibility of an Agile team, not any one individual. Offloading quality tasks to Tester people is a handoff that decreases the responsibility as well as the agility of the team.  Offloading will not increase quality in the long run nearly as much has collaborating. These people should be integrated, which means they need to collaborate with the rest of the team on quality tasks as well as collaborate with the team on other tasks (including story pointing). ...