Proving Our Worth: Quantifying the Value of Testing
54 min 38 sec - Aug 10, 2006
Average rating: 
(9 ratings)
Description: Google TechTalks August 10, 2006 Lee Copeland has over thirty years experience as an information systems professional. He has held a number of technical and managerial positions with commercial and non-profit organizations in the areas of applications development, software testing, and software development process improvement. Now, as a consultant with Software Quality Engineering, Lee has developed and taught numerous training courses focusing on software development and testing based on his extensive experience. In addition, he provides consulting services to SQE's clients ABSTRACT The real purpose of testing is to create information. So, when managers complain that testing "costs too much" perhaps they are really trying to say, "I'm not getting enough valuable information to justify the cost of testing." Join Lee as he discusses why quantifying the value of testing is difficult work — perhaps that's why we concentrate so much on testing process—that's much easier. But until we do this difficult work, until we prove our worth through quantifying our contribution, we should expect the bombardments to continue.
Friday, November 03, 2006
"Proving Our Worth: Quantifying the Value of Testing" on Google Video
Thursday, November 02, 2006
Watch "Proving Our Worth: Quantifying the Value of Testing" on Google Video
Proving Our Worth: Quantifying the Value of Testing
54 min 38 sec - Aug 10, 2006
Average rating: (9 ratings)
Description: Google TechTalks August 10, 2006 Lee Copeland has over thirty years experience as an information systems professional. He has held a number of technical and managerial positions with commercial and non-profit organizations in the areas of applications development, software testing, and software development process improvement. Now, as a consultant with Software Quality Engineering, Lee has developed and taught numerous training courses focusing on software development and testing based on his extensive experience. In addition, he provides consulting services to SQE's clients ABSTRACT The real purpose of testing is to create information. So, when managers complain that testing "costs too much" perhaps they are really trying to say, "I'm not getting enough valuable information to justify the cost of testing." Join Lee as he discusses why quantifying the value of testing is difficult work — perhaps that's why we concentrate so much on testing process—that's much easier. But until we do this difficult work, until we prove our worth through quantifying our contribution, we should expect the bombardments to continue.
Want to see more cool videos?
Go to video.google.com/
Think you have an even cooler video?
Add it at video.google.com/videouploadform
If you're having trouble watching the video, try copying the following URL into your browser:
http://video.google.com/videoplay?docid=114463176347297820&q=Software+Testing&pr=goog-sl
Watch "Using open source tools for performance testing" on Google Video
Using open source tools for performance testing
1 hr 4 min 37 sec - Sep 8, 2006
Average rating: (44 ratings)
Description: Google London Test Automation Conference (LTAC) Google Tech Talks September 8th, 2006 Presenter: Goranka Bjedov
Want to see more cool videos?
Go to video.google.com/
Think you have an even cooler video?
Add it at video.google.com/videouploadform
If you're having trouble watching the video, try copying the following URL into your browser:
http://video.google.com/videoplay?docid=-6891978643577501895&pr=goog-sl
Watch "Becoming a Software Testing Expert" on Google Video
Becoming an Expert, an useful talk by James Bach
Becoming a Software Testing Expert
57 min 30 sec - Jun 13, 2006
Average rating: (64 ratings)
Description: Google TechTalks June 13, 2006 James Bach I work with project teams and individual engineers to help them plan SQA, change control, and testing processes that allow them to understand and control the risks of product failure. Most of my experience is with market-driven Silicon Valley software companies like Apple Computer and Borland, so the techniques I've gathered and developed are designed for use under conditions of compressed schedules, high rates of change, component-based technology, and poor specification. ABSTRACT You're already an experienced tester. You know how to design tests and report bugs. Now what? Do you feel like an expert? Unfortunately, if you want to become very good at testing, there aren't many classes or programs available to help you. This means you must manage your own education. This tutorial is about finding a path from experience to expertise. It's based on the context-driven school of test methodology. It focuses on what it means to think like a tester and how to design and critique testing practices (rather than just copy what the "gurus" tell you to do). You'll also get self-study strategies and methods for developing a colleague network. It's an ideal tutorial if testing is your career and you intend to excel in it.
Want to see more cool videos?
Go to video.google.com/
Think you have an even cooler video?
Add it at video.google.com/videouploadform
If you're having trouble watching the video, try copying the following URL into your browser:
http://video.google.com/videoplay?docid=6852841264192883219&pr=goog-sl
Wednesday, October 18, 2006
Thursday, January 12, 2006
Code with Character
Code with Character
by Tod Golding
When I'm writing code, I like my types to be straight shooters. I'm not into
types that are complicated or mysterious. It's simply too much work to
figure out who they are or what they might expect of me.
That's why some of my favorite data types are those that are willing to be
direct and honest with me.
Take my good buddy, Integer. An Integer data type doesn't pull any punches.
He tells you he will hold signed numeric data, and that's exactly what he
does. You try to give him a string or a date, and he'll laugh in your face.
You'll get nothing unusual past him at compile time. He's purely a "what you
see is what you get" type.
Integer is about as trustworthy as they come.
The String type is a little harder to read. He tells me he's simply a
handful of characters that are supposed to representany old literal string
and, for the most part, that is what he is. But he can be deceiving. One
time I discovered him in an application where he was holding numbers and
dates. It was very disappointing. You think you know a type, and then you
find out he's been playing games with you.
Still, String can be a reliable data type. I think he just strays from the
path once in a while.
Some time ago, back in the era of COM, I knew a data type named Variant.
This guy was unlike any other type I'd ever met. He was an integer, a
string, an array, and almost any other type you'd ever met before. At first
glance, you couldn't tell exactly what he was.
Despite his confused nature, Variant was always good about telling you what
mood he was in. If he was feeling like an Integer, he'd tell you outright.
You had to ask, but he'd be very quick to let you know.
So, even though you couldn't determine his state immediately, he gave you
very reliable means of finding out. And for that I was grateful.
It wasn't until this Object data type rolled into town that I really started
to question data types. Object was unlike any other type I had met before.
He was the chameleon data type that could somehow be whatever he wanted to
be. It was as if he had looked at all the other data types and asked if he
could be something more, something that broke through all the type
boundaries. This `60s, free-love spirit gave him a mystique that was
extremely enticing.
Naturally, this disposition also made Object a very popular data type.
Everyone seemed to want to have him around. Object was clearly the life of
the party, and pretty soon he became the "in vogue" data type that
developers just couldn't resist.
Object's appeal seemed rooted in something deeper than pure sex appeal. He
really seemed to be adding value to applications. If you wanted to write a
data container, for example, the Object data type allowed you to create a
general container that could manage any type that could be represented as an
object.
Imagine how different the .NET Base Class Library would look if there were
no Object data type. ArrayList, Hashtable, and the like--all staples of the
BCL--are made possible by the existence of this type.
To see more, please check out:
http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/Software_QA/
<*> To unsubscribe from this group, send an email to:
Software_QA-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Severity and Priority
High Severity with Medium Priority --- If Functionality is working but not 100% Accurate than we take that is in Medium Priority.
Tuesday, January 10, 2006
Code with Character
When I'm writing code, I like my types to be straight shooters. I'm not into types that are complicated or mysterious. It's simply too much work to figure out who they are or what they might expect of me. That's why some of my favorite data types are those that are willing to be
direct and honest with me.
Take my good buddy, Integer. An Integer data type doesn't pull any punches. He tells you he will hold signed numeric data, and that's exactly what he does. You try to give him a string or a date, and he'll laugh in your face. You'll get nothing unusual past him at compile time. He's purely a "what you see is what you get" type. Integer is about as trustworthy as they come.
The String type is a little harder to read. He tells me he's simply a handful of characters that are supposed to representany old literal string and, for the most part, that is what he is. But he can be deceiving. One time I discovered him in an application where he was holding numbers and
dates. It was very disappointing. You think you know a type, and then you find out he's been playing games with you. Still, String can be a reliable data type. I think he just strays from the
path once in a while.
Some time ago, back in the era of COM, I knew a data type named Variant. This guy was unlike any other type I'd ever met. He was an integer, a string, an array, and almost any other type you'd ever met before. At first glance, you couldn't tell exactly what he was. Despite his confused nature, Variant was always good about telling you what mood he was in. If he was feeling like an Integer, he'd tell you outright. You had to ask, but he'd be very quick to let you know. So, even though you couldn't determine his state immediately, he gave you very reliable means of finding out. And for that I was grateful.
It wasn't until this Object data type rolled into town that I really started to question data types. Object was unlike any other type I had met before. He was the chameleon data type that could somehow be whatever he wanted to be. It was as if he had looked at all the other data types and asked if he could be something more, something that broke through all the type boundaries. This `60s, free-love spirit gave him a mystique that was extremely enticing.
Naturally, this disposition also made Object a very popular data type. Everyone seemed to want to have him around. Object was clearly the life of the party, and pretty soon he became the "in vogue" data type that developers just couldn't resist.
Object's appeal seemed rooted in something deeper than pure sex appeal. He really seemed to be adding value to applications. If you wanted to write a data container, for example, the Object data type allowed you to create a general container that could manage any type that could be represented as an object.
Imagine how different the .NET Base Class Library would look if there were no Object data type. ArrayList, Hashtable, and the like--all staples of the BCL--are made possible by the existence of this type.
To see more, please check out:
http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea
Testing Articles on TechnologyEvaluations.com
Technology Evaluation Centers Inc. (TEC) is the impartial advocate for end users and purchasers of enterprise software solutions. It has aided IT professionals with software selection since 1993.
Organizations lose billions of dollars each year because a combination of inadequate evaluation processes and vendor information results in poor hardware, middleware, software, and service selections.
Monday, January 09, 2006
Software development magazine: UML and agile approaches, programming, testing
Methods & Tools is a free magazine with PDF and text issues that provide practical knowledge and information on all topics of software development and software engineering: UML, Agile Methodologies (eXtreme Programming, Scrum, TDD, FDD,..), Software Testing, Software Configuration Management, Database Modeling, Java, .NET, RUP, Software Project Planning and Management, Test Automation, Programming, Software Analysis and Design, Quality Assurance, Software Process Assessment and Improvement, Software Development Tools, Risk Management, Refactoring, IT News, etc.
