Friday, October 28, 2016

Alpha Testing | David Tzemach

Alpha Testing

Alpha testing is one of the most important testing strategies that companies use prior to releasing the application to the wider market as a ‘Beta’ version.  It is used to validate that all defects and concerns are removed and that the application is capable to handle the complexity of a massive environment.

Testing Goals
  • Remove any open concern that the engineering has after the testing cycles.
  • To Ensure that from a customer point of view, we have a functional application without any open issues that can affect the software release timelines or quality.
  • Validate that the application is capable to run on the massive environment.
  • Approve that the software can be released as a Beta version.
  • Help the team to gain further confidence in the application.

Test Environment 
The tests are performed in a very complex environment, some companies will install the application in a real production environment (believe it or not…) and some companies will use an environment that simulates a real customer site. 

Performed By
Alpha tests are performed by many types of resources, in most cases by testers, but in some companies the application is installed and access is granted to all resources (Technical support, Product Managers, developers, and End users) that can use the application and report for any defect/issue that they found during the time of use.

Alpha testing in the software development life cycle
Alpha testing is used toward the final stages of the development process, when implemented in the test environment the product must be in a fully-usable state (There are no obvious bugs/critical issues).

Entry Criteria
The entry criteria for alpha testing must include the following considerations:
  • The environment setup is based on the application requirements.
  • The software is tested and ready for implementation.
  • There is no show stopper/Critical bugs.
  • The Build is available and tested.

Exit Criteria 
  • The application is running and functional throughout the testing process.
  • All bugs that found are fixed and implemented.
  • A test summary report is sent and approved.
  • All tests are done and passed.

Why should you run it? 
  • Help to identify defects that the QA teams cannot find on virtual environments.
  • Performed on a complex environment that simulates the customer site.
  • Will help to determine that the application meets the design criteria.
  • Increases the reliability, stability, and confidence in the application.

Monday, October 24, 2016

Unit Testing | David Tzemach

QA - Unit Testing


תוצאת תמונה עבור ‪unit test‬‏
Unit testing, is a process of testing the smallest available methods of code that can be tested (Units), during the testing process, the developer will use a set of inputs (Negitive and Positive) per function that will help him to understand if there are any logical errors, Failures and eventually to approve the behavior of the function against the preliminary requirements and design

A unit test are performed by the development team (Without a QA is interfering) and considered as “White” box testing. The importance of UNIT tests in the SDLC is critical, because it used by developers to validate that their functions are working correctly after creation and in any other scenario where the code is modified in advanced phases of the software development life cycle.

In addition, Unit tests are the first layer of testing used in the software testing process (Prior to component and integration tests).

Unit testing Advantages

Performed by developers
The tests are performed by developers that possess a Different state of mind from the one that testers use during the regular testing cycles (Black Box testing). 

This state of mind, will help the Eng. Team (who understands the behavior and outcomes for each testing unit) to add an additional layer of functional tests that will increase the confidence in the software prior to moving it to the next testing phase (Component).

Automated tests
The main and probably the biggest benefit in UNIT tests, is that all tests are automated, therefore the tests can be re- used when the code is modified, this will help to determine if the functionality is working as it was prior to the new code.

Simplify the debugging process
When performing unit tests, the developer will examine the functionality of the smallest testable part of code, therefore it will make it easy to debug each test in case of a failure.

Reduces Costs
It’s a known fact that the cost of software defects increases in each phase of the software development life cycle (SDLC). Unit tests are the first testing layer in the SDLC and as such it can help us to remove defects that can appear in older phases of the project.


Software Testing Phase Where Bug Found
Estimated Cost per Bug
System Test
Integration Test
Full Build
Unit Test / Test Driven Development

Increases the Confidence in the written code
Executing unit tests is a great tool for developers to gain confidence in their code, just think that each code change could be examined quickly and after the engineer already knows the previous testing outcomes. In addition, writing tests and executing them allowing the developer to gain additional knowledge about the logical structure of the code.

Unit testing limitations

Unit testing coverage
Unit tests can cover only the functional aspects of the tested code, it cannot provide any indication about other aspects such as User Interface, Usability and many more criteria’s that we need to test to validate that the software is working based on the preliminary requirements and specification.

Complexity of the test
UNIT test is used to test a small part of code, you cannot use it to test complex scenarios that you will cover on advanced phases of the SDLC.

Tests maintenance 
When working with methods that frequently changed (Like complex algorithms) the maintenance of the tests can cause massive investment both in time and money.

Unit Testing Life Cycle

Phase1: Picking the requirements
Every development starts with SRS design that determine the client/Company requirements. In this phase the developer already acknowledged with those requirements and can start the development.of the application.

Phase 2: implementing the code
There are two different approaches that developers can use, the first option is to write the code and then design the unit tests, the second option is to write the tests prior to writing the code using the Test Driven development (TDD).

Phase 3: Executing the tests
After both code and test cases are implemented, it’s now the time to run the tests and search for defects in you code.

Phase 4: Code modifications and re- execution
Based on the outcomes of the previous phase, the developer can modify the code and re-run the tests again.

Thursday, October 13, 2016

Top list of Software Development Life Cycle Risks | David Tzemach

What is Software Risk?

Risk is the potential of loss. This potential is based on both the probability of occurrence (uncertain and undesirable outcomes that may lead to a major problem at any given point in the software development life cycle) and the impact on the business/project and software (combination of time delay, Financial loss, reduce in performance, loss of reputation etc.).תוצאת תמונה עבור ‪Software Risk‬‏

General causes of Risks

There are multiple reasons of project failures, sometimes the cause of the failures are located in the business level and some time on a specific stage of the SDLC. I created this list that has more than 150 real life examples that you can include in your own RM process, the list is divided into few simple categorize that make it more readable for you. 

Stakeholders Related Risks

  • Allowing the stakeholders to dominate the project.
  • Failure to engage the company stakeholders.
  • Failure to understand the response of the stakeholders in case of failed projects.
  • Failure to understand the stakeholder’s expectations.
  • Team members that afraid to take decision because some stakeholders maybe decline it.
  • The Customer changed requirements that may lead to stakeholder’s conflicts.

Business Related Risks

  • Does the project match the company culture?
  • Failure to create an effective communication between the resources that involved in the project (Departments, individuals, Etc.).
  • How the current project will affect the company future “Road-Map”?
  • How the current project will affect the company reputation?
  • How the current project will affect the company revenues?
  • How the project affects the historical/Future sides of the company?
  • How this project affects other projects that spread throughout the business?
  • Software that fails to answer the customer expectations.
  • The product will fail to be “sold” following the expectations?
  • The project will fail to meet the actual needs of the organization?
  • The Software will fail to be delivered on time.
  • Unstable company environment.
  • What amount of other customers will use the current developed technology?
  • What are the extra costs will be, if the software will be failed to be delivered on time?
  • What is the ROI for the company regarding this project?

Project Timelines related Risks

  • An external source(Stockholder, sales person, client Etc.) that pushes that team member to make unrealistic commitments about the project timelines
  • Delays on one task that affecting the total timelines of the project.
  • Expectations that promised by the management and cannot accomplish during the project timelines.
  • Failure to understand the complexity of the project.
  • Failure to understand the project risks.
  • Failure to understand the set of skills that needed to accomplish the project targets.
  • In order to secure a contract with the company customers, the project timelines are cut, in a way that affecting the software quality.
  • Managers that failed to prioritize the daily/weekly/Etc. Tasks.
  • Personals that involved in the process need longer time than expected to learn unfamiliar environments, technology Etc.
  • Schedules that build based on resource that not available.
  • Schedules that built on “Best case”.
  • Specific Project aspects that failed to be concluded in the project timelines.
  • Teams that behind the schedule and hope to catch it without reporting on time.
  • Testing and development activities that dependent on external resources.
  • The analysis that is done to create the timelines are poorly documented.
  • The resources that involve in the project, are not familiar with the project timelines.
  • Tight timelines that affecting the resource productivity.
  • Timelines Estimations that delivered without a solid information.
  • Unexpected tasks that raised during the project.

