Benefits of Finding Defects in the initial stages of the Software Development Life Cycle

Software Project teams work hard throughout the software life cycle to create quality software outputs. It’s a general perception that Testing team  is responsible for the quality of the software by identifying quality defects. The truth is everyone in the Project team is equally responsible for the software quality. The defects can be introduced into the software right from the Requirements writing stage and then can propagate further into the next stages. Defects can be introduced at any stage and by anyone.

For the same reason mentioned above. it is very important to identify the defects as early as possible. There are multiple benefits associated with it, like less cost and reduced time to fix, prevents further multiplication of the defect and better quality, confidence in the processes.

For example, if a defect is introduced in the Requirements stage and not caught by anyone, it could easily multiply in the software code and further into the test cases. On identification at the later stage, it would be more expensive to fix as compared to the early stages. On the other hand, if it’s identified early it can be fixed right at that stage, thereby bringing clarification to all the team members. Static Testing is an important activity to identify such defects.

Static Testing

Static Testing is a very important activity in the Software Testing Life Cycle. Static Testing relates to identifying the defects without executing or running the software. It starts early and addresses the need to find defects as early as possible.

The scope of Static Testing includes all the documentation like software requirements, code, test plan, test cases. The term/process used to perform such a testing is called ‘Review’. Review can be a formal or informal process and makes sure another person (SME) can go through the document to identify gaps, defects in the documentation. Based on the Review comments/feedback, the document is revisited to fix the identified defects.

Testing team relies heavily on the review of all the Test deliverables created in the project to streamline the testing processes and generating quality testing results.

The real benefit comes from the point that gaps identified in the early phase of the software life cycle are easy and inexpensive to fix than if they are found in the later phase of the software life cycle.

Similarly, software code can be reviewed to find defects. There are some tools available in the market which can also be used for the code and this activity is called Static Analysis.

PRINCE2 – Performance Targets/Variables

PRINCE2 – 6 Performance Targets/Variables

There are 6 variables or aspects of a Project to be managed during the Project Life Cycle.

Cost, Quality, Timelines, Risks, Scope and Benefits. The Project Manager (PM) has to monitor these variables to track the performance of the project and to take necessary steps for any deviations from the actual plan. PM needs to understand the criteria to put these factors under Red, Green and Amber status.

Cost defines the Return on Investment (ROI) for a project. The project has to be within budget and PM needs to apply the cost controlling steps, if required.

Quality covers the end result of the project. The Product or Software created should be useful at the end and necessary checks are being implemented to maintain the quality like reviews, software testing, processes.

Timelines are important as all the stakeholders expect outcomes at the defined time intervals in the project life cycle. The PM has to keep notice of the overall finished date while analysing project deliverables at each stage.

Risks are to be visited regularly, either to eliminate them or reduce their impact (if can’t be eliminated). This involves interacting with project teams and understanding each identified risk in terms of probability and impact.

Scope should be clear across all the teams and stakeholders. The PM should remove any ambiguity and stand strong against scope creep unless absolutely necessary to add further requirements during the project.

Benefits define the need of doing the project and expected benefits. The PM must know the benefits and communicates to the project team to make sure they are delivered at the end.

Follow and Like us:

PRINCE2 – Performance Targets/Variables

PRINCE2 – Project Characteristics

The Project characteristics differentiate it from the BAU process. These are the five characteristics,

Change is introduced by the Project and it could be a new implementation or change in the existing functions.

Temporary nature of the project conveys that there should be a start and end date of a project. Once everything defined in the scope is delivered, it should stop.

Cross-Functional talks about the different teams, stakeholders from different business units and all working together to deliver a project.

Unique is the attribute of each project. No two projects can be same, there would always be a unique differentiating factor.

Uncertainty means, there is no surety on the project journey and how all the things are going to happen. It’s just a plan and realised as team goes forward with it. The influencing factor could be internal or external.

Follow and Like us:

PRINCE2 – Project Characteristics

Agile – Daily Scrum – Facts

