Typical day conditions, which gets the beginner: A small organization that takes orders on the development of certain software and consists of a director and several programmers, each of which performs all the possible problems – from communication with the customer to the programming, debugging, implementation and technical support. From the documentation – only "political" TK to formally meet customer requirements, and contract.
With the development of the IT-market, even small by software organizations gradually feel the need to transition from natural to write code to a more or less formalized the development process. Primarily this is done to obtain predictable timing of delivery of projects, but they often come to the fore and the quality of the final product as a weighty factor in the competition. But quality can not be achieved without adequate testing.
The desire to write this article appeared quite a long time as a result of reading the head of the newly created department of the quality of the mass of literature on the testing of software and communication in online forums of quality. The main problem with all these sources of information – a very strong sciolism as presented in general, the basic things and a complete unwillingness to move from generalities to concrete examples, of which a novice can understand anything. As for tuition fees, programs of most courses (at least in this country) suggests that the listener works in the already prepared the organization with an established process for developing, and he needed only to provide the necessary knowledge and skills so that he could in the process as possible painless to join.
And what to do to someone who is just a great desire to improve their efficiency, reduce unnecessary time and expense, to organize the work of subordinates and his own, nor is there any idea where to start and what to begin? Just what I want to tell in this article as an example of some small organizations, many of which can be very close. I do not think the proposed solutions ideal, but they were good enough for my conditions, as did the testing process more efficient. The main goal – tell the tester where to start, push it in the right, in my opinion, direction.
So, today the typical conditions under which falls the beginner: A small organization that takes orders on the development of certain software and consists of a director and several programmers, each of which performs all the possible problems – from communication with the customer to the programming, debugging, implementation and technical support . From the documentation – only "political" TK to formally meet customer requirements, and contract.
If the project is more or less long, then over time the problem of correcting errors, taking into account user feedback and technical support engineers acquire such a scale that programmers often themselves, "bottom", initiated by an increase in the state to "a girl who will poke a button." Thus the organization appears Tester who can go two ways.
First – really "poke buttons. Naturally, when working in this way errors in the tester to quickly come to an end, and users – are what causes all to accuse him of incompetence (and what you would like to “poke buttons girls”???).
Bad besides the fact that at this stage, unfortunately, the special assistance and cooperation from anyone should not wait. Typically, communication with the surrounding looks like this: "On – Test" or "What mistakes? I have everything working. " Therefore, the second way – to organize work more efficiently.
At this stage the important thing to understand the basic purpose of testing.
Definitions in the literature are many, but I like most: "The main purpose of testing – make sure the system does what you need and does what is not needed." And, again, in simple terms, the main purpose tester – how you can develop a more comprehensive system of tests and, thus, do everything, what would the next time do not forget what he did, he found and how to fix this check found.
It is important to begin to understand and formalize your existing development process. You can assume that it is not, but objectively it is simply not good enough. Collect and examine all job descriptions, enterprise standards and other necessary documentation. It may well be that all of this and there – often in small organizations, the process occurs at the level of oral communication. The most harmful consequence of this – the lack of clearly defined responsibilities. The presence of job descriptions not only guarantee that can always be found responsible. During their development are surprisingly good omissions and logical gaps in the existing labor organization. Therefore spelling of the department of testing and job descriptions (even for positions where there is not) – the first necessary step. In the future, ideally, our goal – to get his department to communicate with the outside world only through the documents.
Hence, the first conclusions:
And, of course, be familiar with the theory. Do not be too lazy to allocate a week reading books and Internet forums devoted to testing, though after they left feeling full of emptiness in the head and a sense of inferiority, until you come to the conclusion that the theory should be applied, guided by common sense. You never get to implement RUP in an organization full of five programmers and three testers, so do not need and try to fully adapt to his theory, which uses a giant with many thousands of staff and a budget of billions.
Rational Unified Process – a platform IBM, presents an extensive set of methods for quality assurance at all stages of its development
Need to get out everything useful for you, ruthlessly discarding or simplifying what you think and reason, will only be time consuming. In principle, the whole sea of document types you can start to leave only four, and they simplify to the level of understanding in your organization:
Of all the sea of document types offered, such as RUP, can start to leave only four
At each assembly are all mentioned documents (except, of course, the test plan). As such, they have enough to at the end of the design stage to know that all the basic functionality of the system was tested, and to assert that the assembly is operational.
And here we go to storage and versioning. Strictly speaking, to start the approach is quite simple. Somewhere on the file server generates a shared resource, which creates folders for each project. Each such directory contains the following elements:
To begin with (and for later) such a structure would be enough to control the testing process. Preferably in a folder for each assembly to put the file with a list of requirements for this iteration.
Lists of requirements and registration errors
Requirements, unfortunately, the hardest – programmers do not like to deal with routine, especially in cases where it requires a significant intellectual strain. However, the requirements and needs to know what to test. Therefore, if they do not, the tester must make a list of requirements itself, at least in the form of Excel-plates. For this we have to communicate and to leadership, and with the programmers, and with the customer, and with his own common sense (in this case, again, referring back to the customer), but it is very useful, ultimately, work. By the way, and the development of test cases is very much dependent on the requirements that are checked and described in these tests.
Actually about the primary structure of all the documents, but these documents are not self-sufficient, they just describe what you want to check, but during the inspection found errors that need to process and track.
So at this stage it is time for the introduction of BTS.
Bug Tracking System – a system of registration and tracking the life cycle of defects
For a start it can be even Excel-file with customized AutoFilters, but, ideally, it is desirable to immediately determine the software, which will then be used for automated testing, bug tracking, requirements management, documentation, etc. There are a sufficient number of producers who make the whole specialized complexes. Knowing what area of IT organization operates, what databases and development environments in which we can choose the appropriate product. For example, if you want to use Rational, then as a system of registration and tracking is better to install Rational Clear Quest. And, initially as a working database is better to choose the Access connection to easily convert data from it into anything at the subsequent change management software.
Like any other writings, BTS, first met opposition from developers, but almost a week they can not work without it. Another additional advantage of these systems – formalization of communication between departments and the elimination of misunderstandings in matters of justice. Plus for managers – a way to objectively assess the skills and contribution to the cause of their employees.
Thus, for initial testing organization must perform, we can say the conditions of the three "F":
Actually, what is different and good manufacturing process from the bad – he had not started up to itself, but streamlined and manageable.