Techniques – renierbotha ltd

GANTT Charts

March 9, 2019June 19, 20191 Comment

A Gantt chart is a horizontal bar chart developed as a production control tool in 1917 by Henry L. Gantt, an American engineer and social scientist. Frequently used in project management, a Gantt chart provides a graphical illustration of a schedule that helps to plan, coordinate, and track specific tasks in a project.

Gantt charts may be simple versions created on graph paper or more complex automated versions created using project management applications such as Microsoft Project or Excel.

A Gantt chart is constructed with a horizontal axis representing the total time span of the project, broken down into increments (for example, days, weeks, or months) and a vertical axis representing the tasks that make up the project (for example, if the project is outfitting your computer with new software, the major tasks involved might be: conduct research, choose software, install software). Horizontal bars of varying lengths represent the sequences, timing, and time span for each task. Using the same example, you would put “conduct research” at the top of the verticle axis and draw a bar on the graph that represents the amount of time you expect to spend on the research, and then enter the other tasks below the first one and representative bars at the points in time when you expect to undertake them. The bar spans may overlap, as, for example, you may conduct research and choose software during the same time span. As the project progresses, secondary bars, arrowheads, or darkened bars may be added to indicate completed tasks, or the portions of tasks that have been completed. A vertical line is used to represent the report date.

Gantt charts give a clear illustration of project status, but one problem with them is that they don’t indicate task dependencies – you cannot tell how one task falling behind schedule affects other tasks. The PERT Chart, another popular project management charting method, is designed to do this. Automated Gantt charts store more information about tasks, such as the individuals assigned to specific tasks, and notes about the procedures. They also offer the benefit of being easy to change, which is helpful. Charts may be adjusted frequently to reflect the actual status of project tasks as, almost inevitably, they diverge from the original plan.

Also Read…

Management Communication Plan

PERT Charts

March 9, 2019June 19, 20192 Comments

A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project. PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program. A similar methodology, the Critical Path Method (CPM) was developed for project management in the private sector at about the same time.

A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing events, or milestones in the project linked by labelled vectors (directional lines) representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. In the diagram, for example, the tasks between nodes 1, 2, 4, 8, 9 and 10 must be completed in sequence. These are called dependent or serial tasks. The tasks between nodes 2 and 3, and nodes 2 and 4 are not dependent on the completion of one to start the other and can be undertaken simultaneously. These tasks are called parallel or concurrent tasks. Tasks that must be completed in sequence but that don’t require resources or completion time are considered to have event dependency. These are represented by dotted lines with arrows and are called dummy activities. For example, the dashed arrow linking nodes 6 and 9 indicates that the system files must be converted before the user test can take place, but that the resources and time required to prepare for the user test (writing the user manual and user training) are on another path. Numbers on the opposite sides of the vectors indicate the time allotted for the task.

The PERT chart is sometimes preferred over the Gantt Chart, another popular project management charting method, because it clearly illustrates task dependencies. On the other hand, the PERT chart can be much more difficult to interpret, especially on complex projects. Frequently, project managers use both techniques.

Also Read…

Management Communication Plan

Project Failure? How to Recover and/or Prevent…

February 13, 2019June 25, 2019Leave a comment

Statistics indicate that 68% of all IT projects are bound to failure!

The PMI’s definition of a high-performing organisation, is a company that completes 80% or more projects on time, on budget, and meeting original goals. In a low-performing organization, only 60% or fewer projects hit the same marks.

Projects fail for all kinds of reasons:

Stakeholders can change their objectives
Key team members can leave for other companies
Budgets can disappear
Materials/Vendors can be delayed
Priorities can go un-managed
Running out of time
…and others

In this post:

> How to prevent project failure (with some statistics)

> How to recover a failing project

How to prevent project failure

Prevention is the best cure, so what can you do to prevent projects from failing? Here is some statistics…

Organisations that invest in proven project management practices waste 28 times less money because more of their strategic initiatives are completed successfully.
Source: PMI’s Pulse of the Profession Survey, 2017.
77% of high-performing organizations have actively-engaged project sponsors, while only 44% of low-performing organizations do.
Source: PMI’s Pulse of the Profession Survey, 2017.
46% of CIOs say that one of the main reasons IT projects fail is weak ownership.
Source: The Harvey Nash/KPMG CIO Survey, 2017.
33% of IT projects fail because senior management doesn’t get involved and requirements/scope change mid-way through the project.
Source: A Replicated Survey of IT Software Project Failures by Khaled El Emam and A. Güneş Koru, 2008.
78% of respondents feel that business is out of sync with project requirements and business stakeholders need to be more involved in the requirements process.
Source: Doomed from the Start Industry Survey by Geneca, 2011.
45% of the managers surveyed say business objectives are unclear to them.
Source: Doomed from the Start Industry Survey by Geneca, 2011.
Companies that align their enterprise-wide PMO (project management office) to strategyhad 38% more projects meet original goals than those that did not. They also had 33% fewer projects deemed failures.
Source: PMI’s Pulse of the Profession Survey, 2017.
40% of CIOs say that some of the main reasons IT projects fail is an overly optimistic approach and unclear objectives.
Souce: The Harvey Nash/KPMG CIO Survey, 2017.
Poor estimation during the planning phase continues to be the largest (32%) contributor to IT project failures.
Source: PwC 15th Annual Global CEO Survey, 2012.
Projects with effective communication are almost twice as likely to successfully deliver project scope and meet quality standards than projects without effective communication (68% vs 32% and 66% vs 33%, respectively.)
Source: PwC 15th Annual Global CEO Survey, 2012.