• The Daily Stand-up meeting is an important activity in the Agile-Scrum methodology. Everyone talks about,
  
  
  • what was done yesterday
  
  
  • what is the plan for today
  
  
  • and any impediments
  Here are some of the facts to carry out an effective Stand-up.
  
  
  • The Daily Scrum or Stand-up should start and end at the same time. It shouldn’t wait for someone to turn up.
  
  
  • Outside team members can attend but should not interfere.
  
  
  • Every team member should talk about – Things done yesterday, Planned for today and any impediments and nothing else.
  
  
  • It’s an Inspect and Adapt approach towards the work being done in Sprint.
  
  
  • It’s a Planning platform and not a status reporting meeting.
  
  
  • More details around the issues should be done later and not in the stand-up.
  
  
  • Same location, same time every day.
  
  
  • Time-boxed (15 minutes) and Scrum Master is responsible to ensure the timelines.
  
  
  • Least Manager’s involvement, self-organising team.
  Follow and Like us:

  
  
  Agile – Daily Scrum – Facts

Test Centre of Excellence (TCoE or CoE)

TCoE (Testing Center of Excellence) is a collection of shared services providing different testing services like manual, performance, automation, etc. The main objective is to centralise all the services, processes under a single umbrella and to be followed by all the projects. This ensures consistency of the quality processes all across the organisation/projects.

It can be specific to each client, as per the requirements, catering to diff CoEs like Performance CoE, Automation CoE. In this case, client requires Performance, Automation CoEs only. CoEs can be combined if small and can be separated if large enough.

Another important characteristic of CoE is its existence. It can be permanent (automation) in the project or virtual (create a team for a task and then dissolve it after the completion), as per the project requirements.

TCoE Governance Structure

TCoE Governance Structure

The basic Governance structure of TCoE comprises of two levels. The primary objective is to segregate the management goals and operational execution of the model.

TCoE Leadership Team, chaired by the TCoE Executive Sponsor. The Leadership team is responsible for setting the strategic goals in-line with the TCoE vision.

TCoE Operations Leadership, chaired by the TCoE Project Champion. The Operations Leadership team is to ensure the smooth implementation of the TCoE model by providing overall leadership.

TCoE implementation has four stages.

• Plan

Planning stage comprises of preparing a long term plan for the TCoE process and how to obtain organization’s testing information.

• Do

This phase deals in assessing testing capabilities of the organization.

• Check

The gaps are identified in the current processes. The future metrics, processes, implementation roadmap are defined.

• Act

Testing capabilities are implemented, uplifted throughout the organization to reap the benefits of TCoE.

This entire process goes on as a continuous improvement to refine goals, processes, operating plans.

Follow and Like us:

Test Centre of Excellence (TCoE or CoE)

Traceability Matrix

Traceability Matrix helps in mapping the Software Requirements with the Test Scenarios/Cases. It’s a useful test document to carry out testing activities, especially in an environment where requirements keep on changing.

Whenever there is a change in the requirement, the Test Analyst can refer to this document to identify the Test Cases getting impacted. This would help in understanding the impact and coming up with an additional testing effort required to accommodate that change. In the absence of the Traceability Matrix, it would be difficult to understand the scope and change impact on the testing effort.

Another value add of this document is to include Defects information in it. That way, there is complete mapping of the software requirements to the Test Cases and further to the Defects logged in the test execution phase. Such information can be further used as an input to the Testing Metrics.

Follow and Like us:

Traceability Matrix

Test Plan

Test Plan is a document detailing the scope, approach, resources and schedule of the intended test activities. It specifies the features to be tested, the testing tasks, test documents, roles and responsibilities, test environment, test design techniques, staffing and training needs, entry and exit criteria to be used and any risks requiring contingency planning.

Test Plan can be used for Unit, ST (System Testing), UAT (User Acceptance Testing) or any other phase of testing which is in scope and should cover and discuss all the test related activities for that phase. A Testing team member (Test Manager / Test Lead / Test Analyst ) is responsible for creating a Test Plan.

Most of the sections are self-explanatory. I’ll cover some of them below for better understanding.

The Scope section covers all the Functional and Non-Functional testing that is going to happen in the project and any Out of Scope testing.

Test Approach defines the overall approach and various test techniques like Risk Based Testing approach to carry out the testing activities, number of Test Cycles  required.

Roles and Responsibilities section lists all the Project Team members, their roles, what tasks are expected from them and important contact numbers.

