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