Video game to treat schizophrenia seeks FDA approval

The full (but short) article is here:

http://www.smartplanet.com/blog/rethinking-healthcare/video-game-prescription-brain-game-seeks-fda-approval/6831

Companies are developing computer games as therapies for  people with schizophrenia, depression, and anxiety. Should they be regulated, if so - how?

1. What do you think of the FDA getting involved in regulating this kind of software?
2. What amount of change to the app, the underlying OS, or the base hardware - will be tolerated before the application has to be re-validated?
3. Will the FDA regulate these as medical devices, or as medical smartphone apps? 

Study of Medical Device Recalls by FDA Over Last Four Years

Full report is from here:
http://htl.li/6EMdM

Excerpts from the article:

The information that is publicly available on the FDA website was used to determine the number of devices which had been recalled over the period from January 2008 to June 2011. The information was then analyzed on how often the FDA issued high-risk recalls of medical devices.

The second highest category comprises of recalls due to malfunctioning of device which showed 35 device recalls, that is, 29% of the total recalls.

Given the ubiquity and variety of medical devices in modern healthcare, it is inevitable that a proportion will fail to perform as expected, or even cause harm. What seems unacceptable is increasing number of medical device recalls and a system of regulatory approval for devices that lacks even a basic level of transparency for independent evaluation.

Comments:

1. So what do you think is the acceptable proportion of medical devices that fail to perform, or cause harm?
2. What do you think of the authors claim that the regulatory approval for devices lack the basic level of transparency for independent evaluation?

Opening propriety medical device software up for inspection and review

In the following article, the GNOME director argues for opening up propriety medical device software to review and inspection.  Read the article, and follow the footnotes and links.

http://www.zdnet.com/blog/open-source/gnomes-sandler-is-there-a-killer-in-the-code/9567

Issues raised:

1. Devices fail and people die - the public wants appropriate assurances that these deaths are investigated and effective corrective and preventive actions are taken.
2. The public is not completely ignorant of the vulnerabilities of the technology. "Trust us. We are the experts." - may not be a defensible public position for much longer. The public may demand objective, competent, 3rd party assessment of these products.
3. The FDA is going to have to learn to recognize the difference between "Checking" and "Testing" software, and begin demanding the latter.
4. With the surge in the use of medical device software, the public interest in regulating the risks to the patient of this technology will only grow over time.
5. Hacking will continue to grow as a concern.

1. What is your opinion about using open source software for medical devices?
2. What if someone created an open source hardware/software implantable defibrillator, that cost 1/20th of a proprietary solution. 
   
   Why would the insurance companies and the government not mandate their use?

 

Software Testing Insights: Magic and the EASY button

At TWST, I mentioned to Michael how much I enjoyed his recent "critical thinking skills for testers" video.
http://www.youtube.com/watch?v=ZEIAvD_Hoys&feature=youtu.be

In the video Michael asks, "Are we being fooled? How?".

What parts of our software systems do you think are susceptible to these kinds of problems during testing?

Little targeted videos seem to me to be an effective way to communicate to a broad audience.

Michael then reminded me of this video of James and Jon testing an EASY button:
http://www.youtube.com/watch?v=Vy0I2SB5OLo

First of all, it is fun to watch James and Jon do a Recon Test. Notice the huge benefits of video recording the activity: ease of documentation during the testing activity,the ability to review exactly what really happened, share with other people, and review for your own learning.

If you did a similar product Recon and recorded it, what would it show?
What if your whole group did the activity, what would it show?
What if your local software testing group did this activity over the next month, and shared the results?

And if you want to hack the EASY button, here are the instructions:
http://www.youtube.com/watch?v=6OEFxc3zTls&feature=related

James Bach Interview: Match the Metaphors

UTest has published a recent interview with James Bach.  James is always insightful, provocative, and can turn a phrase.   Here is the link:  http://blog.utest.com/testing-the-limits-with-james-bach-part-i-2/2011/09/

But don't read the article yet! Take this test first.

Match column A, with James's metaphor from column B:

A                                            B
testing maturity models          like frightened bunnies
certification                          like trying to invent an android that can talk to your wife for you
being a developer                   like a  possum 
the quest for the clever tool     a sin for testers
belief                                      like completing 25 crossword puzzles every day
tester giving a report               grand festival of waste
fake software testing                a tape worm parasite, living off our flesh

Pencils down. Now read the article. And Part II:
  http://blog.utest.com/testing-the-limits-with-james-bach-part-ii-2/2011/09/#more-14621