Test Environments are very important for the Testing. A schedule to use the environment needs to be discussed and agreed with the Test Environments owner as there could be a number of projects planning to utilise the particular environment for testing. The usage dates clashes need to be dealt very carefully considering the project priorities and other factors. The owner of the Test Environment can be a Testing team member or from the Infrastructure team.

Release Management is another area often neglected by the project teams. The process to get the release of the builds or versions of the software and deployment (including approvals) has to be agreed, especially in the vendor-client relationship.

The Entry & Exit criteria always have one or two exceptions which need to be approved by the stakeholders before moving ahead.

Follow and Like us:

Test Plan

PRICE2 – Initiating a Project Process | Initiation Stage

The Initiation Stage (IP) is the first stage of the project after the approval from the Project Board. The Project Manager (PM) does most of the work by taking help from others like Executive for the Business Case, Users & SMEs for the Product Descriptions & Estimations.

The Product Initiation Document is the output in this stage and consists of the following:

• Project Plan


• Product Descriptions


• Business Case


• Strategy documents ( Quality, Risk, Configuration and Communication Management)


• Project Controls


• Team Structure, Roles and Responsibilities

All the information is provided to the Project Board and based on the assessment, especially considering the factors like Risks, Benefits and ROI information, the decision is made to go ahead or not.

The IP stage takes longer time than the SU stage.

Follow and Like us:

PRICE2 – Initiating a Project Process | Initiation Stage

Defect or Bug Triage Meeting

Defect or Bug Triage Meeting is very important in the Test Execution phase. The meeting can be hosted by a Test Lead/Manager, Development Manager or Business Analyst. The goal is to make sure valid defects having correct severity & priority are going into the Defect Life Cycle and there is no impediment to the defect life cycle. Any invalid defects are quickly recognised in the meeting so that there is no additional time spent on such issues.

The Defect Triage meeting can happen daily or weekly as per the project requirements or current status of the Project. It plays a vital role in keeping track of the Defects Count, status, severity and their Fix Rate. Any gap can easily be identified and then an appropriate action can be taken to bridge that gap.

For Example,

• If high severity defects are not getting fixed by the Development team then the Test Manager or Business Analyst or any other stakeholder can escalate in the meeting to target their fixes.


• Another example could be if there are too many defects in one feature then an action plan can be prepared to target such feature pro-actively.


• Testing team has too many defects and are not getting re-tested to clear out the testing team bucket.

Follow and Like us:

Defect or Bug Triage Meeting

Defect or Bug Life Cycle

Let us discuss a typical Defect Life Cycle in a Software Development Model.





New – A Defect is in a New status when logged. The Project stakeholders discuss about the defect in the Defect Triage and if it’s valid, move it further to the next stage.

Open/Assigned – The Open status defect is a valid defect and assigned to the Development team to fix it.

Fixed –  After successfully fixing the code, the Development team marks the defect as Fixed and is available for the Testing team to retest.

Re-Opened – In case, the fixed defect still displays the earlier deviation from the expected requirement then the Testing team re-assign it to the Development team by marking it as re-opened.

Closed –  If the defect is fixed and the requirement is working as expected, the Testing team mark it as Closed.

Deferred – The defects are put into this status, if they are not considered to be fixed in the current release or version of the software. They are marked as deferred to pick them again in the future version/release.

Duplicate – In case the logged defect is already available in the bug report, it’s marked as Duplicate.

Invalid – The defects which do not fall under the project scope or logged because of the lack of tester’s knowledge, can be marked as invalid.

There could be some additional status of the defects as per the Project requirements.

Duplicate, Invalid (Testing) and Re-Opened (Development) count or metrics can be utilised to measure the performance of the Testing and Development teams.

Follow and Like us:

Defect or Bug Life Cycle

Difference Between a Tester and Test Analyst

I’ve seen many people using a generic term Tester(s) to refer to the testing team members, which is quite normal. But on the other side of it, many testing team members often feel offended by the term Tester, especially those who are Test Analyst (TA). To the outside world, there is no difference but within the Testing team, it does make a difference.

Tester is anyone who is executing test cases or doing some type of testing by executing the software.

Test Analyst is a person who is doing analysis of the software requirements, doing estimations, preparing and executing test cases.

So, to differentiate at a high level Test Analyst job is a specialised skill-set and requires some experience while a Tester can be anyone executing piece of software to find bugs.

Follow and Like us:

Difference Between a Tester and Test Analyst

