The ISTQB-CTFL (Certified Tester Foundation Level) curriculum details 5 levels of testing, 4 test types, and 3 testing approaches.

The five levels of testing are as follows: Component Testing, Integration Testing, System Testing, User Acceptance Testing, and Maintenance Testing.  They are missing a needed sixth level, Smoke Testing. Perhaps one day they will add it.  Here is a description of all of them.

Smoke Testing: A quicks run through of all of the screens and reports within a system to ensure the developers gave you everything.  This ensures you don't get 2 days into testing a large app only to discover a ".dll not found" error due to the developers not including everything in the install package. Smoke testing should take now longer than 20 minutes or so.  Two added benefits once an organization has smoke test in place is that the implementation team can use the smoke test to test a new install, and if a production system goes down and is brought back online a smoke test and ensure all of it was brought back online.  But, I digress....

Component Testing: Checking each component of a system. There are 5 types of comports in software: 1. Screens, 2. Reports, 3. Interfaces, 4. Logic Modules, and 5. Data Structures.  Typically, component testing in software is checking each screen, and each report. The interfaces are tested at the next level.  While screens and reports are tested using requirements-based "black-box" testing, logic modules are best tested using "white-box" tools like logic trees and logic tables.

Integration Testing: There are two types of integration testing.  Internal integration testing is testing module to module (screen to report, for example).  External integration testing is testing system to system (your app to Paypal interface, for example).

System Testing: The best way to system test an app is to create a set of "typical day in the life of a user" flows representing different ways a user would use an app.  Providing all of the previous test levels worked reasonable well, system testing is a way to ensure everything is working together.

User Acceptance Testing: Once the system has been tested enough that the release success criteria has been met, the system should be shown to a real end-user for a final approval.  This should not be a surprise to the end-user.  In a healthy environment, the end-user should have been working closely with the development team as the software was created. Since the product should match requirements, any changes at this point would require updated requirements, and likely a new work order.

Maintenance Testing: This type of testing is used after an OS updated, or database change, or some other type of refactoring has occurred.

The Four Test Types found on the CTFL Exam are:

Functional testing (Black-box Testing): Requirements-based testing. When you cannot see the code, but all you have is a set of requirements, or user-stories. This is traditionally what people think of when they envision testing software.

Non-functional testing: Non-functional requirements are "implied" requirements which apply to the entire software app.  For example, security requirements, or HIPAA requirements, or PCI requirements.

Structural Testing (White-box Testing):This is used for component testing logic modules, where the developer share the code with you, and together you create flowcharts, logic trees, and logic tables.

Change Testing: This testing happens after a bug is found and the software is sent back to the developer, and the developer fixes the bug and returns the updated app to be tested again.

The Three Testing Approaches are:

Black-box Testing: For testing components with requirements, such as screens and reports. 

White-box Testing: for testing components where you can see the code, like logic modules.

Ad-hoc Testing: for testing an app when no requiems are present.  This can be due to time constraints, or perhaps you were just given an app and have to learn about it to create an approach and set of test plans to test it adequately.

I've been instructing students on the ISTQB-CTFL Certification curriculum for a number of years now.  I like to tell students the CTFL program is really a mini project-management training program.

Somebody hands you a software app to test, what do you do now?  You decompose the App in to smaller portions which make sense to you, constructing a Work Breakdown Structure.  Then you identify items to test within the WBS, organizing them by Test Plans. They you prioritize all test plans into a Test Execution Schedule so and your test team will know in what order to perform the tests.

You'll keep track of test coverage, and results, reporting on progress as you work through the app. Here's where it's important to communicate with your developers thoroughly so they can fix bugs you find and get the updated app install back to you for confirmation testing.

finally, when your testing matches the success criteria, you'll report of the final results of your findings and wrap up the testing project, adding lessons learned, estimates vs. actual, and other information into a test historical repository.

All of these activities are the foundation for project management.

In August of this year (2021), the Project Management Institute will release PMBOK 7!  This edition will be different than past editions of the PMBOK as PMI is emphasizing a descriptive program versus a prescriptive program.

The new Project Management Body of Knowledge will contain 12 Project Management Principles, which help guide decisions, 8 Project Performance Domains, and 7 Model Sets.  They are as follows:

12 Project Management Principles:

