Thursday, September 8, 2022

Software Testing and STLC (Software Testing Life Cycle)

Software Testing and Software Testing Life Cycle

Software Testing:

Testing is the process of exercising the software product in pre-defined ways to check if the behavior is the same as expected behavior. By testing the product, an organization identifies and removes as many defects as possible before shipping it out. Software testing means verification of Application under Test (AUT).  Software Testing is a method to check whether the actual software product matches expected requirements and to ensure that software product is defect or bug free.

Software testing undoubtedly forms an integral part of the application’s software development lifecycle (SDLC), with agile and DevOps software methodologies on the rise, and the enterprise's quest for faster releases and quality products, it requires software testing methods that are faster and efficient than manual testing methods. At this point, test automation frameworks fits in.

Purpose of software testing is to identify error, gaps, missing requirement in contrast to actual requirement and ensures a quality product is delivered to customers. Software Testing is important because if there is any bugs or error in software it can be identify early and can be solved before delivery of the software product. Testing is important because software bugs could be expensive or even dangerous.

 


Types of Software Testing

1.      Functional Testing: ensures that functions and features of the application work properly. It is a type of software testing that validates the software system against the functional requirements or specifications. The purpose of Functional tests are to test each function of the software application, by providing appropriate input, verifying the output against the Functional requirements.

a.      Unit Testing

b.      Integration Testing

c.      UAT

2.      Non-Functional Testing: has a goal to validate performance of software. It is to check non-functional aspects like performance, usability, reliability, etc. of software applications. It is designed to test readiness of a system as per nonfunctional parameters which are not addressed by functional testing.


a.      Performance

b.      Load

c.      Value

d.      Scalability

3.      Maintenance Testing: performed to either identify equipment problems, diagnose equipment problems, or confirm that repair measures have been effective

a.      Regression

b.      Maintenance

 

STLC (Software Testing Life Cycle):

STLC is a sequence of specific activities conducted during the testing process to ensure software quality goal are met. STLC is Software Testing Life Cycle. It consists of a series of activities carried out by Testers methodologically to test your software product.
Phases in Software Testing Life Cycle model:

1. Requirement Analysis

2. Test Planning

3. Test Case development

4. Test Environment Setup

5. Test Executive 

6. Test Cycle Closure


Black Box Testing: A test that only considers the external behavior of the system; the internal workings of the software is not considered.

White Box Testing: A method used to test a software taking into consideration its internal functioning. It is carried out by testers.

Black Box

White Box

Testing method where the internal structure / design is NOT known to the tester

Testing method where the internal structure / design is known to the tester

Applicable to higher levels of testing (e.g. Acceptance, integration & system)

Applicable to lower levels of testing(Units, component, some integration & system)

Programming knowledge not required

Programming knowledge required

User stories/specifications used as basis for test cases.

Detail design / code used as basis for test cases (inputs, outputs)

        All-pairs Testing

        Orthogonal Array / Combinatorial Testing

        Statement

        Branch (Decision)

        Path

        Full Regression


Tuesday, August 30, 2022

JIRA: Create a sample Scrum project

 Create a Sample Scrum Project

  1. Open your Jira portal
  2. Go to Project > Create project
  3. In the Project Template screen, click Scrum

  4. In the Software Development screen, click Use Template.


  5. In the Choose a project type screen, select 'Select a Users Managed Project' and click Next.


  6. Enter a name for the sample project & click Next 


    Tip: If you are creating the project for a specific user, name the project 'Sample - [name user]'. This will make it easier to find and delete later.

  7. Click Connect, this will connect Bitbucket & Opsgenie to the newly created project.


  8. Check for the 2 green ticks & click 'Go to Project'


  9. New Project created



*You need to be a Jira Service Management administrator.

Thursday, July 28, 2022