Team related Risks

  • Lack of positive and negative feedbacks.
  • Problematic team members are failed to be excluded from the project.
  • Team is built with unclear hierarchy.
  • Team members are failed to work together as one unit.
  • Team members that are not experienced enough.
  • Team members that are not qualified enough to handle the project complexity.
  • Team members that failed to understand the company business case.
  • Team members that failed to understand the user “use” cases while designing and executing their tests.
  • Team members that failed to understand the user expectations.
  • Team members that failed to understand the user story.
  • Team members that failed to understand their responsibilities.
  • Team members that failed to understand their role in the team.
  • Team members that ignore or failed to understand the design documentation.
  • Team members that ignore the project process.
  • Team members that resistance to work based on the requirements.
  • Team members that work more hours that they should because other team members failed to perform their job.
  • Team members with Lack of commitment.
  • Team members with Lack of motivation.
  • Team members with Low team spirit that affects the team performance.
  • Team members with negative attitude towards the project goals.
  • The team failed to contain a specialist to support the technical difficulties that may raise during the project.
  • The team is built based on unqualified persons for the job.
  • There are insufficient resources in the team to handle the project tasks within the current timelines.

Environmental related Risks

  • Architectures that designed with a lack of flexibility that will be needed for different SDLC levels.
  • Designed architectures that are impossible to implement during the project timelines/costs.
  • Dev/QA team members are not familiar with the tools that used in the project.
  • Development and testing Environments that designed for the project, but not relevant to the actual needs.
  • QA\Dev teams that don’t have an appropriate hardware/Tools Etc., to accomplish the development and testing requirements.

Budget related Risks

  • Additional expansions due to new requirements/changed requirements.
  • Costs that related to meet the release deadlines.
  • Failure to forecast the cost estimations.
  • Improper estimations of the needed budget.
  • Project delays that may consume more money than originally expected.
  • The costs of External service providers.
  • The costs of internal employee’s.
  • The costs of the software’s that involved in the Management/reporting/ development/testing process.
  • Unexpected Budget cuts.


Planning and design related risks

  • Different developing teams that start their developments individually (each team is responsible for single component) without the basic thinking of the overall developing architecture (the classic example is failure of integration of those individuals).
  • Choosing the first available solution without considering if other solutions have better met the project goals.
  • Failures that related to a corrupted process implementation.
  • A Highly complex, software architecture that delivered as single process inset a small chunks that easier to process.
  • Lack of project planning that cause development and testing duplications.
  • Lack of project planning that cause development and testing gaps.
  • Lack to design an appropriate methodology to handle the project complexity.
  • Planning is considered as the project owner responsibility, although it’s should be a team activity.
  • Planning that ignoring critical project parts.
  • Planning that made by people that doesn’t have the experience.
  • Poor project design that affecting the entire project (Timelines, costs Etc.).
  • Poor project design that affecting the technical aspects of the software (Developing, Testing and maintenance).
  • Teams that move into the next project phase without completing the previous stage.
  • Unclear responsibilities for the resources that involved in the project.
  • Underutilized resources that affecting specific areas in the software.

Resource allocation and hiring related Risks

  • Contactors/Permanent workers leave the project in the middle.
  • Failure to allocate the best available people for the project.
  • Failure to hire the correct propels.
  • Hiring of new resource is taken longer than expected.
  • Insufficient resources to accomplish the project timelines.
  • Part time employees.
  • People that got assignments but not capable to handle them.
  • Persons that have specific skills cannot be found and recruited in time.
  • Resources that not tracked properly.
  • Resources that participates on multiple projects.
  • Resources that shared between multiple projects.
  • The company best workers are not available for the project.
  • Underutilization of the resources involved in the process.

