Sunday, June 26, 2016

Job interview Mistakes to avoid | David Tzemach


In this article, I will review the main mistakes that you can do during an interview in the software industry, the list is combined from my personal experience and from stories that I gathered along my 12 years in the software industry.

The principals

Prior to reviewing the list, let's talk about the key principles that you must be familiar with.
·         The software industry has many opportunities that you can use to find your next job.
·         My list will help you to avoid the basic mistakes that are interview "Killers".
·         Try to find the hidden goals behind the interviewer questions.
·         The software industry needs more and more people.
·         Remember that when you go to an interview, you should always position yourself as the solution to their problem.

Interview killer mistakes


1.       Make sure that your resume is reflecting your real knowledge.
2.       Your CV are not focused to the specific job that you want.
3.       Never lie, a good interviewer will catch you!
4.       Providing the wrong contact information.
5.       Validate that your resume is short.
6.       Make sure that your CV contains the relevant data, the interviewer does not care what you did 100 years ago.
7.       Never have a Grammar error.
8.       Never have a spelling error.

Interview preparation

9.       You don’t know what is the exact position that you invited for.
10.   Failing to understand the importance of a phone interview.
11.   Failure to explain why you are the best man for the job.
12.   You don’t know that characteristics of the job.
13.   You don’t know the requirements of the job.
14.   Remember what you wrote on your resume.
15.   You don’t know what the company does.
16.   You use assumptions instead of facts.
17.   Do not answer with 'Yes' or 'No'.
18.   Keep the basic Dressing codes.
19.   Know the salary expectations.  
20.   Do not late to the interview.
21.   You failed to ask questions.
22.   Do not arrive too early.

Personality Mistakes

23.   You are nor demonstrating enthusiasm.
24.   Showing off, no one will appreciate it.
25.   Sounding too desperate for the job.
26.   Speaking rudely to the interviewer.
27.   Not receiving any criticism.
28.   Forgetting your manners.
29.   Do not be too emotional.
30.   You are being too needy.
31.   You Become Defensive.
32.   You Become angry.

Interview mistakes

33.   Don’t ask about the job benefits on the first phase of the interview.
34.   You indicate that you are not willing to work after official hours.
35.   You indicate that you are not willing to start at the bottom.
36.   You indicate that you are not willing to work in a team.
37.   You are using a "Slang" language during the interview.
38.   Failing to listen to what the interviewer is telling you.
39.   lying about your experience and knowledge.
40.   Making an obvious weakness seem positive.
41.   Bad-mounting your former employer.
42.   Don’t lie about your salary demands.
43.   You failed to explain your strengths.
44.   Negativism against the interviewer.
45.   Trash talking with the interviewer.
46.   Complaining about stupid things.
47.   Do not ask too many questions.
48.   Failing to make an Eye contact.
49.   Interrupting the interviewer.
50.   Leaving your cell phone on.
51.   You apologize too much.
52.   Overselling Yourself.
53.   Don’t talk too much, philosophy is great, but you can keep it to yourself if you didn't ask to explain it.
54.   Chewing gum.

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


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!


  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


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:

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.
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?
When the priority status is set, the owner can change it during the defect life cycle (DLC). 
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