How to Write an Effective Defect or Bug Report

Writing an effective Defect/Bug Report is very important from Testing perspective. It’s communicating the software defects/bugs to the development team and stakeholders.

The following are the guidelines, one can keep in mind before writing a Bug Report.

• Write steps clearly, in a way that anyone without the knowledge of the software/application can reproduce the bug.


• Title should be brief and communicate the exact bug behaviour.


• Mention the exact environment in which the bug is reproducible.


• One report for one bug. Don’t mention multiple bugs in a single report.


• Report all the bugs even the trivial.


• Attach the relevant proofs like screenshot, video, crash log.


• Assign clear Severity and Priority as per the bug.


• Separate fact from speculation.


• Don’t target anyone in the report, it should be generic.


• Mention additional observations separately in a different section in the report.

Follow and Like us:

How to Write an Effective Defect or Bug Report

PRINCE2 - Starting Up a Project (SU)

In PRINCE2, the Project is initiated by the Corporate Management team by creating a Project Mandate. A Project Mandate could be in the form of an email, one-pager document or a format document created on company’s standard template and represents an idea or an output of some analysis which would give future benefits if implemented. It provides the high level business case information for the project, reasons to start the project and some other basic information.

Starting Up a Project is the first process and comes under a Pre-Project activity. It’s actually provides information to the Project Board, to seek approval to start the Project – Initiation Stage. Another important reason is to analyse if it’s beneficial to even start the Initiation Stage of the project. The main outputs expected from this process are,

• Project Brief – It covers the Project Scope, Business Case information available in the Project Mandate is further expanded in this document as Outline Business Case and other collected information in this phase.


• Initiation Stage Plan –  A detailed planning of the work for the Initiation Stage.


• Project Product Description –  Project Manage creates a description of the main product that will be produced.

The timelines for this process are very short (say, one week) as compared to the rest of the project timelines and differ from project to project.

Follow and Like us:

PRINCE2 - Starting Up a Project (SU)

Motivating Team Members

Every leader/manager encounters this question on a daily basis. How to keep his/her team engaged and motivated?

The answer is simple but yet difficult to implement. The leader has to map team’s aspirations with the company goals or project opportunities. Most of the time, the primary aspiration is same for all the team members. In that case it becomes very tricky from management point of view. My viewpoint is to make sure the deserving team member gets the priority and manage other team members with some other motivational factors.

Another important approach to keep the team motivated is by delegating the authority which makes them own the tasks and instils the responsibility factor.

There would always be situations where one or more team members will feel let down and that’s the test of a true leader to manage it properly without any impact on the team and work.

Follow and Like us:

Motivating Team Members

Agile Scrum - Sprint Retrospective Facts

• Sprint Retrospective meeting is strictly between the Scrum Master and the Development team. Others can be invited if they provide a value add to the meeting purpose, even the Product owner.


• The primary motive is to learn continuously from the previous Sprint mistakes.


• The Action items from the meeting fall under the SMART criteria i.e. Specific, Measurable, Attainable, Relevant and Time-Bound.


• The Scrum Master should change the meeting format from time-to-time to encourage participation and fresh ideas rather than sticking to the same format.


• Sprint retrospective is focused on the processes being followed and how to improve them.


• Positive team culture and trust are important factors for the success of Sprint retrospective.


• The Retrospective is applicable to all the teams, irrelevant to the high-performing or low-performing team.


• To encourage participation from everyone, it’s a good idea to have a few opening lines from every participant.


• Apart from the Scrum Master, others can also facilitate the meeting.

Follow and Like us:

Agile Scrum - Sprint Retrospective Facts

Test Summary Report / Test Sign-off Report

The Test Summary Report (TSR) of Test Sign-off Report provides a test execution summary for the testing phase (e.g. Sys, UAT) and a recommendation of the readiness to progress to the next phase (e.g. Production).

The purpose of the TSR is to share the testing results, outstanding defects & issues, assessment of the risks & conclusion and a recommendation based on the confidence of the testing team.

The Test Summary Report document should state a recommendation from the testing team highlighting the testing experience and reasons for the decision to progress to the next phase or to continue in the current phase. It should also specify the overview of the test conditions tested/not tested and their results, Defects closed & their severity, any outstanding Defects along with the impact, variances from the Test Plan, any Test Cases removed from the planned testing and Change Requests added to the overall testing scope.