Customer related Risks

  • A customer that changed the requirements all the time.
  • A customer that failed to deliver a detailed requirement.
  • A customer that failed to understand that deadlines are dynamic and may be changed during the SDLC process.
  • A customer that failed to understand the complexity of the project.
  • A customer that finds bugs
  • A customer that has ambiguous requirements.
  • A customer that has unrealistic expectations.
  • A customer that uses the software in a different way than expected.
  • Customer that we know that we had prior problems on other projects.
  • Customers that interrupt the SDLC process.
  • Customers that will not buy the software, although the software delivered in time and based on the asked requirements.
  • Promises that made to customers that the software will eliminate their problems without a real proof.
  • The customer declines the software due to low quality.

Requirements related Risks

  • Ambiguous and insufficient requirements.
  • Key requirements are poorly documented.
  • Requirements that demands new methods in the Dev/testing process.
  • Requirements that demands new testing methodologies.
  • Requirements that demands new testing types.
  • Requirements that doesn’t reviews by the project resources, this may lead to different expectations and wrong design.

Technical and technology related Risks

  • 3rd party applications that failed to provide the expected solution.
  • 3rd party applications that used without an expert that can answer the open questions.
  • Badly chosen auto tools that failed to support the project needs.
  • Components that build by external vendors.
  • Components that built with unreliable technology.
  • Components that built with unstable technology.
  • Customer requirements that demands new technology development.
  • Customer requirements that demands older code modification that involved in the current SDLC process.
  • A Development that based on a new technology that unfamiliar to the engineering.
  • Insufficient methods and tools for software analysis.
  • Is there any customer specific hardware/software that needs a special development?
  • Lack of understanding of the chosen technology.
  • Lack of understanding in the coding language that need to be used in the coding stage.
  • Lack of understanding of the testing tools that used in the testing process.
  • Multiple technologies that need to be combined to handle the customer expectations.
  • New technologies that used in the current project.
  • Software that poorly documented.
  • A Technology that used and hard to maintain.
  • The software should support new operating systems that have never been supported before.
  • What are the testing tools (if any) that used in the testing process?

Daily activities related Risks

  • Activities that abandoned from the project scope.
  • Conflicts between team members.
  • Failure to create a valid mechanism that can track and implement the customer newly added requirements (failure to establish such mechanism will lead to failure in handling the requirements that leads to the growth of the project scope).
  • Failure to prioritize the project activities.
  • Lack of formal technical reviews (Code design).
  • Lack of formal technical reviews (Project requirements and specifications).
  • Lack of formal technical reviews (Testing process).
  • Management and project owners that disregard important meetings.
  • Missing or poor documentation that leads to a poor description of the project requirements.
  • Multiple “Change-Requests” that documented poorly and against the original requirements.
  • Project changes that failed to be addressed to the project resources.
  • Stakeholders and management conflicts may cause project distractions.
  • The amount of documented reports take too much time.
  • Too much formality that results slower progress.
  • Under/overhead communication between the project resources.

Project Management related Risks

  • Management and project owners that disregards the project daily status.
  • Management and project owners that disregards the project process.
  • Management decisions that reduce the employee’s commitment.
  • Management decisions that reduce the employee’s motivation.
  • Management politics that cause any interruptions.
  • Management that doesn’t believe in the project.
  • Management that failed to handle resources that perform below the expectations.
  • Management that failed to have good relationships.
  • Management that failed to say “No” when they know that they cannot deliver the expected quality during the specified timelines.
  • Management that failed to understand the project complexity.
  • Management with lack of confidence.
  • Managers that deliver poor project planning.
  • Managers that doesn’t have enough experience to lead large scale projects.
  • Managers that failed to create an efficient team structure.
  • Managers that failed to handle the project pressure.
  • Managers that failed to make an appropriate “Risk” analysis.
  • Managers that failed to manage the golden criteria(Timelines, Quality and Costs)
  • Managers that failed to prioritize the employs tasks.
  • Managers that failed to provide new timelines when needed.
  • Managers that failed to think ahead about potential problems.
  • Managers that works based on assumptions and not by the true facts.
  • Mangers that failed to provide a clear and solid mile stones.
  • Organizational management changes during the project.
  • Owner that use an intensive “Micro-Management” that affect the development and testing performance.
  • Owners that failed to create an appropriate training program.

My Presentations