Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science)
Wednesday, June 9, 2010
Books
Working Effectively With Legacy Code
Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science)
Test Driven Development: By Example by Kent Beck
Structure and Interpretation of Computer Programs - 2nd Edition (MIT Electrical Engineering and Computer Science)
Performance & Security Testing in Agile Development
6/9/2010
Tracy DeDore (HP)
Testing baked into each sprint: cant be a manual approach
Not uncommon to take a hybrid approach between agile/waterfall: scrummerfall
Important to be diligent when mixing practices
Non-functional testing often gets deferred till the end: risky
Functional/performance/security testing should be addressed in release planning & each sprint
automated load testing: bottlenecks/root cause analysis etc for performance degradation
wont have a working full application every sprint: need to be able to test components
headless/gui-less performance testing
Service virtualization tools: capture/model target system's behavior/performance so you dont need to use live systems for testing each time
static source code analysis: scan for vulnerabilities during dev: many false positives
step or path-specific business process testing
black box/dynamic web application scanners: requires a fully functioning app
leverage automation tools: allows dev & QA to test without being security experts
Tracy DeDore (HP)
Testing baked into each sprint: cant be a manual approach
Not uncommon to take a hybrid approach between agile/waterfall: scrummerfall
Important to be diligent when mixing practices
Non-functional testing often gets deferred till the end: risky
Functional/performance/security testing should be addressed in release planning & each sprint
automated load testing: bottlenecks/root cause analysis etc for performance degradation
wont have a working full application every sprint: need to be able to test components
headless/gui-less performance testing
Service virtualization tools: capture/model target system's behavior/performance so you dont need to use live systems for testing each time
static source code analysis: scan for vulnerabilities during dev: many false positives
step or path-specific business process testing
black box/dynamic web application scanners: requires a fully functioning app
leverage automation tools: allows dev & QA to test without being security experts
Manifesto for Agile Software Development
First principles of Agile, from http://agilemanifesto.org/
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Tutorial: Agile Use Cases
Instructor: Rebecca Wirfs-Brock
Rebecca is the inventor of the two column use case. She has been doing use cases since 1992. It was in a Smalltalk magazine that she published a use case with two columns. The side-by-side use case was born... no, No, NO.
Agile core values
Actor = a user or another system
Use case body forms
User stories are a similar to use cases.
From wikipedia: "A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software."
Rebecca is the inventor of the two column use case. She has been doing use cases since 1992. It was in a Smalltalk magazine that she published a use case with two columns. The side-by-side use case was born... no, No, NO.
Agile core values
- Design simplicity (use case application: simple writing leads to simple coding)
- Interpersonal communication
- High degree of trust
- Satisfying stakeholders
- Constant learning
- Decision making spread across project duration
- Information when needed ... just in time (often through conversations and additional tests)
- Functionality from a particular point of view
- ... describes a chunk of the system
- Can be a various levels: In the clouds (scope) and at sea level (code)
- Agile use cases are not so detailed
Actor = a user or another system
Use case body forms
- Narritive form
- Step-by-step form
- Side-by-side form (Conversational)
User stories are a similar to use cases.
From wikipedia: "A user story is a software system requirement formulated as one or more sentences in the everyday or business language of the user. User stories are used with Agile software development methodologies for the specification of requirements (together with acceptance tests). Each user story is limited, so it fits on a small paper note card—usually a 3×5 inches card—to ensure that it does not grow too large. The user stories should be written by the customers for a software project and are their main instrument to influence the development of the software."
Subscribe to:
Posts (Atom)