JIRA Sprint : How to Complete or Close Sprint in Jira

 Completing or Closing an Active Sprint

  1. Open Jira portal

  2. Go to Backlog

  3. Go to the Active sprints of your Scrum board to view all the application 'active sprints' planning

  4. Select the sprint you want to complete from the sprint drop-down or right pane, & click 'Complete Sprint' this will delete all finish tasks associated with sprint.
    Note: that if you have multiple sprints in the Active sprints of your board, the 'Complete Sprint' button will not appear until you select one of the sprints.


  5. If all the work in this sprint is done the sprint is over.

  6. On above right corner you will see Complete Sprint, click it.

  7. If sprint has incomplete or open issues, a popup will emerge & ask you to select the next sprint to move All incomplete issues to new/upcoming sprint.

  8. If the sprint has incomplete issues, select from one of the following:

    • Backlog, to move the issues to the backlog

    • Any future sprint, to move the issues to any future sprint that's already created

    • New sprint, to create a new sprint and then move the issues to the new sprint


Note: Your issues won't be marked with the date the sprint was closed; however, you can always view the sprint for an issue to find out when the sprint ended.

Tuesday, April 7, 2020

BABOK Flash Cards - BABOK Exam Prep Concepts & Guide

BABOK Flash Cards

Plan Business Analysis Approach
1. Planning Approach
2. Formality and Level of Detail
3. Business Analysis Activities
4. Timing of BA Work
5. Complexity and Risk
6. Acceptance

Plan Business Analysis Governance
1. Decision Making
2. Change Control Process
3. Plan Prioritization Approach
4. Plan for Approvals

Acceptance Criteria
Criteria associated with requirements, products, or the delivery cycle that must be met in order to achieve stakeholder acceptance.

Actor (BA)
A human, device, or system that plays some specified role in interacting with a solution.

Adaptive Approach
An approach where the solution evolves based on a cycle of learning and discovery, with feedback loops which encourage making decisions as late as possible.

Predictive Approach
Defined before implementation to maximize control and minimize risk.

Artifact (BA)
Any solution-relevant object that is created as part of business analysis efforts.

Vertical
A prototype is used to drill down into a proposed solution to uncover requirements and design considerations through multiple layers

Prioritization
The process of determining the relative importance of a set of terms in order to determine the order which they will be addressed.

Solution Assessment is defined as:
Tasks a BA performs to assess the performance and value delivered by a solution.

Solution Requirements
The capabilities and qualities of a solution that meet stakeholder requirements.

Operational Support
Involved in monitoring day-to-day management and maintenance of a system

Evolutionary
A prototype created, reviewed with stakeholders, then modified, then reviewed and modified again

Document Analysis
Elicitation Technique most ideal if the objective is to gather details of the existing solution

Requirements Package
A set of requirements grouped together in a document or presentation for communication to stakeholders.

Business Case
Define the business need & recommend a solution

Business need is composed of Strategic and Tactical business needs

Requirements Sign off is the formal approval of a set of requirements by a sponsor or other decision maker

The business case articulates the projected cost benefit and risk assessment, but most importantly defines: How the cost/benefit will be measured

Business Analyst, as a change enabler, does certain activities during pre-project and continues to contribute even after the project is over.

A set of reasons for the change is called rationale.

Business Analysis:
Pre Project:
Performing needs assessment, creating business case to justify the reason for initiating a project & preparing benefits management plan.

During Project:
Handling the scope part of a project / requirements & designs (Specify & model,verify & validate), allocating the requirements to solution and recommending the best option.

Post Project:
Evaluating the solution for value realization, analyzing the factors preventing and providing recommendations to increase the potential value

If there is no standard, business analyst needs to collaborate with right stakeholders to define the approach (Plan Business Analysis Approach).

In projects, the approach (Plan Business Analysis Approach) can be developed during planning phase.

Document Analysis used to review existing organizational assets that might assist in planning the approach.

Stability indicates the maturity of the requirement. a changing requirements is not stable.

Information Management Approach: It includes the defined approach for how business analysis information will be stored, accessed, and utilized during the change and after the change is complete.

Business Analysis Approach:
The business analyst determines which approach is suitable for the initiative (Predictive / Adaptive), what is the formality or level of details needs to be captured, when the activities are supposed to be performed (In specific phases / iteratively), what activities are part of it, the size of the change and how complex it is and finally getting the consensus of key stakeholders to obtain sign-off.

Stakeholder Engagement Approach: 
Business analysts identifies and performs the stakeholder analysis to prepare effective communication and collaboration approach to be followed throughout the initiative.

Governance Approach: 
the business analyst determines the suitable governance approach and steps for various decision-making processes including change control, prioritization and approvals.

