Software Testing: How to start

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 Software testing company process more efficient. The main goal - tell the tester where to start, push it in the right, in my opinion, direction.

Motives for the appearance of the tester

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 Software QA Services - 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.

When nothing yet …

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:

·         terms of their responsibilities in the organization need to specify (often, incidentally, means "narrow") and secure;

·         testing needed, but oral histories developers have documented the system requirements (in simple terms the requirements, a list of what the system must do and how to comply with conditions). The more elaborated list of requirements, the easier it is to test the system;

·         found defects must somehow register in such a way so you can keep track of their life cycle;

·         test results must be stored somewhere in a convenient form of search and analysis;

·         In no case does not begin immediately with test automation. It is on that and "Automation" to automate the existing and established process, and if you start right away with her, nothing but the huge financial and time losses, will not work.

They have and what we do …

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:

·         test plan document containing brief information about the system, the forces and means by which it is supposed to test what is supposed to test (up to the list, or even a description of tests), about plans for the timing, criteria for the testing and recognition of the successful release, the risks and Other information that may affect the testing process. In literature and on the Internet there are lots of pieces of test plans from which to draw for himself the desired template. There are two approaches to writing the test plan - static and dynamic. Static - when the test plan is written once during the development of testing strategies, and contains only immutable data. And dynamic - when the test plan contains more details and tests, which in the course of software development are corrected and supplemented. Frankly, I do not understand why doing this if any changes can be made in the related test plan documents, which allows a better structuring and tracking versioning, but - a matter of taste. I take the first approach.

·         test case - a document describing a specific test. Its specification should not be excessive - after all, alleged in the article working conditions you will not get to it neither the strength nor the time. The main requirement for the test case - a description of testing and expected results of a well-defined independent of the functionality (or properties) software, which must be unequivocally clear, and you and your subordinates, if any. The beauty of these test cases is that they can then be structured as you want, making a set of tables of control (with test automation is to be set);

·         Table Control (Check-list, he’s Suite - a set) - actually, in the previous paragraph I wrote about them. This spreadsheet document, combining (via hyperlinks) set of test cases with notes on the outcome of their performance and notes.

·         test report - the result document that contains a link to a table control and the findings about the health of release signed by the tester and project manager.

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:

·         file with the test plan;

·         template file test report;

·         directory TestCase with a set of test cases for this project;

·         Catalog Builds, which are stored in separate folders exhaust test cases for this build (almost a copy of the directory TestCase, the documents from being used as a template) and a test report.

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.

Three conditions for a successful start

Thus, for initial testing organization must perform, we can say the conditions of the three "F":

·         formalization of responsibilities - a writing job descriptions and position of department;

·         formalization of communication with the programmers - the introduction of BTS;

·         formalization of the testers - creating test cases, scheduling, and account for testing.

Actually, what is different and good manufacturing process from the bad - he had not started up to itself, but streamlined and manageable.