Ten Ways to Improve Quality Productivity

Having worked in Quality Assurance in many different roles and organizations over the years, I have come to realize that some days, we are the *rock stars* of the organization (or at least we feel like we are) and other days barely get to log a defect.

In thinking this over to try and gain a better understanding of what holds back the rock star days I have come up with a few things I noticed in my own day that apply across the board. Small or large organization, there seems to be some commonality, without further adieu, here they are:

Limit meetings to once a week or less.I know, most of you are shaking your head here. While it is important for QA to be involved from the very beginning on all projects, it is also just as important to have time to work on those projects. Assess what meetings are truly important to your projects and productivity and attend only those. The three hour meetings to discuss button color for the new application is hardly going to increase the productivity of QA. Make sure you ask for an agenda for each meeting you are requested to attend so you can ascertain if this one is for you.

Leave yourself a breadcrumb trail. Be creative and define a method for yourself so that you can determine where you left off should an emergency crop up and cause you to be distracted from testing. Doesn't have to be elaborate, can be as simple as typing a large "X" on the line of the test plan you were working on or some other indication to you personally that will help you to get right back in the game without having to hunt down where you left off.

Have a plan. Take the time to plan out your projects and your working hours and stick to it. It is very easy to get distracted during a busy workday, keep your plan in mind in all you do, in all your interactions and develop personal methods to keep yourself on track.

Work in a lab. Hopefully, your organization has a lab for you to work in, an isolated area where the noise and hustle and bustle of the day to day business activities are outside of earshot and sight. If you don't have one, talk to your manager or team lead and work to build one, it's worth it. This is not to say QA should work in a vacuum, rather, QA needs concentration time that is often impossible to obtain amidst regular business activities.

Kill the IM's. Have the IM on your desktop and not on your lab or testing machines. IM is a fabulous tool to keep me productive in other factors of my work, but when it comes to writing test cases and plans, the less distraction you have from outside influences, the better.

Take a walk. Try taking a short walk in the morning before work starts or some form of exercise, even if it is only twenty minutes. Your body needs that time and exercise, it matters to your overall health and well being. Hard to be productive if you are ill or your body feels neglected.

Take lunch. Most of us get so engrossed with our work, we loose track of time and forget to take even thirty minutes for ourselves to eat and chat with others. Put lunch in your daily plan and take it. Even if it is only thirty minutes, do it and make plans to have lunch with others. Being social and taking some breathing space during the workday is essential for your personal well being and your productivity. Working lunches are great only if you have a light schedule for the day, otherwise, steer clear of them and give yourself a mental and social break. You will be impressed with how positively this impacts your attitude and productivity.

List common distractions. Take a minute or two and think about what distracted you over the past week. Know what the distractions are, write them down. Now make a plan to address those things you feel hampered your productivity. Having a plan to address these things in advance will make you feel more focused and in control of your destiny.

Tear yourself away from email. Again, this is another fabulous tool to increase productivity and by all means, the urgent emails must be addressed. So address those that are critical or urgent and get back to your plan. Leave all the other emails for the end of the day, they can wait until you are done with your testing.

Get out!. Get your team members together and get out at least once a month together where you do not talk about work. being social and building relationships with your team members is a fabulous way to understand one another better. You can talk about work if you must, but be sure to get personal, know who you are working with and maybe make a new friend or two. It doesn't hurt, promise!Hopefully this will help you to have that rock star feeling more often and feel more productive. I have employed these rules to my own day and find I feel much better at the end of the week with a nice list of accomplishments to present to the business. I am not saying any of these are easy, but at least get started and see how much better you feel at the end of the day. Speaking of the end of the day, here is a bonus tip:

BONUS: Take the night off! It is sometimes ever so tempting to work into the evening and at times, you cannot avoid it. Don't make a habit of working overtime if you can avoid it. Your peak hours of productivity are the first six you work each day, anything after that, your effectiveness drops considerably. Consider this and ask yourself if working late is going to accomplish anything more than missing dinner with your family, friends or significant other.

Have a "Rock Star" QA Team with some of these suggestions to get your started.

Getting Started with your Virtual QA Lab

You love the idea of a virtual QA Lab but wonder how to begin. At the beginning, as with any project, with the high level requirements and the business systems design review. Get your ideas in line with the needs of the business.

Define and Prepare

