Feeds:
Записи
Комментарии

Archive for the ‘Странности’ Category

Требуется QA с опытом работы в QA
Опыт может быт небольшой, но надо.

Реальный текст вакансии в коммьюнити /qa_israel/

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

Потребовался им тестировщик, а я кто — правильно, я тестировщик, и если вы все еще проводите интервью №1, тогда я иду к вам. Тем более, что мне их рекомендовали.

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

Cудьба!

(далее…)

Read Full Post »

Для самомнения вердикт «Can’t reproduce» не так страшен как «Not a bug«, но — тоже неприятно.

Официальщина:

«Не могу воспроизвести» означает только то, что работник, ответственный за починку дефекта, не смог его воспроизвести на билде, указанном в описании дефекта.

Почему не смог?

  1. Из-за разницы в конфигурации компьютеров

    В веб-отрасли это бывает реже, чем в десктопных приложениях. Но бывает. Но редко.

  2. В описании бага отсутствуют какие-то шаги или нюансы

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

  3. Дефект уже починен в более новом билде, а девелопер как раз и проверяет это дело на этот самом «обновленном»

    Это самое противное и требующее рассмотрения.

Третья причина является проблемой из-за того, что входит в противоречие с официальным толкованием статуса «Не могу воспроизвести»:

Дефект проверяется на билде, указанном в описании дефекта.

Дефект, зарегистрированный в версии 1.9, отложен и принят к
рассмотрению в версии 1.12. Высока вероятность того, что в 1.12 он уже
будет как-то починен? Если рассматривать ситуацию абстрактно, то
вероятность весьма, весьма, гм, вероятна.

А если так, то является ли преступлением против системы треканья багов проверить исторический баг на новом билде, и заявить, что «не могу воспроизвести»?

Не является.

Но проверять дефект на обновленном билде, как правило — на текущем — это потенциальная брешь и проблема. Предположим, не воспроизводится. А ну как он, зараза, снова всплывет? Мы точно знаем, почему этот гадёныш не воспроизводится?

Единственно верное решение:

Поставить билд 1.9, воспроизвести, понять, отчего это произошло, и убедиться в том, что в билде 1.12 эта проблема несомненно решена. Убеждаться — в коде.

И если дефект при проверке уже считается недействительным, нужно ставить ему статус «Fixed» с указанием билда, в котором баг считается починенным.

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

Вышеизложенное написано в поисках уточнения: баг, который не воспроизводится на обновленном билде — он все-таки «Fixed», или «Can’t reproduce»?

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

Read Full Post »

Неделя ушла на подготовку нагрузочного тестирования.

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

А сам тест-убийца занял ровно 15 минут. На уровне 200 threads сервер начал «задыхаться» уже через минуту. Затем отключился 😦

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

«Скоропостижно скончался сиг«…

Это из Шефнера…

Read Full Post »

Весьма рассудительная статья План тестирования на блоге «Про тестинг».

Для тех, кто только что присоединился

Тест план (Test Plan) — это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Резюме статьи краткое:

хороший тест план должен как минимум отвечать на следующие вопросы:

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

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

Но бывают дни, когда тестировщик остается один на один с приложением. И возня с документами для него критична по времени. Например, никому не нужна…

На этот случай есть вариант создания тест-плана без возни с документами. Иногда можно и без тест-кейсов обойтись…

Ну так, рецепт:

  1. Логически разделить приложение на отдельные, независимые друг от друга модули (да, принципиально это возможно).
  2. В каждом модуле перечислить доступные функции.
  3. Для каждой функции написать списки (в виде заголовков тест-кейсов, не более) вероятных проверок для каждой функции. Без спецификаций или подробных документов.
  4. Проверять каждый пункт последовательно.

В этом стиле лучше всего работать с приложением типа MindMap или FreeMind, если Linux. Но в принципе все это можно сделать и в простом Notepad или Excel приложении (второе на порядок удобнее, например, можно модули по страницам разбросать, а потом автоматизировать отчет о количестве уже проверенных пунктов и о результатах проверок). Но так или иначе, главное — чтобы был список.

Со списком можно уверенно и быстро работать, неимоверно рулят принципы GTD. Видно, что можно вычеркнуть, а что важно. Видно, сколько еще софта осталось непроверенным. Многое видно, короче.

Простой тест-план, он же чек-лист, готов.

Еще раз — этот вариант подходит для ситуаций, когда времени на составление документов нет. Или когда нет необходимости в составлении околотестировочных документов.

Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.

Важное дополнение: хороший тест-план отвечает на косвенно задаваемый вопрос «Почему?».

Пример: https://ru.scribd.com/document/39391857/TestPlanTemplateV1-0

 

Read Full Post »

Летом прошлого года в сети появился неизвестный человек по имени Aлeкceй Пaфнутoв. Он предложил всем желающим прослушать его курс по обучению тестированию.

Первая строчка главной страницы:

«Я убежден, что тестировщиком может стать каждый!»

Пафнутов Алексей

Дальше идет весьма грамотно составленный текст, который объясняет, мол, чувак, все в моих руках, но если хочешь — все будет в твоих руках!

(далее…)

Read Full Post »

« Newer Posts

%d такие блоггеры, как: