We are pleased to bring for the first time to the main stage, SQGNE Treasurer and Webmaster Alison McKendree to share her API development and testing insights. Most testers and automated test tools are oriented to the Graphical User Interface (GUI) humans interact with. That is necessary and important but can neglect much of software “guts,” where most of the useful work and complexity (i.e., source of defects) occur. A key approach to that involves the API, or Application Programming Interface, which Google describes as “a set of rules and tools that allows different software applications to communicate with each other. It acts as a messenger, defining how requests can be made and what kind of responses to expect, without revealing the underlying code.” What you will take away from the presentation:

• API development and testing concepts
• Enough information to be immediately useful/productive
• How API tools support the entire SDLC/STLC
• How API tools support all management, development and testing roles
• Skill building resources
• Just how much fun all this is!

In her first career, Alison was certified nationally as a Physician Assistant and worked eight years for a major medical institution. After earning programming and technical writing for software certificates, she started developing for several companies representing various industries before joining Aries as a Software Engineer in 2006. In 2012, as an Automation Engineer, she helped create a test suite of 295 automated tests. The past five years, she's been a Quality Test Engineer on Aries’ Quality Engineering (QE) team.

Our November meeting was joint with the IEEE Boston Consultants Network. Their incoming President, Mark Fitzgerald, gave a most-interesting jam-packed presentation on, "How Consultants Improve Software Quality / Opportunities to Work with SQA Professionals." The recording is under the Calendar at www.SQGNE.org (as is Gerie Owen’s October talk on cognitive bias) Mark deals largely with hardware engineering but has considerable interaction with software and software quality. His classic engineering orientation peeked through with references to international standards (which software folks are less likely to know and address) and design specs (which software folks are less likely to have). He started with a primer on software quality assurance that was more thorough than I suspect many SQA specialists could have put together. Consultants could help with any and all of the activities, especially assuring requirements are testable, setting up a requirements traceability matrix, documenting, and better understanding/complying with standards. He cited personal experience case examples Mark felt you shouldn’t start SQA until you have proper requirements, and you should automate most of your tests, probably with AI assistance. Consultants can help here too. Control can be aided by moving code from developer to integration to production “branches” (or regions). He suggested “using Agile for SQA” in a separate process from the developers, which meant that a testing sprint followed a development sprint. Then Mark shifted to describing why and how to engage consultants. Decide if you can/should use a consultant. Consultants can help reduce risk and bring intellectual property to your project. There are various sources for finding a consultant, including the IEEE Boston Consultants Network (CNET). Mark offered some tips for hiring a consultant and described several different contracting approaches, including retainers, which he felt could be used more. Please add your reflections and comments on Mark’s talk in the SQGNE LinkedIn post.