How to recover a failing project

These statistics show that the odds are not in your favour. It is inevitable that you will have to deal with a failing project or two, some time within your career… You could turn the odds in your favour by taking action in recovering failing projects.

Here are four steps you can use that could save a failing project — backed up by original research from Gartner, iSixSigma, PMI Project Zone Congress, The Institution of Engineering and Technology, and Government CIO Magazine. Follow these four steps and salvage your failing project!

Step 1: Stop and Evaluate

Step 1 – Big action items:

Issue a “stop work” order
Talk with everyone

Metrics/Indicators: The right project Management Information (MI) should give you the needed early warning signs when things are not going according to plan and heading to failure. These signs should drive you to action, as rescuing a failing a project is not a task to be sneezed at. It takes planning, and the process can consume weeks of key resources time and effort.

People: To help ease the pain of stopping a project, work with the team members’ managers (resource owners) to identify and assign interim work. As people are your most important asset, it is important to keep them productively engaged while you are evaluating and re-planning your project recovery.

Project artefacts/deliverables: Make sure all the project artefacts and deliverables are safely stored where it cannot be tampered with for the interim period.

Communicate: (clear, concise, and concrete) – Communicate to your team why their project is on hold. Spend the needed time to learn as much as you can about each team member’s opinions of the project and of each other. Learning that their project will be put on hold will inevitably create distrust. Transparency and tailored messaging is the best way to mitigate bad feelings. See blog posts “Management Communication Plan” and “Effective Leadership Communication”

Project/Delivery Manager (You):Check your ego. Go to the major stakeholders and ask for anonymous feedback on their view of the overall project. When evaluating their responses, don’t forget to consider company culture and politics and how those factors may have played a role in forming the stakeholders’ opinions.

Step 2: Why your project is failing – Root causes

Step 2 – Big action items:

Establish allowable solutions for project rescue (including project termination)
Identify root causes of the problem
Identify risks to project continuation

Determine the root causes: Most times the cause of project problems is not immediately obvious. Even the best project managers — those with excellent project plans, appropriate budgets, and fantastic scope control — also struggle, on occasion, with project failure.

You’ll only get to the bottom of it by doing a Route Cause Analysis (RCA) and the “5 Why’s” technique can help with that. See “The 5 Whys for route cause analysis”

Surface-level answers are often the temptation when project managers reach this step. They might focus on the complexity of their project, their outdated project management softwareor methodology, their unclear objectives or their stakeholders’ lack of involvement. All of these problems are so generic that they don’t provide enough insight to create real solutions.

Apply the “5 Whys” and be specific when answering these questions… i.e.

Why are objectives unclear?
Why aren’t users getting involved?
Why are the estimates wrong?

Of course, some of these answers may be hard to hear, and solutions can range from the challenging to impossible. Remember: if these issues could be easily remedied, they would have been addressed and resolved. Even simple problems — like a team member leaving — can take months to fix. Ask yourself: are you using the right technology for the job? Are your dependencies so external that project control is simply out of your hands?

If you’re still struggling to figure out where the root of your project failure is, consider these seven issues – the most common causes of project failure.

Complexity
External
Financial
Operational
Organizational
Schedule
Technology

Risk Assessment:What are the risks when trying to salvage the project? Are those risks worth it? Is the project salvageable? Answer these questions before moving on.

Step 3: War Room

Step 3 – Big action items:

Set up the war room
Re-engage stakeholders
Create a tentative plan to move forward

Okay, General!

Assemble the team, seat them all together, and work through a rescue workshop. You’re in the mentality of “kill” or “fix” you’re done fact finding, asking question for further research, or finding other excuses to delay the process. That should all have been done in step two. You’re focussed to figure out what to do with your project.

The “war room” will be intense – all members need to be prepared and the right mindset of problem solving!

The decision-making process could take two hours or several days. All key decision makers must be present. As this is not always possible some executives may prefer to be called in as the meeting is nearing its end, where team members can present prepared options.

To get the most out of the workshop, conduct the meeting face to face (take the meeting offline). Try to limit the meeting to ten people, including the most important stakeholders (like the sponsors), project manager, senior team members including technical representative to give insight to plan feasibility.

The war room is serious business – prepare for it. Create an agenda to go over findings, from quantitative reporting to team member interviews. Encourage pre-war-room collaboration (covering the outcomes of steps 1 and 2) toward the ideal shared result.

When you start the war room meeting, all project material should be readily available. That’s your fact base driving factual data driven assumptions and decisions.

Using the facts, the purpose of the war room, in essence, is to answer three deceptively complex questions:

Is the business case still valid?
If the business case is no longer valid, is there potential for a new, reimagined, justified business case?
(If so): Are the added costs for project rescue worth it?

Encourage your task force to focus on identifying the project’s primary drivers (i.e. business need/value, budget, schedule, scope, or quality). Ideally, there should only be one driver that controls the outcome of the project – this is usually the business need for the project’s deliverables.

Sometimes the primary driver is beyond repair. For example, if the core due date has passed and it was aligned with a market cycle (ex: Black Friday to Christmas), then the project is irremediable.

