Software the Agile Way....

Jez Humble and Dave Farley defined the following principles in their Book “Continuous Delivery”: Repeatable reliable process  – use the same release process in all environments. If a feature or enhancement has to work through one process on the way into the integration find a way of popping up. Automate everything  – automate your builds, your testing, your releases, your configuration changes and everything else. Manual processes are inherently less repeatable, more prone to error and less efficient. Once you automate a process, less effort is needed to run it and monitor its progress – and it will ensure you get consistent results. Version control everything  – code, configuration, scripts, databases, documentation. Everything! Having one source of truth – and a reliable one – gives you a stable foundation to build your processes upon. “Bring the pain forward”  – deal with the hard stuff first. Time-consuming or error prone tasks should be dealt with as soon...

1.  Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs. 2.  Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change. 3.  Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place. 4.  End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust. 5.  Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs. 6.  Institute training on the job. 7.  Institute leadership. The aim of supervision should be to help people and...

How should the software perform when the network is slow? How should the software perform when the network has 5% packet loss? How about 10% or 30%? If the software requires a persistent connection, what needs to happen when the user steps into an elevator, or when the device goes to sleep, or when the application is interrupted by a phone call? The standard screen resolution for smartphones is 320x300 pixels, but tablets are larger and next-generation mobile devices can support HD screens. What should the user see in all that extra white space? We integrate with Facebook, Twitter or Google login. What do we do when that service is down, and how can we test it? Source- http://searchsoftwarequality.techtarget.com/tip/Mobile-application-requirements-Same-process-new-challenges

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...