Don’t Be Afraid … Change!

Over the last several years, my teams have made significant changes to our project management, development, testing and implementation processes and paradigms. We’ve had some bumps along the way and in no way do I consider this evolution over. I will continue to challenge my team members to find a better way to build the mouse trap that drives our software development lifecycle.

Let’s look at some of the successes the teams have had introducing change into the organization:

1. Our project management process used to be split into separate and distinct teams: 1) project management for business and operational teams; 2) project management for technology teams. This has been consolidated into one project management team managing all project related activity across the organization. This has streamlined activity and improved communication across all teams involved in the process.
2. Our lifecycle was revamped as we consolidated the project management organization. During the revamp – we created RACI documentation that clearly outlined 1 owner for each key task/milestone within the overall project activity, along with those that would act in the roles of responsible, consultative and informed parties. This has provided clarity to who owns each activity and what the key tasks are that are included within every project.
3. Recently we made additional changes to the lifecycle – completely eliminating 1 phase and adjusting the tasks and milestones associated with both our scoping and design phases. This has allowed us to streamline the process and give clarity to when project activity actually starts within the organization.
4. We have challenged all of our team members to review the overall standard tasks/milestones within any given project, and challenge the project manager and sponsor to eliminate tasks and standard artifacts when it is justified and where there is minimal risk associated with utilizing an altered process.  This decision then is documented as part of the project and communicated to the team to ensure that down the road, people can review the effort and understand why certain documents or tasks might not have been done. This should allow us to be more nimble and find the best path for each project to take thru the organization.
5. A couple of years ago, it took up to 3 weeks to complete regression testing associated with key functionality within our application silos. This was a manual effort that typically was handled by multiple individuals. The teams have worked hard to automate the regression tests associated with these applications. Today, the execution of these tests can be done in less than 17 hrs. The labor savings moving forward will more than pay for this effort. This also allows us to provide quicker feedback to the development teams and ensures that our regression testing is more consistent across all projects.
6. Recently, the teams also completed the resurrection of standardized test data to be used across our test and development environments. This will be further enhanced as our automated tests are enhanced to create/modify/cleanse and reset data needed for a given test. This will reduce the time spent creating test data for each project and will ensure downstream processes/applications have the data that is needed to execute their regression tests.
7. Over the last several years, our implementation plans have seen significant improvement. Our business demands that our systems be available 24x7x365. When you want to buy a tank of gas at 3AM or 3PM, you want the transaction to go through so that you can continue on your way. You would not find it acceptable for us to deny the transaction because we are updating our systems.  Our implementation processes have been templated and include all implementation activity, across all application and infrastructure silos, commands, scripts, validation and fallback steps in the order they will be executed.  Recently, our external auditors informed me that our implementation plans are among the best that they have ever reviewed. This has hardened our implementation activity – reducing the overall time needed to implement changes into our production environment, standardizing the validation activity during and after implementation activity has occurred and most importantly having fallback steps at the ready when any validation activity shows that there may be an issue.
8. Our development teams have changed their processes to include code reviews of all changes prior to those changes being introduced into our production environment. This is hardening our code base and reducing the risk of making changes within our production environment.
9. Our development teams have changed their processes to ensure that unit tests are created for all code being touched within a project.  These unit tests are then kept in a repository and used in future projects. This, again, has hardened our applications and reduced the overall number of bugs slipping through the process into our quality assurance testing or into our production environment.
10. Our development teams are now doing nightly builds – with reports going back to each team on build failures, unit test execution failures, code coverage and other statistics. This is giving immediate feedback to our development team and ensures that issues are addressed within 24 hours.

These are just some of the changes that have been implemented by the teams over the last several years. And we’re not done! Moving forward, we will move the regression testing into our nightly build process. We will be evaluating further changes to our development lifecycle to reduce the amount of time between idea generation and product introduction into our production environment. We will continue to improve upon our implantation planning. We will introduce key metrics across the development lifecycle. And where it makes sense, we will introduce Agile techniques into the development process.

I talk to college and high school students on a regular basis to discuss what it means to be in the technology field (specifically software development). The one constant that I tell students is that being in this field means you will constantly have to learn. They will learn new languages, they will drive change into the organization, they will experience multiple different development paradigms. All of this is good – it means the organization is alive, is learning and is adapting to its competition. 

