SALar

 

 

Вот полистайте навыки:

— Описывать тест-кейсы

— Описывать чек-листы

 

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

 

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

Или в гуглодоках — так может быть даже удобнее. Помните о том, что ваш комп может внезапно сдохнуть))) А в остальном тоже согласна, пока нет смысла вкладываться во что-то платное, сначала нужно задачи понять

 

Возможно, хорошим решением будет "office 365". Все таки гугл делать приложения не умеет. Здесь я с Эльдаром Мусаевым ( http://www.eldar.com/node/266 хороший был блог, жаль помер) полностью согласен. И цена вроде как не кусается. 

А вот redmine  несмотря на бесплатность будет очень дорогим решением. После знакомства с redmine  я понял, почему Ольга говорит, что jira и confluence хорошие продукты. Я то думал, что хуже джиры сделать сложно. Не. Можно, еще как можно.

Лучший для постановки мозгов как писать тесткейсы / чеклисты является книга Алистера Коберна https://www.ozon.ru/...ail/id/8747662/

Единственное но. Модель "CRUDL" нужно расширить до "CrClRUUsUtDeDaLO". Но этого вы уже нигде не найдете. Пока нет этого в печатном виде.

Рекс Блек "Ключевые процессы тестирования". Тяжелая книга, но одна из лучших именно по организации тестирования.

А для начала "тест гринкевича".

Некоторые образцы документации можно посмотреть в моем блоге: http://blog.shumoos.com/archives/267 и т.д. Документ устарел, но до сих пор крайне полезен. Есть там и другие примеры.

Поможем начинающим.

*. lessons learned in software testing, на русском Канера- отличная штука

*. "ключевые процессы тестирования" Рекс Блэк - тяжеловат для начинающих, но тем не менее

*. "Записки автоматизатора" Орлова - совершенно обязательно к прочтению

*. Алистер Коберн - все, что найдете

Блоги:

* Алексея Лупана

* Ольга Киселева очень неплохо пишет, 

* И самый крутой русскоязычный блог, та дам! Александр Александров http://www.luxoft-tr...eekend/32.html 

Из художественного:

* Цикл "Бета тестеры" http://www.lki.ru/to...&order=&page=3 

* Цикл "Байки для Оруженосца"

Савин, Савин. Ну почему не начать с Канера?

2cpmBugHunter Хороший ответ. Лайкну.

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

 

Может я и не прав. 

В шахматах считается, что нельзя стать гроссмейстером не проанализировав 100 000 позиций. Среди музыкантов считается, что нужно отыграть 10 000 часов.

На мой взгляд, тестировщик становится экспертом после 10 000 ошибок. Причем хотя бы половину нужно не завести самому, а проанализировать у других. 

Поэтому, крайне рекомендую книги "Наука отладки", "Записки автоматизатора". И читайте "Панбагон".

Найм, найм. Ну, давайте я буду нанимать только тех, кого вы отвергли. Через год мой отдел будет лучше вашего. Я полностью согласен с Демингом, что ключом является обучение сотрудников. А не "подбор персонала". И в последнее время я перестал читать резюме и проводить собеседования. Нефиг время тратить.

Про мотивацию. Вот не надо меня мотивировать. Совсем. 

http://cartmendum.li...com/111627.html  и  https://cartmendum.livejournal.com/115119.html

Насколько я знаю, а я интересуюсь этой темой очень много лет (больше дюжины) здешние курсы одни из лучших. Скорее, лучшие. Большинство тренеров я знаю лично. Как очень сильных тестировщиков. И как очень сильных преподавателей.

2Oldman1987. Вам действительно лучше составить карту развития и брать курсы здесь.

Если все тесты всегда завершаются успешно, то они просто не нужны. Деминг лет 50 назад это прекрасно показал. Ну и раз мы обсуждаем статьи конструктивно, то вот мой ответ: "Идеальный тестовый набор"

Я даю теорию вариаций на своих тренингах. Почти на всех. Считаю, что это абсолютно необходимо. И вариантов применения масса. Например, выбор объема тестов отлично описан ЕМНИП в 15 главе "Выхода из кризиса" доктора Деминга. И внимательное изучение этой главы совершенно необходимо для роста тестаналитика. 

Кстати, по "по тесткейсам бегать" тоже необходимо знание теорвера. Иначе вы регрессионное (выпускное) тестирование не организуете нормально. И здесь я бы рекомендовал книгу "Аудит" Лоббека. Но это кирпич. Я его год курил.

Впрочем, эта тема очень сложная и ее хорошо бы голосом обсудить за чаем. Как думаешь, Павел? Хорошая тема для Радио-QA?

-----------------------------------------------------

Немного офтопик. https://www.google.r...EiGgUey-a1RVZVP

Темы, которые относятся, скорее к инженерам, а не менеджерам я выделил жирным.

1. Для подавляющего большинства тервер был и остается «Игрой в бисер» не имеющей  никакого практического применения. Но величайшие менеджеры двадцатого века были специалистами, в первую очередь в тервере и строили свои модели управления на основе тервера.
2. Применение центральной предельной теоремы для планирования релизов.
3. Понятие общей и особой причин вариации. Эксперимент воронка и мишень.
4. Влияние вариаций на процесс разработки ПО. Несбалансированная и  сбалансированная производственные цепочки. Списки задач с избытком и с недостачей.
5. Общие и особые причины вариаций в процессе оценки трудоемкости. Эксперимент «Ошибка планирования». Влияние оценки трудоемкости на сроки проекта.
6. Карты Шухарта как средство для разделения общей и особой ошибок вариации и как средство построения «Соглашения об уровне сервиса».
7. Рекомендации по дальнейшему развитию.

Душевно.

В субботу обещают морозец.

Так что приглашаю тестировщиков Москвы на шашлыки в субботу 23 декабря. Ориентируемся на то, что начало будет в 12:00 и часа три посидим. Может какую-то тему разберем.

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

История. Первый раз мы (тестировщики Москвы) собрались на шашлыки в 2007 году. Много с тех пор изменилось. Можно будет понастальгировать.

Для того, чтобы занятость команды была «как на ладони», я рекомендую вводить списание затраченного времени на каждую задачу так, чтобы в конце дня сумма трудозатрат сложилась в рабочий день. Неважно, будет ли это строго 8 часов или какое-то произвольное время, принятое за продолжительность рабочего дня в вашей команде. Отчет по времени должен быть обязательным для каждого в команде, независимо от местоположения. Помимо достижения прозрачности ежедневной загрузки сотрудников вы сможете анализировать реальные трудозатраты по периодам/видам работ, что в итоге упростит планирование, а также позволит оптимизировать процессы.

 

Коллеги, внимание. Вот этого делать нельзя.

Тех, кто не понимает, почему это так, приглашаю поиграть в игру "сбалансированная производственная цепочка".

1. Dashboard - очевидное решение.

2. Поиграться с интеграцией с конфлюенсом и строить отчеты там.

3. А вообще, у jira отвратные фильтры. После трекстудии было очень некомфортно. поэтому, если захотите странного - напишите небольшую примочку, которая будет дергать API или на прямую дергать БД и стройте много всякого разного.

И если б БД джира была спроектирована с использованием темпоральной модели... Была бы сказка.  Но нет, программисты из Австралии не таковы.

Отличная статья

https://habrahabr.ru...u/blog/344132/ 

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

Как вы справляетесь с "безработицей" на работе? :)

Не надо справляться. Перефразируя Голдратта - если все сотрудники заняты на 100%, фирма терпит неоправданные финансовые убытки.

У тестировщиков должен быть запас по мощности (они обязаны простаивать). Иначе все плохо. Это не всегда так, но почти всегда так.

Добавьте:

* про возниктовение термина "Гуд инаф". И равновесие по паретто "время (упущенные деньги) - качество (потерянное деньги)".

* Влияние соцсетей на отношение к качеству. Про разорение фриланс.ру из-за одной, единственной неудачной фичи.