Monday, December 28, 2015

Extreme Programming (XP) |David Tzemach


  • XP was developed by “Kent Beck” and introduced in his first book “Extreme Programming Explained: Embrace Change (Addison-Wesley, 1999)”.
  • It was one of the earliest agile methodologies and the first one that challenge the traditional Waterfall model.
  • XP is a designed to support a small/medium software development teams.
  • It’s called “Extreme Programming” because it takes 12 known proven software development principles/practices and push them to extreme levels. 

Extreme Programming as an Agile Methodology

The Manifesto for Agile Software Development

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

                      Individuals and interactions over processes and tools
                     Working software over comprehensive documentation
                     Customer collaboration over contract negotiation
                     Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”  -Kent Beck-

The Values of extreme Programming


  • Do the simplest that could possibly work.
  • Remove any code that you will not use.
  • The team members will focus on things that matters and don’t waste time on things that they doesn't ask for.

"XP is making a bet. It is betting that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used anyway."   -Kent Beck-


  • There should be a good communication between the team and the client.
  • The entire team members should work together to complete each task.
  • Face to face communication will reduce the need of documentation.
  • The project coach should validate that there is a good communication (Developers->Developers, Developers->Client etc.)


  • Developers should have the courage to take fast decisions due to the collective ownership.
  • Developers should have the courage to tell the truth about the effort they need to complete tasks (Time Estimations, implementation effort etc.).
  • Developers should have the courage to make real changes in the software design and architecture when needed.


  • Extreme programming embraces Feedback as a great way to evaluate the current state of the development process.
  • Fast feedback will increase the effectiveness of the process.
  • Each resource that involved in the project is relevant, Examples:
    • Developers – Estimate the user stories and respond with estimations.
    • Customer – Test the software and send feedbacks that will increase the quality.


  • Respect the other team members.
  • Respect the customer.
  • Respect the project.

Activities in Extreme programming


  • All developers should follow a predefined code standards.
  • Continuous integration throughout the entire process.
  • The Code is based on the customer user stories.
  • The Customer should be available at all time.
  • First Code is written for Unit tests.
  • Collective code ownership.
  • Pair Programming.


  • Testing is made by the developers (Unit) and by the customer (ATP for functionality).
  • Every part of the code should be tested with a dedicated unit test.
  • You cannot say that your code is working until you test it.
  • All tests should run on every new build.


  • Developers should listen to the client requirements about how the system should develop.
  • Developers should listen to each other to develop a better and resilience software.
  • Developers should listen to the client feedback about the generated code. 


  • A good and simple design will reduce the complexity of the system.
  • Every developer can take an active part in the design process.
  • The Design is made at the start and during the process.
  • Refactoring is a decisive part of the design process.
  • Although Xp embraces fast development that add business value, it doesn't mean that the designing process is excluded.

The 12 Key Practices of Extreme Programming

The Planning Game

  • The company evaluates the client requests against the cost estimations and development time.
  • The primary goal is to produce the maximum business value in the fastest way.
  • There are three basic rules to follow on this phase:
    • Business comes up with the list of requirements from the client (User Stories).
    • Engineering team review the “User Stories", and then answer these two questions:
      • How much effort the team can produce per iteration (How many user stories they can deliver per iteration)..?
      • What is the time estimation and effort will they need to put in order to deliver each item?
    • Business review the estimations and decide what are the user stories that will be developed and in what order.

Small Releases

  • The first release is developed with the smallest useful set of features to increase the business value.
  • The main target is to release a working and tested software early as possible.
  • Software updates should be developed often to support fast releases.
  • The customer can use this software in its own environment that involve real users (Which allowing the customer to evaluate the software and send his feedbacks).

System Metaphor

  • Another responsibility of the “Metaphor”, is to determine a set of keywords that describes a common technical entities (Common Terms, Class Names etc.).
  • Each project as its “Metaphor”, is job is to guide the project resources on how the whole system works (Components, integrations, etc.).
  • Metaphor in XP is the common vision of the team members on how the program should develop and work. 

Simple Design

In Agile methodology the requirements are frequently changed, Based on this assumption, you should always use the most simplified software designs that allowing you to make the job done.

Continuous Testing

  • Testing is done throughout the entire process.
  • All tests must run and pass with 100% before a new development.
  • There are two types of tests that involve in this process:

Test Driven Development (TDD)
  • Automated tests that are written by the development team (Per functionality).
  • Programs write the tests prior to the application code development.
  • The code is produced with almost 100% test coverage.

