Solved

Checklist post application development (JAVA)

Posted on 2014-02-19
4
808 Views
Last Modified: 2014-02-21
Hi,

Over my years as a dev, I've put together a checklist of things to dig into after i would be done with my application.

So for example, i build an app, i test it locally, i deploy it to dev env and test there, then qa takes it put its to qa / uat and eventually prod but sometimes along the way there are hiccups in config misses and etc.

So my question is, does anyone know of a good source where there's essentially a checklist for developers to be aware of to check AFTER they have just finished coding their app and are ready to release it? This could include stuff like "is it configured to run in all environments?" , "are the jms / topics set up in all envs", "if the app downloads some file, what if the file doesnt arrive or what if the file is too big or etc"...but more generic..

Any ideas? Some best practices as well possibly.
0
Comment
Question by:Squadless
4 Comments
 
LVL 26

Expert Comment

by:dpearson
ID: 39872701
The checklist you describe sounds to me a lot like a test plan for QA.  That's generally where you go through things like making sure all environments have been considered, what happens if you upload too large of a file etc.

Unfortunately there's no recipe that I'm aware for building such a plan.  That's where the skill of a QA team lead or QA members comes in (usually working closely with a dev team lead or dev members) to formulate the right plan and cover all of the bases.  You can talk about things like "code coverage" and other measures of test completeness but as you point out there are lots of cases where code can execute correctly in one situation but fail in another.

I think asking for a generic plan rather implies it's something formulaic when I think it's really a skill.  A bit like asking for a checklist of steps needed to build a fully working app.  We as developers know there is no such checklist.  There may be one day, but our skills as a community haven't reduced development to a simple process and so far I don't think we have for QA either.

Just my opinion,

Doug
0
 
LVL 37

Expert Comment

by:zzynx
ID: 39872763
Just to let you know that I completely agree with Doug's comment.
0
 
LVL 34

Accepted Solution

by:
Gary Patterson earned 500 total points
ID: 39873994
I disagree with Doug and zzynx.

This is not QA.  This is change management, and the document you describe is an implementation plan.  

I'm a consultant, and I've worked as a developer, tester, QA manager, project manager, DBA, sysadmin, network admin, security admin, operations analyst, and other roles over the years.  

Some of these places were very good at change management, and some were very, very bad.

The larger the environment, the more complex (and risky) implementations become.  I think it is a good idea to start with the most complex cases - large-scale application cross-platform development in a sensitive environment (military, medicine, financial services), and then work backwards to adapt the best practices found in those environments to smaller, less sensitive applications and environments.

In small shops, I've seen development, QA, implementation, and post-implementation all handled by a single developer.  Projects tend to be relatively small, and since all the responsibility for getting the application into production falls to one individual, these deployments usually go pretty well (or the developer doesn't last long...).  Good small-shop developers carefully document what they change in development, and make sure each required change is applied to production.  

I can certainly see how a general checklist would be handy in this environment.

For large implementations, a basic implementation plan document template (or group of templates from different teams) is often used - and that document contains sections used as a "checklist" for each group involved in a deployment.

Smart organizations update these implementation plan templates based on "lessons learned" from previous problems.

In larger organizations, implementation plan development responsibilities are often spread out over a much larger group - and implementations are often very, very complex.  For example each development team involved is responsible for generating the initial implementation plan by capturing every change made in the development environment into the implementation plan document.  

The implementation plan may be "owned" by the dev teams, a project manager, an implementation manager, etc.

In large environments, other teams are also often involved in developing and approving the implementation plan: security, network, capacity, database, system administrators for various related systems, infrastructure, operations, etc.  

As the project transitions into QA, the QA teams involved are also responsible for updating the implementation plan with any deficiencies discovered, or changes required during the QA processes.

Eventually, all of the teams involved, plus teams like change management, operations, and production support that have to deal with the application in production all must  review, update, and ultimately approve the implementation plan - taking into consideration common issues and concerns from previous implementations of this application or other similar applications.  

This is also a good point in the project for one last (automated if possible) comparison of the dev/QA/prod environments to verify that no required implementation steps have been omitted.

As a developer, I know that when something goes wrong, it often falls to me to fix it - or at least to identify where the problem is and engage the appropriate resources to get it fixed - regardless of the location or cause of the problem.

The best way to do that is to assume a lot of ownership for the implementation plan, and to carefully review it prior to production implementation.

A few thoughts:

1) Automate deployments - especially complex deployments, and carefully test the deployment automation process.

2) Set up your development/QA environments to match the production environment as closely as possible.  Compare the relevant portions of the of the dev/QA and prod environments before each production release - and it is a great idea to automate this step.

Require resolution of every discrepancy before the new change can move to production.

3) Require developers to carefully document every change made in the development environment - code changes, setting, new queues, config file changes, new/updated code libraries, os changes, etc.  Require every person or department that has a role in the development, testing, and deployment to review, update, and approve the implementation plan.

4) Hold a pre-implementation review meeting to carefully go through each item in the implementation plan, explain and discuss the required timing and responsibility for each implementation item, and get approval from each of the teams involved.

5) Develop an implementation plan template, and any time there is a deployment failure or post-deployment issue, review the implementation plan and template and address the deficiency.  Also update the template as new applications, tools, and technologies are implemented to make sure that any unique implementation considerations for those items are addressed.

There is no "one size fits all" implementation checklist that will work for every shop, but if you have change management problems, many organizations find it is well worth the time, effort, and money to bring in an experienced consultant to help design a change management process for your organization.

- Gary Patterson
0
 
LVL 1

Author Closing Comment

by:Squadless
ID: 39876968
great reply! 5 stars.
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Introduction This article is the second of three articles that explain why and how the Experts Exchange QA Team does test automation for our web site. This article covers the basic installation and configuration of the test automation tools used by…
A short article about problems I had with the new location API and permissions in Marshmallow
Video by: Michael
Viewers learn about how to reduce the potential repetitiveness of coding in main by developing methods to perform specific tasks for their program. Additionally, objects are introduced for the purpose of learning how to call methods in Java. Define …
Viewers will learn about arithmetic and Boolean expressions in Java and the logical operators used to create Boolean expressions. We will cover the symbols used for arithmetic expressions and define each logical operator and how to use them in Boole…

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

18 Experts available now in Live!

Get 1:1 Help Now