Wednesday, June 22, 2016

What is Software Quality Assurance (SQA)? | David Tzemach

Software Quality Assurance (SQA), is a crucial process that we use in the software industry to guarantee that the developed application meets the client requirements, specifications and any other quality standards that (ISO 9000, ISO 13485, Six sigma, CMMI, etc.)
SQA is a crucial part of every Software development life cycle (SDLC) no matter what is the development methodology (Traditional\Agile), because it will help the team to ensure that the software is developed with the highest quality as expected by the company clients.

During the implementation of SQA, we will use different Tools, activities and dedicated processes that will help us raise the software quality, Examples:

·         Define the Test Strategy and methodology.
·         Writing and executing test scenarios.
·         Testing the application.
·         Inspection and reviews.
·         Release Management.
·         Time estimations.
·         Removing Risks.
·         Software Design.
·         Training.

In addition, I just want to add that on my opinion, every organization that shares respect for is clients will not release any application without a dedicate SQA process that implemented at all phases of the software Development life cycle (remember that SQA is not about testing, it has so much more J).

Monday, June 20, 2016

Checklist for Testing Text input Fields | David Tzemach

Checklist for Testing Text input Fields

This list should be used to test almost any "Text" field object in your application, use it wisely as a baseline and add more use cases based on the application specific demands.


  • If the text field should receive only numbers, try to write any other character.
  • Do not enter any syntax as input (the submit button shouldn’t be allowed).
  • Try to Add more characters than the MAX allowed number of characters.
  • Validate the text field with both lowercase and uppercase alphabets.
  • Test the boundaries of the input field (MAX number – 1).
  • Test the boundaries of the input field (MAX number + 1).
  • In any case that the text field should receive a specific value, validate that the user can insert data that following the predefined validation pattern.
  • Test the boundaries of the input field (MAX number).
  • Test the boundaries of the input field (MIN number).
  • Try to copy -> paste syntax from another location.
  • Add the MAX number of the allowed characters.
  • Add Asian languages (Japanese, Chinese etc.).
  • Do the text field support math equations?
  • Does the text field support currency ($5.2)?
  • Insert both negative and positive numbers.
  • Blank text at the beginning of the syntax.
  • Insert both positive and negative values.
  • Does the text field support date format?
  • Use keyboard shortcuts (Ctrl + Z / P / C).
  • Insert spaces between words/chars.
  • Blank text at the end of the syntax.
  • Validate with lowercase alphabets.
  • Validate with uppercase alphabets.
  • Insert special characters/Symbols.
  • Validate with decimal numbers.
  • Try to add ASCll characters.
  • Insert Unicode characters.
  • Add multiple characters.
  • Add only one character. 

Friday, June 10, 2016

Team compatibility and Motivation checklist | David Tzemach

Overview

This checklist will review 25 simple questions and principles that will help you guarantee that your team has the right motivation and quality to handle any project goals.

In addition, I'm sure that you have few more ideas that I excluded from this list. Therefore, I will be more than glad to receive a few more ideas that will help me increase the efficiency of this checklist. Enjoy!

Checklist:

  1. Does your team familiar with the deliverables that they need to provide during the project?
  2. Does your team believe that they can accomplish the job in the suggested timeframe?
  3. Does your team members are familiar with the responsibilities (Personal and Team)?
  4. Does your team have enough knowledge in the application supported platforms?
  5. Does your team have the knowledge to use the automation framework (If used)?
  6. Does your team have enough product experience to handle the testing effort?
  7. Are the testing tasks distributed in a fair manner among the team members?
  8. Does each team member, can contribute to the success of the project?
  9. Do you know what is the technical boundaries of the team members?
  10. Does your team understand the "business case" behind the project?
  11. Do you have a sufficient resource to handle the project goals?
  12. Is your team motivated enough to handle the testing effort?
  13. Do the team members respect you, so they can follow you?
  14. Do the people in the team communicates well with you?
  15. Does your team understand the goals of the project?
  16. Does your team have experience in similar projects?
  17. Does your team familiar with the project timelines?
  18. Does your team is built in the correct hierarchy?
  19. Do the people in the team communicate well?
  20. Does your team know the risks of the project?
  21. Does your team understand the test strategy?
  22. Does your team have the right commitment?
  23. What is the ratio of testers to developers?
  24. Is your team familiar to you?
  25. Does your team have a good communication with the other teams that involve in the project (Developers, DB, Support, etc.)?

Saturday, June 4, 2016

Defect Severity Vs Priority in Software Testing | David Tzemach

Overview

A basic question that I come across many times, is the difference between the two terms Severity and Priority.  

For some reason, many people are still failing to understand that those terms are always combined together (mandatory fields on every bug incident), but each one of them has its own importance and scale when examined individually.


To simplify the differences, please see the table below:


Priority
Severity
Scheduling Vs Quality
The priority level is the factor that determine the priority of bugs should be resolved, example: 10 bugs with the same severity, the bugs with higher priority are fixed first.


In addition, the priority level is the main factor that determines the urgency of the bugs that needed to be fixed sooner (Bugs with ‘Urgent’ priority will be fixed first no matter what is the severity that assigned on them).
The severity level is all about quality, the severity level is the term that determines the level of deviation from the product requirements and specifications.

In addition, the bug severity   is the factor that indicates for the level of impact that this bug has on the system/component and functionality.
Perspective
Priority is more about the importance of fixing the bug based on the business perspectives.
Severity is more about the importance of fixing the bug based on the system perspectives.
Is the status remain constant?
No,
When the priority status is set, the owner can change it during the defect life cycle (DLC). 
No,
When this severity status is set, the owner can change it during the defect life cycle (DLC).
Associated with..?
Priority is associated with timelines/scheduling
Severity associated with the   product quality
Determined by...  
The priority level is determined by the project owner/Test Manager/PM/ Etc.
The severity level is determined by the tester who reports the incident

My Presentations