I'm here at StarWest 2008 with several hundred of my closest friends this week.
Yesterday I presented my tutorial on Becoming an Influential Test Team Leader. We had a really great time together as a class - all 70+ of us. It's always exciting to me to have this opportunity to present this session.
Today I present my half-day tutorial - Pairwise Testing with a Twist, which describes how to apply pairwise testing to scenario-based tests. This is a very interesting technique that can be applied to UAT and SOA testing or any time you need to test an end-to-end process.
I don't have any observations to report at this point, but once the main sessions start, I'll post some of the key points.
Tuesday, September 30, 2008
Tuesday, September 16, 2008
SOA Testing Online Training Course Finally Ready!
I've been working the past month or so to bring my newest course, Testing Service-Oriented Architectures to the online format. Well, the day has arrived!
To register and learn more about the course, visit:
https://www.mysoftwaretesting.com/ProductDetails.asp?ProductCode=SOA101
To see a demo:
http://softwaretestingtrainingonline.com/moodle/course/category.php?id=11
(you can login as a guest and stay anonymous.)
The great thing about my e-learning courses is that you can learn at your own pace. Plus, it's ideal for small teams. The online course has exactly the same content as the live course, except the lecture is more time-compressed (I don't take as long to explain things.) and the exercises are optional, but encouraged.
You may also notice I have a new shopping cart!
On another note about SOA, I was interviewed my Mike Kavis recently for an article at www.cio.com on "Six Questions to Consider Before Building a SOA Testing Team". You can read the article at: http://www.cio.com/article/448970/Six_Questions_to_Consider_Before_Building_a_SOA_Testing_Team?page=1
When it comes to testing, just like development, SOA has a different set of technology, business and project concerns. You really need to be thinking about the testing aspect of SOA early in your project because there are some far-reaching implications, such as performance and security that you just can't piece together at the end of the project.
I the article, I mention finding 2 or 3 people in other organizations that have some lessons learned and tapping them as mentors. You can't find every thing you need to know in books, articles and courses (even mine!). When you are on the "bleeding edge" of technology, you need people to brainstorm with!
Now I must go and get my September newsletter out. Have I mentioned I've been busy lately?
To register and learn more about the course, visit:
https://www.mysoftwaretesting.com/ProductDetails.asp?ProductCode=SOA101
To see a demo:
http://softwaretestingtrainingonline.com/moodle/course/category.php?id=11
(you can login as a guest and stay anonymous.)
The great thing about my e-learning courses is that you can learn at your own pace. Plus, it's ideal for small teams. The online course has exactly the same content as the live course, except the lecture is more time-compressed (I don't take as long to explain things.) and the exercises are optional, but encouraged.
You may also notice I have a new shopping cart!
On another note about SOA, I was interviewed my Mike Kavis recently for an article at www.cio.com on "Six Questions to Consider Before Building a SOA Testing Team". You can read the article at: http://www.cio.com/article/448970/Six_Questions_to_Consider_Before_Building_a_SOA_Testing_Team?page=1
When it comes to testing, just like development, SOA has a different set of technology, business and project concerns. You really need to be thinking about the testing aspect of SOA early in your project because there are some far-reaching implications, such as performance and security that you just can't piece together at the end of the project.
I the article, I mention finding 2 or 3 people in other organizations that have some lessons learned and tapping them as mentors. You can't find every thing you need to know in books, articles and courses (even mine!). When you are on the "bleeding edge" of technology, you need people to brainstorm with!
Now I must go and get my September newsletter out. Have I mentioned I've been busy lately?
Thursday, September 11, 2008
More on Agile, Requirements and Modeling
Today was the third and final day of the private conference I mentioned in my previous post. Today's keynote speaker was Scott Ambler, who discussed Agile Modeling.
A few notable things I jotted down from a 90-minute session:
* According to research at Dr. Dobbs Journal, 69% of those surveyed said they were currently using agile methods on projects, 15% of those that aren't currently using agile are planning to.
* In a 2007 survey (Dr. Dobbs), 72% of agile projects were considered successful, 63% of traditional projects were successful and 43% of offshore projects were successful. That's interesting! http://www.ambysoft.com/surveys/success2007.html
* According to the Standish Group in the Chaos Report, version 3, 45% of implemented requirements are never used. 19% are rarely used. Wow, that's a whopping 64% of features that probably no one would ever miss! Only 7% of the implemented requirements are used always.
http://www.agilemodeling.com/essays/examiningBRUF.htm
* To determine the effectiveness of documentation, ask "What is the probability that:
C - the documentation is correct
R - the docs are read
U - they are understood
F - they are followed
T - they are trusted"
Then, multiply C*R*U*F*T to get the overall effectiveness score.
* When you hand off a document to someone there is an immediate 25% information loss (much like the old game of "gossip").
* Models do not equal documentation. Modeling is a key scaling strategy for agile, is an important communication technique, and many agile practitioners perform modeling whether they admit it or not. Drawing on a whiteboard can be considered modeling.
Good information to think about!
Here's an interesting article:
A few notable things I jotted down from a 90-minute session:
* According to research at Dr. Dobbs Journal, 69% of those surveyed said they were currently using agile methods on projects, 15% of those that aren't currently using agile are planning to.
* In a 2007 survey (Dr. Dobbs), 72% of agile projects were considered successful, 63% of traditional projects were successful and 43% of offshore projects were successful. That's interesting! http://www.ambysoft.com/surveys/success2007.html
* According to the Standish Group in the Chaos Report, version 3, 45% of implemented requirements are never used. 19% are rarely used. Wow, that's a whopping 64% of features that probably no one would ever miss! Only 7% of the implemented requirements are used always.
http://www.agilemodeling.com/essays/examiningBRUF.htm
* To determine the effectiveness of documentation, ask "What is the probability that:
C - the documentation is correct
R - the docs are read
U - they are understood
F - they are followed
T - they are trusted"
Then, multiply C*R*U*F*T to get the overall effectiveness score.
* When you hand off a document to someone there is an immediate 25% information loss (much like the old game of "gossip").
* Models do not equal documentation. Modeling is a key scaling strategy for agile, is an important communication technique, and many agile practitioners perform modeling whether they admit it or not. Drawing on a whiteboard can be considered modeling.
Good information to think about!
Here's an interesting article:
Asimov solved internet fraud 30 years ago
See you later!Wednesday, September 10, 2008
Being Smart About Agile
I've had a great time this week at a private developer/tester conference at a large world-class company. I've been staying busy speaking and consulting here and enjoying every minute of it.
Today we heard a keynote address from Ivar Jacobson that was very interesting. It was about being smart in software development. Here are a few of the main points that resonated with me:
* Being smart means being agile plus doing the right thing in a particular situation.
* Knowing the right thing to do requires knowledge, training and experience.
* Interesting "factoid" - 90% + of companies still use waterfall methods.
* Small, cross-functional teams are best (10 people or less)
* Trying to define requirements early at a level of 80% completeness or higher is futile.
* Only 5 - 10% of requirements have a critical impact. These are the ones needed to build the initial interation(s) - the "skinny system".
* Agile isn't what it was 5 years ago. It's smarter today.
* Architecture is still important. Without it, you have a chaotic mess.
* On the other hand, "An architecture without executable code is a hallucination."
* Refactor over releases. Large scale refactoring is costly.
* "Whatever you do, you are not done until you have verified that you did what you wanted to do."
* We are all testers.
* A law of nature: People don't read documents
* Make sure your documents add value
* Practices over processes. Practices can be assembled from a variety of sources. They are separate but composable. In this way, you can select what works for you.
* Appropriate mentoring can help you become smarter faster.
* Change through evolution, not revolution.
* Agility responds to risk and unknowns.
I thought this was a thoughtful and helpful session. It gives me some new ways to think about agility as I help my clients make the transition from traditional methods.
Today we heard a keynote address from Ivar Jacobson that was very interesting. It was about being smart in software development. Here are a few of the main points that resonated with me:
* Being smart means being agile plus doing the right thing in a particular situation.
* Knowing the right thing to do requires knowledge, training and experience.
* Interesting "factoid" - 90% + of companies still use waterfall methods.
* Small, cross-functional teams are best (10 people or less)
* Trying to define requirements early at a level of 80% completeness or higher is futile.
* Only 5 - 10% of requirements have a critical impact. These are the ones needed to build the initial interation(s) - the "skinny system".
* Agile isn't what it was 5 years ago. It's smarter today.
* Architecture is still important. Without it, you have a chaotic mess.
* On the other hand, "An architecture without executable code is a hallucination."
* Refactor over releases. Large scale refactoring is costly.
* "Whatever you do, you are not done until you have verified that you did what you wanted to do."
* We are all testers.
* A law of nature: People don't read documents
* Make sure your documents add value
* Practices over processes. Practices can be assembled from a variety of sources. They are separate but composable. In this way, you can select what works for you.
* Appropriate mentoring can help you become smarter faster.
* Change through evolution, not revolution.
* Agility responds to risk and unknowns.
I thought this was a thoughtful and helpful session. It gives me some new ways to think about agility as I help my clients make the transition from traditional methods.
Monday, September 08, 2008
What's Big in SOA Security?
I got this question recently, so I thought it would be good to answer here as well. Basically, the question is, "With all the threats out there, which of them should SOA architects be concerned with?"
What I see most are the threats that are related to messaging in terms of access to the XML payload. In traditional applications, we have gotten pretty good at authentication (even though that is still hackable sometimes). However, in SOA with web massaging across HTTP/HTTPS, it is easier to find a point in the messaging process where the payload can be accessed. This can lead to a variety of attacks: malware, large payloads, XPath injection, etc.
In my SOA testing course (which is soon to be in an online format - stay tuned!), I describe the nature of these attacks. Most are similar to traditional attacks, except oriented to SOA. Take for example XPath injection. It is similar to SQL injection attacks, except is uses the XPath to gain access to data that is thought to be protected.
Keep in mind that SSL secures the message in transit only, while WS-Security maintains encryption until the message is processed. There are some other advantages of WS-Security over SSL, such as being able to specify securing only part of a message if you like. This can help reduce the performance cost of security.
What have you seen as the "big threats" in SOA security?
What I see most are the threats that are related to messaging in terms of access to the XML payload. In traditional applications, we have gotten pretty good at authentication (even though that is still hackable sometimes). However, in SOA with web massaging across HTTP/HTTPS, it is easier to find a point in the messaging process where the payload can be accessed. This can lead to a variety of attacks: malware, large payloads, XPath injection, etc.
In my SOA testing course (which is soon to be in an online format - stay tuned!), I describe the nature of these attacks. Most are similar to traditional attacks, except oriented to SOA. Take for example XPath injection. It is similar to SQL injection attacks, except is uses the XPath to gain access to data that is thought to be protected.
Keep in mind that SSL secures the message in transit only, while WS-Security maintains encryption until the message is processed. There are some other advantages of WS-Security over SSL, such as being able to specify securing only part of a message if you like. This can help reduce the performance cost of security.
What have you seen as the "big threats" in SOA security?
Subscribe to:
Posts (Atom)