Apollo 11 Source Code

The software used to guide the Apollo 11 moon mission was written by Margaret Hamilton and her team at MIT in the 1960's.  The code is public domain and you can view it on github including this program for the lunar module: BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc .   Here's a link to the repo: https://github.com/chrislgarry/Apollo-11

Lean: practical applications

Lean originated in manufacturing and its principles can be applied in service and technology domains as well.  This is a running thread to collect examples of practical applications of Lean principles.

Test Automation: Lead with Strategy

I read a blog post today where a person described how their "management" suggested the test team watch free youtube videos to learn an automation technology and automate their testing.  I can imagine there was more context to this but suppose there wasn't.  Let's suppose that this wasn't just a frustrated complaint but an honest attempt to find a better way.  Here's an approach I recommend.  It starts with asking yourself some questions.

1. What are the strategies of the business, engineering, product, sales, ...?
2. What is your quality strategy?
3. Is your quality strategy available for others to review, learn, help improve?
4. Does your quality strategy include a visual roadmap showing test automation capability growth?
5. How have you invested in developing the relationships required for others to learn your vision and support it?
6. How have you invested in developing the relationships required for you to learn others visions and how you can support them?
7. How have you invested in self-guided learning?
8. How often do you contribute to and attend community-based learning/sharing opportunities such as Meet-ups, Tech Talks, conferences?

Bottom line: look inward, invest in relationships, and lead with strategy.

Drive Quality and Velocity with Test Abstracts

Six years ago, I began experimenting with Lean Test Plans as a way to help test teams drive project results. (I now call them Test Abstracts to distinguish from test instances that can also be called Test Plans.) Test Abstracts articulate the test approach and scope (what will be tested and how it will be tested). I also include an assumptions list, a risk register, a RACI chart, and important project related links.

When Test Abstracts are used, there is increased awareness that QA is tracking this collection of information in addition to testing and defect status. This contributes to successful on-time project delivery; risk and challenge visibility occurs early; meetings are effective and efficient as assumptions and risks are status checked quickly. Scope and timeline changes can be better negotiated and the quality-killing "QA Crush" at the end of the release cycle is lessened. The single page summary content has also been used to help auditors rapidly understand how the organization is going to achieve its compliance and quality goals.

Test Abstract elements

• Project name
• Project purpose statement
• Test approach description
• Test approach detail (bullet points)
• Link to the test plan (HP Quality Center, JIRA, TFS, Excel, etc.)
• Defect control links (tickets, queries, charts; HPQC, JIRA, TFS, etc.)
• Epic and story links (JIRA, TFS, VersionOne, etc.)
• Link to Project Management charter, detail pages
• Assumptions list
• Risk register
• RACI chart
• AUT/SUT diagram links
• Workflow diagram, process guideline, procedure, policy links

Observations

• Format is less important than content. My preference is for individuals doing the work to pick what works best for them (Confluence, SharePoint, Google doc, Word doc, etc.). Adopting what the Project and Engineering content is managed on is a good rule of thumb. When Test Abstracts are a new concept to a team, I help develop the content and demonstrate how it can be done.
• People like Test Abstracts. I found stakeholders like the early, clear communication. QA likes the control it gives them. As a manager, I like how Test Abstracts help us negotiate better when scope and timeline changes occur.
• QA Team confidence is higher when Test Abstracts are used.

Tips

• Use Plain English principles.
• Let Project Management manage dates. Train your team to discuss progress and expectations in terms of milestones in partnership with Project Management.
• A goal should be to have the main abstract page viewable on a single page or screen.

I've used Test Abstracts successfully at three organizations. A key to successful adoption is to identify and work with innovators and leaders on a team and provide a lot of support. Encourage them to experiment on making it work for them and perfecting it for their specific needs. As the early adopters experience success and ownership, others observe the positive results and join in.

Why do we test? What does QA do?

Recently I was asked for a definition of QA testing and what happens in QA in 1 to 3 sentences:

QA tests and checks software functionality, performance, integrations, and configurations.  We test to demonstrate that the software and system are "Fit-for-Use".  Testing and checking activities include requirements review, test planning, test execution, test progress and status reporting, development of test assets (diagrams, test cases, automation), and defect management.

Failures, errors, faults, defects, and bugs...

The Junit test framework TestResult class distinguishes between failures and errors.  The distinction is a failure is anticipated and an error is unanticipated.  I think this is a helpful distinction that can be used in general when describing problems we see when testing software.  Now, just need to do the same with faults, defects, and bugs.

"The test framework distinguishes between failures and errors. A failure is anticipated and checked for with assertions. Errors are unanticipated problems like an ArrayIndexOutOfBoundsException."

Three D's of a Quality Culture

These three D's are threaded throughout my quality journal:

• Discovery
• Dialog
• Diversity