Least case scenario: Clearly articulate the primary goal. Then identify what the team can do with the least amount of effort. Develop a scenario that costs the company the least and gets closest to achieve the primary goal.

Project termination considerations: If the primary goal cannot be achieved, prepare a recommendation to terminate the project… but not without scrutiny. Several variables must be considered and thoroughly addressed in the war room.

Consider trade-offs that could make the worst-case scenario more possible than originally thought.
Think about the potential backlash from killing a project.
- How does that decision affect business strategy?
- Other projects?
- Public perceptions?
- Potential future clients? All these variables must be considered and thoroughly addressed in the war room.

Alternatives: Should the least-case scenario makes sense, explore more alternatives. Are there alternative options that can deliver more of the project’s objectives, and consider how adding those solutions to your plan can create additional potential scenarios — positive or negative.

New project charter: Write down the main points of your plan in a revised project charter.

Replacement project option: It’s not uncommon for stakeholders to propose a replacement project instead of a rescue. That’s a totally viable option — kill the project, salvaging only essential, functional portions of the original attempt, and work to create a new plan.If the decision is to completely start over, abandon project rescue altogether. Justify the replacement project on its own merit (a new scope, budget, resource plan, etc.)

Step 4: Set your project in motion

Step 4 – Big action items:

Finalise how your project will move forward
Confirm responsibilities
Reset organizational expectations.

Following your war room meeting, your next steps are all about follow-up. The real project rescue starts here and is the most challenging part of project rescue.

Re-engage stakeholders around the contents of the new project plan and complete the detail with precise commitments for each team member. Plans should be finalised within two days.

Be careful as hesitation and procrastination can limit team commitment and lower morale. You’re the general; get your troops ready to re-engage and to stay committed and focussed!

Reconfirm all project metrics: Validate all project aspects especially resources, as people has been allocation to productive work while you were reworking your rescue plan.

As the project rolls forward, be sure to detail the new project’s profile, scope, and size to the core team and beyond. Emphasize expected outcomes and explain how this project aligns with the company’s goals. Don’t shy away from communicating what these changes can mean on a big-picture scale. While you may receive some feedback, be direct: the project is proceeding.

Make sure all communication is clear. Confirm that stakeholders accept their new responsibilities to the project.

Cyber-Security 101 for Business Owners

January 5, 2019February 8, 2019Leave a comment

Running a business require skill with multiple things happening simultaneously that require your attention. One of those critical things is cyber-security – critical today to have your focus on.

In the digital world today, all businesses have a dependency on the Internet in one way or the other… For SMEs (Small Medium Enterprise) that uses the Internet exclusively as their sales channel the Internet is not only a source of opportunity but the lifeblood of the organisation. An enterprise has the ability, through the Internet, to operate 24×7 with digitally an enabled workforce bringing unprecedented business value.

Like any opportunity though, this also comes with a level of risk that must be mitigated and continuously governed, not just by the board but also by every member within the team. Some of these risks can have a seriously detrimental impact to the business, ranging from financial and data loss to downtime and reputational damage. It is therefore your duty ensuring your IT network is fully protected and secure to protect your business.

Statistics show that cybercrime is exponentially rising. This is mainly due to enhancements in technology enabling and giving access to inexpensive but sophisticated tools. Used by experienced and inexperienced cyber criminals alike, this is causing havoc across networks resulting in business downtime that costs the economy millions every year.

If your business is not trading for 100 hours, what is the financial and reputational impact? That could be the downtime caused by, for example, a ransomware attack – yes, that’s almost 5 days of no business, costly for any business!

Understanding the threat

Cyber threats take many forms and is an academic subject on it’s own. So where do you start?

First you need to understand the threat before you can take preventative action.

Definition: Cyber security or information technology security are the techniques of protecting computers, networks, programs and data from unauthorized access or attacks that are aimed for exploitation.

A good start is to understand the following cyber threats:

Malware
Worms
Trojans
IoT (Internet of Things)
Crypto-jacking

Malware

Definition:Malware (a portmanteau for malicious software) is any software intentionally designed to cause damage to a computer, server, client, or computer network.

During 2^ndQ’18, the VPNFilter malware reportedly infected more than half a million small business routers and NAS devices and malware is still one of the top risks for SMEs. With the ability of data exfiltration back to the attackers, businesses are at risk of the loss of sensitive information such as usernames and passwords.

Potentially these attacks can remain hidden and undetected. Businesses can overcome these styles of attacks by employing an advanced threat prevention solution for their endpoints (i.e. user PCs). A layered approach with multiple detection techniques will give businesses full attack chain protection as well as reducing the complexity and costs associated with the deployment of multiple individual solutions.

Worms

Definition:A computer worm is a standalone malware computer program that replicates itself in order to spread to other computers. Often, it uses a computer network to spread itself, relying on security failures on the target computer to access it.

Recent attacks, including WannaCry and Trickbot, used worm functionality to spread malware. The worm approach tends to make more noise and can be detected faster, but it has the ability to affect a large number of victims very quickly.For businesses, this may mean your entire team can be impacted (spreading to every endpoint in the network) before the attack can be stopped.

Approximately 20% of UK businesses that had been infected with malware had to cease business operations immediately resulting in lost revenue.

Internet of Things (IoT)

Definition:The Internet of things (IoT) is the network of devices such as vehicles, and home appliances that contain electronics, software, actuators, and connectivity.