• Stewardship
• Team
• Stakeholders
• Value
• Systems Thinking
• Leadership
• Tailoring
• Quality
• Complexity
• Risk
• Adaptability and Resilience
• Change

8 Project Performance Domains:

• Stakeholders
• Team
• Development Approach and Life cycle
• Planning
• Project Work
• Delivery
• Measurement
• Uncertainty

7 Model Sets

• Situational Leadership
• Communications Models
• Motivation Models
• Change Models
• Complexity Models
• Project Team Development Models
• Other Models

ITIL, the Information Technology Infrastructure Library, was created by the British Government in the 1980's to address growing complexity in the management of IT infrastructure.  It is based on many of W. Edward Deming's quality principles, and Walter Shewhart's Plan-Do-Check-Act Cycle, which the Western world was just finding out about.

ITIL originated as a voluminous set of books which were simplified during versions 2, and 3, down to 5 books. In 2019 ITIL 4 was released, adding considerations for cloud-based management, DevOps, and Agile.

ITIL 4 emphasizes looking at an organization as a Service Value System (SVS).

Four dimensions that comprise a SVS are:

1. Organizations and People
2. Information and Technology
3. Partners and Suppliers
4. Value Streams and Processes

In addition, ITIL 4 covers governing the SVS, Continual Improvement, and multiple areas of practice, in which ITIL principles can be applied.

Mike Berry Red Rock Research

I just read Freakonomics: A Rogue Economist Explores the Hidden Side of Everything, by Steven D. Levitt and Stephen J. Dubner.

This New York Times bestseller is an analytical exploration into social cause and affect.  Using analytics, Levitt shows how he was able to detect administrative cheating in the Chicago school districts, prove that sumo-wrestling is fixed, and suggested which baby names will be most popular in 2015.

I can't say enough good about this book.  It was compelling to read, and a great mind-opener about the value of the relatively-new field of business analytics.

Mike J Berry www.RedRockResearch.com

September 6, 2017,  PMI will release Version 6 of the Project Management Body of Knowledge (PMBOK) Guide.  The updates in the new guide reflect slight adjustments to the framework expanding it to encompass managing equipment as well as human resources, and changing terminology from “control” to “monitor” in many areas.  In addition, PMI will publish the new Agile Practice Guide which will become PMI’s definitive resource for all things Agile.   

The PMP and CAPM tests will not change until January, 2018.

Knowledge Area Changes:

• Project Time Management > Project Schedule Management

• Project Human Resource Management > Project Resource Management

Process Name Changes:

• Plan Stakeholder Management > Plan Stakeholder Engagement (Planning)

• Plan Human Resource Management > Plan Resource Management (Planning)

• Perform Quality Assurance > Manage Quality (Executing)

• Control Communications > Monitor Communications (M&C)

• Control Risks > Monitor Risks (M&C)

• Control Stakeholder Engagement > Monitor Stakeholder Engagement (M&C)

New Processes:

• Manage Project Knowledge (Added to Executing)

• Implement Risk Responses (Added to Executing)

• Control Resources (Added to M&C)

Deleted processes:

• Close Procurement’s

The Project Management Institute (PMI) announced a new certification for Business Analysts.  Called the Professional in Business Analysis, the PMI-PBA is a program for business analysis, and many other professionals who perform business analysis activities.

Think of Business Analysis as what happens before a project, the Scope development and change management happening during a project, and the post-release RIO work that may happen after a projects.  

Before a large project concept is approved, a Business Analyst may be commissioned to perform a feasibility study, and assuming the concept is feasible, create a Business Case Analysis showing the most recommend option and a few lesser options.

Assuming the Business Case is approved by the proper authority, a project is created and the Business Analyst transfers their information to the new Project Manager and may or may not become part of the team.

If they become part of the team, they likely will manage the Scope baseline, while the Project Manager manages Schedule and Cost baselines. During this process they will also work closely with the Project Manager to implement change control.  They will also makea good 2nd witness for assessing how well the project team is working with other stakeholders.

When the project is complete, they will help evaluate the projects success criteria, which was put into the Project Charter from the Business Case they created. If the success criteria is met, the project can be Closed.  

Any post-solution deployment ROI work can be measured and calculated by the Business Analyst to determine if the target ROI was reached with the solution. This target ROI, and the pre-determined techniques to measure it are found in the Benefits Measurement Plan, also created by the Business Analyst to compliment the original Business Case. Multiple measuring points and a Statistical Process Control chart, and an efficiency frontier chart can be used to assess ROI.

