Заключение

Что Вы узнали из этой книги?

В этой книге Вы познакомились с видами программного обеспечения, операционными системами, клиент-серверной технологией.

Вы узнали основы языка запросов SQL.

Вы поняли, что такое тестирование ПО, его цели и задачи.

Кроме того, Вы узнали и о практике тестирования, о его реалиях.

Я познакомил Вас с тестировщиком – кто он, как он думает, чем занимается.

Я рассказал о документации тестировщика.

Вы узнали о видах тестирования, его классификациях.

Вы прочли обзор инструментов тестирования.

Теперь Вы знаете и что такое автоматизация.

Я рассказал об отчетности, как важной составляющей работы тестировщика.

После прочтения этой книги Вы имеете начальное представление о сфере тестирования программного обеспечения. Теперь Вы можете решить – интересна Вам эта область или она не для Вас. А если же интересна – то Вы узнали основные вещи, необходимые для работы в тестировании.

Если Вы хотите узнать что-то еще о тестировании ПО, добро пожаловать на мой сайт: www.softwaretesting.ru , а также на мой блог: www.softwaretesting.ru/blog .

C вопросами и предложениями обращайтесь на support@softwaretesting.ru .

Тезисы к главе №6

- Написать хороший отчет - очень важно.

- Количество заявленных дефектов не должно превосходить их качество.

- Перепроверяем дефекты, прежде чем о них заявить.

- Если обнаружили ошибку – сразу же по ней отчет!

- Обращаем внимание на минорные баги.

- Регистрируем невоспроизводимые ошибки.

- Один баг – один отчет.

- Схема отчета.

- Задача тестировщика – найти и описать проблему.

Домашнее задание.

Описать любые три дефекта (можно взять из головы) для любой программы, который Вы пользуетесь повседневно.

Каждый из этих трех дефектов должен иметь свой тип: ошибка кодирования, предложение, расхождение с документацией.

По одному дефекту на каждый из этих типов.

Достаточно написать заголовок проблемы, ее описание, шаги воспроизведения и вывод.

Можно написать и предлагаемое исправление.

Если Вы хотите заработать себе дополнительный очки, авторитет, то можно писать предлагаемое исправление.

Если Вы понимаете, как это должно функционировать – написать кусок кода, то это неплохо. Но с этим надо быть аккуратным, смотреть, как это принято в Вашей компании. Если такое предложение будет воспринято негативно, то в будущем лучше воздерживаться от такого пункта описании. Если же будет похвала – естественно продолжаем в том же духе. Если промолчали – то все равно, это наверняка, кто-то видел, можно сказать – молчаливо одобрил.

Это можно практиковать, самому решать найденные проблемы.

Но приоритет в Вашей работе для этого должен быть самым низким.

Главное внимание уделяете тому, чтобы найти ошибки и их описать.

Претендовать на роль эксперта не нужно. Не стоит пытаться выглядеть крутым экспертом, который умеет и тестировать, и писать код лучше разработчиков. Смотреть свысока на программистов тоже не надо. Просто можно в качестве помощи предлагать Вашу точку зрения на исправление проблемы.

Прежде чем заявить ошибку, при возможности – скажите о ней программисту лично.

Если Вы не уверены, что это ошибка – Вы заодно выясните это. Может быть, Вы неправильно установили программу, не зарегистрировали какие-то библиотеки, эти сомнения Вам поможет развеять программист. Такое общение сэкономит Вам много времени, т.к. после заявления бага, пока он проходит по всем инстанциям, по всем участникам процесса – может пройти до нескольких суток. Это задержка времени, и если эта задержка времени необоснованна, если она произошла по Вашей вине – это не очень здорово. Поэтому если есть сомнения или хотя бы подозрения – лучше спросить программиста.

Естественно, по мелочам бегать и отвлекать не надо, но по серьезным вещам это допускается и даже поощряется.

Тестировщик использует в своей работе целую систему по отчетности и документированию ошибок.

Это система баг-треккинга – система отслеживания ошибок.

Очень удобная программа, которая осуществляет доступ к хранилищу информации о зарегистрированных дефектах.

С ее помощью всегда можно посмотреть зарегистрированные ошибки по программе, какие из них еще не исправлены. Можно посмотреть какие из ошибок исправлялись и сколько раз, чтобы учесть это при регрессионном тестировании.

Как должен выглядеть отчет?

Схема:

1) Заголовок.

Одним предложением, одной строкой пишем самое важное: специфика ошибки, ее пределы, ее влияние. Надо писать так, чтобы по заголовку можно было примерно понять, что это за ошибка, в какой области программы она содержится.

2) Реальный приоритет ошибки.

Не надо драматизировать обстановку, чтобы на Вас обратили внимание или, наоборот, скромничать, недооценивать ситуацию. Это приходит с опытом.

Обычно приоритет, серьезность ошибки делятся на 3 класса: 1) фатальные ошибки – критические, при которых программа просто падает, либо не работают важнейшие функции программы; 2) серьезные дефекты, когда некорректно работает, например, одна функция программы; 3) незначительные, минорные баги – недочеты, неточности, мелкие ошибки.

3) Описание ошибки.

Подробно, пошагово описываем ошибку – краткий и понятный список шагов, которые приводят к сбою.

Кстати, сбой – это не ошибка.

Сбой – это то, что мы видим, когда происходит ошибка. Ошибка – это причина сбоя, это то, что его вызвало. Например, ошибка кодирования - неправильно написан оператор в коде программы, в результате чего происходит сбой.

4) Результат.

Напишите, что произошло в результате выполнения шагов из предыдущего пункта, а также что Вы ожидали, что произойдет. Должен присутствовать в описании краткий вывод, краткий результат.

Решать проблему – не Ваша задача.

Вы тестировщик и Ваша задача – найти проблему и ее описать.

Решать проблему – хлеб программиста, если это ошибка кодирования, либо хлеб аналитика, технического писателя – если это ошибка в требованиях, инструкции.

Главное – найти ошибку и ее описать.