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

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

Джеймс Бах бабахнул по новому предлагаемому стандарту тестирования ISO 29119. Мол:

The ISO organization claims to have a new standard for software testing. But ISO 29119 is not a standard for testing. It cannot be a standard for testing.

И Сэм Канер (Кем Кэйнер) добавил того же:

If ISO 29119 is adopted and then broadly accepted as a legitimate description of good professional practice in software testing, then context-driven testing will be an example of something you should not do, a way of thinking you should avoid.

Development of ISO/IEC/IEEE 29119 began аж in May 2007.

ISO/IEC/IEEE 29119 parts 1, 2 and 3 became official International Standards in September 2013.

The convenor of ISO/IEC JTC1/SC7 WG26 is:

The co-editors of ISO/IEC/IEEE 29119 Software Testing and members of WG26 are:

+ ещё 78 неизвестных имён.

К сожалению, на http://www.softwaretestingstandard.org/ есть описание (сюжеты) каждой темы, но там нет текстов, которые можно читать и обсуждать. Там только Table of contents для каждой темы.

Где же взять текст-то? А прямо directly via ISO here – though you should note that to view the standard in its entirety, you will have to pay for a copy. Например, pdf с ISO/IEC/IEEE 29119-1:2013 «Software and systems engineering — Software testing — Part 1: Concepts and definitions» стоит $194.

Приплыли.

Read Full Post »

Знаю ли я Диму Пивоварова с Харькова?

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

о_О

В частности:

Проходили собеседование пару тестировщиков. Спрашиваю — что учили, что знаете про тестирование.

Ответ: «Я изучал тестирование полностью по блогу А. Лупана«

Гы 🙂

— А у Руколь, Баранцева бываете ? Читали? Курсы?

— А кто это?

— Э… Как же вы тогда изучали тестирование по блогу Алексея?

—  А чо я, там всякие ФИО смотреть должен? Я ж тестирование изучал )

А потом сообщил, что ты ему подарил свою футболку в которой был на тренинге Баранцева. Я вот очень сомневаюсь что ты ее подарил ему 15 июля, а потом забрал, и пришел 23-го на тренинг 😀

При этом он сказал что футболка была на него коротка. А рост у него  1,73… Ну, явно твоя майка была б ему по колено, примерно )

Тут меня окончательно пробило на «бугугугугагага!». Ведь если соврал про футболку, следовательно, соврал и про то, что учился.

В общем, должность парню не предложили.

Дима, пожалуйста, пришли мне по почте (наложенным платежом) свои глаза.

Хочется в них посмотреть 🙂

И иди — учись.

Реклама того, что в рекламе не нуждается

С 17 по 21 октября (c понедельника по пятницу) с 17-00 до 19-00 часов по Москве в рунете пройдет ConfeT&QA, онлайн-конференция нашего дорогого стоящего портала software-testing.ru.

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

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

Среди докладчиков будут известные и неизвестные российские и нероссийские специалисты по тестированию.

Я своему докладу для этой конференции уже сделал тестовый прогон под суровым присмотром ведущих автоматизаторов Киева, и готов его презентовать. Только думаю, что слайды юзать не придется, иначе не проявится особая, тестерская магия Selenium IDE. Оно бегает, шуршит, шурует и шурупит, наглядно и понятно. Будут Firefox, Eclipse, Excel и Selenium IDE.

Read Full Post »

На собеседованиях я всегда спрашиваю, в чем смысел тестирования.

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

Один из самых распространенных ответов таков:

«Тестирование повышает качество продукта».

Ну…

Вообще — нет, хотя… Да, с точки зрения рабоче-крестьянской логики, все именно так и происходит.

Я сам когда-то думал точно так же.

Я когда-то вообще думал только о том, как взять полууменьшенный минорный септаккорд от Ми, бо у Розенбаума оно получается, а у меня нет 🙂

Например, мое понимание смысела тестирования с годами ощутимо поменялось, и нынешнее свое понимание я совершенно не готов выбивать в мраморе на своем обелиске…

(далее…)

Read Full Post »

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

А речь идет о стонах.

Да, они — тонут и стонут. Они — это человеческие ресурсы, которых всем вам так не хватает.

(далее…)

Read Full Post »

В рабочей почте внезапно появилось такое сообщение:

CruiseControl Build Results for project TestEF (web page)

BUILD SUCCESSFUL
Project: TestEF
Running time: 00:13:03
Integration Request: Dashboard triggered a build (ForceBuild)
Last log entry: Minor changes.
Tests run: 0, Failures: 0, Not run: 0, Time: 0 seconds
No Tests Run
This project doesn’t have any tests

Read Full Post »

Искренне хотел бы рекомендовать целый ресурс о тестировании — iqa.com.ua, но пока можно рекомендовать только отдельные его записи, вроде «Валидация E-mail адреса. Читаем RFC«. И то, не столько запись, сколько комментарий автора к ней.

Странное соотношение — в записи автор изрядно скромнит, а раскрывается как следует только в комментировании.

Музыка: Тролль-ля-ля, тролль-ля-ля, оседлали мы коня…

Похоже, следует изложить тему подробнее.

(далее…)

Read Full Post »

Страшные, злые, недоброжелательные тестировщики с завышенными самомнениями сидят на своем страшном-страшном форуме, и страшно-страшно гнобят КАЖДОГО программиста, который к ним обращается с минутным делом — установить и протестировать на производительность и возможные ошибки одну программу…

Две эпические истории взаимонелюбви:

А вот настоящим программистам ничего не стоит помочь страждущим на форуме программистов. Они не только консультируют, исправляют код, пишут с нуля, но и ведут до конца разработку и заметьте, совершенно бесплатно. Заметили? Так заметьте!

Только у собак-тестеров всё вот так корыстно, ради денег…

Стыдно-то как!

Оне изволятъ рычать!

Оне изволятъ рычать!

Read Full Post »

Требуется 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 »

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