More devices are able to connect directly to the web, which has a number of benefits, including greater connectivity, meaning better data and analytics. However, various threats and business risks are lurking in the use of these devices, including data loss, data manipulation and unauthorised access to devices leading to access to the network, etc.

To mitigate this threat, devices should have strict authentication, limited access and heavily monitored device-to-device communications. Crucially, these devices will need to be encrypted – a responsibility that is likely to be driven by third-party security providers but should to be enforced by businesses as part of their cyber-security policies and standard operating procedures.

Cryptojacking

Definition:Cryptojacking is defined as the secret use of your computing device to mine cryptocurrency. Cryptojacking used to be confined to the victim unknowingly installing a program that secretly mines cryptocurrency.

With the introduction and rise in popularity and value of crypto currencies, cryptojacking emerged as a cyber-security threat. On the surface, cryptomining may not seem particularly malicious or damaging, however, the costs that it can incur are. If the cryptomining script gets into servers, it can send energy bills through the roof or, if you find it has reached your cloud servers, can hike up usage bills (the biggest commercial concern for IT operations utilising cloud computing). It can also pose a potential threat to your computer hardware from overloading CPUs.

A recent survey, 1 in 3 of all UK businesses were hit by cryptojacking with statistics rising.

Mitigating the risk

With these few simple and easy steps you can make a good start in protecting your business:

Education: At the core of any cyber-security protection plan, there needs to be an education campaign for all in the business. They must understand the gravity of the threat posed – regular training sessions can help here. And this shouldn’t be viewed as a one-off box-ticking exercise then forgotten about. Having rolling, regularly updated training sessions will ensure that staff members are aware of the changing threats and how they can best be avoided.
Endpoint protection: Adopt a layered approach to cyber security and deploy endpoint protection that monitor processes in real-time and seek out suspicious patterns, enhancing threat hunting capabilities that eliminate threats (quarantine or delete), and reducing the downtime and impact of attacks.
Lead by example: Cyber-security awareness should come from the top down. The time is long gone where cyber-security has been the domain of IT teams. If you are a business stakeholder, you need to lead by example by promoting and practicing a security-first mindset.

Different Software Testing – Explained

December 21, 2018January 30, 2019Leave a comment

Testing of software and application is an integral part of the software development and deployment lifecycle. But with so many different types of tests to choose from when compiling your test approach, which are best suited for your requirements?

In this post 45 different tests are explained.

Software Application Testing are conducted within two domains: Functional and Non-Functional Testing.

Functional testing is a software testing process used within softwaredevelopment in which software is tested to ensure that it conforms with all requirements. Functional testing is a way of checking software to ensure that it has all the required functionality that’s specified within its functional requirements.

Functional testing types include:

Unit testing
Integration testing
System testing
Sanity testing
Smoke testing
Interface testing
Regression testing
Beta/Acceptance testing

Non-functional testing is defined as a type of Software testing to check non-functional aspects (performance, usability, reliability, etc) of a software application. It is designed to test the readiness of a system as per nonfunctional parameters which are never addressed by functional testing.

Non-functional testing types include:

Performance Testing
Load testing
Stress testing
Volume testing
Security testing
Compatibility testing
Install testing
Recovery testing
Reliability testing
Usability testing
Compliance testing
Localization testing

45 Different types of testing – explained

Alpha Testing

It is the most common type of testing used in the Software industry. The objective of this testing is to identify all possible issues or defects before releasing it into the market or to the user. Alpha testing is carried out at the end of the software development phase but before the Beta Testing. Still, minor design changes may be made as a result of such testing. Alpha testing is conducted at the developer’s site. In-house virtual user environment can be created for this type of testing.

Acceptance Testing

An acceptance test is performed by the client and verifies whether the end to end the flow of the system is as per the business requirements or not and if it is as per the needs of the end user. Client accepts the software only when all the features and functionalities work as expected. It is the last phase of the testing, after which the software goes into production. This is also called as User Acceptance Testing (UAT).

Ad-hoc Testing

The name itself suggests that this testing is performed on an ad-hoc basis i.e. with no reference to test case and also without any plan or documentation in place for such type of testing. The objective of this testing is to find the defects and break the application by executing any flow of the application or any random functionality.

Ad-hoc testing is an informal way of finding defects and can be performed by anyone in the project. It is difficult to identify defects without a test case but sometimes it is possible that defects found during ad-hoc testing might not have been identified using existing test cases.

Accessibility Testing

The aim of accessibility testing is to determine whether the software or application is accessible for disabled people or not. Here disability means deaf, color blind, mentally disabled, blind, old age and other disabled groups. Various checks are performed such as font size for visually disabled, color and contrast for color blindness etc.

Beta Testing

Beta Testing is a formal type of software testing which is carried out by the customer. It is performed in Real Environment before releasing the product to the market for the actual end users. Beta testing is carried out to ensure that there are no major failures in the software or product and it satisfies the business requirements from an end-user perspective. Beta testing is successful when the customer accepts the software.

Usually, this testing is typically done by end-users or others. It is the final testing done before releasing an application for commercial purpose. Usually, the Beta version of the software or product released is limited to a certain number of users in a specific area. So end user actually uses the software and shares the feedback to the company. Company then takes necessary action before releasing the software to the worldwide.

Back-end Testing

Whenever an input or data is entered on front-end application, it stores in the database and the testing of such database is known as Database Testing or Backend testing. There are different databases like SQL Server, MySQL, and Oracle etc. Database testing involves testing of table structure, schema, stored procedure, data structure and so on.

