NVP Software Solutions

Tag: software testing

  • Upcoming Software Testing & Quality Assurance Events – April 2016

    NVP Software Solutions will be participating in the following three software testing and quality assurance events happening this April in Ontario, Canada. The events are located in Toronto, Kitchener-Waterloo and London in the coming two weeks. 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!

     

    Toronto Association of Systems & Software Quality

    TASSQ – Toronto Association of System and Software Quality – Everything you Wanted to Know about the CSQE! – Brenda Fisk, Director,
    ASQ Canada Deputy Regional Director 2014-2016
    Software Division, Division Executive Team – April 26, 2016 – See http://www.tassq.org/

     

     

    Software Testing in Kitchener Waterloo

     

    KWSQA – Kitchener Waterloo Software Quality Association – the bare minimum you need to know about web application security in 2016 – Ken De Souza – April 27, 2016 – See www.kwsqa.org

     

     MANHATTAN

    London Quality Assurance Peer-to-Peer Contact neil@nvp.ca for more details

  • Quality Assurance Assessments – Part 3

    Quality Assurance Assessments take a variety of forms in an IT project and can range from very informal to very formal in nature. This week we will discuss HOW to do a QA Assessment now that we have completed an explanation of WHY to do Assessment in a past blog.

    HOW Quality Assurance Assessments are Done:

    The following needs to be done in order to complete a Quality Assurance Assessment:

    1. Determine the objective of the assessment. (Refer to Why Quality Assurance Assessments are Done in a past blog).
    2. Set up a team (may be a team of 1) to do the assessment.
    3. Determine the targeted group who are going to provide information to the team.
    4. Determine the method of getting the information (questionnaire; in person interviews; survey).
    5. Using the method selected above, carry out the assessment.
    6. Collate the results.
    7. Provide a report.

    The above is a general methodology. The following is a short example of a very basic QA Assessment.

      1. The objective is to determine how well the Software Testing Process worked on the last project.
      2. The team will be the Quality Assurance department (not involved in the particular project).
      3. Target audience: Software Testers, Developers, Project Manager(s), End Users, Management, all other interested stakeholders.
      4. Methodology: Individual interviews using a questionnaire. Some sample questions follow
        • What went right with the project in terms of Software Testing?
        • What went wrong with the project in terms of Software Testing?
        • What expectations were and were not met?
        • How could the process be improved?

    This is a very small sample of questions to be answered. From there:

    1. Compile the answers into a report removing the names and any identifying comments.
    2. Create a set of recommendations based on the results.

    If you are having trouble working this out, contact us and we can help guide you and your team in the right direction.

    Finally, we’ll leave you with a few questions and ask you to post your answers.

    1. Have you participated in a Test Process Assessment?
    2. What was the justification for the Assessment?
    3. Were the results used for Process Improvement?

    Next Week: KWSQA, TASSQ and London Peer-to-Peer

  • Software Testing Strategy – The Test Plan

    Any given test plan and its contents vary widely depending on to who is doing the testing and what template is used. Test plans can be found anywhere on the web. They can be generic in nature or specific to a particular industry and have specific sections that are critical for regulatory or risk reasons. A test plan can also be seen as a strategy, while in some cases strategy is never considered. Sometimes test cases are included in a test plan.

    We consider a test plan to be a document that outlines a path for the testing but excludes the test cases (which we like to keep in a database). The test plan often includes the following (not a comprehensive list):

    1. Introduction
    2. Test Approach
    3. Assumptions and Dependencies
    4. Risks and the Risk Plan
    5. Schedule and Resources
    6. Glossary

    The Incredible Shrinking Test Plan

    We’ve seen where one client invested a lot of time creating a test plan template for use within their organization. The template with various sections indicated what the contents of that section should include, however, if the section was irrelevant,  a statement as to why it was inapplicable was to be noted. Under no condition was any section to be deleted. Unfortunately, one group misunderstood the importance of keeping ALL data and deleted any section they felt was unnecessary. They innacurately used the previous plan version as the template for the next one and so on. So every time a section was deleted it was lost forever. We used to refer to those plans as the The Incredible Shrinking Test Plan, it just got smaller and smaller.

      1. Do you write test plans?
      2. If you use a template, do you have trouble filling it out?
      3. Do you get test plans reviewed by the relevant stakeholders?
      4. Are they approved at any point?
      5. What is your experience in how well they test what you need to test?

    And most importantly: Do you ever review them after the project is over and see how well you adhered to the initial outline?

    Next Week: Assessments – How

  • Quality Assurance Centre of Excellence – Part 6

    Over the past 4 weeks we have been discussing the following list of items related to Quality Assurance. While it may not necessarily be a full comprehensive list, it is a starting point for many Quality Assurance activities. In looking at the list, there are many things a tester could concentrate on. We also have to be concerned about perceptions of the Quality Assurance department. Concentrating on any one of the items to the exclusion of the rest can not only cause one to lose sight of the larger picture, it can also cause problems with the remainder of the organization that feels that Quality Assurance has one one agenda.

    1. Proactive
    2. Analytical
    3. Focused on Root Causes
    4. Focused on Process

    Given the above list, what can a Quality Assurance Centre of Excellence concentrate on in order to provide value to the organization?

    Proactive We need to spend some time each week looking at the future and how Quality Assurance can address it. The first few weeks are difficult because you may not know what to look at or look for and you may not be aware of what to ask. Some initial interviews asking for expectations might help guide the agenda. The answers need to be analysed and weighed so that emphasis can be placed on the correct items. Be prepared for your initial ideas to be wrong and for them to change over time.

    Analytical This one can be more political. People do not like having their work focused on with the intent of seeing what has gone wrong. You will need to repeat the words ‘We are here to help’ constantly, and demonstrate that you are living up to them. Since this is reasonably concrete, it is easy to spend all your time here and start generating reports that may or may not be useful. Results from this item need to be reviewed to check for their usefulness.

    Focused on Root Causes We already indicated what this one was and what would be involved. It is easy to spend a lot of time on this and not get anywhere. After all, if Root Causes were easy to find, they would already have been discovered and corrected. Brainstorming on the Root Cause followed by a time for reflection is probably best. Be prepared to be surprised as to what the Root Cause really is followed by resistance to any sort of correction.

    Focused on Process There are entire books and courses on Process Improvement. Much of the above will drive the processes since it is the processes that are wrong and are causing the problems in the first place. So while you can do Process Improvement in isolation, it can also be driven by what comes from the previous three sections. Be prepared for some long payback cycles and a lot of resistance.

    Visit our website for ways we can help your organization.

    Next week Assessments

  • Testing for System Integrators – Part 5

    Last week our blog discussed the remaining answers to the questions and promised that we would look in detail at two of the answers (which are somewhat similar so we will concentrate on one only).

    There is nothing in the contract (contract is signed) and there is no intention of putting anything in the contract about Quality Assurance.
    Now you have a challenge. Clearly the process is mostly done and there is absolutely no buy-in to Quality Assurance. The next question that needs to be asked is “Why have you brought Quality Assurance in if there is no interest?”

    The key steps here are to determine your position and map out your strategy. There is any number of answers to the question of “Why have you brought Quality Assurance in if there is no interest”.

    1. The final client has belatedly required it. I.e. they have realised it is an omission from the contract and now feel it is incumbent on the System Integrator to provide this as part of the deliverables. You need to determine the final clients needs and work towards those.
    2. The solution is more complex than the System Integrator thought and now they feel a need for Quality Assurance. I.e. like the client above they have realised the value provided by Quality Assurance and now want to implement it even though they were trying to avoid it earlier. There is probably still little buy-in from most of the group. You need to look at each of the Stakeholders and determine their status vis-a-vis Quality Assurance and plan to convert them all to supporters. This is a crucial piece of your strategy in order to be successful.
    3. The System Integrator’s management is becoming nervous and wants Quality Assurance there as a check. While you have management support the team may feel they have an extra burden and possibly someone who is watching them. As in the above, you will need to look at the Stakeholders and see how to convert them to supporters. Otherwise you will get no information at all.
    4. The last possibility is they want someone to blame. This is a tricky one. No matter what you do (either proactively or reactively) they may blame you. You need to plan carefully in order to make sure that your work is recognised as contributing to the success of the project. You need to be very proactive in stating what needs to be done; why it needs to be done and the benefits accruing from having it done. And make sure that everything is documented!

      Happy New year

  • Testing for System Integrators – Part 4

    Over the next few weeks, the NVP blog will focus on Software Testing for System Integrators. From NVP’s point of view, a System Integrator is someone who brings together a number of applications (from vendors), adds some glue and ends up with a solution for the organization they are working with. This seems to agree with the Wikipedia definition fairly closely. So where does Quality Assurance come into this? One would like to think early or very early in the process but that’s not always the case.

    Last week we looked at responses to the first 4 questions. This week we are continuing with the remainder:

    1. The contract states the following specifically about Quality Assurance and everyone is in agreement
    2. The contract says nothing about Quality Assurance but it’s noted as a topic and the contract will not be finalized without this discussion
    3. The contract says nothing about Quality Assurance so far, but now that you have brought it up we will add it.
    4. There is something in the contract about Quality Assurance and we can look it up for you (contracts are signed).
    5. There is nothing in the contract (contract is signed) and there is no intention of putting anything in the contract about Quality Assurance
      Now you have a challenge. Clearly the process is mostly done and there is absolutely no Buy-in to Quality Assurance. The next question that needs to be asked is “Why have you brought Quality Assurance in if there is no interest?” The answers to this and the response will be next week’s blog
    6. We don’t know (but that is a good question)
      There is some hope here and you are in a position to influence the content and results. It may be late in the process but we can try.
    7. We don’t know (and we don’t care)
      This is a similar situation to the answer to number 5. There is a challenge for Quality Assurance and that challenge must be tackled.

    Suffice to say the items in the above list have an obvious gradation from very manageable to a real challenge in the order they are presented. If you get the first answer, you’re well on your way. If you get some of the middle answers you have some work to do, but there’s still time to make change. If you get the last few answers, you are in trouble but not defeated!

    Next Week: What to do with Number 5 and 7.

  • Testing for System Integrators – Part 3

    Over the next few weeks, the NVP blog will focus on Software Testing for System Integrators. From NVP’s point of view, a System Integrator is someone who brings together a number of applications (from vendors), adds some glue and ends up with a solution for the organization they are working with. This seems to agree with the Wikipedia definition fairly closely. So where does Quality Assurance come into this? One would like to think early or very early in the process but that’s not always the case.

    Last week we provided several possible answers to our original

    1. The contract states the following specifically about Quality Assurance and everyone is in agreement
      This means that you simply have to “bridge the gap” between what is expected from the vendors and what is promised to the final client. The only problem may be that you do not agree with the contracted items.
    2. The contract says nothing about Quality Assurance but it’s noted as a topic and the contract will not be finalized without this discussion
      This is almost the best situation. While it may be a little late in the process, the willingness to add Quality Assurance exists and people are behind it.
    3. The contract says nothing about Quality Assurance so far, but now that you have brought it up we will add it.
      The same comment as above is applicable except that there is not quite the backing we might have had earlier.
    4. There is something in the contract about Quality Assurance and we can look it up for you (contracts are signed).
      Well at least they considered it; it may not be correct or complete but it was not entirely ignored. Once you find out what is in the contract you may (or may not) have concerns to handle.
    5. There is nothing in the contract (contract is signed) and there is no intention of putting anything in the contract about Quality Assurance
    6. We don’t know (but that is a good question)
    7. We don’t know (and we don’t care)

    Suffice to say the items in the above list have an obvious gradation from very manageable to a real challenge in the order they are presented. If you get the first answer, you’re well on your way. If you get some of the middle answers you have some work to do, but there’s still time to make change. If you get the last few answers, you are in trouble but not defeated!

    Next Week: What to do with the answers (remainder).

  • Testing for System Integrators – Part 2

    Over the next few weeks, the NVP blog will focus on Software Testing for System Integrators. From NVP’s point of view, a System Integrator is someone who brings together a number of applications (from vendors), adds some glue and ends up with a solution for the organization they are working with. This seems to agree with the Wikipedia definition fairly closely. So where does Quality Assurance come into this? One would like to think early or very early in the process but that’s not always the case.

    Last week we asked two $10,000 dollar questions and this week we promised the possible answers. Unlike the questions, which are specific to the final client and the suppliers, the answers are more general and apply to both.

    1. The contracts state the following specifically about Quality Assurance and everyone is in agreement
    2. The contracts says nothing about it so far but we have Quality Assurance as a topic and the contract will not be finalised without this discussion
    3. The contracts says nothing about Quality Assurance so far but now that you have brought it up we will add it.
    4. There is something in the contracts about Quality Assurance and we can look it up for you (contracts are signed).
    5. There is nothing in the contracts (contracts are signed) and there is no intention of putting anything in the contracts about Quality Assurance
    6. We don’t know (but that is a good question)
    7. We don’t know (and we don’t care)

    Suffice to say the items in the above list have an obvious gradation from good to terrible in the order they are presented. If you get the first answer, you’re well on your way. If you get some of the middle answers you have some work to do, but you may be in time to effect some change. If you get the last few answers, you are in trouble!

    Next Week: What to do with the answers.