PS:  James says - "I’ve been playing with “R”. It’s a free statistical analysis system.
There are several books on it. I love tools that help me work with complicated data."
- I will have to connect him with Meijian

PPS:  The tool that has helped me most recently is my Canon solid state video recorder combined with my micro tripod.
- I will have to add one to my kit. I already have a flip video camera.

So what is your opinion on what James said?

TWST 7: Testers, stakeholders and ethical questions

Over the weekend I was attending a peer conference:
7th annual Toronto Workshop on Software Testing (TWST).

 The theme of the workshop was:

“Stakeholders: the tester’s duty to represent, and other ethical questions”.

1. Do we have a duty to represent the stakeholders of a software system?
2. How do we determine who they are?
3. If there are conflicting priorities, how do we decide which stakeholder group is “more important”?
4. How far do we take our responsibilities?
5. Are there other ethical issues with regard to stakeholders that you have experienced in your testing?

I found the subject particularly interesting since I spend so much of my time testing medical products. The patient stakeholder has very little power, bears the risks, and will suffer direct harm if there are failures. For me, there is an ethical responsibility to appropriately consider and protect vulnerable stakeholders. "Ethical Conduct" after all is the first principle in the World Health Organization's Handbook on GCP.

One interesting finding from the workshop was the concept of "the zeroth ethical stakeholder" - which is yourself. People need to be more self-aware of the ethical dilemmas they are entering, how they will resolve competing values between stakeholders, and what their ethical bright-lines are.

Ethical concerns are corrosive and need to be surfaced and dealt with - ethically and congruently - for the health of the people, the organization, and project.

1. Do you think testers have an ethical duty to stakeholders?
2. Have you had ethical concerns during your projects? 
3. How was it resolved?
4. How does the culture of your organization or project deal with people's ethical concerns?
5. What are your ethical bright-lines that you would leave/quit over?

Coverup of $217m software bug causes $2.5m penalty, plus accusation of fraud

Finance software bug causes $217m in investor losses

Dev pays $2.5m for hiding decimal-percentage flaw

http://www.theregister.co.uk/2011/09/22/software_bug_fine/

The article emphasizes a point that Cem Kaner makes about how the law is applied to software products. Software producers need to fully disclose their bugs that will materially impact their customers. Else you risk perpetrating fraud.

Our software does not have to be perfect (else we would never ship the product). But it is a reasonable expectation that when the producer becomes aware of a material defect in the product, they have an obligation to notify their customers of the defect.

“In 2009, an employee of Rosenberg's company, Barr Rosenberg Research Center, discovered a two-year-old bug in the code that caused it to incorrectly calculate risks.

How seriously do you consider correcting newly discovered problems that exists in multiple previous versions of the product? Do you discount fixing it because the customer has not reported the problem?

The error stemmed from the failure to reconcile the use of decimals in some of the data and percentages in other information, causing risks to routinely be underrepresented.

I have seen that exact same type of data precision error before. Have you?  What would it look like?

The employee disclosed his findings to Rosenberg and the firm's board of directors that same year.

I wonder if they fired him for finding and disclosing that bug all the way to the board of directors.

Rosenberg directed the others to keep quiet about the error and to not inform others about it, and he directed that the error not be fixed at that time,”

Did Rosenburg make an ethical choice with respect to all the stakeholders?

The error caused about $217 million in losses to more than 600 client portfolios.

In addition to paying the $2.5 million penalty, Rosenberg agreed to never again work in the securities industry.

The SEC said Rosenberg willfully violated anti-fraud provisions of the Investment Advisers Act of 1940.

The coverup is what really got him - because it lead to a fraud.  Plus he got the industry death-penalty.

What one lesson from this story would you apply to the way you manage your corrective action process?

Software Testing in the Medical Domain

by Ruud Cox, Patrick Duisters & Jurian van de Laar

http://www.improveqs.nl/files/testingexperience13_03_11_Cox_Duisters_Laar.pdf

A short three page article about how the particularities of the medical domain influences the organization of software testing. The authors make good observations and  their recommendations are similar to mine.

How do you react to the articles comments on traceability, the collection of evidence, risk-based testing, and exploratory testing?

Test Design Course's Bibliography - Cem Kaner

A New Course on Test Design: The Bibliography by Cem Kaner 

Good news! Cem Kaner is about to release his long awaited course on test design.

As part of that process, Cem has released the bibliography of the class - with over 500 references.

Bookmark the list, and happy reading!

Parking Meter HICCUPPS Too Expensive to Fix

