Risks in software testing
In the footsteps of training on dealing with risks in testing, I decided to disassemble the topic of risks in the testing to the simplest components, so for themselves and colleagues, this semi-mystical, polushamanskaya topic has become transparent and manageable.
So, firstly: the risks and problems are often lumped together. Risk, by definition, some existing or evolving factor of a process that has potentially negative impact on the process and, consequently, its result. You can, of course, to endure every challenge to the concept of risk, but why? On average, a typical training on risk management consists of only 20-25% of the material about the process of risk management and describe the typical risks, and the remaining 75% of the time coaches are trying to cram the guise of describing the risks of process concerns under sauce "and yet you can be here that … ". I repeat - why?
Risk - the existing or emerging factor in the process, which has a potentially negative impact on the process.
Simply put, to clearly delineate the risks and problems: the risk is something that can happen and lead to negative consequences, but the problem is something that has already happened and discourages work. And the risk and the problem may hinder or interfere with work, but ways of dealing with risks and challenges somewhat different: the first must try to understand, find, and if possible to minimize their consequences before they "shoot", and the problems we have to work in fact - to repair or "stew". Separating the risks and challenges of risk management becomes much simpler and easier.
A simple example that is not the risk associated with QA testing services, but often to those concerns is to use one environment for testers and developers. Uncomfortable situation, which generates or can generate a lot of problems, but it is the source of the problem, not risk.
Activity of cyclical risks, like any other project activity, if you work in iterations. Moreover, if the iteration you are long enough cycles of works related to risk management may be several such internal cycles can for simplicity be called "loops".
What usually causes difficulties in the initial stages of risk: the actual start (to make these activities in the work plans) to understand that dealing with risk is not rocket science and that such activity as any other must be planned, resourced (performers) have been fulfilled, and the results should be analyzed (that "shot" that - not with what we did successfully, etc.).
An interesting point: sometimes we can not do anything with risk, or our actions are not enough to eliminate risk from the list, but it happens. Systemic risks to a system and that all can not be excluded, as they often are a feature of the process in which we operate. Clearance of mines, the process is risky, but work to do. In this case, we try to insure themselves in case of fire from its consequences and to paint instructions in the event of hostilities.
I will not dwell in detail, but the stage of the analysis of the results and lessons learned are often ignored, which leads to a repetition of an unsuccessful outcome at the next iteration - that, actually, is characteristic of any process: if we do not analyze "to hit", the next shot hits again " somewhere to go … ", instead get" wherever necessary ".
Also, do not want to detract from the main subject of the article ideas about the proper goal-setting, but if the risk management plan will be written to "talk with the chief of PO lead tester" instead of "resolve the question of increasing PO lead tester at 20%, then the result of the Tasca such a plan would probably not "have increased by 20% CB", and "talked with the chief about the rise …."
What I would like to fix before we proceed to consider the typical risks associated with testing software. In order to properly handle risks and this work brings results, it is necessary to clearly understand to which level applies to a particular risk - the level of your responsibility as a manager of testing or to the level of project risks, which need to work on with the project manager and lead developer. Systemic risks or risk level of business in which you work, are usually beyond the zone of influence of the project team, but the project team can take part in the preparation of some decisions and analyzing the current situation, to provide decision makers timely and understandable information.
Typical risks in software testing
What is the project? Project from the perspective of the manager - this time, money and hepines customer. Project to test this same project, with the difference that money directly to the test manager manages the rare, but their resources in the form of man-hours in the money, you can convert or work with labor costs directly.
Incomplete evaluation of labor on the project
Frederick Brooks, in his famous book "The Mythical Man-Month," noted that this particular risk is often the main reason for failure to timely or completely failed project.
In general, the risk is, of course, refers to the level of project risk, and more precisely to the risks of project management. But, since the estimate labor costs for the project includes an assessment of labor costs for testing and the testing effort are on the critical path plan for the iteration, the risk is often linked to the misjudgment of labor costs for testing, which we will consider the following individual risk.
Risk is characterized by the fact that the testers are not involved in any labor costs to Review the project or to obtain estimates themselves. Situation in which the evaluation of testing just down the project manager, customer or someone else is often clinical and contrary to basic principles of project management: an assessment of the problem gives the executor, or executor may not take up the task and is not responsible for the result.
I repeat - the risk of the project level, when it comes to assessing the labor costs of the project, but some can be managed and minimized the QA team or its manager, by including testers in the process of getting estimates for labor costs and Review of the estimates and project plans.
Partly estimated labor costs for testing
Similar to the previous risk, based mainly on the violation of the principle of assessment of labor gives singer ", but at the level of project tasks for testing.
In addition to the basic causes of "shot" of this risk, also significantly risky factors may be missing implicit requirements, incorrect definition of the types of tests and configurations that will be tested - these problems are most affecting the amount of work on testing and as a consequence of mistakes made in carrying out these problems lead to a change in the scope of work on testing and significantly influence the test plan.
How to deal: reviews and audits, formal and "on the fly." At this point, one head is good, but two - better.
The situation can be generated or exacerbated by combining the roles of test manager and test designer. In the separation of these roles at various project team members tested, the test designer must justify and defend his proposed strategy for testing and evaluation of their labor. This protection often works better than formal reviews.
Test plan is not tied to the project plan
Strictly speaking, this is the problem of the testing process, which, meanwhile, is so widespread that I would recommend to focus attention on it as a serious risk.
Testing and development are sitting on one project resources - on time. If the plans of the two directions are not connected tightly (preferably at the level of a general plan of the project, just links of between tasks in MS Project or any other similar system) or are not synchronized on a regular basis, there is a likelihood or risk that the shift of development plans (which impact on the delivery date version in testing) will not be counted in the work plan for testing, leading to inadequate time for testing and, consequently, to pending testing phase.
Why plans for testing and development have yet to be firmly linked to the level of a single project plan: the area of ??responsibility the project manager for a fixed duration iteration among other things is the volume management (scope) iteration, for which he needs to see the testing effort. Roughly speaking, a time-limited task of iterating the PM and choose an amount of functionality that the team has time and make and test.
If the project manager to estimate labor costs for testing are not necessary (see "Clinic"), the task manager to test their work into the project plan and associate them with acc. targets for exploitation. In such a scheme to move the timing of testing is extremely difficult - some part of the testing effort will simply clear vylazit deadline for the plan or on the charts.
The testing strategy is absent or failing the development team or customer
Technically not a risk, but a problem which raises the risk that the testing strategy will fail in that part of the problems, where the overlap with the tasks of developing or will not be provided with resources (often the design time), and the result is still not completed.
How to deal: Formal Review strategy or test plan is usually not helpful. Formal apruv in this place, often means "I saw that you have a document with the name of strategy or plan and you have it updated in this iteration. In fact these are the words "well done, the main thing that you’re a good student" who do not give you as test manager, ability to obtain the necessary understanding of the development team and sootv.resursy to implement this strategy and your plans.
The risk of dismissal of key or not a key employee is always there.
The problem is not that people go, but that goes when you need them, instead of the project and to enter a new employee, train them and output to "project power" it takes time - resp. plans to subside, speed drops, all nervous.
What to do. Keep the "bench" is not always possible for economic reasons. "Feed the better" does not always help, and sometimes (in the case of a time with no key companions) is also simply not profitable. What can I do? The most obvious thing I see is "to negotiate with its neighbors - just to talk with neighboring departments, or projects (in which this risk also exists), and agree that in the event of such an event, they will be able to somehow (if it will allow product-specific and the current workload) to help you people. Similarly, be prepared to help themselves. Yes, the rescue of drowning - the handiwork of drowning.
Changing even documented requirements or priorities, often referred to as risks as to factors that affect the amount of iteration and acc. lead to a revision of plans and possibly disrupt delivery schedules version. I would not call this part of the design of risk - a reality that we must work with both design constraints and try not to even reach the status of the problem. Effective way is to just limit the volume of iterations in the dates of when any change in the requirements leads to the expulsion of some other piece of work (and real estate development and testing) in the next iteration. Forcibly or administrative "force" requirement is not changed yet, no one turned out - the business is changing, the requirements are changing and if the customer is willing to pay not only for natural changes in the requirements, but also for their "fantasy" or "disorganized" - it must accept and be able to live with it. Ways to eat and they work.
Difficulties in the group testing is associated with the testing is actually very little. Seen described as a particular risk of software implementation of the Product level "no GUI». On the fact of not being a risk, this feature of the project or product can be a significant limitation in the testing strategy and to impose stringent requirements on the qualifications of personnel involved in testing. I repeat - this is not a risk, it is a feature of your product or project. You do not complain that the interface is your product written in English as intended for the Western market, although in Russian, it might be easier to test.
In conclusion, I would like to focus on is fairly obvious, but ignored the risk that consists in the idea of ??ignoring the risks.
The risk of ignoring the risks
One of the risks, which applies to all levels of risk management.
Refusing to take into account the fact that there are risks that the process (even the most well-established, verified, formalized and controlled) can lead to inefficiencies, usually leads to overly optimistic plans to conflicts with their non-compliance, the need to reschedule a "fire mode" ( that usually leads to miscalculations, and more violates the normal rhythm of work) and as a result of failures.
What to do: to start working with the risks (however hackneyed and trite not sounded this conclusion, but there is no other recommendation). In testing the specific risks a bit. Most of the risks the project level, may be solved by joint efforts of the testing, development and project management.
Now, hopefully, it will be easier.