In back-end testing GUI is not involved, testers are directly connected to the database with proper access and testers can easily verify data by running a few queries on the database. There can be issues identified like data loss, deadlock, data corruption etc during this back-end testing and these issues are critical to fixing before the system goes live into the production environment

Browser Compatibility Testing

It is a subtype of Compatibility Testing (which is explained below) and is performed by the testing team.

Browser Compatibility Testing is performed for web applications and it ensures that the software can run with the combination of different browser and operating system. This type of testing also validates whether web application runs on all versions of all browsers or not.

Backward Compatibility Testing

It is a type of testing which validates whether the newly developed software or updated software works well with older version of the environment or not.

Backward Compatibility Testing checks whether the new version of the software works properly with file format created by older version of the software; it also works well with data tables, data files, data structure created by older version of that software. If any of the software is updated then it should work well on top of the previous version of that software.

Black Box Testing

Internal system design is not considered in this type of testing. Tests are based on the requirements and functionality.

Detailed information about the advantages, disadvantages, and types of Black box testing can be seen here.

Boundary Value Testing

This type of testing checks the behavior of the application at the boundary level.

Boundary value Testing is performed for checking if defects exist at boundary values. Boundary value testing is used for testing a different range of numbers. There is an upper and lower boundary for each range and testing is performed on these boundary values.

If testing requires a test range of numbers from 1 to 500 then Boundary Value Testing is performed on values at 0, 1, 2, 499, 500 and 501.

Branch Testing

It is a type of white box testing and is carried out during unit testing. Branch Testing, the name itself suggests that the code is tested thoroughly by traversing at every branch.

Comparison Testing

Comparison of a product’s strength and weaknesses with its previous versions or other similar products is termed as Comparison Testing.

Compatibility Testing

It is a testing type in which it validates how software behaves and runs in a different environment, web servers, hardware, and network environment. Compatibility testing ensures that software can run on a different configuration, different database, different browsers and their versions. Compatibility testing is performed by the testing team.

Component Testing

It is mostly performed by developers after the completion of unit testing. Component Testing involves testing of multiple functionalities as a single code and its objective is to identify if any defect exists after connecting those multiple functionalities with each other.

End-to-End Testing

Similar to system testing, End-to-end testing involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Equivalence Partitioning

It is a testing technique and a type of Black Box Testing. During this equivalence partitioning, a set of group is selected and a few values or numbers are picked up for testing. It is understood that all values from that group generate the same output. The aim of this testing is to remove redundant test cases within a specific group which generates the same output but not any defect.

Suppose, application accepts values between -10 to +10 so using equivalence partitioning the values picked up for testing are zero, one positive value, one negative value. So the Equivalence Partitioning for this testing is: -10 to -1, 0, and 1 to 10.

Example Testing

It means real-time testing. Example testing includes the real-time scenario, it also involves the scenarios based on the experience of the testers.

Exploratory Testing

Exploratory Testing is an informal testing performed by the testing team. The objective of this testing is to explore the application and looking for defects that exist in the application. Sometimes it may happen that during this testing major defect discovered can even cause system failure.

During exploratory testing, it is advisable to keep a track of what flow you have tested and what activity you did before the start of the specific flow.

An exploratory testing technique is performed without documentation and test cases.

Functional Testing

This type of testing ignores the internal parts and focuses only on the output to check if it is as per the requirement or not. It is a Black-box type testing geared to the functional requirements of an application. For detailed information about Functional Testing click here.

Graphical User Interface (GUI) Testing

The objective of this GUI testing is to validate the GUI as per the business requirement. The expected GUI of the application is mentioned in the Detailed Design Document and GUI mockup screens.

The GUI testing includes the size of the buttons and input field present on the screen, alignment of all text, tables and content in the tables.

It also validates the menu of the application, after selecting different menu and menu items, it validates that the page does not fluctuate and the alignment remains same after hovering the mouse on the menu or sub-menu.

Gorilla Testing

Gorilla Testing is a testing type performed by a tester and sometimes by developer the as well. In Gorilla Testing, one module or the functionality in the module is tested thoroughly and heavily. The objective of this testing is to check the robustness of the application.

Happy Path Testing

The objective of Happy Path Testing is to test an application successfully on a positive flow. It does not look for negative or error conditions. The focus is only on the valid and positive inputs through which application generates the expected output.

Incremental Integration Testing

Incremental Integration Testing is a Bottom-up approach for testing i.e continuous testing of an application when a new functionality is added. Application functionality and modules should be independent enough to test separately. This is done by programmers or by testers.

Install/Uninstall Testing

Installation and uninstallation testing is done on full, partial, or upgrade install/uninstall processes on different operating systems under different hardware or software environment.

Integration Testing

Testing of all integrated modules to verify the combined functionality after integration is termed as Integration Testing. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Load Testing

It is a type of non-functional testing and the objective of Load testing is to check how much of load or maximum workload a system can handle without any performance degradation.

Load testing helps to find the maximum capacity of the system under specific load and any issues that cause the software performance degradation. Load testing is performed using tools like JMeter, LoadRunner, WebLoad, Silk performer etc.

Monkey Testing

Monkey testing is carried out by a tester assuming that if the monkey uses the application then how random input, values will be entered by the Monkey without any knowledge or understanding of the application. The objective of Monkey Testing is to check if an application or system gets crashed by providing random input values/data. Monkey Testing is performed randomly and no test cases are scripted and it is not necessary to