Another important section is to mention the status of the Test Entry and Test Exit criteria and any reasons, exceptions taken during the testing phase if the criteria was not met.

The Risk section highlights the risks identified in the Test Plan, their realisation and any impacts.

It should mention the Test Estimation variance in terms of actual and planned test effort.

The last sections cover the builds deployed, any downtime  for the testing team.

So, overall Test Sign-off document provides a clear idea to the stakeholders about the Testing phase and testing team’s viewpoint which helps them to take the next action in the software life cycle.

Follow and Like us:

Test Summary Report / Test Sign-off Report

Risk Based Software Testing

In today’s world, more and more companies are focussing towards Risk Based Testing (RBT). It’s a comprehensive approach to risk rank the requirements and prioritising the test approach. The requirements are assessed on the basis of two factors; Business Criticality Risk and Failure Probability Risk. This would result in the prioritisation of the requirements and the corresponding mapped test cases. The objective is to increase the confidence in testing and optimising the test effort cost.

There are number of benefits at the Project and Testing levels in applying the RBT approach. Some of them are mentioned below: – A common understanding between all the stakeholders on different types of risk. – Identified focussed areas for all the project and test activities. – Developers can focus on developing critical requirements first and testing team can target to test those requirements on a priority. – Defects can be detected within critical risk areas in the initial phase of test execution. – Minimising the threat to the Project objectives.

It’s a MUST do activity in every project to prioritise the focus areas before starting the software development life cycle.

https://youtu.be/naNPLZUxVPk

Follow and Like us:

Risk Based Software Testing

AdWords Marketing

AdWords Marketing has helped various businesses across the globe in reaching out to the potential customers.

• Quick facts about AdWords:


• Make your business visible to your customers on the web.


• Improve ROI up to 300%.


• Reach out to the Wider Worldwide Audience.


• Multiple Advertising Networks/Platforms.


• Track the progress and performance of the Ads.


• One pays only if some use clicks on the Ad under Pay-Per-Click option.


• Target countries as per your Products, services and categorise them into campaigns.

AdWords is the biggest Revenue earner for Google and as per my viewpoint, it is getting popular day-by-day. People are actively utilising its features like Re-marketing, Targeting. Google is continuously improving the AdWords experience. Some of the new features introduced recently in 2015,

• Display campaigns can be created more easily.


• Search App install ads in Google Play.


• Multiple campaign types in simple reports.


• ‘Final URL’ instead of ‘Destination URL’.


• Testing Landing page before saving the Ad.


• Call Only Ads available worldwide.

Follow and Like us:

AdWords Marketing

Security Testing

Security Testing is a non-functional testing type and intends to identify the flaws in the security mechanisms of the software. Software security vulnerabilities are big business for potential attackers.  Identifying them early and knowing what common pitfalls to avoid can make a big difference to the resilience of the applications.

To be concise, the top 10 application security vulnerabilities are:

1. Injection


2. Broken Authentication and Session Management


3. Cross-Site Scripting (XSS)


4. Insecure Direct Object References


5. Security Misconfiguration


6. Sensitive Data Exposure


7. Missing Function Level Access Control


8. Cross-Site Request Forgery (CSRF)


9. Using Components with Known Vulnerabilities


10. Unvalidated Redirects and Forwards

Follow and Like us:

Security Testing

Defects Prevention Process

Software Testing provides confidence in the quality of the software. The Defect metrics help in analysing the quality up-to an extent. Lesser the defects, more the quality of the software and therefore less cost. This is the ideal goal every Project Manager hopes from the Software Testing Life Cycle.

Defects Prevention Process is an activity aimed to identify the root cause of the defects and preventing them from occurring in the future.

There are various ways through which we can learn from the defects history and can target to reduce the defects count. One of the way is to follow a Defects Prevention Process. It is applicable to all types of defects whether from Static testing or Dynamic testing.

It has four stages,

• Testing Processes/Methodologies The existing Software Processes are applied to the Development Life Cycle.


• Analysis stage involves researching the defects encountered in the earlier phases of software testing or analysis of the historical defects data. Once the relevant information is available, the defects are grouped together into the identified reasons.


