Regression Testing

By Jon M. Quigley

 

I saw a LinkedIn post yesterday about scope of testing during times of compressed schedule. The position was to test what is new in the software, and of that new, what is the most important, perhaps meaning what if it goes wrong, would be the worst for the client or customer.  Generally this is probably a good idea. However, there are some drawbacks to this approach.  This means no regression testing. Regression testing is testing of the old software features when we add new software features to the product.

Testing as above, is predicated on the belief that those things that we have changed or added, have no implication or impact on those features and functions that were already in place prior to this last iteration of the software. That may not be true.  If we make changes to some software module that is used by other functions, we may miss testing a change in … Continue reading

5S

If you have spent any time in the automotive industry you have probably spent time working within a system called the 5S. Continue reading

Patent

How do new ideas occur to us? What is the secret mixture that enables this spark that creates something new?  I have long wondered this, including when watching my son build things that I found interesting, and with no clear sign of what of the source of that idea that became reality.  I saw him build things with Lego blocks, and I watched him build things at an online game called Roblox.  In both instances it made me think, what is the source?

The same is true for my own life, especially my work life.  I have been part of groups that have produced 7 US patents and other intellectual property.  Each time was so different it is difficult to discern an underlying theme that made this creation possible or at least facilitated.  What can be said in each instance to varying degrees, is there was a perceived difficulty or problem, some desired end state that was presently not … Continue reading

Tools and Teams

I recently saw a post on Twitter from the Great John Cutler on allow the team to pick the tools that they use to do the work.  Generally, this is not a bad idea, but not necessarily a great idea either.  It sort of depends.

 

 

My experience in companies that also have hardware parts associated with the software, each group selecting their tools comes at a great disadvantage when it comes to understanding the various work products as it moves through the organization.  It is not possible for one team to see what the other team has done, when the tools are not connected, or each group selects what that individual group needs without consideration of the departments that are depending or associated with the work.  In these cases, a product life cycle management tool that connects the various work departments and work packages can help tie all of these together. Consider a vehicle manufacturer that develops … Continue reading

Kanban and Visual Management

Kanban and Visual Management

Kanban is a lean method for identifying and managing the work and the flow, and it does so by creating a pull through environment.  We will start by identifying the work we need to do. Each work item we need to do will end up on an individual card.  The cards will be “pulled” as we have the time and talent to commence that specific work element. The card then moves from the backlog of work items, to the WiP or Work in Progress section of the visual management board.  The visual board may have headings such as:

Backlog Work in Progress (WiP) Work for Review Work Completed / Demonstrated

We will pull items from the backlog and place the card in the state that corresponds to the work, for example, the work moves from backlog to work in progress as the work commences.  It is easy for anybody to see the status of the work. … Continue reading

Evolution of the Horseless Carriage

In preparation for our trip to Eindhoven University of Technology to lecture on Configuration Management, we provide a brief excerpt on the evolution of the horseless cariage.

Traditionally new market segments open due to the need to solve a problem. Such problems may be real as in the case of the environmental crisis solved by the automobile or the need may be concocted. New markets and products are rarely developed through the inspiration of a single individual. The automotive market came about through a synergy of the existing body of knowledge and other environmental conditions both in the marketplace and in the nature.

One topic of discussion at the world’s first international urban planning conference in 1898 was the growing health concerns due to horse excretions and the creatures that accompanied them. As the primary means of locomotion for wagons and other forms of transport, horse populations exceeded human population in cities.*

Manufacturers of “horseless carriages” using steam, electric, … Continue reading

My Career Part 1

My Career

I have been very fortunate in my career, and that really means very lucky.  Upon graduating from the University of North Carolina at Charlotte, I had two job offers after sending my resume to more than 100 companies.  That is not a very good yield, but it would be good enough.  I selected the smaller company, but I selected that company because they created new things.  The company I started at developed embedded industrial control systems.  It also turns out the people with which I would be fortunate enough to work, were very friendly, and as I would say, were a hoot to be around.  Some of my other blog posts describes shenanigans.  To this day we still have secret words, that mean something to us but nothing to anybody else (R4).

What drives me

My interest or objective has never been one thing when it comes to product development.  In the beginning, I was interested in … Continue reading

Value, Scope and Change Requests

Value, Scope and Change Requests

Change requests are part of any development project.  Change requests are sometimes necessary as we learn by building and doing the work.   In my experience, change requests often are born from requirements we thought we understood, only to learn by working with the product or system that we really did not have enough understanding to be able to record this in the form of specifications.  We think we are making things better when we spend an abundance of time documenting the requirements, at least those requirements about which there is uncertainty. That is not to say this is not a worthwhile endeavor, we have been in product development long enough to know there are downsides to delivering a product that has no associated documentation.  The testing and manufacturing portions of the work will make use of these requirements documentation and the errant or lack of documentation makes the work of these areas and more difficult … Continue reading

Value Proposition

Value

Business is predicated on providing value to the customer, but it does not end there. The business itself needs to see value in the work, so this is really a value chain that is only as strong as the weakest link.  If the value to the customer is too low or not existing, no customers will purchase the product.  If the value to the business from the product is too low, there will be no investment

What is value

Value is the difference between the utility received and the cost for things.

Value = Utility – Cost

Value = Benefit – Cost

The utility may be customer dependent, but this must be understood, as this will drive the subsequent work. Not knowing what the customer values, clouds how we approach the work.  We will write more about the conundrum later.  It suffices to say no value to the customer means no value to the business, … Continue reading

What works: team participation

The team

My first job out of university was with a small product development and manufacturing company. The company developed their own embedded products for sale all over the world.  I do not know how this collection of technicians and engineers ended up as a tight or as close when it came to work.  The group was a collection of characters. The other electrical engineer, we will call Flicky (we had secret names for each of the team members). There was one technician we referred to occasionally as IR because of the unfortunate anagram is name made.  There was a mechanical designer we referred to as BWI, I will explain that later.  There was another assembler / technician we referred to as Wal.

Games with the Team

When it came to the electrical or embedded product idea generation and development, I can recall a game we played.  We would read the specifications together, asking questions where we could of the sales … Continue reading

Single Sign On provided by vBSSO