Information Management Approach:
the business analyst determines the storage and access part of Business Analysis Information including the attributes, level of detail and maintaining it for long term use.

Business Analysis Performance Assessment:
The focus is to understand whether business analysis activities are effectively performed and finding out ways to improve the performance to set guidelines for effective performance.

Understand the Scope of Elicitation: 
Business Analyst should be able to recognize and respond if the elicitation activity strays
from the intended scope.

Elicitation Results (confirmed):
Integrated output that the business analyst and other stakeholders agree correctly reflects captured information and confirms that it is relevant and useful as an input to further work.
To summarize, Business analyst verifies the information for correctness to avoid conflicts.

Determine Objectives and Format of Communication
The reason for preparing Business Analyst Information package: communication of requirements and designs to stakeholders, early assessment of quality and planning, evaluation of possible alternatives, formal reviews and approvals, inputs to solution design, conformance to contractual and regulatory obligations, and maintenance for reuse.

Stakeholder Engagement:
Willingness from stakeholders to engage in business analysis activities and interact with the business analyst when necessary.

Prepare for Elicitation:
To understand the scope of the elicitation activity, select appropriate techniques, and plan for (or procure) appropriate supporting materials and resources.

Conduct Elicitation:
To draw out, explore, and identify information relevant to the change.

There are three common types of elicitation:
Collaborative: involves direct interaction with stakeholders, and relies on their experiences, expertise, and judgment.
Research: involves systematically discovering and studying information from materials or sources that are not directly known by stakeholders involved in the change.
Experiments: involves identifying information that could not be known without some sort of controlled test. Some information cannot be drawn from people or documents—because it is unknown. Experiments include observational studies, proofs of concept, and prototypes.

Confirm Elicitation Results:
To check the information gathered during an elicitation session for accuracy and consistency with other information.

Communicate Business Analysis Information:
To ensure stakeholders have a shared understanding of business analysis information.

Manage Stakeholder Collaboration:
To encourage stakeholders to work towards a common goal

Level of Formality:
The effort to trace requirements grows significantly when the number of requirements or level of formality increases.

Maintain Attributes:
An attribute may change even though the requirement does not.

Penalty: 
Consequences that result from not implementing a given requirement.

Cost:
Effort and resources needed to implement the requirement. Information about cost typically comes from the implementation team or the vendor. Customers may change the priority of a requirement after learning the cost.

A proof of concept may be developed to establish that high risk options are possible.

Dependencies are identified as part of the task Trace Requirements.

Time Sensitivity:
The 'best before' date of the requirement, refer to seasonal functionality that only has value at a specific time of year.

Prioritization is an assessment of relative value.

Business analysts also ensure each proposed change can be traced back to a need.

Validate: 
Relationship between a requirement and a test case or other element that can determine whether a solution fulfills the requirement.

Stability: 
The likelihood that the requirement will change, either because it requires further analysis or because stakeholders have not reached a consensus about it. If a requirement is not stable, it may have a lower priority in order to minimize unanticipated rework and wasted effort.

Verify Requirements is for Quality

Validate Requirements is for alignment with business processes

Business Analyst Value Spectrum
Strategy Analysis focuses on Need and Solution Scope
Requirements Analysis & Design Definition (also known as delivery phase) Requirements (needs) and Design(solution)
Solution Evaluation focuses on PoC/Prototype, Pilot/Beta, Operating releases.

Task : Verify Requirements
The requirements and designs are ready for validation, and provides the information needed for further work to be performed.

Identify Assumptions:
Assumptions are identified and defined so that associated risks can be managed.

Define Measurable Evaluation Criteria:
To evaluate how successful the change has been after the solution is implemented.

Validate Performance Measures
Decisions about which measures are used to evaluate solution performance often reside with the sponsor, but may be made by any stakeholder with decision-making authority.

Performance measures themselves rarely trigger a decision about the value of a solution.

Requirements are focused on the need; designs are focused on the solution

Thursday, April 2, 2020

IPMO Course Outline


