/* out for now...*/ Fulbright IT = Testing Brilliance and State of the Art Testing Solutions

These days, this is not a new concept, however, it is one of the slickest ways to improve the performance and extensibility of a Financial Services platform. The use of Virtual Environments and De-Coupling the components of a financial enterprise system to communicate with each other in real time, is proving a powerful combination of methodology for:
1. Maintaining a Master Copy of the baselined engine, which is rolled through the dev and testing process using VERSIONED updates into a virtual environment.
2. Keeping a daily reconciliation accurate for a report or even a GL inquiry.
2. Makes the old BATCH methodology obsolete.
3. Opens the door to automation and parameterization of testing for complex systems.
a. lower costs for testing attributed to automation (repeatable and parameterized)
4. Provides instant converted data (once Data Quality is completed) with a direct drop into an iterative, virtual database for testing
5. Direct and INSTANT communication with Database from Platform

Just adding new text for sending notice…

These are just a few of the most obvious advantages. But this is representative of the new types of systems becoming available to large financial institutions globally. Fulbright IT & Testing is actively engaged with clientele that adopts this approach, and is successfully producing Testing Methodology that is compatible and congruent with this new level of technology. 10 years ago this was unheard of. 5 years it was being done with homegrown, hand stitched internal systems – effective, but touchy. Now we have some time and development behind us and there are new frameworks – out of the box – which provide a working platform to accelerate the development of regional requirements, and proprietary products and services.

We are the leading edge in testing these environments.

We have been THE ONLY presenter at PegaWorld for the last 4 Years. NO ONE else has even attempted to present. I have built and held the only existing Testing Methodology for Pega PRPC since version 4.3 through 6.2. There are other client BREs that have benefitted from our approach and methodology.

If you have a system such as this, and would like more information on how to harness this powerful environment and testing methodology, please contact us.

Thanks,

Bill Fulbright
Fulbright IT & Testing
bill@fulbrightit.com
770-880-0959

Be the first to comment
del.icio.us this! Digg this! Share this by email. Share on Facebook! Share on LinkedIn! Share on Myspace! Share on NewsVine! Stumble Upon this! Tweet this! Share on Reddit! RSS 2.0 TOP

New Resume Updates

By Bill | Filed in News, Resume Updates, Testing

New Resume Update as of 11-9-2011 for William A. Fulbright.

Please see the updates to my Resume on my Resume Page or use the links below.

Download Link – High Level Resume Summary – William A. Fulbright

Download Link – Detailed Resume – William A. Fulbright

Be the first to comment
del.icio.us this! Digg this! Share this by email. Share on Facebook! Share on LinkedIn! Share on Myspace! Share on NewsVine! Stumble Upon this! Tweet this! Share on Reddit! RSS 2.0 TOP

Web Service Testing or SOA?  Requirements vs. Rules?

There is so much complicated talk about Web Service testing. or is it SOA? There is a difference! SOA is more involved, and we will get into that.

Web Service Testing can be a simple thing, since there are really ony 3 elements to the process:
1. Create and send the Web Service “Request”
2. Receive the “Response”
3. Evaluate whether or not it worked.

These can be tested with home-grown interfaces, free downloads such as soapUI, and even automated with the same. No need for complicated toolsets.

Rules and Requirements
Great. Now there is this subject of validating an application’s set of rules. Rules are the functional expression of a Work Flow or a Business Process as described by a set of Requirements. What? no Business Requirements? Why – how can that be? I can tell you that that is the usual state of companies these days. No requirements. OR if there ARE requirements they are written at a general level, with not enough specificity to drive a functional requirement through a paper bag. Occasionally we see good requirements, but as a rule – “there is just not enough time… here – just do this…”.

Process before Testing
Unfortunately, that opens the whole question about …. “Hey, WHERE is the PROCESS?”…. Some have better process than others, some have none – but in either case, there is always a need to improve a process forgotten, minimal, broken or non-existent.  Testing without a well defined and full SDLC (Software Development Life Cycle) is like trying to drive a car without a steering wheel.

There needs to be a Charter, Planning, Joint Accelerated Development meetings, Business Requirement Documents to define the product, Analysis of the BRD to create a Development Framework and a Testing Strategy, a Construction period for both Development and Testing, a release phase into a Testing Environment, a full Testing cycle for Functional, Integration, End to End and User Acceptance testing.  All of this before the public ever sees one piece of it.

Does this sound familiar?  How much of it is in place for your project?  Is your company or project chasing it’s tail and failing to meet the desired outcomes?  Don’t feel alone.  These problems are in every single company I have ever consulted with over the past 16 years.   There is ALWAYS a solution and a remedy to make it better.  “That’s the we have always done it” is not the right answer – ever.  The right questions are what do you expect to have when you are finished?  How do you expect to get there?  How long will it take you if you have a specific plan for delivery and resources?

Just saying we are going to develop something and release it will not work.  The IT and Testing departments will be chasing their tails forever.  Especially if there are no checks and balances between the Business, Development, Testing and Operations.  Many a company is run by it’s Business which is good, some by the Development group, which is ok, but not the best.  Mostly the Business runs the show as they have the checkbook.  If Development runs the show, it is because there are no checks and balances.  Process levels the playing field a good bit, and makes everyone play with the same playbook.

So, when testing Web Services, or Rules Engines, Testing cannot be expected to just sit on the other side of the wall until Development throws something over and says “Hey, just test this”.  The results will be as obtuse as the request.  Testing should be involved from the Requirements phase until delivery to Production.  Testing can participate early on to grasp the direction of the development and prepare for the releases to come.  Partnership between Dev and Test needs to be a close and working relationship.

to be continued…

7 Comments so far. Join the Conversation
del.icio.us this! Digg this! Share this by email. Share on Facebook! Share on LinkedIn! Share on Myspace! Share on NewsVine! Stumble Upon this! Tweet this! Share on Reddit! RSS 2.0 TOP