Don’t settle for how it works today or with someone telling you, “well, that’s the way we’ve done it for decades!” Your job, no matter what role you play in the organization, is to find a better way, review your suggestion with those that can help implement, trial those changes and then roll them out across the team and the organization. Change is good – don’t settle for the status quo! 

If you'd like more information on my background: LinkedIn Profile

Project Managers: Tactical ways to Push Testing

So, in my previous post, I talked about some of the high level things that you, as the Project Manager, need to be thinking about, as it relates to testing, when managing your projects.  In this post, I'm going to step down in to the tactical.  Specific things that you can begin to push within your projects and my recommendations for who should shoulder the responsibility.  These recommendations are based off of things that I've seen work in my current environment as well as things that I've seen work in various other organizations.

Now, before we dive in, a word of caution.  You need to evaluate what I'm saying and throw it up against the reality of the environment within which you work.  Some of what I say will work, some of what I say would probably spin heads within your organization.  Take what works for you and throw out the rest.  We're currently reevaluating some of the test strategies that are used within my teams and six months from now, I may have a different take on the subject.  My biggest concern is ensuring that we put enough thought in to the process to allow less experienced team members to be successful when working with unfamiliar subsystems or product features.

And, with that said, it's time to dig into the details and talk about things that I've seen work - note for those readers willing, I'd love to get feedback from others on what they are seeing work/not work in their environments.

First up, what are your end users (or the team members representing the end users) doing to drive the quality initiative?  These are the folks that are creating the user stories or requirements for the products that you're building.  Are they being held accountable at the start of the process to define what success means?  Are they telling you up front what they will do when performing user acceptance testing?  If not, it's time to sit down and have a conversation.  Why do they feel comfortable telling you what to build if they can't tell you how they will know it is right?  Specifically, what are the conditions and scenarios that they will use to validate that the functionality delivered is acting properly and producing the correct results?

1. What set of information needs to exist within the system to allow them to create the scenarios that they will use to test the requested functionality?  What specific elements of data will be used in the testing - both from a positive and negative test perspective?
2. What business logic is being used to assess whether the outcome is valid?  What will change within current processes?
3. Ultimately, what does success mean to them?  How will they know that what you've delivered works or doesn't work?

Now, ask yourself, if these do not exist prior to the design and development of the solution, how will the team know that the proposed solution will actually solve the problem?  This function must be driven by the end users (or those team members representing the end users).  They can collaborate with others on the team, including business analysts, technical team members and dedicated testers.  But, ownership of the acceptance test plan must fall on the shoulders of the end users.

