We know how to deal with functional requirements. We know they are important – we can walk the dependency chain from goals to use cases to functional requirements. But how do we get to the non-functional requirements? Leathej1 points out the elephant in the room – non-functional requirements don’t get enough attention when it comes to testing. Let’s look into it some more…
Agile / Foundation series / Process Improvement / Software development / Test Automation / Testing
Posted on:
Foundation Series: Functional Testing of Software
Functional Testing, also referred to as System Testing of software is the practice of testing the completed software to confirm that it meets the requirements defined for the software. A functional test is typically a test of user interactions, but can also involve communication with external systems. We contrast functional testing with unit testing. We also show how functional testing provides different benefits than unit testing.
Agile / Lists / Process Improvement / Software development / Test Automation / Testing
Posted on:
Ten Essential Practices of Continuous Integration
Martin Fowler has identified the key process elements of making Continuous Integration work. You could even argue that they are the elements that define Continuous Integration (done correctly). We include his list and our thoughts below:
Agile / Foundation series / Process Improvement / Software development / Test Automation / Testing
Posted on:
Foundation Series: Continuous Integration
Continuous Integration is the software development and quality process where all team members merge their code and verifies it frequently – at least daily. This verification project includes both an automated build process and automated testing. The main benefits of continuous integration come from risk-reduction and cost-reduction.
Process Improvement / Project Management / Software development / Use Cases
Posted on:
Where Did You Get That Estimate?
How good are our estimates? We can use PERT to estimate the time it will take to implement each requirement. We can use timeboxes to schedule the requirements within each release. If we don’t know how good our estimates are, its an exercise in futility. Scheduling is about more than predicting the future, its about knowing how much faith to have in our predictions.
Agile / Process Improvement / Software development
Posted on:
Getting agile – should we?
Should we adopt an agile process for our team? Methods and Tools has posted a two part article titled Adopting an Agile Method. In thier article, they explore five areas of consideration. We provide our thoughts on each area. Five areas to consider (from the article) Our organization’s culture Our […]
Agile / Interaction design / Process Improvement / Product Management / Requirements / Requirements management software / Software development / Use Cases / UX
Posted on:
Gartner research on Agile Requirements Definition and Management (RDM)
Gartner has a research report available for $95, titled Agile Requirements Definition and Management Will Benefit Application Development (report #G00126310 Apr 2005). The report is 7 pages long and makes an interesting read. Gartner makes a set of predictions for 2009 about requirements definition and management (RDM) systems, and the software created with RDM tools. Gartner misattributes several benefits of good process to RDM tools. We give them a 3.5/7 for their analysis – check out the details here.
Agile / Process Improvement / ROI / Software development
Posted on:
Two big benefits of incremental delivery
Tarun Upadhyay wrote a fair criticism of our previous post on why incremental delivery is good on his blog today. It is great that he is extending the conversation, and he makes some valid points. We definitely missed a big benefit of incremental delivery, and will cover it in this post.
Consulting / Foundation series / Process Improvement / Project Management / Software development
Posted on:
Foundation Series: Basic PERT Estimate Tutorial
PERT is a technique for providing definitive estimates of how long it will take to complete tasks. We often estimate, or scope, the amount of time it will take us to complete a task or tasks. PERT allows us to provide not only an estimate, but a measure of how good the estimate is. Good estimates are a critical element in any software planning strategy. In this post, we will present an introduction to using PERT, explain how it works and how to interpret PERT estimates.