Saskatoon Parking Meter "Cheating Glitch" Too Expensive To Fix
http://www.thecarconnection.com/news/1066342_saskatoon-parking-meter-cheating-glitch-too-expensive-to-fix
http://www.thestarphoenix.com/technology/Park+free+downtown+users+exploit+card+glitch/5316815/story.html

This is the intersection of a real issue from the field, and the practical application of M. Bolton's test heuristic HICCUPPS.  http://www.developsense.com/articles/2005-01-TestingWithoutAMap.pdf 


Great quote:  "I guess I was shocked actually that there was possibly a way to even do that kind of thing. I don't know who figured it out in the first place," he said in an interview Friday.

Some interesting questions:
a. I wonder what the organizational root causes were for this issue escaping were.
b. If the system was designed with roles or use cases, I wonder if there were any "cheater" roles/use cases.
c. It seems like such an obvious test, that I wonder if it was known before shipping the product - but not publicly disclosed.
d. I wonder how much the public embarrassment was worth in their mind, when they decided the fix was too expensive. 

Do you test for malicious intent or use, or exploitation of your systems?

Does your organization test using the HICCUPPS heuristic, per Michael Bolton's article? 

What parts of the HICCUPPS heuristic do you think are the strongest reasons to advocate for getting this issue fixed?  

Human ingenuity trounces automated methods: "Scientists Astonished"

Online gamers crack AIDS enzyme puzzle

from:  http://news.yahoo.com/online-gamers-crack-aids-enzyme-puzzle-175427367.html

I found this article an interesting parallel to software testing and soft project management.

Online gamers have achieved a feat beyond the realm of Second Life or Dungeons and Dragons: they have deciphered the structure of an enzyme of an AIDS-like virus that had thwarted scientists for a decade. 

This was a difficult problem that had frustrated smart scientists.

The exploit is published on Sunday in the journal Nature Structural & Molecular Biology, where -- exceptionally in scientific publishing -- both gamers and researchers are honoured as co-authors.

Their target was a monomeric protease enzyme, a cutting agent in the complex molecular tailoring of retroviruses, a family that includes HIV.

Figuring out the structure of proteins is vital for understanding the causes of many diseases and developing drugs to block them.

So solving this problem was meaningful.

But a microscope gives only a flat image of what to the outsider looks like a plate of one-dimensional scrunched-up spaghetti. Pharmacologists, though, need a 3-D picture that "unfolds" the molecule and rotates it in order to reveal potential targets for drugs.

This is where Foldit comes in.

Developed in 2008 by the University of Washington, it is a fun-for-purpose video game in which gamers, divided into competing groups, compete to unfold chains of amino acids -- the building blocks of proteins -- using a set of online tools.

Here is the link to the game.   http://fold.it/ 

This site could be a potential application for weekend testing.
http://weekendtesting.com/chapters/america

To the astonishment of the scientists, the gamers produced an accurate model of the enzyme in just three weeks.

 Astonished? Really? Because they were not recognized and certified as experts in this field by scientists?

Cracking the enzyme "provides new insights for the design of antiretroviral drugs," says the study, referring to the lifeline medication against the human immunodeficiency virus (HIV).

It is believed to be the first time that gamers have resolved a long-standing scientific problem.

"We wanted to see if human intuition could succeed where automated methods had failed," Firas Khatib of the university's biochemistry lab said in a press release.

What a nice quote:  "We wanted to see if human intuition could succeed where automated methods had failed." Jerry Weinberg introduced me to the MOIJ model. 
http://www.nkarten.com/moimodel.pdf  
http://www.estherderby.com/2011/07/empowering-leadership-ii.html 
It seems to me Firas did a "big jiggle" and changed the motivation, organization, and information around the problem.

"The ingenuity of game players is a formidable force that, if properly directed, can be used to solve a wide range of scientific problems."

To paraphrase:  "The ingenuity of people is a formidable force that, if properly directed, can be used to solve a wide range of  problems."  I would love to hear a debrief of this project. 

The folded protein problem was the easy problem. The hard problem is the shaping, enabling, and nurturing individuals and groups to be more effective problem solvers.

One of Foldit's creators, Seth Cooper, explained why gamers had succeeded where computers had failed.

"People have spatial reasoning skills, something computers are not yet good at," he said.

Score +2 for the humans. 

+1 for our collective intuition and spatial reasoning skills. 

+1 for project management choosing to stop ineffectively hammering on the problem with automated methods - and try something different. 

