Software the Agile Way....

In the Scrum meetings, if the one of the team members are digressing from the agenda then  other team member will say "can we take this after this stand-up meeting" instead of Scrum Master saying this. In the daily stand-up meeting, team members are stressing on the done activities rather than discussing something which is not bringing clarity. Team is flexible to accommodate small ( non significant requirement changes) rather than becoming rigid in not accepting this. Team members respect each other and one conversation is going on during the meeting. Team members are asking question to PO on why this feature is needed? Team members are looking for improvements and taking interest during retrospective meeting to bring the topics without any fear. Team members are skilled and confident of the work and are not scared of ambiguity rather than working towards it to make it clear.  Team members respect time. Team members trust each other and do not depend on email or a...

C ommunication - Most desirable is face–to–face communication where we can talk, respond, gesture and draw on a whiteboard. Less desirable are written documents. XP stresses communication through practices such as pair programming. S implicity - This is a value of XP teams because it keeps their focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.They remain constantly focused on doing the simplest thing that could possibly work. F eedback - XP teams value feedback, and the more immediate the feedback the better. This is achieved by Pair programming, Continuous Integration,Automated Testing and from customers. C ourage - XP teams value courage. For example, they have courage to refactor their code (because they have automated tests to back up that courage).They will use a metaphor and maintain a simple design through refactoring and test driven development.

Technical proficiency -  automation can free the time of testers to do more exploration, which allows discovery.   Investigative curiosity Observational skills Communication skills Writing skills and bug advocacy Domain knowledge Willingness to learn Social skills Humor Practice "Testing is questioning a product in order to evaluate it . Software testing is about revealing the unknown." Source-  http://www.ebaytechblog.com/2013/01/31/becoming-a-world-class-tester/#.VTNlhNKeDGd http://java.dzone.com/articles/3-technical-skills-every

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

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

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

Usability - e.g Number of Clicks User Experience - e.g. Scroll acceleration Performance - e.g. latency and Throughput Sizing  - e.g. Period of Transactions to keep Scalability -  e.g. multithreading/multiprocessing Availability  - e.g 3-9s/4-9s/5-9s Security - e.g. authentication/authorization  Certificates/Legal etc  

Automation Testing Automated tests are important, but they can't always address the complexity of finding potential problems related to usability, reliability, performance, compatibility and other quality criteria. Automated tests can't ensure the documentation matches the final product. They don't typically cover test scenarios past common use (like disfavored use or extreme use).  Automated tests are great for testing specific aspects of functionality, but for complex applications they aren't so great at testing the platform dependencies (external hardware or software, deployment configurations).  They don't often address issues related to operations (dealing with how data ages, alarming/alerting, logging, etc.).  And automated tests aren't often focused on relationships between the product and time (concurrency, changing rates or transactions, or delays on input). Exploratory testing: Exploratory testing to help inform the project team about p...