Monkey Testing is performed randomly and no test cases are scripted and it is not necessary to be aware of the full functionality of the system.

Mutation Testing

Mutation Testing is a type of white box testing in which the source code of one of the program is changed and verifies whether the existing test cases can identify these defects in the system. The change in the program source code is very minimal so that it does not impact the entire application, only the specific area having the impact and the related test cases should able to identify those errors in the system.

Negative Testing

Testers having the mindset of “attitude to break” and using negative testing they validate that if system or application breaks. A negative testing technique is performed using incorrect data, invalid data or input. It validates that if the system throws an error of invalid input and behaves as expected.

Non-Functional Testing

It is a type of testing for which every organization having a separate team which usually called as Non-Functional Test (NFT) team or Performance team.

Non-functional testing involves testing of non-functional requirements such as Load Testing, Stress Testing, Security, Volume, Recovery Testing etc. The objective of NFT testing is to ensure whether the response time of software or application is quick enough as per the business requirement.

It should not take much time to load any page or system and should sustain during peak load.

Performance Testing

This term is often used interchangeably with ‘stress’ and ‘load’ testing. Performance Testing is done to check whether the system meets the performance requirements. Different performance and load tools are used to do this testing.

Recovery Testing

It is a type of testing which validates that how well the application or system recovers from crashes or disasters.

Recovery testing determines if the system is able to continue the operation after a disaster. Assume that application is receiving data through the network cable and suddenly that network cable has been unplugged. Sometime later, plug the network cable; then the system should start receiving data from where it lost the connection due to network cable unplugged.

Regression Testing

Testing an application as a whole for the modification in any module or functionality is termed as Regression Testing. It is difficult to cover all the system in Regression Testing, so typically automation testing tools are used for these types of testing.

Risk-Based Testing (RBT)

In Risk Based Testing, the functionalities or requirements are tested based on their priority. Risk-based testing includes testing of highly critical functionality, which has the highest impact on business and in which the probability of failure is very high. The priority decision is based on the business need, so once priority is set for all functionalities then high priority functionality or test cases are executed first followed by medium and then low priority functionalities.

The low priority functionality may be tested or not tested based on the available time. The Risk-based testing is carried out if there is insufficient time available to test entire software and software needs to be implemented on time without any delay. This approach is followed only by the discussion and approval of the client and senior management of the organization.

Sanity Testing

Sanity Testing is done to determine if a new software version is performing well enough to accept it for a major testing effort or not. If an application is crashing for the initial use then the system is not stable enough for further testing. Hence a build or an application is assigned to fix it.

Security Testing

It is a type of testing performed by a special team of testers. A system can be penetrated by any hacking way.

Security Testing is done to check how the software or application or website is secure from internal and external threats. This testing includes how much software is secure from the malicious program, viruses and how secure and strong the authorization and authentication processes are.

It also checks how software behaves for any hackers attack and malicious programs and how software is maintained for data security after such a hacker attack.

Smoke Testing

Whenever a new build is provided by the development team then the software testing team validates the build and ensures that no major issue exists. The testing team ensures that build is stable and a detailed level of testing is carried out further. Smoke Testing checks that no show stopper defect exists in the build which will prevent the testing team to test the application in detail.

If testers find that the major critical functionality is broken down at the initial stage itself then testing team can reject the build and inform accordingly to the development team. Smoke Testing is carried out to a detailed level of any functional or regression testing.

Static Testing

Static Testing is a type of testing which is executed without any code. The execution is performed on the documentation during the testing phase. It involves reviews, walkthrough, and inspection of the deliverables of the project. Static testing does not execute the code instead of the code syntax, naming conventions are checked.

The static testing is also applicable for test cases, test plan, design document. It is necessary to perform static testing by the testing team as the defects identified during this type of testing are cost-effective from the project perspective.

Stress Testing

This testing is done when a system is stressed beyond its specifications in order to check how and when it fails. This is performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to the system or database load.

System Testing

Under System Testing technique, the entire system is tested as per the requirements. It is a Black-box type testing that is based on overall requirement specifications and covers all the combined parts of a system.

Unit Testing

Testing an individual software component or module is termed as Unit Testing. It is typically done by the programmer and not by testers, as it requires a detailed knowledge of the internal program design and code. It may also require developing test driver modules or test harnesses.

Usability Testing

Under Usability Testing, User-friendliness check is done. Application flow is tested to know if a new user can understand the application easily or not, Proper help documented if a user gets stuck at any point. Basically, system navigation is checked in this testing.

Vulnerability Testing

The testing which involves identifying of weakness in the software, hardware and the network is known as Vulnerability Testing. Malicious programs, the hacker can take control of the system, if it is vulnerable to such kind of attacks, viruses, and worms.

So it is necessary to check if those systems undergo Vulnerability Testing before production. It may identify critical defects, flaws in the security.

Volume Testing

Volume testing is a type of non-functional testing performed by the performance testing team.

The software or application undergoes a huge amount of data and Volume Testing checks the system behavior and response time of the application when the system came across such a high volume of data. This high volume of data may impact the system’s performance and speed of the processing time.

White Box Testing

White Box testing is based on the knowledge about the internal logic of an application’s code.

