Глава 6. ДЗ

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).


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

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

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

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

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

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

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 6. Заключение

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 6. Схема отчета

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

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

Схема:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 6. Дефекты_2

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Также надо регистрировать и невоспроизводимые ошибки.

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

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

Такие ошибки надо регистрировать, и не надо забывать о них. В качестве доказательства используем либо запись, либо скриншот, т.к. для заявления таких ошибок должно быть какое-либо доказательство.

Может быть множество различных ситуаций, и лучше понять причину ошибки. Если же не получается, всё равно невоспроизводимые баги мы регистрируем!

При формировании отчета по багу, лучше делать на каждую ошибку отдельный отчет.

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

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

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

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 6. Дефекты

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Количество не должно довлеть над качеством.

Поэтому сомнительные баги лучше несколько раз перепроверить. «Семь раз отмерь – один отрежь!».

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

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

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

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

Откладывать найденные дефекты в долгий ящик не надо!

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

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

Естественно, выяснив подробности, если не уверены. Не надо откладывать ошибки, потому что они очень быстро забываются.

Иногда Вы будете чувствовать, что Вы боитесь зарегистрировать ошибку.

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

На самом деле, это чувство губительно для тестировщика!

Если Вы ему поддадитесь, это будет означать Вашу профессиональную смерть.

Надо учитывать критику, но не боятся регистрировать новые ошибки.

В этом случае лучше переусердствовать, чем наоборот.

Также надо обращать внимание и на мелкие ошибки, минорные баги.

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

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

Не надо путать серьезность ошибки и приоритет ее исполнения. Это разные вещи. Ошибка может быть серьезной, но отложена к исполнению. Или наоборот ошибка может быть мелкой, но исправить ее надо срочно.

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 6. Отчеты об ошибках

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Глава № 6 – Отчеты об ошибках.

Как написать хороший отчёт и заслужить себе авторитет.

Эта глава посвящена отчетности об ошибках.

Отчетность - важная часть любой работы, в частности - тестировщика. Тестировщику зачастую необходимо отчитаться о проведенном тестировании продукта.

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

Если представить себе необработанный алмаз – он выглядит не очень привлекательно, по крайней мере, не впечатляет. А ограненный – становится настоящей драгоценностью.

Так и с работой.

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

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

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

Считается, что чем больше багов заявлено, тем лучше.

Этот подход не очень правильный.

Встречаются различные ситуации. Возможно, программа уже хорошо протестирована и отлажена, тогда в ней будет обнаружено мало ошибок, даже при большом объеме проделанной работы.

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

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

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 5. Автоматизация. Тезисы

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).


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

Автоматизация применяется: smoke-tests, модульное, нагрузочное, конфигурационное, комплексное, endurance – тестирование.

Когда целесообразно применять автоматизацию.

Стратегия автоматизации, требования к тестированию.

Автоматизация далеко не всегда хороша!

Минусы автоматизации на примере регрессионного тестирования.

Скорость, надёжность и масштабируемость как плюсы автоматизации.

Инструменты тестировщика.

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 5. Автоматизация. Инструменты

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Теперь я хочу сделать небольшой обзор рынка инструментов тестирования, которые широко используются в среде тестировщиков. Например, продукты IBM Rational.

Итак, Rational Robot – с его помощью проводим функциональное тестирование, которое выполняется на основе объектно-ориентированной технологии.

С помощью Robot тестируются свойства объектов, в том числе и скрытые. С его помощью мы можем протестировать логику работы приложения через пользовательский интерфейс (использование GUI – скриптов ), а также выполнить нагрузочное тестирование (VUvirtual users скрипты ).

Rational Functional Tester – название говорит само за себя.

Это средство автоматизации функционального тестирования.

Это пакет программ, который включает в себя и Rational Manual Tester – средство проведения ручного тестирования.

Functional Tester тестирует приложения на Java, а также с его помощью можно протестировать Web приложения. Тестовый сценарий также пишется на Java.

IBM Rational Perfomance Tester – средство функционального и нагрузочного тестирования.

С его помощью мы можем выявлять проблемы производительности еще до того, как мы выпустили продукт. До развёртывания мы можем эффективно оценить его производительность приложения.

Он предназначен для тестирования Web – приложений. Тесты представляют собой записи – как пользователь выполняет действия в браузере. Для пользования Perfomance Tester не требуется знание программирования. Достаточно простой и удобный в пользовании продукт.

IBM Rational XDE Tester – с его помощью тестируем Java-приложения и Web- сайты. В качестве языка тестовых сценариев опять же используем Java.

IBM Rational Purify Plus – пакет программ, включающий в себя: Purify, Pure Coverage, Quantify.

Rational Purify тестирует программу на наличие runtime – ошибок. С его помощью также можно отследить утечки памяти.

