Speaking
Sell, Sell, Sell
You must be your own advertising agent within your organisation. In many cases test groups are the low men on the totem pole and it is up to you to get your team recognized for what they are doing and how they are progressing as an organisation.
Take every opportunity to get involved in overall process oriented meetings, applications development staff and/or project meetings and business events that can give your team exposure. Establish the test factory, as the ever friendly, always helpful and energetic people to call on for assistance or information.
Communication Routes
Communication needs to be started as early as possible and be consistent throughout a project’s life cycle. Have your team sit in on as many project meetings, staff meetings and business meetings as possible. If there are no formal meetings or if there is resistance from the applications development area, then have them make it a habit of scheduling at least half hour sessions to provide an overview of what they are doing. Use these meetings to ask questions and obtain as much information as possible. Also share what you are doing as a group. Even if the conversation doesn’t revolve around business topics, you are being recognized as part of the overall organisation.
I’ve found scheduling half hour meetings with each business area’s applications development team and infrastructure vice presidents once a month is a great opportunity to provide a brief status on our involvement on hot projects and to identify any potential concerns or issues that have filtered up to their level from their respective teams. In general most people don’t mind giving up a half hour if you show that your main concern is to make sure they are informed and that you want to catch any potential problems early.
Establish Identity
Make sure your applications development teams know who supports them and attempt to establish a team approach to the project delivery. I know how difficult this can be, but it is essential to your success as a test factory. Perseverance is the key and holding up your end of the team to stay on schedule, even if that means cutting corners in testing, can earn you the partnership you need. Go for lunch, drinks, whatever it takes! The goal is to become a team with applications development and then get them to do things your way!
Application Assessment
Establishing yourself as a resource for information from the infrastructure departments in your organisation can also enhance your image. We developed a simple form to use as an application assessment tool.
It can be completed from design documentation, system documentation or if there is no documentation, which is often the case, by simply asking a series of questions. The information is helpful when planning your test effort.
We also pass it along to the other infrastructure groups (Network & Data Center Ops, Database Administration, Tech Standards, Logistics and Training) as a heads up. Often these groups are not given any advance notice during a project’s development and this information helps them contact the necessary people to prepare for that phase of the project development. Below is a sample assessment form:
| ENVIRONMENT ASSESSMENT | |
| Assessment Question | Assessment Answer |
| General environment: | |
| What operating system(s) are the users running? | Description: |
| Equipment: | |
| Are you planning on using existing equipment (servers)?Yes ☐ No ☐ | Description: |
| If No – Has equipment been ordered?Yes ☐ No ☐ | Description: |
| Application environment: | |
| What is the user environment(Laptop/Desktop)?Laptop ☐ Desktop ☐ Other ☐ | Description: |
| User specifics: | |
| Number of expected users? | User Description: |
| Location(s) of expected users? | Additonal Description: |
| Special considerations: | |
| Please specify any special environment requirements for this application. | Description: |
| APPLICATION ASSESSMENT | |
| Assessment Question | Assessment Answer |
| General Application: | |
| Is this new development or changes to existing application? | Description: |
| Application Deployment: | |
| If existing application – has it been deployed to Production in the past?Yes ☐ No ☐ | Description: |
| Application Specifics: | |
| What is tjhe criticality of application? | Description: |
| Special considerations: | |
| Please specify any special application requirements. | Description: |
DOCUMENTATION ASSESSMENT |
|
| Assessment Question |
Assessment Answer |
| Business requirementsdocument?Yes ☐ No ☐ | Description: |
| Application design documents?Yes ☐ No ☐ | Description: |
Writing
Methodology
It is a good idea to develop a basic test methodology which can be expanded and revised as your test group matures. Your methodology should indicate how you will receive and prioritize requests for testing, how you go about testing, what results will be retained, testing type (automation verses manual test methods) and how testing results will be reported during the test process.
This can be as general as a business flow diagram or as complex as a fifty page detailed methodology document. My advice would be to keep it simple, but consistent. Our methodology consists of the following sections:
- Change Request – How requests for Qualty Management services are handled
- Prioritisation – How the test effort is determined
- Test planning – Test plan template
- Test design – Test scenarios
- Automation verses Manual testing
- Defect recording and tracking
- Completed test results – How it is documented
- Index to test Assets – Where and how everything is located
We employ the same methodology for all projects and produce the same documentation regardless of whether we are doing a full system test or simply testing a new module to an existing system.
Test Plan Template
We developed a master test plan template. This provides a uniform way of documenting the test effort and enables us to obtain the approval of the appropriate business and applications development staff on the testing scope. The template captures the following sections and is used for all testing done by the Quality Management (QM) group:
- Change Summary:
- File Location
- Version Notice
- Introduction:
- Purpose/Scope
- Responsibilities
- Tracking
- SQA Repository and Project
- Resolution
- Severity Criteria
- Defects
- Software Promotions
- Status Reporting
- Hardware Problems
- Test Overview
- Project Plan
- Software Overview
- Scope
- Hardware/Software Overview
- Prerequisites
- Test Tools
- Hardware/Software Overview
- Test Requirement
- Test Deliverables
- Quality Management Test Scenarios
- Scenario Template
- Artistic Testing
- Defect Recording
- Quality Management Certification Statement
The template covers many of the standard categories that are described when reading about what should be covered in a master test plan. The whole team agreed upon these sections and the format was developed as a group effort. The most important sections for any template are the Software Overview, Scope and Test Requirements. The team will often develop these sections during the initial engagement in a project and fill in the remaining sections toward the end of the test effort.
Scenario Designer
Just as the test plan template provided a uniform way of documenting our test effort, we wanted our test scenarios (or test cases) to be uniform as well. We developed an internal Visual Basics application that resides on the SQA (Software Quality Assurance) repository that we used for all automated testing to define our test scenarios. Each test requirement, identified in the master test plan, requires a test scenario to be entered in Scenario Designer (the test case database), regardless of whether the test will be automated or manual. Within Scenario Designer, we documented each test case purpose, the detailed testing method, expected test results and any relevant notes for each test designed. It also provides us with a history, which is helpful, when one member of the team joins a test effort and modifies an existing scenario. The goal of Scenario Designer is to uniformly record the steps necessary in duplicating any test. It becomes the heading of all automated tests in the SQA .rec file, but would be just as useful as a template residing in MS Word if the majority of your test efforts are recorded manually outside of a system repository.
Test Assets
With the goal of our team to automate whenever possible, most of our test assets are located in the SQA repository. For those tests that are not automated we generally use screen shots, screen cams or printed reports to document the test results. In either case, it is important to determine a standard directory and directory structure to hold all of your test assets. Within our SQA repository project directory, we create a documents directory to hold the application assessment form, master test plan and any test results that are in the form of screen prints, screen cams or reports. We created a high level document called ”Index to Test Assets” that points to the location on the server of all test assets and identifies what was done for a particular project. The goal here is to enable your team and anyone else who is interested, to quickly and easily find all documents pertaining to a particular project.
First Steps – Playing
A’s and B’s
Generally a test group is told “Do it All” or “You can’t do it all” in either case you need to determine which applications will be the players for your particular group to tests. If your management is of the “Do it All” mentality, then have them prioritize and make sure their expectations regarding the time necessary to test are realistic. If the reality is that time will not permit you to “do it all”, then within the application, identify the (A) areas – those that must be tested and the (B) areas – those that will be tested if time allows. Perhaps you need to validate the (A) area data through the GUI (Graphical User Interface), and if you have time, it would be good to also validate your (B) area data results against the database. Just be sure to have signoff from applications development and/or the business that this level of testing is acceptable. The “You can’t do it all” mentality works the same way, but on the application level. Have the business and/or applications development identify which are the (A) applications (applications that must follow the standard test process done by the QM group or (B) applications – (applications that can go directly to a user test after applications development does their own version of QM testing. By attempting to get the business/applications developers to determine what is critical and therefore requires the more rigorous testing effort, you enable your team to be effective and follow a process that makes their efforts more valuable.
To be continued…..
Heidi Kristoffersen 