Acceptance Tests
  • This tests is the “Contract” between the customer and the company.
  • The client can validate that the software is developed as specified.
  • Tests that are specified by the customer. 


  • To achieve value per iteration, the development team must build the software based on a simple and effective design.
  • Refactoring cannot be made without a corresponding testing to ensure that nothing was broken.
  • Refactoring is a design continues improvement that developers can do at any time.
    • During the refactoring phase, programmers can:
    • Edit their code (Edit code, but without changing the functionality).
    • Improve the software design.
    • Remove any code duplication.

Pair Programming

Two programmers are working on the same computer to complete a single Task.
  • Programmer no’1 – Responsible to write and implement the code.
  • Programmer no’2 – Watch the implementation and identifies any code errors.

The assumptions
  • Programmers will gain more confidence in their code.
  • Developers will enjoy working together.
  • Tasks will be resolved faster.
  • Produce higher quality code.

Continuous Integration

  • New builds are created Daily with the full code (the entire code that was developed by this point).
  • Any development is integrated to a single location when the code is ready.
  • IN XP developers must keep the system fully integrated at all times
  • All Unit tests must be run and pass with 100%.

Collective Ownership

  • Any developer must have the ability to work on any part of the code.
  • No specific developer that responsible for a specific component.
  • Code can be changed by any developer without delay.
  • A new code is reviewed by the entire team.
  • Increase the responsibility of developers.

On-site Customer

  • Developers can access to a real client environment (where the software is implemented.).
  • The customer should lead the project (Requirements, Priorities and timelines).
  • The customer should be available at all time (Face to face communication).
  • Developers will not use any assumptions during the development process.
  • The customer is one of the most important resources in XP process.
  • The customer should answer any open questions.

The 40-hour Week

  • In most projects, this practice is not relevant, the real world is different from the theoretical one J
  • Consecutive overtime hours will indicate that there is something wrong in the process.
  • The team will go home on time, there is no reason to do overtime hours
  • The project shouldn’t interfere with the developer’s personal life.
  • The work week should be no more than 40 hours.
  • Tired developers do more coding mistakes.

Coding Standards

  • Coding standards will help to develop a better code.
  • Every developer should follow the code standards.
  • Code review should be used as a method to validate that the expected standard is enforced.
  • Examples for “Code Standards”:
    • The code must include comments per method.
    • Coding conventions (Formatting, Naming, etc.).
    • Develop based on a specific design pattern.
    • The code should be easy to maintain. 

Extreme Programming Participants Roles

Image result for RolesCustomer

  • Responsible to specify and test the software functionality.
  • Specify the software requirements and specifications.
  • Determines the development priorities.
  • Create and explains the user stories.


  • Monitor the entire process and validate that the project stays on course.
  • Guides and mentors the team members.
  • Should lead by example.


  • Maintain the software through the process and after implementation.
  • Make the code implementation (User stories into working code).
  • Estimates the time and effort of the user stories.
  • Test the code (automated unit tests).


  • Responsible to make sure that small issues remain small and not get out of proportion.
  • Responsible to make sure that when a crises occurs, everyone will know about it.
  • Validate that each resources knows the risk involved.


  • Validate that each developer is on track with his assigned tasks.
  • Validate that each developer is synchronized at all time.
  • Arrange meetings with the client when necessary.
  • Validate that the project is going as scheduled.


  • Report for defects and any other issues that may affect the user experience.
  • Test the software functionality.

Thursday, December 24, 2015

Types of Performance Tests | David Tzemach


In order to achieve the best from your performance tests, you can combine few testing types that available under the term of “Performance”, a good and effective combination will lead to better and more precise results.

Please note, that for this post I will list each type of test, with a very short description (but I promise to create a dedicated article for each one of themJ). 

Types of Performance tests

Spike Tests
Testing the software with sudden overloads, the main goal is validate that the software can handle situations where there is a sudden jump in the user activity.

Reliability / Endurance / Soak Tests
Testing the system with different load for a long period of time, the main goal is to see that the system can handle sustained use for a long period of time.

Load Tests
Testing the software with increasing set of data (Near to the software limitation), the main goal is to see that the software can handle such loads without having any side effects (unexpected crushes, memory leaks, bottlenecks Etc.).

Scalability Tests
Testing the software performance while increasing the volume of users/environment and determine how the software will adjust to the growing scale.

Stress Tests – testing the software under load that exceed the system limitation, the main goal is to cause system failures ,  analyze the crash, and determine the way that the software recover in case of such failure.

