немасштабируемо

и бежит делать этот асап из чатика

в команде на 5 человек на лендинге прокатит.

ну, каждый занят своим делом

тестировщик <> находить баг и править

ок, тогда что именно тестировщик ==, по вашему?

что есть "тестирование"?

ага, а фикс тестировщиком в комманде из 15-ти разработчиков, и 20-ти тестировщиков - каждый правит кусочки и льет коммиты)

что такое качество и эффективность?

звучит куда правдоподобней)

ага, а фикс тестировщиком в комманде из 15-ти разработчиков, и 20-ти тестировщиков - каждый правит кусочки и льет коммиты)

А это где так?

и откуда взялась такая численность?

ага, а фикс тестировщиком в комманде из 15-ти разработчиков, и 20-ти тестировщиков - каждый правит кусочки и льет коммиты)

а что в этом не реального?

обычный проект, с таким количеством

что такое "обычный проект"?

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

если квалификации исполняющих роль тестировщик хватает для фиксов - что не так?

Привет)) 1. работаю в Глобал Лоджик Киев. 2. QA automation java, python. 3. Интересен опыт других людей. 4. Узнал о сообществе из фб. Всем добра?

да все не так

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

Можно подробней про вторую часть? Я такого не писал. Меня спросили про определение белого ящика. Не приписывайте мне того, что есть в вашем воображении.

даже если хватает, зачем он будет заниматься не своим делом?

почему не своим-то?

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

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

почему не своим-то?

в тестировании нет такого понятия как правка бага

даже если хватает, зачем он будет заниматься не своим делом?

почему не своим? цитирую скрамгайд Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment;

в тестировании нет такого понятия как правка бага

как же так?

в тестировании нет такого понятия как правка бага

А какое есть?

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

Думаю эт не царское дело фиксить баги qa?

Это значит, что тестер видит баг, лезет в код, правит, коммитит фикс и проводит верификацию. >> это не есть определения белого ящика, нигде в статьях такого не видел

Это значит, что тестер видит баг, лезет в код, правит, коммитит фикс и проводит верификацию. >> это не есть определения белого ящика, нигде в статьях такого не видел

А я и не говорил, что это официальное определение.

ну тогда не надо людей путать :-)

Дайте своё определение.

а то еще кто поверит в это опираясь на ваш огромный опыт и знания

белый ящик - тестирование ПО через исходный код

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

белый ящик - тестирование ПО через исходный код

Красиво. А алгоритм какой?

например, юнит (модульное) и интеграционное.

это к белому ящику

к серому ящику я незнаю какой тип тестирования надо применить

но в книгах пишут - тестирование исходного кода по методу чёрного ящика

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

а глоссарии istqb разве не так?

Согласно ISTQB: тестирование белого ящика – это: – тестирование, основанное на анализе внутренней структуры компонента или системы.

про интеграционное ничего не увидел.

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

Пожалуй, да. Возможно интеграционное может присутствовать.

анализирование структуры компонента, это разве не "копаться в исходном коде"?

ну я могу своими словами описать, как я это опнимаю. Черный ящик - когда ты для тестирования используешь разные данные не зная ничего о самом приложении, и пытаешься понять поведени. Серый ящик - это когда у тебя есть достаточно информации о продукте, есть майндмапы, доступ к БД, архитектура приложения, ты можешь посмотрить в инспекторе верстку, можешь продумывать тестирование и разные там техники и прочее базируясь на информации, которая есть без доступа к коду. А вот белый ящик - тебе дают досту к коду, ты уже тестируешь и разбираешься, что там и как, можешь залесть в код. Но ничего ты там не фиксишь. В моем опыте мне однажды дали доступ к коду CRM системе, потому что никто не знал как там перемещаются тикеты по состояниям и какие статусы применяют. Тогда мне дали достук к коду и я смог по коду разобрать и нарисовать схемку, как все там происходит

FYI: http://joxi.ru/823OZjwf6xYqE2.jpg

вот, значит тестировщику не нужно править баг

конечно не нужно

В теории - не нужно.

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

а те кто требует это малость упороты

Что, все по скраму работают? Добуквенно? или аджайл у вас тоже из коробки?

Я уже писал ,но мне не лень это повторить.

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

И при этом продукт выходит качественный.

а хотите гипотетический пример - когда фикс будут коммитить тестеры и это будет вайтбокс?

это издевательство будет

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

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

это издевательство будет

Над кем?

это издевательство будет

это реальность :)

Нет серебрянной пули, ну сколько раз повторять-то.

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

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

по-моему, фирма сыкономить решила на спецах

кстати, мы ж забыли про роль из книги "как тестируют в гугл"

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

по-моему, фирма сыкономить решила на спецах

вы так говорите, как-будто экономия это что-то плохое?

экономия - это стыдно

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

Ну, а типа, при других араскладах ошибки в прод попасть не могут?

Философия аджайла, о которой так много говорили, в том и заключается, что нет "правильно, неправильно". Есть "работает" и "не работает". И если это работает и всех устраивает, то это НОРМАЛЬНО.

могут

но их проще найти потом и найти края

есть тикет, есть коммит

>потому что два дня будут только коммиты разгребать, чтобы понять что кто сделал там без тикета.. У коммитов есть описания. Ваш Кэп.

а есть commit, но нет тикета

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

Окей, почему сразу без тикета? Тестер завел тикет и пошел в рамках него.

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

То есть кто-то это делает. Вы не в курсе, они рзвалились уже или нет?

нет им просто в голову пришла такая идея, до этого не делали никогда

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

> Я просто не могу понять, как вы о таком так серьезно пишите, с таким огромным опытом, Абсолютно серьёзно. И пишу я об этом потому что вижу ситуацию такую: 1. Здесь увидели нестандартный подход. 2. Вместо того чтобы подумать, примерить его на себя сразу стали отбрасывать. 3. С формулировкой "не по правилам, не работает". Правила должны помогать. Если правила мешают - правила надо менять.

такой подход мне нравится конечно)

я за

но фиксить баги - есть много но)

Возможно он утопичен, я не спорю. Но это не значит, что он не работает.

а есть компании, где оеально такое практикуется?

что вы скажите о командах без тестировщиков ака отдельный человек?

но фиксить баги - есть много но)

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

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

не нужны отдельные тестировщики.

Есть такое правило, что проверять код должен другой человек. Это одно из "правил" олимпиадного программирования

а есть компании, где оеально такое практикуется?

Да, я такое видел. Но там тестер это не на прод выливает, а на стейджинг. И перед мерджем это проходит код ревью у разработчика. И, да. есть тикет. Должность этого человека "software developer in test". Экономия времени большая. Разработчик просто ревьюит код тестера, не отвлекаясь от написания новых фич на правки.

тут иногда тестировщика сложно найти со зниниями верстки + sql

Мне за всё время моей работы sql не пригодился ни разу. я его не знаю.

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