мне кажется, что вполне вероятно, что именно вот это и хотел заказчик.

корпоративные люди должны страдать

большим корпорациям - заказной говнософт

увы, это в 99% случаев так

увы, это в 99% случаев так

работал в том самом 1% случаев, когда не так :)

а то сечйчас начнётся, давайте перегнём и сделаем форму красивой, а потом объясним заказчику,почему одна форма красивая, а остальные из 90-х, добавим работы себе, программистам, начальникам, да, почему бы и нет )

Оцените форму по 10 бальной шкале:

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

а еще очень много бордеров

Ок, спасибо

+10 баллова за то что вписываетесь по дизайну в 99% корпоративных приложений

+10 баллова за то что вписываетесь по дизайну в 99% корпоративных приложений

+1

как уже говорилось выше, сотрудники должны страдать?

ну есть корпоративное приложение, Слак называется

а еще Basecamp

Ок, спасибо

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

а еще Basecamp

Как я рад, что больше с этим говном не работаю.

:D

+1, но что поделать если нужно где-то иметь бизнесовый воркфлоу и обсуждения

можно постараться сделать это в Трелло

int blech (int j) { j = j -1; // should be j = j + 1 j = j / 30000; return j; } Какие 4 инпута помогут найти скрытые баги? принимает int J потом отнимает 1 и делит на 30000 и просто считает и выдает результат, при условии что мы считаем на 16 битной системе то минимальное значение моэет быть -32768 а макс 32767

тестовое задание дали ? )

нет, книгу читаю, в других чатах не ответили =) вот хочу у спецов спросить

да и свериться

как бы первые 2 окей, а вот бага 3 и 4 как-то сомневаюсь

какие первые два? ) про минимальное и максимальное значение?

угу

число меньшее 30к

по модулю

ибо у тебя тут int

и на выходе получится 0

граничные значения возьми будет тебе четыре

ну еще 0

т.е -32678 выдаст баг ? и -32679 ?

если верить книге то если взять меньше 30к к примеру 42 то ответ будет 0 и это не бага

такие задачи плоховаты

можно еще подать на вход число с точкой )

такие задачи плоховаты

стоит ли читать книгу которая дает плохие задачи?

если верить книге то если взять меньше 30к к примеру 42 то ответ будет 0 и это не бага

От языка зависит. Где-то результат деления всегда вещественный и такой код не скомпилируется

что за книга-то?

что за книга-то?

сикрет покачто =)) тут ее посоветовали вроде как

....не Савин? )

"A Practitioner's Guide to Software Test Design

не =)

ну вот интрига прошал

Lee Copland

?

http://robertvbinder.com/software-testability-part-3-white-box-complexity/

coopeland :D

вот тут как раз задчу обсуждают твою)

книга нормас, но сама задача нет

спасибо

у нас qa в команде саботируют автоматизацию

Вот и верь после этого в светлые намерения тестеров

а чем мотивируют?

что значит саботируют ?

у нас qa в команде саботируют автоматизацию

кек, сталкивался с таким явлением

у нас qa в команде саботируют автоматизацию

с доводами типа "это ж разбираться надо"?

у нас qa в команде саботируют автоматизацию

Главное не перепутай с разумными возражениями, автоматизация не серебряная пуля

На прошлой работе я был против автоматизации, а на этой стал за

автоматизировал процесс @ уволили твою подругу с бенефитами, с которой сидите рядом в офисе

На прошлой работе я был против автоматизации, а на этой стал за

почему ты был против?

кек, сталкивался с таким явлением

расскажи? что значит "саботируют"?

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

расскажи? что значит "саботируют"?

В моём случае- отказ от автоматизации как таковой, "нам это не нужно"

почему ты был против?

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

По факту я думаю людям просто было лень учиться чему то новому

ERROR: S client not available

Сейчас наоборот - нужно проверять определенные сценарии, желательно быстрее, изменения в UI небольшие, время на починку/переделку автотестов есть, спешки нет, а профит от автотестов заметный

что значит саботируют ?

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

звучит так, как буд-то им некогда, может это правда?

Ну такое уже не первый месяц просто

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

Но можно например по 100500 разу провалидировать вручную 50 тикетов и открыть 10 багов. А можно написать тесты и эти баги даже не будут доходить до qa

Значит задача ПМ - выделить время :)

во-во

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

Может сначала навести порядок в задачах? Выбить время на автоматизацию?

Интересно, а если не "делать бизнес" а заниматься автотестами - как быстро взвоет ПМ

А то пока она не заработала времени будет нехватать еще больше

Интересно, а если не "делать бизнес" а заниматься автотестами - как быстро взвоет ПМ

Ну в общем-то я так и делаю примерно

Да и потом тоже - поддерживать надо

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

Мне кажется ТС не учитывает несколько важных факторов. 1) Тесты требуется поддерживать 2) Автотесты могут быть настолько дороги, что не окупятся за несколько лет 3) Автоматизировать можно не всё

Мне кажется ТС не учитывает несколько важных факторов. 1) Тесты требуется поддерживать 2) Автотесты могут быть настолько дороги, что не окупятся за несколько лет 3) Автоматизировать можно не всё

Тестирование API - самое безобидное и быстрое, что можно начать делать

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

Мне кажется ТС не учитывает несколько важных факторов. 1) Тесты требуется поддерживать 2) Автотесты могут быть настолько дороги, что не окупятся за несколько лет 3) Автоматизировать можно не всё

Последние два пункта как минимум весьма спорные.

Мне кажется ТС не учитывает несколько важных факторов. 1) Тесты требуется поддерживать 2) Автотесты могут быть настолько дороги, что не окупятся за несколько лет 3) Автоматизировать можно не всё

Они дороги, потому что вы обучаете обезьяну или как?

Или они дороги, потому что вы пишете анрил энджин автоматизацию?

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

Лично считал. :)

Думаю проблема в том что для тех кто не привык писать тесты, их эффективность неочевидна и недоказуема

корочи :) я не знаю как вы считаете окупаемость и сложность, но явно там не всё учтено :)

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

Я не могу представить как тестировщику может быть лень подумать как накатать в Питоне 200 строк кода чтоб потом раз за разом не регрессить по одному долбанному методу апи, например

ну вы себе апи представляете а я UI

Я не могу представить как тестировщику может быть лень подумать как накатать в Питоне 200 строк кода чтоб потом раз за разом не регрессить по одному долбанному методу апи, например

Вот они занимаются именно этим. Раз за разом прокликивают странички. Правда у нас там структура данных очень сложная.

АПИ конечно же легко и быстро покрыть тестами

Да и с ui то же самое. Смоук тест на коленке

А UI космически сложно покрыть тестами, конечно.

представь себе страницу ютуба, покрой автотестом проигрывание видео