Mike Berry Red Rock Research

The PMP, or Project Management Professional certification, indicates a person possesses years of industry experience participating in projects, and they understand the PMBOK framework.

The PMBOK, or Project Management Body of Knowledge, is a framework comprising 42 processes useful to managing formal projects.

Legendary in the industry, the PMP exam is one of the toughest professional exams out there.  It consists of 200 questions and takes most people the entire 4 hour allotment of time to complete.

The test is put together using Blooms Taxonomy, a learning framework that describes different ways people process learned information.   Recalling lists versus selecting the best option from a set of viable options are examples of categories in Blooms Taxonomy.

One major tip for passing the PMP exam is to expect to be reading questions in street lingo.  For example, the question may be a short story about a manager asking for something from her project manager.  The question will contain no terminology...you will be expected to translate the street lingo into the particular framework component being described and select the correct answer from the choices given.

I teach a PMP Exam Prep class and have many students who pass, and a few who don't.  What's the difference?  Quality study time.  Be sure you take this exam seriously so that you can benefit from the PMBOK framework concepts.

Mike J. Berry, PMP, CAPM, CBAP, ITIL, ACP, CSP, CSM, CSPO
John C. Maxwell Leadership Coach
www.RedRockResearch.com

Recently while coaching Agile to a large client in the Salt Lake City area one of the developers on one of the teams asked me why an Agile team should decompose features into one or two day units of work.  It seems, he said, the particular unit of work he was considering could not be broken down into anything smaller than 4 days.

This is a common question for groups first exposed to Agile.   Decomposing features into one or two day tasks can be challenging at first.  Here are several reasons why it is a good practice:

1. Breaking down features and large tasks into one or two day units of work forces the Agile team member to really understand the nature of the tasks.  Ambiguity is the enemy of success and large units of work really are ambiguous.

2. Smaller units of work limit the amount of risk that a particular task can adversely impact a schedule that was estimated incorrectly.

3. Decomposing work into many one or two day tasks gives the team member a win every one or two days.   They and their teammates will enjoy a sense of accomplishment more frequently, helping team morale.

4. Decomposing work in to one or two day tasks creates more transparency and precision so the team can account for completed work more accurately.  This many not be noticeable for one single work item but imagine the effect if the entire team kept work items at a non-decomposed level...too much ambiguity.

5.  Some teams I encounter hold stand-up meeting less frequently than daily.  This is a mistake.  Stand-up meetings should be held daily.  When I drill down and ask why, I typically hear that the team is reporting on the same work item the whole week.  Further questioning reveals they are not decomposing work into one or two day tasks.  When they start decomposing work into one or two day tasks then they have something new to report each day, and the stand-up meetings become more helpful.

Mike J. Berry Red Rock Research

I can't remember where I first heard of the book Leadership and Self Deception, an international bestseller written by the Arbinger Institute.  It's a short book, only 175 or so pages cut in a 5 x 8.5 inch format.

The cover is strikingly attractive, a collission of two black and white surfaces with some red spilling out.

The book talks about being "in the box" versus "out of the box" with respect to how we interact with people around us.  As we create false impressions of reality around us, through our own rationalization, self-deception, lack of empathy, or fear, and communicate with others under these pretenses, we put ourselves "inside a box."

Being inside a box adversely affects our ability to maintain the trust, respect, and finally peace with those around us.  Being able to recognize when we are leading ourselves "into the box" and taking proactive measures to stay outside of the box raises our emotional intelligence and helps maintain trust, respect, and peace with those around us.

Now let me say that the concept is groudbreaking, but the book is not.  I could only get about half way through this book before I had enough of the watered-down leechy "you've turned one sentence into a whole chapter, again!" prose.

The book is written from a "corporate fairytale" perspective and I have to say I feel like I am being patronized like a seven year old at story time when I read this book.  Instead of being to-the-point, the authors create a long burdensome drawn-out fabrication of actors and problems in a fictitious business culture.  You are supposed to read the fairytale and apply it to your own reality.

I suppose nursery rhymes caught on well enough, so maybe that's why this book is an international bestseller.  I would recommend you have someone explain the concept in the book to you, rather than spend the time reading it.  If you do read this book, just read the first few chapters, then read the captions under t ick-figure drawings throughout the rest of the book to get the point.