The solution must be designed to provide stable services to the Quality Assurance and Development Departments by implementing network servers and updated software purchased from approved vendors. This will have direct impact on reducing business risk, increasing availability of the applications in line with current projections for the QA and Development Departments and compliance with SoX audit trail requirements. Not worried about SoX? Someone in your organization will be concerned with audits, be is SoX or something else. Having an audit trail protects the business from anything that may occur in the future so plan for it now.

Anyone for Scope?

Gain a complete understanding of what exists today in your world. Do you have any single point of failures? Lack of failover systems? Operating systems that are not part of a security patching schedule and are therefore out of date posing a security risk. Have the needs and volume changed since the original equipment was put in place? What are those? How do you plan to address that?

The Virtual QA lab will aims to resolve all the outdated and growth issues now and in the future by upgrading hardware, implementing adequate security polices and adding support and training. Be sure your plan:

• Specifies clearly the needs and offerings.
• Is clear and focused to avoid misinterpretation.
• Measureble to be quantified and compared to other data.
• Attainable: achievable, reasonable, and credible under conditions expected.
• Realistic: fits into the organization's constraints and is cost effective.
• Timely.

Phase It!

This is not a simple undertaking for an organization that has not walked down this road before. Avoid the overwhelming feeling by phasing your plan. Make it simple and understandable to avoid the "this is too complex" thoughts your customers have in their minds before it hits their lips.

For example, in the initial phase, new hardware may be purchased and installed in an approved data center. New Application software may be installed and configured. Be sure to include assets and how they will be accommodated.

Be absolutely certain to include savings, this is a critical part of this plan. Include those costs associated with exposure due to outdated and aged out hardware, as well as growth both immediate and in the future.

Get Specific

If you have done your homework up to know, you are fully aware of the pains within the QA organization and the organization overall. Address those pains in specific, real terms. What if you are new or trying to do this as an outside vendor with no specifics? Ask questions! Most clients are more than happy to talk about their pain. They need your help, after all, that is why they are talking to you in the first place. Don't miss any opportunities to learn about the pain and pleasure of the current systems and environments and address them.

Need Help?

Give me a call, an email or contact me in whatever way you feel most comfortable. I am very happy to help and am certain I can be of help to you in your plan. I have implemented this solution ins both large and small organizations and can customize this cost saving solution to fit any environment and company size.

LoadRunner 9.0 - A Review of What's New

LoadRunner 9.0 is released, debugged and ready to sere the needs of performance testers. It's been out there since August, but had some "issues" that are reportedly fixed. So let's take a look and see what we get!

New Features

The best improvement in VUGen is the most basic and simple - we finally have a FIND feature!
The most notable in VuGen is the user defined Business Process Report in Microsoft Word format, that summarizes the VuGen script for various protocols including the infamous and troublesome Citrix_ICA. This works well, but text would have been a far choice since this is to be a template that is reusable and Word adds extra formatting codes you are going to have to hunt down and get rid of before you can actually use this.

In the Controller, a new scheduler is available with a GUI to actually see the firing off of Vusers to that schedule. This is a help for when you are in the process of taking down a server, you can show it visually to the impacted team with little explanation necessary. One less meeting is always good in testing.

New Functions

Five star new function, IMHO, is at long last, the support for RDP testing with a run time viewer! Now if we could only get the application itself to run with VNC and RDP it would be great!

For you Citrix fans, the new ctrx_execute_on_window function (replaces ctrx_set_exeption) provides for the use if wildcard characters in the window caption, less scripting for you!

The SLA Wizard gives you the opportunity to define performance metrics against established SLAs. Purely a business reporting tool that will help when it is analysis and reporting time, Loadrunner will go out and perform the measurements for you and report them on demand. A great time saver if you are in regression performance testing mode. Works well, I had no issue getting the metrics I asked for even when the SLAs were not possible (negative numbers).

Improved

Java support has been improved, we now have JMS (for Weblogic 8.1, Websphere MQ 6.0 and TIBCO EMS), JACADA and the ability to add custom as always.

Still needs work

The RMI support still needs work if we are going to use it without winsockets. I know the technology is old school, but we have tons of legacy apps alive and well that use this function.

Visual Studio integration is still not quite there. You will find some of the old errors and mis configurations still exist.



=============================================

Citrix

Citrix Vuser scripts emulate the Citrix ICA protocol communication between a Citrix client and server.

