Being able to walk though testing requires that you know what steps to take and why you are taking them.
To get clarity ask questions, and then ask questions, and continue to ask questions until both you and everybody else has reached clarity and is in complete agreement and understanding of what needs to happen and when it needs to happen. Let’s not forget the “how”. Remember there is no stupid question! Except, possibly, a question not asked. That missing question can have potential fatal outcome…..
The Who?
Determining the right resources required for testing is always difficult, but when you determine what will be tested, that decision becomes easier. For now I am going to stay with “resource” and come back to the “what” later
The correct composition of a test team is extremely important and not to be taken lightly. Ideally, a team should possess a mix of various testing disciplines, functions, knowledge, and skills. Besides specific test expertise, knowledge of the subject matter to be tested, a good knowledge of the organisation, and some general IT knowledge is required.
And not to forget good proactive social skills in combo with positive and a “can do” attitude is equally important (it is not a good idea to have too many of the Sheldon Cooper type on the team). In order to acquire this mix, training is often needed.
The challenge that I had in building the Test Factory was the mere size of the program being executed. It required that I would have to go and hire a substantial amount of resources. Initially I had 25 resources (Test Managers and testers) and over a 12 month period this grew to 30 Test Managers and 100 testers….
Managing 25 programs with 115 projects and 130 resources required smart thinking. I could not afford to under estimate the contributions of skilled testers. This is what would become the core element of a smoothly running test process. A test team only consisting of users or developers would not be enough and would reduce the chances of realising a good quality test process.
Next to skilled testers, it is equivalently important to arrange support and management of the test process:
• Methodical support means help in defining the test strategy.
• Technical support is necessary to organise and operate the infrastructure.
• Functional support helps to answer functional questions that arise during testing.
For these latter forms of support in particular, parties outside the test process are needed, so it is important to coordinate the effort well and in time. Lack of support can cause devastating delay in the test process.
Once we had determined the testing resources to be involved the next step was to identify any other related resources necessary to support the test effort. This included applications development as well as other infrastructure groups. In our organisation, the applications development group coordinates with the infrastructure groups, but we found we didn’t always know who to speak to in applications development; we needed a SME as a point of contact. The SME, a.k.a. Subject Matter Expert, is the key contact person for the project and can either be someone from the business or the applications development group.
They coordinate with our team and serve as the knowledge base for the application being tested. By implementing this simple process of identification we saved a lot of time when questions or issues surfaced.
The What?
Identify what will be tested and then begin assembling your essential pieces to the test process. For us this included beginning the application assessment form, creating a master test plan, identifying test scenarios and determining if the test effort would be manual or automated. This is where you’re actually getting ready to test!
The Where?
Unfortunately this usually doesn’t mean that you can take off for the beach to begin that test effort, but you do need to make sure your test environment needs are being addressed. Ideally you should have a separate database environment (essential if you are automating your tests) and a pristine desktop environment that mimics the business user’s desktop. Because budget issues prevented our group from having its own lab, we required that applications development provide either a QA or UAT database environment dedicated to us during our test effort. We managed to maintain multiple business user desktop types by implementing imaging software. This eliminated the need for multiple test workstations
When?
Begin your test effort as early in the project life cycle as possible. Sit in on design meetings, review documentation, talk to users and request demos or access to prototypes. The earlier you begin the more efficient your actual testing will be. We were able to have a pre-release application walkthrough, which gave us early access to an application, perhaps before all the business logic was complete, and we used it for creating our master test plan and test scenarios. We did not consider it an actual test and we did not report defects, but it saved time when we began the test effort. We were able to become aquatinted with the application and able to complete a draft of the test plan and scenarios we would use for testing. Make sure to be clear on when the official turnover of an application will occur and when actual testing will be scheduled to begin.
Why?
This is the reason for your existence so you need to be clear on the risks of not testing. Work with the business to identify how they will be affected if an application doesn’t perform as expected. Don’t be afraid to make recommendations. The worst that can happen is they ignore the risk. Just make sure YOU don’t ignore the risk. Encourage a User Acceptance Test, and if resources permit, help define the UAT tests that will be conducted. Be an advocate of the business user as well as applications development in delivering a quality product.
To be continued….
Heidi Kristoffersen 