MODULE 1: BUILDING THE CONTEXT AND NEED FOR PMO’S
  • How Organizational Vision, Mission and Operational Objectives are linked to the realization of organization strategy through portfolios comprising of projects and programs
  • How project, program, product and portfolio life cycles are related
  • Functional, matrix and projectized organizations
  • Challenges and risks associated with projects, programs and portfolios
  • Project Methodologies – pros, cons and risks associated with knowledge based, procedural and competency based methodologies
  • Complexity and the need for principle based methodologies
  • Understanding the difference between project management success and project success
  • Success factors and success criteria – what they are and how to select the right ones to achieve success
  • Type 1 and Type 2 errors – impact on project, program and portfolio success
  • Stakeholders and their impact on PMO performance and project success
  • ‘Constantly changing factors’ and the impact on projects, programs and portfolios
  • The historical requirement for PMOs
  • History and evolution of PMOs (tactical vs strategic)
  • Mapping project, program and portfolio success factors to the PMO function
  • Why organizations are now giving senior management attention to fully understanding the potential of PMOs in both single and in a multi-PMO construct.
MODULE 2: PMO LIFECYCLE TO BUILD AND RUN PMO’S
Introduction to the PMO Lifecycle Framework
  • Definition of capability, service and how they are applied within the PMO context
Business Strategy and Environmental Enterprise Factors
  • Definitions and what they are
  • Describe how they influence PMO needs, design and running of PMOs
  • Techniques to categorize impacts and approaches to leverage opportunities and reduce threats
Governance
  • The concept of governance
  • PMO governance responsibilities
Adaptive Alignment
  • Definition
  • What is adaptive alignment
  • Why is it important
  • Process of adaptive alignment
MODULE 3: ASSESSING THE NEED, BUILDING AND/OR EXTENDING PMO’S
Business Needs
  • Process to determine direct and indirect business needs
Identification/Evaluate/Strategize
  • Identification of existing PMOs and potential PMO need
  • Evaluate existing and new PMO opportunities within organizational context
  • Strategize – How (PMOs will best fit and support organizational needs)
Business Justification
  • Building PMO Business Case(s)
  • Initiative specific PMO
  • Organizational PMO
  • Tools and Techniques
Design, Pilot and Implement
  • Design
  • Pilot
  • Implement
  • Defining metrics and tools
  • Planning for Quality (QA and QC)
  • Leveraging Organization Process Assets
MODULE 4: RUN, MONITOR AND CONTROL ONE (OR MORE) PMO’S
Run PMO’s
  • PMO Operations handbook
  • PMO Services and Capabilities handbook
  • Identifying and supporting troubled projects
Monitor, Adjust (Change) & Control
  • Proactive and Reactive aspects of PMOs
  • Assessing PMO maturity levels
  • Managing and Controlling Quality
MODULE 5: TRANSFORM/RETIRE PMO’S
  • Reason why PMOs are retired
  • Detailed process to close a PMO
  • Tools to support the closing processes
  • Facilitation of PMO Lessons Learned Discussions
  • Guidelines for transforming a PMO into another entity


Module 6: PMO Success and PMO Maturity
  • PMO Success
  • Is PMO Success a Good Term to Use
  • How to View PMO Success
  • Ways to Measure PMO Success
  • PMO Maturity
  • Defining maturity
  • Maturity models
  • Defining maturity metrics
  • Supporting an assessment process
  • Defining the ‘to-be’ state
  • Analyzing gaps
  • Link between PMO Maturity and PMO Success
  • Insights into current research


MODULE 7: CAPABILITIES TO BUILD AND RUN A PMO
  • Strategy
  • Business
  • Project/Program Management/Portfolio related
  • Service/Capability Management
MODULE 7: EPONYMOUS LAWS, THEORIES AND LATEST PROJECT MANAGEMENT & PMO RESEARCH
  • Definitions of a eponymous law, theory and phenomenon
  • Examples of eponymous laws that apply to project management
  • Use of theories in academic research
  • Single and Double loop learning systems
  • Applying system dynamics to model processes, contracts etc. to understand throughput and constraints before they happen
  • PMO hot research topics and top 10 findings
  • Managing management expectations on PMOs and how to stay relevant
  • Reasons why PMOs average life is only 2 years and how to adapt to increase the PMO’s value proposition
  • What comes after PMO certification in your career development


Monday, March 30, 2020

PMO Cheat Sheet

PMO Cheat Sheet

