Category: it

Category was added automatically. Read all entries about "it".

тестировщик

Настроение

Программисты выкатили большой пакет изменений в продукте, который давно не топтал. Аж прям соскучился.
Приятно пофигачить, не в режиме "у нас проблемы с процессом" или "надо подумать и запланировать", а просто Get over here!

Под такую примерно музыку, гг.


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

Сказка.

Вот тут дедушка Лупан рассказывает:
http://testitquickly.com/2014/02/03/ballada-despre-ebalani/

Люблю сказки и написал продолжение. Прочтите сперва балладу Алексея, она того стоит. И язык шибче.

Итак, сказ о Тестировщике из баллады дедушки Лупана.

А скорее не о нем даже, а о неком собирательном образе. Обезличенном. Все совпадения с миром реальным, не сказочным - остаются на совести человека, эти совпадения нашедшего..

Попал как-то тестировщик - еще в одну команду.
Опытных программистов в команде было не меньше половины. Светлы лицом, умны и добры были программисты, новому открыты, гитом пользовались, PMD и CPD уважали, непрерывную интеграцию одобряли. И были процессы. Процессы, которые не просто указатели на дороге, но сугубо рельсы стальные.

Проблема была только одна. 9 ошибок после релиза клиенты находили.

И воскликнул тестировщик - будет отныне тестирование перед релизом.Collapse )
тестировщик

Мысли

Приходится отвечать на до поры до времени гипотетический вопрос: какой язык выбрать для написания автотестов:
Python или java?

Аргументы за python:
- Мои программисты пишут на python - и в случае выбора этого языка готовы помочь
- Мой продукт написан на python
- Мне полезно изучить python
- У меня сложилось мнение, что python предпочтительней для небольших проектов и для скорости

Аргументы за java:
- Существующая инфраструктура тестирования (CI, selenium grid итпх) и ее автотестеры используют java.
- На java есть откуда копипастить куда обращаться за решениями по кодированию именно автотестов (пользуясь случаем, передаю привет)
- Я уже писал автотесты на java
- WebDriver первыми выпускает обновления для java и вообще лучше работает с этим языком (тут я могу и ошибаться)
- Лично мне больше нравится java (а тут я могу и передумать)

Аргументы отсортированы по весу, первыми - самые значимые. Стратегически правильным считаю выбор питона, так как программисты совместно со мной будут владеть кодом, помогать, в перспективе - самостоятельно чинить и даже писать тесты. В случае java они этого делать точно не будут.

В противовес: java может быть не пожеланием, а требованием инфраструктуры автотестирования. Создавать собственную, с серверами, гридом и прочим - глупо, долго, геморно. Я этим занимался, я знаю.

Мое слово - не последнее, но кино будет именно моим, хотелось бы запастись аргументами.
тестировщик

(no subject)

Создал тривиальную задачу программистам - поправить пару id элементов интерфейса, делов на пару часов, сломать ничего нельзя.

В течении дня получу 4 письма от JIRA о изменении полей таски:
1. Обратная связь аналитикам: Не нужна
2. Requirements review status: Не требуется
3. Проверять на dev-стенде: Нет
4. Нужен автотест: Отклонен

Контроль качества - такой контроль.
тестировщик

(no subject)

Вот тут okiseleva высказывает разные мысли, и цитирует некоторые книжки, мне очень понравилась мысль (насколько я понял, okiseleva не совсем согласна):

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

Я за концепцию, когда операционная система не задает глупых вопросов, но позволяет отменить (или не позволяет, играем на nightmare, хрен ли). Нажимая кнопку клавиатуры я подтверждаю, что согласен, ответственен и так далее. Ибо уже со мной что-то не так, если я топчу кнопки не думая или выполняю одни и те же действия тысячи раз.

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

Я не люблю

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

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

Изначально Я слышу эту фразу так: Я не потрудился рассказать вам об этом раньше