Fail-Over/fault-tolerance Tests
Testing that the software corresponding to failures while involving two or more physical nodes, in this type of tests, we need to validate that in case of failure the users can continue with their work and the application data/services are moved to the available “Active” node.

Redundancy Tests
Testing the application redundancy mechanism in case of load, the main goal is to determine the effectiveness of the balancing system. 

Volume Tests
Testing the application with different amount of data, the main goal here is to understand the limits of our application and demonstrate how a specific amount of data can affect the predefined requirements.

Tuesday, December 22, 2015

Lesson 4 – JMeter Element review (Part 1)


Now that you know how to build the testing environment for this course, we can start to review the different elements in the JMeter user interface. 

Each Element is unique and designed to serve a specific purpose, therefore you need to understand the capabilities and the power that each element can provide when creating a test Plan.

A JMeter Test plan is built from a few elements (we will review them in the next few paragraphs) that the user can use during the creation of the test plan, the variety of elements will allow the user to gain a more flexible test that he can change based on the test results (the only limitation is that you must use at least one "Thread Group" which holds that combination of one or more elements: Timer..).


Thread Group

The Thread Group element is mandatory for every test plan that you build, therefore we can say that this element is the first element that you need to configure during the creation of a test plan.

That's great, but what is the purpose of this element…? The answer is that every Thread Group is a collection of one or more threads (Thread is equal to user) that using the application during the test execution (in other words, every thread that you set in JMeter, is compared to a real user that query the server that is under test).

How can we configure a new "Thread Group"..?

Option 1:  Edit Menu -> Add -> Threads (Users) ->Thread Group
Option 2: On the left Grid -> Right click on "Test Plan" -> Add -> Threads (Users) ->Thread Group

What are the "Thread Group" elements?


Name:  The name of the thread group.
Comment: just add a comment if you need one

Number of threads: Remember that each thread is simulate a physical user, this section will determine the number of users that connected a query the server during the test execution.

Ramp-Up Period: How long it takes to JMeter to reach to the full defined number of users. . If, for example, you defined 10 users with ramp-up period of 200 seconds, then JMeter will start all threads within the defined time (Each thread will start 200/10 seconds after the first thread is set to "Running" state (Delay of 20 seconds per thread)).

Loop Count: By default, JMeter will run for a single iteration, if you want to add more iterations you can control it by changing this field value (In other words, it’s the number of times that JMeter will run the test…).

Scheduler/Scheduler configuration: Once selected by the user, a new configuration window will be available with many different options that control the Start\Stop time of the scheduler.


As we already know, JMeter uses Thread Groups to simulate a user request to the tested server, but what are the type of requests that we can use? And how JMeter knows which one to send..?
The answer is Samplers, Samplers provide the ability to send a specific types of requests to the target server, and the user can use a predefined list of samplers, some examples:

HTTP Sampler

This sampler allows the thread group to send an HTTP/s Web request to the target server (IIS, Apache…).


1.       JMeter Send HTTPS Request to a Web Server.

2.       The Server returns his response (HTML page).

3.       JMeter process the server response.

4.       The User receives the analyzed results.

FTP Sampler

This sampler allows the thread group to send an FTP Request to a File Server.


1.      JMeter Send FTP Request to an FTP Server (We want to examine the response time when requesting to download a file from the server).

2.       The Server returns his response (File objects).

3.       JMeter process the server response.

4.       The User receives the analyzed results.

SMTP Sampler

This sampler allows the thread group to send an SMTP requests to a mail server (Email messages).


1.       JMeter Send SMTP Request to a Mail Server

2.       The Server returns his response (Server response time).

3.       JMeter process the server response.

4.       The User receives the analyzed results.

Logic Controllers

Logic controllers are assigned at the sampler level and provide the ability to control the sampler's execution and processing order per a sample element (If condition, Loop, Random Controller….). 

Tuesday, December 8, 2015

What Is Performance Testing ? | David Tzemach


In my opinion, if your goal is to be an excellent tester- Performance testing is one of the most important testing methods you need to get familiar with.

The main reason for it is, that this is one of the best ways to evaluate your systems' stability, reliability, and effectiveness, all under a given workload.

While executing performance tests, we must validate the system's ability to deliver an expected performance based on the predefined requirements and specifications (i.e.: Operation X should last between 1-5 seconds, Operation Y should not cause any delay greater than 1 millisecond).

Performance Tests –Main Goals

We can say that there are four main aspects we want to achieve during the process of our test execution, those four aspects relevant to the “Non-Functional” side of testing: 

