Agency QA: Script dependant testers need not apply...
Having worked in a fair share of digital agencies one is afforded the opportunity to experience the various types and degrees of process-driven test practices in place. Some of these are driven by upper and other senior management within the technical realm but not a part of the test team themselves, while other practices and processes are a result of in-house testing teams who have formulated their own methodologies.
Those who come from traditional testing backgrounds often look to apply a similar approach within an agency environment, bringing values applied in traditional corporate and software development environments to their testing within the agency world. Likewise, testers previously inexperienced in the field, who may come to the industry expecting the supportive framework that traditional testing environments often provide, will sometimes find themselves ill-prepared for the way in which the dynamics of the agency environment operate.
With no two agencies the same it would be an unreasonable assumption to expect there is a blanket approach that would represent a one-size-fits-all approach when it comes to performing testing within the agency environment. The significant varied approaches and levels of embracing 'being Agile' also represent their own challenges to a tester in an environment with some agencies being more representative of traditional web development houses all the way through to marketing agencies that have 'attached' on a digital division.
The risks though when dealing with testing in this environment means that the balance between insufficient and an excess of process (i.e. 'over process') is a critical one that should be crafted around available human and technical resources, project time lengths and time allocated for testing within these projects and any potential influences external to the testing team that will impact on delivery times.
As projects will vary frequently in scale and time available there is a necessity to be able to make judgement calls as to scaling one's approach based around these factors rather than attempting to apply the same practices from project to project. As such what I would cite as 'over documentation' or 'excessive process' is that which demonstrates little benefit to the objective of getting something as thoroughly tested as possible while meeting provided deadlines as a potential risk.
While a case can be made for traceability and maintainability of testing plans, such documentation tends to either become impractical, quickly invalidated or inappropriate for a significant portion of projects, only where larger scale projects running over a longer term exist does there then become a greater requirement for increased levels of documentation that can be used as a reference that can be used to demonstrate the areas of test coverage as well as a checklist for a tester to work against.
Keeping documentation in this more succinct form means that the tester is better able to respond to and deal with on-going client change requests. It also makes the documentation itself more maintainable as less time is lost on documentation and more time can be spent hands on performing the actual testing and re-testing.
Utilisation of web-based resources such as Wiki pages provides a means of having something that meets these requirements of being easily maintainable and is something that can be built upon / expanded on over time as well. This provides the benefits of offering something that is quickly accessible and can also be easily digested and referenced when performing testing on a project and can be used to store links to common tools as well as information such as baseline requirements common across projects or general notes / specifications specific to a particular project too.
A tester who spends an excessive amount of time preparing and updating documentation within this environment is often bound to then run short on time for performing the actual testing and re-testing required. This becomes particularly important when last minute client requests / change requests come in at the eleventh hour of a project due for delivery that were previously never documented or planned for and potentially throwing previous plans out the door. The tester then needs to be able to think on their feet and adapt their testing appropriately.
As documentation / requirements and information can often also be thin on the ground, this increases the requirement for the tester to be able to work out what is necessary to test as well as be a good communicator with those external to the testing team such as project managers, programmers and designers / creative staff. In addition to this an agency-based tester has to be aware of details that more likely evade those less familiar to the specifies of the agency world where appropriate capitalisation, pixel perfection, style guidelines and strict adherence to designs often holds great importance.
Therefore the agency sector is best suited to a pro-active, self-motivated and passionate tester who is well organised and is able to draw on their experiences and knowledge within testing and is able to abandon traditional testing methodologies yet use and adapt ideas drawn from traditional methodologies where appropriate when working in this field. It also rewards those who show ownership and commitment to the tasks they work on and are willing to go the extra mile when required to help ensure the expected deadlines are met.
For all its demands though it often provides a dynamic environment that can offer a challenge to those willing to accept it and allows people the opportunity to work on cutting edge projects often using / integrating some of the latest technologies on the market, while providing solutions for what is a very social area of the IT world. And sometimes you may even get to see things relating to projects you worked on covered in major newspapers or featured in advertisements on TV or the movies too.
A tester can make his/her life easier by using some basic scripting to automate repetitive tasks. Two examples of small scripts that I wrote with beginner's knowledge of a scripting language (Python, in this case)...
