IT 309 - Part 2 Lesson

Testing Constraints

• A constraint is anything that slows a system down or prevents it from achieving its goal.
• Types of constraints in testing include policy, equipment, people, paradigm, and market.
• Policy constraints are due to company procedures and policies.
• Equipment constraints are delays caused by faulty, slow, or outdated equipment, or lack of space.
• People constraints can arise from the number of people on a project; too few or too many skilled individuals can cause a bottleneck.
• Paradigm constraints are caused by beliefs such as thinking 'lines of code' is a good metric for productivity.
• Market constraints occur when you're creating more software than needed, leading to over-engineering or feature creep.
• Most web application is shifting towards mobile application which is a challenge for development and testing due to different testing approaches.
• No fixed approach exists to test the application, and every individual/team plans their own test approach.
• Most companies are trying to shift to automation, while manual testing is still important.
• Testing is time-consuming, taking 30-40% of the SDLC life cycle.
• One needs to continuously learn and update their knowledge of multiple testing tools.
• Triple project constraints include time, scope, and cost.
• Time constraints relate to the project's schedule and time at which each part of the project should be completed including the final delivery.
• Scope constraints include all the features and functionality of the software product, as well as its goals and tasks that need to be completed.
• Cost constraints include the material resources including money that should be spent on a project to be delivered on time and according to the predetermined scope.

Testing Occurrence

• Testing should occur at every development stage of the product, not just as an after-the-fact activity.
• Test data sets must be derived, and their correctness and consistency should be monitored throughout the development process.
• If testing is isolated as a single phase late in the cycle, errors in the problem statement or design may incur exorbitant costs.
• Testing should be involved throughout the Software Development Life Cycle (SDLC) in order to bring out a quality product.

Testing Life Cycle

• The Software Development Life Cycle (SDLC) depicts or stands for a structured process that aids in producing high-quality, low-cost software in the quickest possible production duration.

• The Six Phases of the SDLC:

  • Requirements analysis
  • Designing the product architecture
  • Implementation
  • Testing Phase in SDLC
  • Deployment
  • Maintenance

• Software Development Lifecycles Models:

  • Sequential Development Models
  • Iterative and Incremental Models

• Classic life cycle or waterfall model is a type of development life cycle model in which a complete system is developed in a linear way of several discrete and successive phases with no overlap between them.

• Iterative and Incremental Models are a process of establishing requirements, designing, building and testing a system in a series of short development cycles.

• Examples of Iterative and Incremental Models include Prototyping, Rapid Application Development (RAD), Rational Unified Process (RUP), Agile development models

• Some Vital Phases of the SDLC Life Cycle:

  • Waterfall
  • Agile
  • Spiral
  • V-Model

• Common SDLC Models:

  • Waterfall
  • Agile
  • Spiral
  • V- Model

• For every development activity, there is a corresponding test activity.

• Each test level has test objectives specific to that level.

• Test analysis and design for a given test level begin during the related development activity.

• Testers participate in discussions to define and refine requirements and design. SDLC vs STLC:

  • SDLC: Requirement Gathering > Analysis > Design > Coding > Testing > Deployment
  • STLC: Requirement Analysis > Test Planning > Test Design > Environment Setup > Test Execution > Test Closure

• Software Development Life Cycle (SDLC) aims to produce a high-quality system that meets or exceeds customer expectations and works effectively and efficiently in the current and planned information technology infrastructure. Software Testing Life Cycle (STLC) identifies what test activities to carry out and when to accomplish those test activities.

• Software Testing Life Cycle (STLC) identifies what test activities to carry out and when to accomplish those test activities.

• Phases of STLC:

  • Requirement
  • Test Planning
  • Test Design
  • Test Environment Setup
  • Test Execution
  • Test Closure

• A bug lifecycle is also known as the Defect life cycle

• A software bug can be defined as the abnormal behavior of the software.

• Defect Life Cycle States:

  • New: When a tester finds a new defect.
  • Assigned: Defects that are in the status of New will be approved (if valid) and assigned to the development team by Test Lead/Project Lead/Project Manager.
  • Open: The development team starts analyzing and works on the defect fix
  • Fixed: When a developer makes the necessary code change and verifies the change, then the status of the bug will be changed as "Fixed" and the bug is passed to the testing team.
  • Test: If the status is "Test", it means the defect is fixed and ready to do test whether it is fixed or not.
  • Verified: The tester re-tests the bug after it got fixed by the developer, if there is no bug detected in the software, then the bug is fixed and the status assigned is "verified.”
  • Closed: After verified the fix, if the bug is no longer exits then the status of the bug will be assigned as "Closed."
  • Reopen: If the defect remains the same after the retest, then the tester posts the defect using the defect retesting document and changes the status to "Reopen”.
  • Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the status is changed to "duplicate” by the development team.
  • Deferred: In some cases, the Project Manager/Lead may set the bug status as deferred.
  • Rejected: If the system is working according to specifications and the bug is just due to some misinterpretation (such as referring to old requirements or extra features) then the Team lead or developers can mark such bugs as "Rejected"
  • Cannot be fixed: Technology not supporting, Root of the product issue, Cost of fixing a bug is more
  • Not Reproducible: Platform mismatch, improper defect document, data mismatch, build mismatch, inconsistent defects
  • Need more information: If a developer is unable to reproduce the bug as per the steps provided by a tester then the developer can change the status as "Need more information'.