One of the things that I like to do once the users have defined their needs and the design phase is underway, is to have the technical subject matter experts (SME's) begin to identify high level integration test objectives.  This is built at the same time that the technical design is being worked and is a very brief document outlining the gotchas that the development teams need to be aware of when developing and exercising the new systems/features.  This is intentionally kept very high level - usually just descriptions of each item that will need to be fleshed out in later stages.

1. Identify touch points between various sub-systems that will need to be tested.
2. Identify data replication strategies that will be used and that will need to be tested.
3. Identify data transformation strategies that will be used and that will need to be tested.
4. Identify services that will be relied on that will need to be tested.

This acts as a roadmap for the entire technical team.  It should be a roadmap used to identify data validation and functional validation.  It can be used by those that may be unfamiliar with specific subsystems to gain a further understanding of the interrelationships between the various subsystems and external/internal services.  The IT SME's own this high level integration test plan and pass it along to others in the process.

As we dive down in to the detail design - several things begin to happen.  First, the development team begins to flesh out the high level integration test strategy and it becomes the Integration Test Plan.  This document details the specific actions that will be used to test the touch points previously identified and should include the data and functional validation - data should be traceable throughout the system with the end points being validated.  This includes identifying the specific data elements that will be used to perform the tests as well as the expected positive/negative results.  While driven by individual development team members, the plan will be reviewed and validated by the Technical Leads.

Additionally, the individual development team members begin to identify their individual Unit Test strategies.  Each functional unit of code being created or modified needs to be tested to ensure that it is performing to spec prior to moving in to integration testing.  I believe in the paradigm that the tests should actually be created prior to the code being written, but I've seen development teams be successful using several different paradigms - so I won't harp on it.  The individual developers own this and are responsible for ensuring that they develop clean code.

Once the developers have been able to execute their individual Unit Tests, then they work together and move in to pre-Integration Test planning.  This time is spent ensuring that the necessary data has been identified and created/setup, that the configuration changes needed to the system and supporting sub-systems have been applied, that the network configuration changes needed to open ports to talk to internal/external services have been applied, and that all of this has been documented for production.  This particular block of activity is owned by the Development Team and the Technical Leads.  Infrastructure Teams may support the activity, but the Development Team and Technical Leads should ensure the configuration is complete and documented for the Implementation Plan.

Now we step in to Integration Testing - executing the plan that was documented earlier.  It is inevitable that something will have been missed - but that is what this stage is for, to find the bumps before you move your changes into the quality assurance (QA) and production environment.  Here you will find the missing data elements or calls to services/api's that work differently than documented.  You will uncover the fact that replication strategy for data you rely on wasn't documented properly and the underlying data you were expecting to see doesn't exist.  All sorts of unknowns will surface and you'll spend time playing whack-a-mole to clean it all up to a point where you believe it is functional.  The Development Team and the Tech Leads own this piece of the puzzle and work to ensure that all of the individual pieces come together and work as a whole. 

Now, let's take a few minutes to talk about Regression Testing.  I'm actually in the midst of transitioning our teams form the old style of moving code in to QA and then running a full regression test of the code along with new function/feature testing to a model where the code is built nightly and then the suite of regression tests is run when the build has finished.  This has been a tectonic shift for the teams in that the developers are getting daily feedback on code that has been checked in to the repository and we actually are building up a set of statistics that show us the overall state of the code.  I can now walk in on a daily basis and see the various package builds, number of tests being executed and the success/failure rate - along with a whole suite of statistics on coverage and severity of the failures.  Benefit number one - immediate feedback to the development team while the code is still fresh in their minds.  If we need to change something due to a failing test, the developer doesn't need to spend time remembering what changes were made.  Benefit number two - reduction of effort by our QA Team Members to get code through the testing process - their focus is on new feature/function testing, not regression testing.  Benefit number three - the developers have more buy-in on the testing process and begin to have a better understanding of the underlying data.  The Development Team is responsible for the Regression Testing and must review the results with QA to validate that the code is ready to move in to QA Testing.

QA Testing is focused on the new features/functionality to ensure that they are operating within defined constraints.  Here is where I want to hit the system hard with positive and negative testing associated with the new features/functionality being introduced within the overall system.  What happens where certain pieces of data are missing from messages exchanged between subsystems?  What happens when a user forgets to input data?  What happens when a web service that we are relying on isn't available?  What happens when the system thinks everything processed fine?  I will also want to take a look at load testing on some system to ensure that we are staying within expected SLA's.  This testing is the responsibility of the QA Team with input from the Development Team, Tech Leads and support from the Infrastructure Teams.

As  part of the work that is being done during QA Testing - we should also work with those team members representing the end users to execute the User Acceptance Tests (UATs).  This should tie all the way back to the beginning stages of the project where the business teams defined the success criteria of the effort and began building the definition of their UATs.  During the entire project, these high level UATs should have been fleshed out and reviewed to ensure that they align with the final requirements of the project.  QA and the User Teams should jointly execute and review the results of the associated UATs and prepare to sign off and give final authorization to move the code in to production.

As a Project Manager, you need to assign tasks to cover these activities within your overall project plan.  More importantly, you need to be following up with the responsible parties at various stages of the lifecycle to ensure that they are not being ignored.  Your organization may hold different team members responsible for the specific activities outlined.  They may also skip some of the items outlined above.  However, you need to ensure you are covering enough of the pieces to confirm that the system being built will satisfy the requirements originally identified at the beginning of the overall effort.

Well, we've reached the end of the discussion today.  I hope that you've found some of what I've discussed useful and that you're able to take pieces back in to your organization.  Feel free to share and let me know your thoughts on what has been presented and let me know what works in your organization.

Tags: SDLC, Software Development Lifecycle,  Project Lifecycle, Project, Manager, Development, Paradigm, Security, Secure Development Lifecycle, Communication, QA, Quality Assurance, Testing

For more information on David L. Collison: LinkedIn Profile

Until it's in Production, it doesn't matter ...

It doesn’t really matter until it’s in production!

Yep, we can all work hard, play and enjoy what we are doing, but it doesn’t count until we’ve packaged it all up, wrapped it in a bow and moved it into production.  But, that being said, how many of you are planning your implementations vs just moving them into production.  And, yes, just moving them into production is a plan - not, a very good plan, but it is a plan.  Similar to my comments on no process being a process.

So, let me ask this question - if you’re “just moving it into production”, how much time do you spend afterwards cleaning up the mess:

1. Oh, forgot to update my stored queries to account for the new data elements that I implemented in my users table.
2. Oops, what’s that, the billing app doesn’t recognize the new billing codes that were implemented along with our new service?
3. Argh, Bob didn’t tell me that I needed to move that property file into the models directory.
4. Why didn’t someone tell me that the XML configuration file needed to be updated?
5. Great, we forgot to begin replicating the new data elements into the warehouse, management’s reports are all busted.
6. Are you kidding me, we’re getting calls saying that the install is bombing out - they’re getting some message about a missing property file.

When I speak with students, I try and get them to understand that coding is actually a small part of what they need to be concerned about as a professional software engineer.  They need to think through all of the phases of the lifecycle.  Side note: a frustration point - our higher educational institutions for the most part skip a great deal of the software development lifecycle.

If students are going to successfully transition into the workplace, they are going to need to understand and hold themselves accountable for the entire lifecycle - that means everything from the initial vision all the way through to ensuring that the final product can be installed in a production environment or shipped out the door/over the internet to be installed by the final end user:

1. Scoping/Discovery: In many organizations, the software engineers work alongside partners across the business organization to define what will/will not be included within the specific release.  Today, it is difficult for non-technical resources to solely make these decisions as technology is pervasive within the business and the technical resources understand the various capabilities and constraints of the systems being developed/modified.
2. Requirements: Some organizations make it the responsibility of the software engineers to drive discussions and document the requirements for a particular application.  Even if the software engineers are not responsible, they need to understand how to read the requirements, clarify any outstanding/open issues and use the requirements to drive the rest of the process.
3. Technical Design: Yep, before you start coding you better have a plan in place.  Most developers want to hit the keyboard and start chunking out code.  As much as I like to code, I’ve learned over the years that planning is the better part of coding.  It will more than pay for itself on the back-end.
4. Coding: Finally!  Yep, this is where the rubber meets the road and you get to do what you love to do.
5. Testing: In previous posts, I’ve talked long and hard about testing - in short, don’t forget or you will pay for the transgression.
6. Implementation: I’m done coding, time to move on to the next project.  Hold up there, partner.  Until someone is using your code you’re not going anywhere.  Yes, now that you’re done, you need to put the finishing touches on that present, wrap the bow and hand it over to the users.

See, it’s not just about creation of something wonderful.  It’s also about ensuring that the people that originally wanted this beautiful thing created, actually get to use your masterpiece.

How many of us actually sit down ahead of time and plan how we are going to move our code into production or how we will create the install packages that we deliver to our customers?  How many of us actually execute the implementation plan to ensure that we have identified every step, every property file, every change to the database, the removal of files that are no longer needed, the removal of data no longer needed, the removal of property files or registry entries no longer needed?

And, by the way, you also need to plan a graceful fallback!  If you’re in the middle of the implementation and something starts to go bad - can you back out?  How do you back out the changes?  Can you put Humpty Dumpty back together again so that your users can go about their business?  More importantly, have you just shut down the companies ability to make money?  Don’t place yourself in a career limiting situation just because you didn’t plan.

None of this is rocket science, but if you don’t go through the exercise you will get caught.  You may be able to move minor projects into production without too much concern, but I guarantee the bigger the project, the more interconnections with other systems, you will need to have a plan.

Hey, but I’m on a 2 week sprint and the system automatically performs the build and moves things into production.  It does it in the middle of the night, nobody even has to be there.  Has it ever failed?  If it does, what will you do?  Can you promise your manager that you’re not going to take the site down for a day because the auto-build/deploy process broke?  Have you ever walked in the morning after one of your automated installs to have calls coming in from your user community because something isn’t working right?

I work for an organization whose systems must be accessible 24x7x365.  We don’t get downtime to perform installs on our OLTP engine - we need to replace pieces in flight without interrupting our ability to handle transactions.  Luckily on our other applications, we can take small outages in the middle of the night to install our code.  That said, those windows are extremely tight and we must have things planned extremely well so that we don’t waste time and that we can recover quickly if something does go sideways.

The teams that I have the pleasure of being associated with, plan extensively to ensure that our OLTP engine is always available - even when we are installing new pieces of code.  They also ensure that on our offline systems the outages are as small as possible.  This takes time and energy to do right.  Yes, we have automated some of the pieces, but there are still steps we take manually to ensure that we have proper gating through the implementation process.  We test our implementation plan, and if it is a critical system, we’ll actually test the fallback plan to ensure that we can back changes out quickly.  The teams are on-site for the implementations and we are monitoring our systems to ensure that transactions continue to flow and that entries propagate through the various systems accurately.  Monitoring is a key driver for the success of our installs - there are typically checkpoints along the way where we validate certain events across the system.

So, the question is, how are you your teams implementing code into the production environment?

Tags: #SDLC #softwaredevelopment #qa #lifecycle #implementation

If you'd like more information on my background: LinkedIn Profile

Testing - Making Changes

So, in the last couple of blog posts, I’ve discussed incidents from my past that have driven me to take testing more seriously than when I first entered the field.  Today, it has become even more critical for the teams that I lead to address testing as a critical component of the software development lifecycle.  My teams produce applications that, at peak times, can process 10’s of thousands of transactions a minute.  If we make a mistake - we can propagate that mistake really quickly. 

In the past, we have relied on brute force to test the applications that we release into production. This included individual scripts, but they would be kicked off manually and the results were tracked manually.  As our environment has grown more complex and the pace at which we release software has increased, it no longer makes sense to continue to try and manage this activity manually.

What we are in the midst of doing is automating and exposing all of the test information.  If you’ve been reading along in my blog postings, you can probably figure out that I like process.  Process, when used properly can actually accelerate the volume of activity within a development team and can bring greater returns to the business.  I readily admit the process run amok can destroy a team. It’s a fine line and I attempt to be cognizant of where the benefits can occur and where the pitfalls are that can wreak havoc across the team.

So what are we doing?  Well baby steps first - and none of this is revolutionary:

1. I’ve asked our Quality Assurance Teams to own the organizational test plans.  I’ve moved them forward in the process to work alongside the business teams as functional and nonfunctional requirements are identified.  They are responsible for documenting what testing will be needed and how it will be accomplished.  Is this an app that needs load testing, have we thought about security, is there a user interface component?  By doing this, we are working through the test requirements at the same time.
2. I’ve asked our Development Teams to move towards a Test Driven Development(TDD) methodology.  We are beginning to implement these strategies in individual project initiatives and over time, this should spread to all of our ongoing project activity.
3. I’ve asked our Development Teams to move towards a continuous build/continuous test development paradigm where individual applications are either built nightly or weekly with automated unit, integration and regression test results accumulated and published to a central location.  Developers are notified of errors in the code base.  Management has insight into immediate reporting identifying key statistics including - code coverage, test success rate, conformance to best practices, etc..
4. I’ve asked our Development Teams and Quality Assurance Teams to communicate more closely so that QA has visibility into the tests being generated and executed during the development cycle and that they have visibility into the continuous build/continuous test results.  This allows our QA Teams to validate that development is properly exercising the code that is being generated and ensuring that they aren’t breaking things that already work.
   
   

If done properly, this will allow our Quality Assurance Team to focus on New Function testing - while validating the integration and regression testing performed via our automated build/test scripts. Additionally, this should allow us to produce reliable test reports that can be reviewed with management and ultimately the business teams as they validate their UAT’s.  This should give them a higher degree of confidence that the applications we are moving into production have been tested thoroughly.

Over the last few months the teams have made big strides in changing the paradigm of testing within our organization.  We have a long way to go, but I’m confident that the team members understand the benefits to their individual teams, to the organization as a whole and ultimately to the customers that we serve.

I’ll admit that this is the tip of the iceberg - there is a quite a bit more that we can do.  However, we are making changes that can be implemented relatively quickly and that have the highest payback to the organization and to our customers.  As time moves on, the teams will evaluate what additional steps can be taken to improve the process and harden the delivery of applications to our production environment.  Our QA Teams have done a superb job to date of managing the applications we move through the test phase of the lifecycle, now it’s time to expand the responsibilities associated with testing across the organization and to utilize tools that allow us to automate key portions of the test strategy and produce standardized test metrics across all project activity.

Tags: #SDLC #softwaredevelopment #metrics #lifecycle #qualityassurance #qa

If you'd like more information on my background: LinkedIn Profile

A Room Full of Errors

At one point in my career I was involved in the merger of two organizations.  Both were roughly equal in size and I was working for the CIO of the acquiring company in an effort to evaluate systems across the two organizations and make decisions on which systems would be used going forward.

Let’s back up a ways and find out how we got into the mess - literally a room full of errors.

During the acquisition, the CEO of the acquired company let it be known that he had hired an outside consulting firm to create a new order entry/contract system that was beginning to be implemented within the company.  It was a new application built upon a thick client vs the application that we were using internally that ran on an IBM AS/400.  The argument was being made to ditch the green screens and use the sleek looking new interface of this new system.

So the acquisition is complete and we begin to send individuals down to review the systems and gain insight into where they are in the migration process from their old system to the new system and to evaluate if the new system might support the merged organization.  These trips occurred 2 times a week and sometimes I stayed on-sight for 3 or 4 days at a crack.  

It took a while, but over time I began to hear rumblings that all was not well in the world.  Bugs that had disappeared would suddenly reappear, errors were being encountered in the migration process, contracts could not be generated, resources were having to back key stuff in to the new system that people thought had been migrated.

The developers that were on staff also began to feel comfortable with me and started asking if they could be put in control of the contractors that were driving the development of the new system.  They began to pull back the doors and show me bug reports that were being sent to the contractors and how the bugs would recur on a regular basis.  They showed me the system and how data would disappear.  Not a good situation by any means.

The kicker finally came one week as we were preparing for a team meeting to discuss the status of the development work and the current migrations being scheduled.  Immediately prior to the meeting I was meeting with some of the production folks and they said I needed to see something.  We walked through the building and arrived at an office - the door was closed and the lights in the office were off.  As they opened the door - I could see boxes stuffed with paper lining the walls of the room.  I was curious and asked what I was looking at.  This, they indicated, were all the errors from all the migrations that had already occurred.  My jaw hit the floor!  To say that I was stunned was an understatement.  I am not kidding when I say that the walls were lined.  The boxes were stacked in piles over 6’ in height and wrapped around the room.

I quickly found my boss - the CIO - and let her in on what was happening.  Needless to say, our direction changed.  In that meeting, we pulled the plug on the new system.  The direction was made to fall back the migrations to the old system so that their sales teams could get reliable information.

Yikes, a lot went wrong here ... in hindsight, we found out a lot of things:

1. IT had no management oversight of the contracting company.  They reported directly to the acquired companies CEO.
2. The contract development team was not using any type of source control system - bugs were either reappearing because developers were not validating who had what code, or they were intentionally making changes to reintroduce bugs.
3. The test process used by the contract development team was woefully lacking - from what I was able to determine, there were no formalized test plans anywhere.  Each developer was responsible for writing the code, testing the code and moving it to production.
4. Migration issues were largely ignored by the contracting company - in their eyes, fixing those issues were not an issue with the system.
5. User issues were ignored by the contracting company - the CEO was satisfied with the system, so they didn’t feel any pressure to make corrections.
6. The requirements documentation built by the contract company was mostly fluff - very little concrete documentation identifying what was/was not included.  The contractors were mostly going off of seat of the pants - show me the screens you currently use, show me the reports you currently get, we’ll do the rest.

First, I would like to put on record - if you’re generating enough errors to fill up an office, there is something seriously wrong with what you’re doing!  Period - not even up for conversation.

During the actual negotiations, we had very limited ability to confirm what was being said.  However, after the sale was complete and I was able to get on site - I should have been more aggressive in my review of the migration activity of the system and the actual use of the system.  It ended up taking me several weeks to figure out what should have been noticed within the first few trips.

If memory serves me right, it took almost a $1M to clean up the mess and get all of the data back into the original system.  These were real $’s - not some estimate of lost productivity. Ultimately, that part of the organization became a very successful part of the larger organization.  We moved the contractors out - hired staff to build up the internal development team and put the few local resources they did have in to leading the new hires.

Now, I’ll circle back.  Look, if you getting test results that tell you something is wrong, and you proceed anyway, you’re a fool.  If you’re ignoring the results and plugging away and propagating errors into your production environment, and you think that’s ok.  You’re in the wrong job.  There were many warnings in this project - but nobody listened to the people on the front line that were finding all of the issues.  If I didn’t understand it before I got involved in this situation, it became crystal clear to me that if you wanted to be able to claim success, you needed to ensure that the end users of the system were happy with the results.  It really doesn’t matter how clever of a developer you are, if you’re not testing the system and ensuring that the users can be functional, then you’re not doing your job.

What lessons have you learned along the way that gave you better insight into the need for true testing within your lifecycle?

Tags: #SDLC #softwaredevelopment #metrics #lifecycle #qa #qualityassurance

If you'd like more information on my background: LinkedIn Profile