Improved script replay stability and predictability.
New bitmap synchronization replay error management compares bitmap synchronization errors as they occur, and adds the necessary changes to the the script in a single click.
Improved text trapping and text synchronization algorithm, including showing the synchronization area in a snapshot.
Improved tree view, including replay snapshots and additional options in the context menu.
New ctrx_execute_on_window function (replaces ctrx_set_exeption) enables usage of wildcard characters (*) in the window caption.
Supports Metaframe server 3.0 and Metaframe server 4.0
Supports Citrix client 9.x and 10.0

WAP

Supports recording using the new multi-protocol mechanism.
Records any type of WAP application/simulator.
VuGen automatically recognizes the application/simulator settings and uses them during recording.
Supports WSP, HTTP proxy, and HTTP direct modes as configured in the application/simulator.

Winsocket

Added support for SSL and UDP.

Mailing Services

Added SSL support for LDAP, FTP, POP3, SMTP & IMAP protocols.

Microsoft Visual Studio 2005 Add-In

Full support for creating, replaying, and debugging scripts from Microsoft Visual Studio 2005 - C#, VB.NET or C++.

Agile Testing Types and Process

Types of Testing and the steps to be followed in sequence to assure your customers receive a quality product. For example, performance testing can only be accomplished successfully AFTER functional testing has been performed and the software passes that step. To do so otherwise would result in functional errors delaying the success of performance testing

Step 1: Unit testing
Performed by the Developer. Unit test case design begins after a technical review approves the high level design. The unit test cases shall be designed to test the validity of the program's correctness. In other words each decision statement in the program shall take on a true value.

Step 2: Test Planning
Performed by QA. Review requirement specifications, architectural designs and use cases to develop test plans, test steps and test scenarios. Identify any gaps or issues that need to be addressed.

Step 3: Requirements Traceability / Testability
Performed by QA. Traceability is the ability to show how requirements are derived from higher level (or "parent") requirements. Conversely, traceability helps to identify all downward requirements derived from parent requirements.

Step 4: Integration Testing
Performed by QA. Integration testing proves that all areas of the system interface with each other correctly and that there are no gaps in the data flow. The final integration test proves that the system works as an integrated unit when all the fixes are complete.

Step 5: Build Verification / Smoke Test
Performed by QA. When a build has met completion criteria and is ready to be tested, the QA team runs an initial battery of basic tests to verify the build. If the build is not testable at all, then the QA rejects the build. If portions of the build are testable those are tested and the results documented.

Step 6: Functional Testing
Performed by QA. Functional testing assures that each element of the application meets the functional requirements of the business as outlined in the requirements document/functional brief, system design specification, and other functional documents produced.

Step 7: Performance, Load and Stress Testing
Performed by QA. Non-functional testing proves that the documented performance standards or requirements are met. Examples of testable standards include response time and compatibility with specified browsers and operating systems.

Step 8: Defect Fix Validation
Performed by QA. If any known defects or issues existed during development, QA tests specifically in those areas to validate the fixes implemented by the developers who have also unit tested these fixes prior to sending them over to QA for validation.

Step 9: Regression Testing
Performed by QA. Regression testing is performed after the release of each phase to ensure that there is no impact on previously released software. Regression testing cannot be conducted on the initial build because the test cases are taken from defects found in previous build in initial there will be nothing to test against.

Step 10: Error Management
Performed by QA. During the QA testing workflow, all defects will be reported using the error management workflow. Regular meetings will take place between QA, development, product and project management to discuss defects, priority of defects, and fixes.

Step 11: QA Reporting and Readiness Review Performed by QA. QA states the results of testing, reports outstanding defects/known issues, and makes a recommendation for release into production.

Step 12: Release Management
Performed by QA. Releasing software refers to the process of providing some named (or otherwise uniquely identified) files to others for use. The others may be your department at work, your classmates, or The World. Managing the release means you know, understand and can explain what went into it.

Step 13: User Acceptance Testing
Performed by All concerned Product Managers, Project Managers and a Customer Focus Group (if applicable) to verify the new system, data and software changes meet customer expectations and meet usability requirements.

Step 14: Release into production
Performed by QA & Project Team If the project team determines that the build is acceptable for production, the configuration/version management team will migrate the build into staging for the implementation team to move into the production environment.

Step 15: Post Implementation
Testing Performed by QA. Testing performed after the software has been deployed to ensure proper implementation.