It is also known as Glass box Testing. Internal software and code working should be known for performing this type of testing. Under this tests are based on the coverage of code statements, branches, paths, conditions etc.

5 Whys

April 2, 2018May 27, 20182 Comments

“5 Whys” technique for Root Cause Analysis (RCA)

Do you have a recurring problem that keeps on coming back despite repeated actions to address it? This might be an indication that you are treating the symptoms of the problem and not the actual problem itself – you need to determine the root cause of the problem – you must conduct a root cause analysis.

Root cause analysis (RCA) is a systematic process for identifying “root causes” of problems and the appropriate response that effectively deals with it. RCA is based on the basic idea that effective management requires more than merely “putting out fires” through quick fixes for problems that develop, but finding a way to prevent them from occurring again or in the first place. A root cause analysis is a process used to identify the primary source of a problem.

An effective method to get to the bottom of a problem is to use the “5 Whys” that was initially developed as part of TPS (Toyota Production System) that gave birth to what we know today as Lean Six Sigma – discussed in more detail in the article on “Lean Six Sigma – Organisational Development and Change”.

5 Whys is an iterative interrogative (problem solving) technique used to explore the cause-and-effect relationships underlying a particular problem.

The primary goal of the technique is to determine the root cause (source) of a defect or problem by repeating the question “Why?”, five times. Each answer forms the basis of the next question.

Why five time? This derives from an anecdotal observation on the number of iterations needed to resolve the problem.

How to conduct the 5 Why technique:

Write down the specific problem. Writing the issue helps you formalize the problem and describe it completely. It also helps a team focus on the same problem.
Ask Why the problem happens and write the answer down below the problem.
If the answer you just provided doesn’t identify the root cause of the problem that you wrote down in Step 1, ask Why again and write that answer down.
Loop back to step 3 until the team is in agreement that the problem’s root cause is identified. Again, this may take fewer or more times than five Whys.

For example:

In business, only one cause for a problem is not the usual case. Using the 5 Whys in conjunction with the Fishbone Diagram (Ishikawa), that helps the exploration process to cover all potential inputs and hence potential causes of problems or defects.

The 5 Whys method can be used to uncover multiple root causes by repeating the process asking a different sequence of questions each time.

Lean Six Sigma – Organisational Development and Change

February 23, 2018May 27, 20182 Comments

Directly related to business performance is the ability to change the business processes for greater efficiency and productivity while terms like specialisation, standardisation comes to mind followed by measurement, data analysis, statistical analysis, root cause analysis and finally process control and quality control.

Remember the saying by Peter Drucker: “What gets measured, gets improved”…

Improvement initiatives bring change.

A brief history of organisational change

Change management has evolved from Organisational Development OD – focused on helping people to manage change and to stay alive post the world war in the 1940S. That lead to Change Management thinking in the 70s and 80s and in parallel project management as another management process, was developed. These processes saw change as linear and hence can it be managed tightly. It starts with a burning platform and a vision to resolve the problem followed by the change journey of solving problems and overcoming obstacles. In the late 80s Appreciative Inquiry emerged changing the focus of change to “best that can be” and driving “what should be” rather than “what is wrong” and driving the “fix it”. The 1990s and 2000s brought more collaborative models and tools to manage change and solve problems and performance coaching got commonly accepted and used.

The drive to improve business performance gave life to various methodologies and frameworks for example:

Toyota Production System (TPS), the origins of Lean Thinking, included the prominent problem solving tools through the “five why’s”, continuous improvement, “Just in Time” production and the elimination of waste.
Business Process Re-engineering (BPR) which encouraged the outsourcing and off-shoring of work deemed to be non essential or too costly to perform.
Balance Scorecard which aims to provide a well-balanced view of the health of an organization through key performance metrics representing the financial, operational, human and environmental aspects of the business performance.
Project Management methodologies and frameworks: PMI, Prince2, Agile SCRUM, LEAN, KANBAN
Quality Control frameworks, methodologies and standards: ISO9001, Six Sigma
Information Technology Service Management (ITSM) frameworks: ITIL

Six Sigma

Six Sigma is a quality improvement approach that seeks to improve the quality of process outputs by identifying and removing the causes of defects and minimizing variability in the delivery processes. This is done through a set of quality tools management tools and statistics.

Another definition – the ability of processes to deliver a very high percentage of the output within a defined specification derived from customer specifications. A key KPI is the defect % and the process to reduce that to be within specification of tolerance – where a defect is defined as any process output that does deliver to customer requirements.

Running a process at Six Sigma quality is defined as defect levels below 3.4 defects per 1M cycles of the process!

Six Sigma principles:

Continuous efforts to achieve stable and predictable process outputs are vital for business success.
Operational business processes can be measured, analysed, improved and controlled.
Achieving sustained quality improvement requires commitment from the entire organization, particularly from the top management.

Each Six Sigma project has a five step sequence (DMAIC):

Problem solving approach:

D – Defining

M – Measuring

A – Analysing

I – Improving

C – Controlling

Defining the problem, and setting a project goal.
Measuring current process performance and collecting relevant data potential root causes.
Analysing the data to investigate and verify cause-and-effect relationships. Determine what the relationships are attempt to ensure that all factors have been considered. The analysis should reveal a root cause of the defect under investigation.
Improving and optimizing the current process by introducing changes that reduce or solve the impact of the identified root cause.
Controlling/Monitoring the newly changed process to ensure no deviation from the expected results occur and that the new process is stable.

