Давном давным (прошедшим жарким июлем) я вдоволь навыступался в тест-клубе Grammarly на тему того, как РЕЗКО и БЫСТРО и В ОДИНОЧКУ и БЕЗ ПОТЕРЬ можно/нужно обустроить тестирование, например, в стартапе.
Поскольку было лето и жарко и лениво, то и подготовка, и само мероприятие заняло достаточно много времени, да и обработка видео, как видим, тоже шла в мееееедленном режиме.
Ожидается, что слушатель хоть немного разбирается в условиях работы в agile, и вообще понимает, что такое agile, и что такое тестирование.
* * *
* * *
* * *
Ну, а теперь я хз, о чём ещё можно рассказать о тестировании в agile 🙂
Реклама
Обновил.
НравитсяНравится
Написал репорт, ждем-с.
НравитсяНравится
Видео недоступно. Обновите, пожалуйста..
НравитсяНравится
Сорри уж, микрофона на теле не было.
НравитсяНравится
А изначально разговор шел о том, что на собрании будет раскрываться тема тестировании в старпаперских условиях, поэтому весь акцент такой.
Да и лучше акцентироваться на чем-то и сказать всё, чем «Вообще бывает по-разному и по-всякому…», и в итоге не сосредоточиться ни на чем конкретном.
Внятные «спирали» я еще не видел. Водопад видел.
«Детальные спеки» — тоже редко видел. Даже в водопадах 🙂
НравитсяНравится
вопрос: а почему речь по сути о стартапном варианте внедрения процесса? я имею ввиду «а потом зовут тестировщика» и «нужен второй тестировщик», а не «у вас команда из 50 человек — прогеры и тестеры и тут решили делать быстрые релизы азаза» — ведь такая ситуация в реальном мире более сложна и интересна, а то все говорят про стартапы и никто — о сложных и серьёзных проектах, развивающихся годами.
пожелание: перестать употреблять термин waterfall. я за 10 лет в тестировании вотерфола не видел никогда. MSF — не водопад, RUP — условно, но если укоротить итерации и сделать регулярные сборки — не водопад, спираль — по сути не водопад, клинрум, рад — могут быть водопадами, а могут и не быть. Я подозреваю, что при разработке атомных станций водопад обязателен, ну или в подобных проектах, где ещё — хз уже лет… ну 8-10-12 точно.
и ответ на «о чём ещё можно рассказать о тестировании в agile»: о том, как избавиться от эджайла и вернуться к правильному подходу (например, компании эппл), а именно — пользователь дурак, мы ему сунем, что мы считаем нужным, решают бизнес-аналитики, маркетинг,делаются детальные спеки, а потом можно их дробить, как угодно, но эти ихнии юзер-сторисы и аналогичная ахинея (как справедливо было замечено, например, о самоорганизации) — это нужно вырубать топором. Ну или быть уверенным, что у тя в команде все — гении глобального масштаба, чего не бывает.
НравитсяНравится
«Реальные лессонсы в тестинге» дубль два 🙂
Я этой записью наши шумодавы протестирую 🙂
НравитсяНравится
«Если ты знаешь себя и знаешь своего врага, ты выиграешь сотни битв» © объяснялка самураю о необходимости постоянно смотреть на противника с открытыми глазами и не жмуриться при ударе 🙂
Однако установка «Только бы не проиграть» всегда вредна. Лучше подумай про «Сделать программистов союзниками». Можно спрашивать их мнение о том, что важно, и на что следует обратить пристальнейшее внимание. И записать, при них, сразу же.
Бублики для программистов не забудь.
НравитсяНравится
Спасибо. Вот как-то именно сейчас и именно мне шибко полезная штука. Есть с полдесятка непуганных программистов и мое ощущение, что мне сейчас — «не проиграть», а не «выиграть». Ну то есть не навредить.
НравитсяНравится
Особенно порадовало: «Тестировщика приглашают, когда проект начинает загибаться»…
Теперь я понял, почему вдруг ожил рынок, и всем вдруг понадобились тестировщики в Agile команды 🙂
НравитсяНравится
[…] Источник […]
НравитсяНравится