What I want to know is, "Why did it take ten years to jiggle the industry to try something different? And is that longer or shorter than we should have expected?"

"Games provide a framework for bringing together the strengths of computers and humans. The results in this week's paper show that gaming, science and computation can be combined to make advances that were not possible before."

Tools should create a framework for bringing together the strengths of computers and humans; striving to extend and magnify the capabilities of humans while remaining a servant to informed human judgement and ethics. If only all our software testing tools actualized this ideal.

What other 'three-week-technical-solutions' are being blocked by our unrecognized project management problems? 

What unsolvable technical problem do you have that might get solved by a big jiggle?

"Downgraded to Testing" by Jerry Weinberg

Jerry provides some career advice to a tester. 

While the whole little article is very good, I am going to pull one part of Jerry's advice out and comment on it.

Your boss has demonstrated he has no interest in "fair enough." And no interest in your career or your family. Your approach is all wrong. You should first find yourself a job in an organization that already values Testing, at least slightly.

In my experience, an organization like yours is never (at least in your working lifetime) going to value testing enough to value you, or pay you what you're worth to them. Nor will it be a good place to learn the profession. All you will learn is what I'm telling you now: that is, you shouldn't stay in this job a moment longer than you must in order to see that your family is fed. (For example, if your wife works, see if you can simplify your finances so you can live on her income, at least for a short time.)

In my travels, there were times where I fell into this trap. It is harsh to hear, "we don't value what you do very much" - technical people are sensitive to that kind of message. Jerry has defined quality as, "Quality is value to some person (who matters)". In this context, the boss matters and the value you are offering is lacking (from their perspective).  That is "OK". The organization is not pure evil and you are not a shlub. The answer is in between. Get over it - you are not going to convert them to your view of the world. Move on.

And one of the nice things about consulting is having to consciously work through the issues: "what is your value?", and "is the potential client's problem a problem for me?".  As I've gotten older I've become less emotionally wrapped-around-the-axel, and adopted a "It is just business. You are not giving me what I want - and I can say no to this relationship.".

Meat industry parallels to software testing

Govt. to expand E. coli tests in meat - Meat industry says added testing too expensive

Notice the parallels to software "checking".

Cost:  The meat industry immediately opposed the move, saying it is too expensive to do the tests and there isn't enough benefit.

Prevention versus detection:  "USDA will spend millions of dollars testing for these strains instead of using those limited resources toward preventive strategies that are far more effective in ensuring food safety,"

 Problem Severity: "People get kidney failure, people die, people have long-term complications. The number the bug has isn't really relevant."

 Expanding customer expectations:  At least one consumer advocacy group said it wants the department to go even further.

Do you find that your software testing/checking faces similar pressures as the meat industry?
How do you react to those pressures?
If the E. coli bugs were software bugs, how would you react?

FDA regulation: mobile applications and clinical decision support systems

The FDA recently held a public forum to discuss the regulation of mobile medical applications and clinical decision support systems. The meeting is discussed here:

FDA forum explores regulation of mobile medical apps

AMIA advises FDA on CDS mobile app oversight 

AMIA Offers Guidance to FDA on Regulation of Mobile Medical Apps

Text of AMIA PRESENTATION TO FDA Public Workshop - Mobile Medical Applications Draft Guidance September 12-13, 2011

 Here is a pull quote that is a good summary:

Nobody disagreed that the FDA should regulate mobile medical apps used specifically for diagnostic or clinical treatment purposes. But for apps in which the use might not be clearly defined, apps that are accessories to other medical devices, and accessories supporting medical apps, the opinions that were expressed reflected controversy and concern.

Mobile devices and the medical apps that support them represent a technology explosion, sure to make a revolutionary change in healthcare delivery. The crux is how the FDA can keep up with mobile developments, protecting patients from potential harms without stifling innovation and R&D investment.

Look at all these free medical applications:    Top 10 Free iPhone Medical Apps for Health care Professionals   and this Top 15 Free Android Medical apps for Healthcare

What is the FDA going to do when someone creates an anonymous free droid application distributed directly to the public that collects and analyzes ECG data - then it makes a clinical recommendation that is correct 97% of the time?  Will a 3% error rate be accepted if the cost is zero? 
 ---
Blog Updates:

FDA Law Blog: FDA Public Meeting on Mobile Medical Apps and ... By Carmelina G. Allis - Below is a summary of some of the key issues discussed during FDA's September 12 and 13, 2011, public meeting on the recently issued ... www.fdalawblog.net/.../fda-public-meeting-on-mobile-medica...

