Blog

  • 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.

  • Working Towards the Final Result

    Working Towards the Final Result

    Finding out requirements by digging through the hierarchy endlessly or how not to implement a product.  A recent upgrade included a migration from one database (home grown) to a commercially available product.  It is well known that migrations are always dangerous and can be quite time consuming.  The issue was that an attempt was made to replicate the existing (and mainly unknown) database into the new one rather than asking what was important to know after the migration was complete.  The testing turned into a series of cycles while the testers dug deeper and deeper into the existing database.

    Lessons Learned:  Make sure to take a 360 degree view of the expectations before going down the testing path.

  • The Importance of User Scenarios

    The Importance of User Scenarios

    A couple of weeks ago, we mentioned one instance of where Edge Cases relating to monitoring of queues caused a two month slippage in the project schedule. A similar issue came up with mobile phones that the client was accustomed to use when not at the desk. The product was designed with the expectation that users would be seated at desks and controlling the product via the workstation interface. When this was not the case, a substantial set of issues came up revolving around getting the calls to the mobile phones, making sure the queues were acted on properly and reacting to new messages. A further delay was encountered working through these unanticipated changes. There was also a problem with call recording for calls starting on the mobile phones.

    Lessons Learned: A scenario showing the Day-in-the-life of a user would have identified a lot of these issues.

  • The Importance of Knowing Report Requirements

    The Importance of Knowing Report Requirements

    Frequently reports do not come up before the end of project and obviously if the product does not work , then reporting on the results or activity will have little value until the data is correct.  However, that does not preclude confirming early in the cycle that the required information is available and in a format that will allow the reports to be formatted and populated reasonably easily.  A list of the existing reports (in the case of a product upgrade or a conversion) can be checked early in the project to ensure that the data is available in the new or upgraded product.

    Lessons Learned:  Make sure a list of the required data is available at the commencement of the project.

  • The Importance of Edge Cases

    The Importance of Edge Cases

    Frequently the consideration of Edge Cases comes up after all the main test cases are complete and passed.  They are often considered to be extra items that may or may not contribute to the major functionality of the product and it may not be necessary for them to all pass.

    However, we recently ran into a case where the ‘edge cases’ were very critical.  The product depended multiple people using it at one time and multiple people monitoring all the queues continuously.  However, in the implementation we were testing, some queues could be left unattended for a few minutes at shift change.  The product was not equipped (for safety reasons) to allow a queue to sit with no one monitoring it and it immediately moved the queue somewhere else leading to the ‘loss’ of the queue.

    The extra work late in the project added two months to the schedule.

    Lessons Learned: Even if the Edge cases are not immediately obvious they need to be listed and the impact determined in order to ensure that the product will address them.

  • Quality Assurance

    How to start QA with an unwilling company?

    Sometimes you run into a situation where a company indicates a wish for QA but will not put in any effort to make it happen. It looks like a large effort to them and they cannot see any reason or benefit. In this case there are several steps that you can take to make this happen. We will discuss these over the next few weeks.

    The need for Quality never goes away; it just reappears in a different format each time. The same techniques often apply; it is just a different situation.

    If you have something you would like to discuss, please get in touch. Our contact information is below.

    Test Leader or Manager with concerns? Test Managers Conference.

    Services NVP Quality Assurance Services

    Contact Contact us

    Meeting Book a Meeting with NVP

    LinkedIn Group Software Testing and QA Group

    LinkedIn Company Page NVP LinkedIn Company Page

  • Quality Assurance

    For those who follow the blog, we gave it a rest over the summer. Not only were we busy with some security testing, we also had a several projects go-live at various dates. One more is going live right now. Between one thing and another, the summer seemed to pass more quickly than we expected. However, quality did not take a break and we are looking forward to the last part of the year for several reasons.

    1. Some of the rush to get critical items updated has abated.
    2. Projects are now running for more extended periods of time which will give more time to get the Quality right
    3. We are getting more buy-in from people with respect to the need for Quality. This is a welcome change

    The need for Quality never goes away; it just reappears in a different format each time. The same techniques often apply; it is just a different situation.

    If you have something you would like to discuss, please get in touch. Our contact information is below.

    Test Leader or Manager with concerns? Test Managers Conference.

    Services NVP Quality Assurance Services

    Contact Contact us

    Meeting Book a Meeting with NVP

    LinkedIn Group Software Testing and QA Group

    LinkedIn Company Page NVP LinkedIn Company Page

  • Last Chance to Register

    Last Chance to Register

    May 2022 TASSQ & KWSQA Events

     

    You might want to consider this event to network with other QA people or learn some of the new ideas in QA.

    NVP Software Solutions will be participating in the following software testing and quality assurance event happening this April. TASSQ is returning to an in-person event for May; KWSQA is meeting remotely on June 1. Check out the relevant websites for more information and to register. This is a great opportunity to connect with other software testing and quality assurance professionals. We hope to see you there!

    Image by Gerd Altmann from Pixabay

     

     

     

     

    THE TOP TESTING TRENDS FOR 2022

    Speaker: Arthur Hicken, Register here

    May 31, 2022 6:00 p.m. EST – In person – Albany Club – Pre-registration required

    Leading From Quality

    June 1, 2022  11:55 a.m.   Online

    Speaker: Ian Howlett

    Register here