Изучать Я изучал python, я изучал рынок, я изучал линукс, я изучал продукт. А что ты делал? С умным видом ковырял конфиги? Как ты мог изучать язык программирования, не написав при этом ни строчки кода? Что ты, черт возьми делал? Я слышу эту фразу так: Два дня я внимательно смотрел на объект исследования

Я ничего не успеваю Слышу так: Я брался за все, я бегал и метался, но так ничего полезного и не сделал

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

Надо понимать Слышу так: Странно, вы не умеете читать мои мысли Надо объяснять!

В целом, в общем В зависимости от контекста Я не могу логически объяснить, как я пришел к этому выводу или Вы делаете все неправильно, так как не понимаете (см. выше) глобальной цели(тм)

Анализировать Это вообще волшебно - Я анализировал цифры и статистику, я проанализировал данные... Каждый раз, когда произносится эта фраза - результатов работы нет. Просто нет. Нет выводов, нет обязательного этапа, следующего за анализом - синтеза. Ах, нет. Есть, блядь, графики. На которые все смотрят с умным видом и не принимают никаких решений. Или принимают, но те, которые уже были до графиков. Я слышу это так: Я выгрузил все это в гуглдок, шесть раз отсортировал, сгруппировал, построил семь графиков. И изучил(см. выше) результат.

Анализ - одно из моих любимых слов. Странно, но почти все, кто его произносит, забывают о синтезе. Я даже расскажу историю.
Жила-была проблема. Например - сбои на n-м этапе техпроцесса.
И были приняты тяжелые меры, усилен накал борьбы, изменен процесс, переучены люди, сменены несколько интерфейсов и ряд регламентов. Вообще случилась масса субъективно полезных вещей, связанных не только с этими сбоями.
А затем человеку дали задание - посчитать, как изменилось количество сбоев по сравнению с предыдущими периодами (там, к сожалению, нужно считать руками).
Все правильно? Да, смарт, измеримый результат (еще б заранее определить целевой показатель, но и так сойдет).
Но есть нюанс и вместе с ним вопрос: зачем вообще нужна эта работа?
Вопрос был задан и на него получен резонный ответ: чтоб узнать, были бы меры эффективными, принесли ли результат.
Отлично, а что мы сделаем, если ответ - нет, не были, не принесли мы вернем все обратно?
Если ответом было бы да, то я сочту проделанную работу полезной.
Если бы мне ответили нет, то у нас получится анализ без синтеза, без принятия решения.

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

Lesson 293

Это последний урок последней главы книги Lessons Learned in Software Testing Сэма Канера и его товарищей.
22 августа 2011 года, 2 года и три недели назад я перевел первый урок.

С того дня я ни разу не менял место работы, сменил три квартиры, два телефона и двух провайдеров.
Через три недели после того дня появится первый тест в системе, которую мы создаем и сейчас. Принятые тогда неправильные решения разгребаем до сих пор.
Скорость перевода - два урока в неделю.
Из козырного кабинета, в который тогда переехала моя группа, нас не выгнали до сих пор.
Единственно верный способ оценки эффективности процесса тестирования (и не только тестирования) вспоминаю до сих пор.
Да мало ли чего еще напоисходило..

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

Дальше - возьму следующую книгу. Виттакера, может быть Копланда. А вообще Сэм, если я правильно понял, написал еще одну книгу, The Domain Testing Workbook, дождусь издания.

Максим cartmendum, пишу, как и обещал. Я добил последнюю страницу.

Слово Канеру

Относитесь к циклам тестирования как к сердцебиению процесса тестирования
Collapse )
тестировщик

Lesson 292

В минувшие выходные боец @Raspberries жгла. Результат примерно такой:
Альбом: Ingress


Подробности и фоточки.

И еще история про кота от Александра Селяева.

Слово Канеру

Создайте стратегию тестирования как ответ на особенности и риски проекта
Collapse )