• Root Cause Analysis follows the Pareto Principle of 80/20 rule which says 80% of the defects are because of the 20% defects causes. The clustering of defects in the Analysis step above would give us areas (defects categories) to focus to reduce defects. The Fish Bone Diagram can be applied to dig deep to find out the exact reason.

The above activity to identify the root cause should be discussed as deeper as possible, to reach to the actual reason of the defect cause/category.

Continuous Learning is a crucial step to optimising the process regularly. The primary reason identified above would need to be addressed and changes are implemented into the processes. The improved processes are then applied to the future projects.

Follow and Like us:

Defects Prevention Process

Software Testing Entry and Exit Criteria

Before entering or exiting the software testing phase, testing team should make sure that the corresponding Test Entry or Exit criteria mentioned in the Test Strategy or Test Plan has been met. It’s a very important step in the Testing Life Cycle as it helps in the implementation of the testing processes. I’ve seen companies not even aware of such practice and those who know don’t follow it properly.

The Test Entry/Exit criteria could differ from company to company but the basic idea is same to facilitate the testing by making sure everything is available and as per the expectations.

For example, System Testing Test Entry criteria covers areas like,

• Evidence of the successful unit testing  


• All components are ready for testing


• Test Environments availability


• Smoke Testing


• Test Documents

Similarly, Test Exit criteria makes sure to assess the following,

• All planned testing successfully completed.


• No critical, high severity defects open


• Test Summary Report approved


• Any outstanding defects have been risk-assessed.

There would be scenarios where these criteria won’t meet and in that case an agreement has to be reached between the project stakeholders whether to move ahead or wait for the completion of the pending items.

Follow and Like us:

Software Testing Entry and Exit Criteria

Defect Severity and Priority

I’ll come straight to the point. Defect or Bug Severity talks about the impact of the defect on the business. The feature getting impacted and its importance to the overall business. For example, a bank software running daily batch files to sort out number of bank transactions. If the batch process doesn’t run then it’s a very Critical/Show Stopper defect. The various severity levels are – Show Stopper/Critical, High, Med, Low.

Severity Category	Description
Critical/Severity 1	Critical/Showstopper error. The test activities cannot commence for the system.
High/Severity 2	Major functionality impacted but testing can continue for other functionalities/features.
Medium/Severity 3	Minor functionality errors / failures but workarounds are available.
Low/Severity 4	Minor/Cosmetic issues that do not impact the functionality of the system or module.

Defect or Bug Priority communicates to the Project team about the urgency to fix the defect. It’s mainly for the development team to identify issues to fix on priority. The above mentioned Batch functionality defect would be a High Priority defect because of its nature and needs to be fixed immediately.

High Severity and Low Priority example – An yearly report functionality not working is of High Severity but the fix can be delayed as once in an year so Low Priority.

Low Severity and High Priority example – A misspelled company name on the Website is a Low Severity but needs to be fixed immediately considering company’s reputation, so it’s a High Priority.

Low Severity and Low Priority example – The color of a button changes after selecting it. It’s not impacting the button functionality, neither the fix is urgent.

Follow and Like us:

Defect Severity and Priority

Agile - Scrum - Self Organisation in Scrum

Self-Organisation in Scrum

Today’s business environment is too complex, fast-paced and always changing. The companies are shifting towards the self-organised teams and Scrum provides that benefit. Though, it’s a one way of achieving that goal within the company but plays a big role in the Project outcome. This consequently leads to the adaptive, highly responsive companies. The self-organisation method doesn’t mean that team members can do whatever they want but it facilitates the evolution of expected behaviours.

Another important factor to discuss over here is the Micro-Management of the team. Scrum doesn’t support micro-management but implements processes, checkpoints to make sure there is no ambiguity or deviations from the plan. So the management doesn’t play a direct authority role that prevents creativity and spontaneity.

Follow and Like us:

Agile - Scrum - Self Organisation in Scrum

PRINCE2 Structure

PRINCE2 Structure has 4 main parts and they are referred to as Elements in PRINCE2 terminology.

Principles are the project characteristics and every project should have the following 7 Principles.

• Continued business justification


• Learn from experience


• Defined roles and responsibilities


• Manage by stages


• Manage by exception


• Focus on products


• Tailor to suit the project environment

Themes convey the things to be focussed continuously in the project life cycle.