Q1) Where Process and Procedures that seems to conflict against the goals of the project, what can be used to determine if they are in the best interests of the project goals?
Answer) Principles

Q2) What are 'Unknown-Unknown' in Risk management?
Answer) Risks that have not been identified & will never identified until the risk has been triggered

Q3) Which PMO document is used to understand stakeholder communication requirements?
Answer) PMO Communication Management Plan

Q4) Which PMO Role is best suited to manage organizational Process Assets?
Answer) PMO Director

Q5) Where is Project or Program Control Center?
Answer) Is where the core project or program team works

Q6) The complete history of product is known as
Answer) Product Lifecycle

Q7) Which of the following is an advantage of projectized Organization?
Answer) Clear Authority

Q8) Which of the following options best describe how governance is applied once PMO governance is defined?
Answer) is continually optimized through improvement process

Q9) What term is used for the approved value of the workto be compelted in a given time?
Answer) Planned Value

Q10) Which of the options is not type of PMO according to PMI?
Answer) Informed

Q11) What is not an Organizational Structure?
Answer) Transparent

Q12) Reference to Agile PMOs is more asoiciated with
Answer)

Q13) Doing the 'right projects' is referring to
Answer) Portfolio management

Q14) The manager responsible for the work of a business function, business line or organization unit is known as:
Answer) Functional Manager

Q15) Governance Principles
Answer) Provide norms, rules and values for setting up a framework to steer management

Q16) A program is:
Answer) Set of related projects and/or sub-programs, and operations that, when managed in a coordinated way, will meet a common business objective.

Q15) A deliverable is a
Answer) Tangible and verifiable item that must be produced to complete the project.

Q16) Stakeholders should be identified and documented in:
Answer) Stakeholders register

Q17) PMO capabilities are NOT built from:
Answer) KPIs

Q18) Including within project decisions all the costs required to develop and operate the product is known as:
Answer) Life cycle costing

Q19) PMO Slack (spare time) should be used for:
Answer) Resources (time) for Knowledge management, innovation and partnering

Sunday, March 29, 2020

Entry Certificate in Business Analysis (ECBA) Based on BABOK® Guide

Module 1 – Introduction to ECBA®

Who is a Business Analyst

  • Catalyst for change
  • Independent assessor
  • Overcome internal inertia against change
  • Create positive attitude of collaboration
  • Self-confident engineer of change
  • Creative problem solver
  • Excellent communicator
BABOK Guide Six Knowledge Areas:

Business Analysis Planning and Monitoring: 
Tasks used to organize and coordinate business analysis efforts. 

Elicitation and Collaboration: 
Tasks used to prepare for and conduct elicitation activities and confirm the results. 

Requirements Life Cycle Management: 
Tasks used to manage and maintain requirements and design information from inception to retirement. 

Strategy Analysis: 
Tasks used to identify the business need, address that need, and align the change strategy within the enterprise. 

Requirements Analysis and Design Definition: 
Tasks used to organize requirements, specify and model requirements and designs, validate and verify information, identify solution options, and estimate the potential value that could be realized. 

Solution Evaluation: 
Tasks used to assess the performance of and value delivered by a solution and to recommend improvements on increasing values.   

Business Analyst Competencies
  • Analytical thinking
  • Behavioral characteristics
  • Business knowledge
  • Communication skills
  • Interaction skills
  • Software applications
  • Business intelligence
  • Business process management
  • Decision analysis
  • Enterprise architecture
  • Compliance issues management
  • Quality control
  • Organizational change management
  • Project management
  • Software improvements
  • Strategic planning
Business Analyst Activities
  • Understanding enterprise problems and goals,
  • Analyzing needs and solutions,
  • Devising strategies,
  • Driving change, and
  • Facilitating stakeholder collaboration.

Knowledge Areas Relationships 

Perspectives:  
  • Agile 
  • Business Intelligence  
  • Information Technology 
  • Business Architecture  
  • Business Process Management

BACCM Framework
Business Analysis Core Concept Model (BACCM) framework for business analysis:

  • Change
  • Need
  • Solution
  • Value
  • Stakeholder
  • Context

Software Testing and STLC (Software Testing Life Cycle)

Software Testing and Software Testing Life Cycle Software Testing: Testing is the process of exercising the software product in pre-define...