FDA public workshop weighs clinical decision support - AuntMinnie ... The FDA wanted to get input from panel members on how to assess these kinds of software, including important factors to assess, allowing the agency to ... www.auntminnie.com/index.aspx?sec=sup&sub...

Mobile medical apps, clinical decision support software FDA panel discussions on the difficulties of regulating clinical decision support software. www.emergogroup.com/.../fda-mobile-apps-workshop-getting...

Spitting Cheerios - How to Learn Faster

At PSL I had a social conversation with Jerry Weinberg that has stuck with me.

Jerry and I talked about dogs: our dogs, training our dogs, how to train our dogs, and lessons I learned while training my dog. It was an opportunity for me share my love of dogs with someone who I respect, who has that same passion.

Now Jerry and his wife Dani are expert dog trainers, while I am an enthusiastic amateur owner who went through one class. Some of the insights I learned from training my dog where:

• Trust is fundamental.
• You are always training your dog.
• What is called "dog training" is really "owner training".
• Be intentional.
• Be clear - simplify your communications.

When I first started training, I became frustrated with my inability to give treats to my dog. I was too slow and I would quickly run out of nibbles.

Finally I resolved to do something different.  I observed that my trainer had a treat pouch on her belt. So I bought one and started using it like she did. I filled it up with kettle corn popcorn, and would reach in and reward the dog when I saw the behavior I wanted. What a simple and optimized solution.

I shared that story with Jerry, and he replied: "I reward the dog by spitting Cheerios."

For two seconds the meaning of those words were pure moon-language to me. Then my solution crashed down like a house-of-cards in the face of Jerry's better solution. I tried it when I returned home - it is more effective.

So what does this have to do with software testing or organizational change? 

Before my conversation with Jerry, I had been thinking about how my "training-Griffin-to-train-my-dog" learnings were so similar  to "training-Griffin-to-be-a-better-change-artist".

• Trust is fundamental to taking risks.
• You are always training yourself, (especially when you are not training).
• Focus on yourself, not the other people.
• Be intentional.
• Be clear - simplify your communications.

And then I wondered, have I been "spitting cheerios", or using some inferior recognition/reward method with myself?
How can I have that positive reward waiting-on-my-lips (pun intended) for the exact golden-moment?
The metaphor forced me to re-examine some old habits and search for better alternatives.

I still struggle doing this, but learning how to "spit a Cheerio" is helping me learn faster.

Discount Code - Agile Development Practices East 2011

I'm a speaker at the Agile Development Practices East 2011 conference this November.
http://www.sqe.com/AgileDevPracticesEast/

Here is a special discount code, SPAS, that allows you to receive up to an extra $200 off your conference registration. Combined with Early Bird Pricing, which ends October 7, that means up to $400 off.

 

Surviving an FDA Audit: Heuristics for Exploratory Testing  

In FDA regulated industries, audits are high-stakes, fact-finding exercises required to verify compliance to regulations and an organization’s internal procedures. Although exploratory testing has emerged as a powerful test approach within regulated industries, an audit is the impact point where exploratory testing and regulatory worlds collide. Griffin Jones describes a heuristic model—Congruence, Honesty, Competence, Appropriate Process Model, Willingness, Control, and Evidence—his team used to survive an audit. You can use this model to prepare for an audit or to baseline your current practices for an improvement program. Griffin highlights the common misconceptions and traps to avoid with exploratory testing in your regulated industry. Avoid mutual misunderstandings that can trigger episodes of incongruous behavior and an unsuccessful audit. Learn how to maintain your composure during a stressful audit and leave with valuable heuristics to help you organize and present your exploratory testing results with confidence. 

The presentation will be similar to my presentation at CAST 2011, with more of an Agile development slant.

http://www.associationforsoftwaretesting.org/conference/cast-2011/proceedings/

BTW - I am interested in presenting to local software testing, regulatory compliance, and quality organizations or work groups. Please contact me.

The FDA's Audit Playbook and Auditor Etiquette

Want to know how the FDA is going to audit your Quality System?
Want to evaluate your system for yourself?
Why not use the FDA's own Guide to Inspections of Quality Systems (all 107 pages)?

http://www.fda.gov/downloads/ICECI/Inspections/UCM142981.pdf

This is one touch stone I use when I create, run, evaluate, and re-tune a Quality System. I am constantly asking myself how what I am seeing/hearing/reviewing is providing the quality and quantity of information I will need to successfully answer these questions.

How do you measure up? Where are you strong? Weak? Look for the root causes of your answers.

