NVP Software Solutions

Blog

  • Process for a Quality Assessment – Step 3

    Process for a Quality Assessment – Step 3

    In the last post on this topic we said we would look at the initial set of questions that might be posed to someone involved in an assessment. Obviously the initial set are intended to elicit the information on the person and where they belong in the organization and for what parts of the product they are responsible. These questions are self-evident. There could be red flags raised here if the person does not feel they are responsible for anything or have too much for which they are needed.

    However, assuming that those questions go well, the next two may be crucial:

    1. ‘Where does it hurt?’ or “What concerns you?’ these questions can frequently lead to a long list of issues. After all we would not be doing an assessment if there were no concerns.
    2. How do you interact with other people who have input on this product? It is crucial to get this question answered by everyone before going for a second round. The answers to this may uncover a lot of secondary questions for people to whom we have already spoken.
  • TASSQ January 2025 Talk

    TASSQ January 2025 Talk

    Toronto Association of System and Software Quality TASSQ is pleased to announce our Webinar for January 2025.

    Topic: Critical Thinking

    Presenter: James Bach

    Location: Online/Zoom

    When: Tuesday January 28 at 6:15 p.m. until 7:30 p.m. EST

    Cost: $14.00 CAD

    Register at: TASSQ

    Presentation Abstract:

    Join James Bach as he discusses the importance and underrated value of Critical Thinking in testing practice.

  • Process for a Quality Assessment – Step 2

    Process for a Quality Assessment – Step 2

    There will be little progress on an assessment without an understanding of basic system architecture. One of the first requests is for a system diagram so we can start putting names, titles and process questions beside each section. Two red flags may be raised here:

    1. If no-one can generate or find a system diagram then there is an immediate concern that there is no-one who understands the system.
    2. Assuming we can obtain a system diagram, are there sections for which it is impossible to attach a responsible person? Again, an immediate concern that there are pieces of the system that are being left unattended.

    Our next blog on this topic will drill down to the initial set of questions.

  • Process for a Quality Assessment – Step 1

    Process for a Quality Assessment – Step 1

    Sometimes the most difficult thing in a Quality Assessment is the first step. While there are usually some obvious quality patterns and issues, it can be difficult to get a starting point. We always start with information gathering interviews with the client representative who requested the Assessment. Clearly they thought that there was benefit to be obtained from an Assessment and their reasoning and motivation is crucial to the subsequent success of the contract.

  • What is a Quality Assessment?

    What is a Quality Assessment?

    To many people, a Quality Assessment seems rather nebulous.    How can one assess Quality in an organisation?  A Quality Assessment looks at the Processes being used to develop or purchase and test software and compares them against industry best practices to see where improvements could be made.  There are some existing standard models that can be used (TMMI for example) which provide lists of attributes and processes to compare.  These can be modified to suit any particular situation and the assessment completed and mapped.

    Next week, we will discuss some of the processes we follow to complete this assessment.

    Lessons Learned:  No one process suits every occasion and we need to be flexible in what is used to provide answers.

  • Get a Consistent Reporting Format

    Get a Consistent Reporting Format

    Reporting results is one of the bigger aspects of testing that is often overlooked in the beginning of a project.  The initial efforts are aimed at getting the testing environment established and the test cases written and approved.  Then the launch into testing occupies a lot of time ironing out the minor irritants to test execution.  At that point the request for reports comes up and the test lead is frequently left scrambling for data to report what is requested.  Failure to anticipate the reporting requirements can lead to a lot of manual work.

    Lessons Learned:  A few hours defining results reporting formats can save hours later in the project.

  • Get Report Mockups Early

    Get Report Mockups Early

    A couple of weeks ago, we mentioned how a knowledge of report requirements early in the project would help ensure that the data existed and could be accessed.  That does not solve the problem of ensuring that the reports are tested and correct.   Report testing is usually late in the cycle and is squeezed for time.  However, reports are critical for information and business decision making and can make or break a company.  It is crucial that the reports be tested for not only appearance but for correctness.  This can be very difficult if the data has been gathered in a different way.

    Lessons Learned:  Report testing cannot be entirely left to the end.

  • Too Many Disparate Pieces of Software (What Happens When One Fails or Goes Out of Business)

    Too Many Disparate Pieces of Software (What Happens When One Fails or Goes Out of Business)

    An assessment of an existing and successful system showed a lot of disparate pieces of software hooked together in various ways.  An inability to properly define and build effective QA environments for testing meant that some testing was not done and taken on faith that it worked or was tested in production (and fixed).  No API testing was completed so any failure of any piece of the solution had immediate repercussions throughout the product and had to be fixed on the fly.

    Lessons Learned:  A proper environment and knowledge and testing of the APIs would have solved a lot of the issues that showed in production.