Software the Agile Way....

Tips for Effective Ice-Breakers ·          Keep it simple. ·          Make it fun. ·          Be creative. ·          Consider various types of Ice-breakers--don't just stick to "questions." ·          Consider your audience. ·          Be aware of time constraints ·          Keep in mind technology requirements. Consider using an ice breaker when: ·          Participants come from different backgrounds. ·          People need to bond quickly so as to work towards a common goal. ·          Your team is newly formed. ·        ...

For sustainability, the team really should own and evolve their standards instead of them being handed a bible. The coding standards can and should change over time. The key is clarity, testability, extensibility and maintainability of the code itself.   It is also important to establish from the beginning that the code base is shared by the whole team. No part of the code should be understood and maintained by only one team member.  Pair programming is the best way to get consistent adherence to standards. The key is the discipline of unit testing and refactoring

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/