... meanwhile ...

When the auditor shows up...

http://carl1anderson.wordpress.com/2011/05/29/gxp-audit-techniques-etiquette/

Here are some reasonable expectations of how an auditor should behave and treat the subjects of the audit. Audit preparation includes considering how you are going to recognize and react to inappropriate auditor behavior.

Wouldn't it be interesting if the auditor set these expectations right in the beginning of the audit process?

"The Art of Compliance" by Robert A. Rhoades of Quintiles Consulting.

http://www.quintiles.com/information-library/white-papers/sustainable-regulatory-compliance/

"The Art of Compliance - Turning Regulatory Compliance into Sustainable Business Advantage" by Robert A. Rhoades - Practice Leader, Quality Systems at Quintiles Consulting.

The last few years have presented extraordinary regulatory and quality compliance challenges for pharmaceutical, biotechnology, and medical device companies charged to do more with less as a result of consolidation, restructuring, and economic uncertainty. Without the right attention, these challenges can permit systems and processes to weaken, domain and critical thinking expertise to erode, and core quality principles to be neglected, leaving companies vulnerable to compliance lapses and enforcement action.

Companies can no longer afford to take a traditional compliance approach in this heightened regulatory environment. In the traditional compliance approach, Quality Assurance and Compliance are backroom cost centers, the internal police or “sales prevention” departments perceived as piling on non-value added requirements that detract from the company’s ability to innovate and be profitable. 

This short white paper describes a strategic vision and business justification for the idea of "sustainable compliance", and moving up the "compliance maturity curve".   The use of maturity smells too much like CMM for my tastes, and I'm working on combining Robert's concepts with Jerry Weinberg's software engineering cultural patterns. Jerry gives each pattern a name, then describes for each pattern: view of themselves, metaphor, management understanding and attitude, problem handling, when the pattern is successful, and process results. 

 

I will keep working on recasting regulatory compliance into a model using a cultural view.

 

Meanwhile, where is your organization on Robert's Compliance Maturity Curve?

Medtech Conference and EuroSTAR Virtual Conference

Attending the Medtech conference today.
http://medtech.org/MEDTECH2011/sessions.aspx

... and watching parts of the EuroSTAR Virtual Conference.
http://www.vconferenceonline.com/vconference/default.aspx

More than 1,000 deaths linked to AED failures in 15 years

http://www.msnbc.msn.com/id/44364504/ns/health-health_care/t/bad-batteries-defibrillators-tied-cardiac-deaths/#.Tm4YVE-Ib60

Source information came from:  Annals of Emergency Medicine.
http://www.annemergmed.com/article/S0196-0644%2811%2901338-2/abstract

The conclusion states: "MAUDE (Manufacturer and User Device Experience) is often incomplete and frequently no corroborating data are available. Some conditions not detected by automated external defibrillators during self-test cause units to power off unexpectedly, causing defibrillation delays."

Seems that there needs to be both:
a.  better testing of the software and total system; and
b.  better system state logging so that effective root cause analysis can occur.

Can you image this kind of problem existing and being tolerated with the flight data recorders recovered from airplane crashes?

Two Approaches to Testing a Subway Exit

Watch the video. 
http://www.youtube.com/watch?v=Qx_8gxh76iM&feature=youtu.be
a. What is the requirement(s) being solved?

b. Compare and contrast the "steps" versus "escalator" groups.
Describe one instance of  testing that you saw versus checking.
http://www.developsense.com/blog/2009/08/testing-vs-checking/

What does "efficient" and "effective" mean for each group? Test variation? Test coverage?
Describe how the tests are under control, and how evidence during the test was collected.
What does "test repeatability" mean for each group?
How is each group mentally and emotionally engaged in the task?

c. Describe an instance where your testing looks/sounds/feels like the stairs. Like the escalator.
Did you intentionally make that choice when you designed the task?  Why or why not?

Wireless Medical Device Hacked

http://www.wired.com/threatlevel/2011/08/medical-device-security/

Here is a wonderful example of why software testing will continue to be needed in the future.

Imagine a worm that targets these devices.

James and Jon Bach on Testing

Here are some videos of James and Jon  Bach talking about software testing.

http://www.youtube.com/watch?v=ILkT_HV9DVU&feature=youtu.be

http://www.youtube.com/watch?v=3FTwaojNkXw

http://video.google.com/videoplay?docid=7894844001159492923

A potential testing tool

I found this:
https://www.smartsheet.com/

and I am thinking about how to adapt it to exploratory testing.