Processes talk about the activities required to be done and who is responsible for them.

Tailoring covers the best way to apply PRINCE2 to the project.

Follow and Like us:

PRINCE2 Structure

Agile – Scrum Master Skills

Scrum Master plays a vital role in facilitating and implementing Scrum methodologies. Therefore, the success of the Scrum is very much dependent on the skillset of Scrum Master.

Effective Communication

The communication skills are required at each job level and they are that much important for the Scrum Master in Scrum for keeping all the stakeholders in sync and avoiding impacts of the communication gaps.

Facilitation

Scrum Master is the facilitator and provides all the help to the development team to let them achieve the goals successfully. He/she should remove any impediments for team’s success.

Socratic Questioning

To encourage thinking and eliciting engaged dialogue to guide people towards the goal.

Collaboration

The Scrum Master needs to collaborate with all the team members in Scrum. This would help in better implementation of Scrum and improved efficiency within the team.

Active Listening

Active Listening quality gives confidence to the Scrum team and they will try to participate more with different ideas.

Coaching

Wherever required, coaching should be given to bring the team on the right track in terms of Scrum Principles, methodologies.

Emotional Intelligence

Every team member is different and behaves, work differently. The Scrum Master has to show his understanding of the team dynamics.

Team Building

A must attribute in any software life cycle model. Team Building goes a long way to establish trust, confidence and bring the best out of the team.

Persuasion

The Scrum Master has to influence the team in many situations to implement Scrum methodologies. The Persuasion attribute is again an important skill.

Servant Leadership

The Scrum Master is actually a servant facilitating, helping the team members in Scrum implementation. The Servant Leadership term talks about playing both the leader and servant roles simultaneously and as per the situation.

Follow and Like us:

Agile – Scrum Master Skills

Agile - Scrum Framework

Scrum is the leading Agile development framework. It is simple, yet powerful to help teams deliver continuously in short time cycles. It aims to have a continuous improvement by following an Inspect and Adapt principle.

The Scrum team has three roles:

• Product Owner has the vision and makes sure to deliver features as per client’s priority and expectations.


• Scrum Master ensures that Scrum framework is being followed and guides the Product Owner & Development team in its implementation.


• Development Team (include Testing team)builds the product and responsible as a whole, for the product.

Scrum Artefacts:

• Product Backlog is a list of prioritised ideas, features for the product.


• Sprint Backlog is a subset of the Product Backlog at any time and contains a list of features to be developed in a Sprint by the Development team.


• Product Increment is a shippable subset of the product, integrated together with the features developed in the past sprints.

Scrum Activities:

• Product backlog refinement


• Sprint planning


• Daily Scrum


• Sprint review


• Sprint retrospective

All the above mentioned three entities work together in a Scrum. 

Scrum Values focus on 5 areas,

• Commitment – The team should commit to a goal. In scrum, the control is within the team to meet their commitments.


• Focus – All the focus and energy should be directed towards the goal committed. The team should not have any distractions.   


• Openness – Nothing is hidden. All the communication at any stage to all the stakeholders, teams. 


• Respect – Every individual is different, so treat everyone equally respecting their background and experiences. 


• Courage – Show courage to implement above values and sharing information whether it’s related to defects, timelines or any other Scrum entity.

The success of the Scrum really depends upon the actual implementation of the framework. The partial or customised implementation doesn’t give the satisfied results; the realisation of the true potential is only possible with the disciplined implementation.

Follow and Like us:

Agile - Scrum Framework

Security Testing - Insecure Direct Object Access

Insecure Direct Object Access occurs when there is no authentication check on the input provided by the user from the web page. The software executes the request and provides the result back to the user. This could be very serious considering an attacker can get access to the unauthorised objects like file, directory or databases. The impact on an organisation can be significant as attackers can dig deeper into the vulnerabilities.

It’s a very basic attack and most of the people do it unknowingly in their daily routine by just changing the parameters or path of the address bar in the web page. Currently, it occupies the fourth spot in the top 10 list of security risks.

www.example.com/profile.php?p=2

Attacker can simply change the value above from ‘2’ to ‘3’ and can access the profile details of other user. Similarly can play around to find other details.

To prevent this attack, the application needs to verify that the user is authorised to access the requested resource.

Follow and Like us:

Security Testing - Insecure Direct Object Access