LEAN Thinking

You are lean when all you resources are used to deliver value to the end customer – nothing else. This value has to flow through the value chain without any interruptions. All activities not directly supporting in the creation and delivery of this value is considered as waste and therefore reviewed for potential elimination.

Another definition: Lean is focused on getting the rights things to the right place at the right time in the right quantity while achieving a perfect workflow that is dictated by the customers demand to deliver the goods just in time.

LEAN – Five Principles:

Specify value from the customer’s point of view. Start by recognizing that only a small percentage of overall time, effort and resources in a organization actually adds value to the customer.
Identify and map the value chain. This is the te entire set of activities across all part of the organization involved in delivering a product or service to the customer. Where possible eliminate the steps that do not create value
Create flow – your product and service should flow to the customer without any interruptions, detours or waiting – delivering customer value.
Respond to customer demand (also referred to as pull). Understand the demand and optimize the process to deliver to this demand – ensuring you deliver only what the customer wants and when they want it – just in time production.
Pursue perfection – all the steps link together as waste is identified – in layers as one waste rectification can expose another – and eliminated by changing / optimizing the process to ensure all assets add value to the customer.

LEAN Tools:

Five S (5S): A process of keeping the workplace ready for use exercising a discipline of 5 workplace practices beginning with S.
- Sort
- Set in order
- Shine
- Standardise
- Sustain

5S optimally prepare the workplace to perform optimum tasks in the future including the idea of visual management.

Seven Wastes: Waste is any activity that consumes resources but do not not creates value for the customer. The purpose of seven wastes is to identify and eliminate waste in processes hence delivery greater customer value. 7 Catagories of Waste: Defects, Overproduction, Unnecessary transportation, Waiting, Inventory, Unnecessary Motion, Over-processing
Takt Time: The average rate at which a deliverable item is required to meet the customer demand. It is used to create the balance in the process between supply and demand and to help calculate the resources required to efficiently process a process just in time.
SMED
Kaizen
Value-Stream Mapping

Underlining the success of Lean is a culture of respect of people – at all levels. As Lean is a whole-system management methodology that requires a overall culture change to be successful – starting at the top.

Lean Six Sigma

General Electric (GE) adopted Six Sigma in the 1980’s – combining that with the principals adopted by the Toyota Production System (TPS), the origins of Lean Thinking provide the methodology of LEAN SIX SIGMA.

It is a complementary combination between the best of both worlds – Lean Thinking, which is focused on process flow and waste elimination and Six Sigma, which is focused on process variation and defects – driving business operational excellence.

Other relevant posts: Executive Overview of Agile #1 and #2

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!

The Art of IT Effort Estimation

October 7, 2010September 12, 2018Leave a comment

Why Estimate at all?

Estimation is an essential part of any project methodology. Estimation is used for a number of purposes:

To justify the project enabling the costs to be compared with the anticipated benefits and to enable informed comparisons to be made between different technical or functional options.
To enforce the discipline needed to make the project succeed.
To secure the resources required to successfully deliver the project.
To ensure that the support impact of the project is fully understood.
To inform and improve the software development process.

What is estimation and why is it so important

Projects are planned and managed within scope, time, and cost constraints. These constraints are referred to as the Project Management Triangle. Each side represents a constraint. One side of the triangle cannot be changed without impacting the others. The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project’s end result.

These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.

What are the challenges

Lack of communication between…a…b…c
Lack of training in basic knowledge and techniques of estimation
Inability to do estimations based on – cost – time – scope
Project failure through time over runs and faulty estimation

Where are we going wrong?

Every day, project managers and business leaders make decisions based on estimates of the dynamics of the project management triangle.
Since each decision can determine whether a project succeeds or fails, accurate estimates are critical.
Projects launched without a rigorous initial estimate are five times more probable of experiencing delays and cancellations.
Even projects with sound initial estimates are doomed if they are not guided by informed decisions within the constraints of the triangle.
If you are working under a fixed budget (cost constraint), then an inaccurate estimate of the number of product features you can produce (scope) within a fixed period of time (schedule) will doom your project.
Inaccurate estimates across your projects de-optimize your portfolio.
Estimates are always questioned when estimates are given with knowledge – no estimation template is being used

How can we improve?

Outsource the project estimation function to an outside qualified consultant for each project to be able to gain viable and realistic project estimations that can be achieved.
Education of in-house project managers and technical leads so that we are able to collectively able to provide clear methodologies on how to estimate accurately.

This can be done through an onsite workshop/course – onsite is cost effective as company will pay one block fee for the attendees instead of delegates going offsite and attending a workshop where individual fees are applicable.

My personal recommendation is option B – as this option will allow us to retain skills in house to be able to produce accurate estimates

What are the long term benefits

Well crafted estimate creates many benefits:

alignment between business objectives and technical estimates
more informed business decision making
reliable project delivery dates
improved communication between management and the project team
controlled project costs, and
satisfied customers

Conclusion

The UK is facing ever tightening economic restraints. This means the quality of work is now, more than ever, of the utmost importance. To stay competitive in a shrinking marketplace, this company cannot afford to get a reputation in the industry for non-performance and bringing in projects over budget and outside estimated time frames. Credibility is the basis on which we build our reputation. In the eyes of clients credibility = successful projects. For us the success of all projects rest on the correct and precise estimation from the start of a project based on best practices, realistic expectations and transparency.