Purify тесно интегрируется с Pure Coverage.

C помощью Rational Pure Coverage мы находим те участки кода в программе, которые не были затронуты при тестировании. Т.е. программа отслеживает, что при тестировании проверяется в коде. Те участки, которые не были проверены, обнаруживаются.

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

Rational Test Manager – этот продукт помогает нам управлять тестированием в целом. Из одной графической оболочки мы управляем всем процессом тестирования. Можно писать тест-планы, все члены рабочей группы могут вносить в него сценарии. Все данные хранятся в унифицированном виде.

Последнее в списке, но не последнее по важности - Rational Clear Questбаг-треккинг система (система отслеживания ошибок).

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

На рынке также есть очень популярные продукты – от HP Mercury, Borland (Segue), AutomatedQA, Compuware.

Если подытожить, то по функциональному тестированию – существует WinRunner и Quick Test Professional от Mercury, Robot и Functional Tester от Rational, Silk Test от Segue, TestComplete от AutomatedQA, TestPartner от Compuware.

Для нагрузочного тестированияLoadRunner от Mercury, от Rational есть Robot и PerfomanceTester.

</div>

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 5. Автоматизация. Стратегия и советы

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Стратегия автоматизации.

Во-первых, надо определить требования к тестированию. А они в автоматизации таковы, что – надо:

1)автоматизировать проверку ключевых функций;

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

3)учесть опыт тестирования, т.к. различные программные продукты требуют различного уровня, опыта тестировщика. Если тестировщик создаст сложный скрипт автоматизации, то не факт, что менее опытный затем в нем сможет разобраться и его повторить, правильно проанализировать его результаты.

Советы:

- Не надо пытаться автоматизировать всё. Болезнь автоматизации присуща программистам. На самом деле, автоматизация далеко не всегда хороша!

- Автоматизация не заменяет ум, интеллект тестировщика. Она только помогает сделать тестирование более быстрым, надёжным и т.д. Но ум она никогда не заменит!

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

В регрессионном тестировании автоматизация находит лишь 15% ошибок от их общего количества.

В конфигурационном же тестировании с помощью автоматизации выявляют от 30 до 80 процентов ошибок.

Поэтому

- В конфигурационном тестировании крайне рекомендуется использовать автоматизацию.

- После обнаружения бага с помощью автоматизированных средств, обязательно проверьте его вручную!

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

У автоматизации есть довольно много минусов.

Особенно это показательно на регрессионном тестировании.

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

- При изменении компонентов в программе, ресурсов – тест будет выдавать ошибки.

- Если ошибка неверно определяется в автоматизированном скрипте, тогда она влечет за собой другие «ошибки», которые на самом деле ошибками не являются. Это может внести значительную сумятицу в процесс тестирования.

- Оператор теста должен обладать соответствующими знаниями: как использовать тест, как его конфигурировать, как его анализировать. Если оператора сменить, то результат автоматизации получится совсем другой.

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.

Глава 5. Автоматизация и инструменты тестирования.

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Глава № 5 – Автоматизация и инструменты тестирования.

Сделай свою работу более интеллектуальной!

Сэкономь время с автоматизацией!

Сегодня я расскажу в общих чертах об автоматизации. Упомяну некоторые продукты, которые существуют на рынке.

Что автоматизируют прежде всего?

Автоматизируют прежде всего smoke – тесты, о которых я уже много говорил, т.е. тесты, которые быстро проверяют основы функциональности программы.

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

Как понять, целесообразно ли использовать автоматизацию?

Надо посмотреть, сколько времени занимает создание автоматизированного скрипта, а сколько Вы тратите на ручное тестирование времени в сумме.

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

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

Также надо учесть опыт тестировщика.

Не каждый тестировщик знаком с автоматизацией.

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

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

В каких еще случаях полезна автоматизация?

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

Совершенно необходима автоматизация в нагрузочном тестировании.

Представьте, что Вам надо смоделировать одновременное подключение нескольких сотен пользователей. Скажем, 500 человек подключаются к серверу одновременно.

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

В конфигурационных тестах очень полезно применение автоматизации.

Когда мы выполняем тестирование на отдельной конфигурации, его можно сделать вручную. Бывают ситуации, когда надо масштабировать до 10 конфигураций: различные операционные системы, различная среда окружения, различные браузеры, различное аппаратное обеспечение. В этом случае проще сделать автоматизированный тест, привязать его к интерфейсу и запустить на разных конфигурациях. Тестирование будет проходить намного быстрее, проблем с ним будет меньше.

Тестирование в течение долгого времени (endurance test) – еще один кандидат на автоматизацию.

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

Вы можете приобрести книгу целиком и сразу в электронном виде (99руб) или сделать предзаказ бумажной книги (250руб).

Original published at Блог Тестировщика.
You can comment here or there.