The Application's Stability
  •  Is the application stable to use when running for a long time?
  •  Are there any architectures that lead to stabilization issues?
  •  Is the application stable to use under different loads?

The Application's Scalability
  • What are the environments that we can use to execute the software?
  • How many users can interact with the software at the same time?
  • How many inputs the software can handle at the same time?

The Application's Response time (responsiveness)
  • How fast the system interacts under different architectures?
  • How fast the system can return the expected output?
  • How fast the system can handle user request?

The Application's reliability
  • Is the application reliable for use by the end users?
  • Do the application critical bugs removed before we deploy the system on user's architectures?

Advantages of Performance testing

There are many reasons that can justify the existence of this testing type, among them we can list a few:

  • Performance tests allow the company to understand the overall limits of the system.
  • Performance tests can be used to evaluate and compare two systems against each other.
  • Poor performance results may indicate a configuration/functional defect.
  • Performance tests are also used to improve the end user experience.
  • Performance tests may involve some additional corresponding testing types that lead to greater coverage (endurance, Spike, and load etc.).
  • Performance tests can evaluate multiple aspects of the software (stability, overall performance speed, bottlenecks, effectiveness etc.).
  • Performance tests will allow the testing team to raise the problematic areas that are affecting the application's performance, based on this, the R&D department can improve the problematic areas that involve in the process. 
  • Performance tests are one of the best ways to evaluate the software under different architectures and overloads.
  • Performance tests will provide confidence in the product (Both from stockholders and management).
  • Performance tests are used to evaluate the product against the predefined requirements and specifications. 

Disadvantages of Performance testing

Although I reviewed many reasons why performance tests are great, every coin has two faces. So I just wanted to raise few disadvantages of this testing method, I know that it may help you when you need to decide whether to perform this type of tests or not.

  • Performance tests may not find functional bugs that you can find with other testing types.
  • Sometimes it’s very hard to understand the root cause of a problem.
  • Performance tests need a dedicated and large testing environment.
  • Performance tests need to be carefully designed and evaluated.
  • Performance tests is a process that takes time, Very long time.
  • Sometimes you cannot anticipate the expected results.
  • Performance tests are a costly process.
  • In most cases, performance tests are executed with 3rd party applications that need further learning and investigation.

Friday, November 13, 2015

How to Determine your bug’s Priority ?

Before we begin to review this section I want to add my personal opinion and say that the ability to determine the Defect priority is a real art, the owner that need to set the level of priority must consider multiple variables that should be calculated before he can set the relevant and appropriate priority level (you will see the complexity and involved parameters during my review).

Defect priority is a mandatory field on every defect report, its usually determined by the project owner and not by the tester which report the incident.
When the owner sets the level of priority he actually answer the basic question of; how urgently is to fixing this bug? 

Remember that during a testing process, you have hundreds and maybe thousands of reported defects with different level of severity (I hope that it’s not your case...), when setting the “Priority” level, we determine the order that those bugs will be fixed by the Eng. Team. 

In my opinion and based on my experience, the parameters that the owner should consider before he can set the ‘Priority’ level: 

  • The level of impact that this bug has on the engineering team (QA/Dev).
  • Is this bug affecting specific functionality/component or system?
  • The bug “Severity” level that determined by the testing team.
  • Available resources that can fix and test the defect.
  • The defect visibility and likelihood to reproduce.
  • The project timelines and current status.
  • Based on the general project priorities.
  • The bug level of “Risk”.
  • How this bug affect other process that doesn’t relate to the basic testing coding (Automation runs that failed to run due to this bug).

There are few concepts regarding the “Prioritization” levels (Depends on the company…), the generic levels that should be part from every scale are: 

Priority 1 (Low)
Bugs with this priority will be fixed only after that all the other bugs with higher priority are fixed , in many cases such bugs are not affecting the software release(in most cases will be fixed in future releases). 

Priority 2 (Medium)
Such bugs should be fixed between the “Low” – “High” priority bugs, in most cases will be fixed in the next software update/releases.

Priority 3 (High/Critical)
Bugs with this priority are critical and must be fixed as soon as possible, there must be a solution in the next build, bugs with this priority should be fixed previously to any lower priority bugs. In addition, bugs with this priority are crucial to the product release and must be fixed in advanced.

Priority 4 (Urgent/Blocker)
Bugs with this priority must be fixed as soon as possible (in some cases the project is stuck until they fixed), such bugs will lead to a major delay in the project and must be fixed prior to any other bugs with lower priority.

My Presentations