Р. Савин Тестирование дот ком
Если коротко - не понравилось.
С самого начала не понравилось, что "читать про тестирование не надо". Ага. Тестировать - как писать рассказы/романы. Зачем этому учиться?
Собственно, как показалось, вся книга - не про то, как стать хорошим тестером, а как крутиться так, чтоб не получить по башке.
Не понравилось формирование образа "кругом - враги", "кругом - лентяи". Почему программеры делают ошибки? Потому что ленивые тупые сволочи, которые сутками сидят в ю-тюбе. Всю переписку сохранять, письма писать не для того, чтобы получить ответ - а чтобы сохранилось свидетельство, что вопрос был. И так далее, и тому подобное.
Ага. Как-то мне ближе "все в одной команде" и "надо подстраиваться под каждого программера" - по возможности, разумеется.
Осталось ощущение, что сам автор тестером не работал. Или у нас был кардинально разный опыт работы.
Не понравился стиль. Показалось, что стиль "простецкого чувака" вымучен, причем с большими мучениями. К чему посреди книги рассказ, "иллюстрирующий" что есть бранчи, не понял. Наверное, для занимательности. Иллюстрации - из той же оперы. Ну, тут, может быть, чисто мое субъективное мнение - "не зашло". Там, где автор забывал, что должен рассказывать "легко и непринужденно", читалось хорошо. Но он, к сожалению, редко забывал.
Не понял, на кого рассчитана книга.
Некоторые простые вещи разжеваны до невозможности - а некоторые, и более нужные, просто названы.
Вроде как для старт-апов, а подразумевается, что спеки есть всегда. Ага. Конечно. Именно в старт-апах. И полная структура компании, да. И с вопросами всегда бегать к тем, кто спеки писал. Ну да, ну да. Нет, это, конечно, правильно, но жизнь, она такая разная...
Противоречия водятся.
Для начала итерации спеки должны быть заморожены - но если очень надо - можно добавить запрос на изменение. И, наверное, не один. Это и называется - заморожена, да.
Тест-кейс должен быть конкретным, с прописанными данными на входе-выходе, иначе это плохой тест-кейс. Тест-кейс должен быть общим, иначе трудно будет поддерживать. Так каким должен быть тест-кейс? А вот как-то так.
Нельзя оценивать работу тестировщика по числу найденных багов - зато эффективность автотестирования именно так и оценивается. Сэкономленное время - так, сбоку.
Системное тестирование - термин, конечно, сложный. Но мнение Майерса, что это тестирование на уровне концепта - мне ближе, чем "это то же интеграционное, просто все и по порядку".
Как писать тест-кейсы - строго говоря, так и не написано. Просто "нагенерить" тестов, и отобрать нужные. Все. А как обеспечить покрытие? Как самому быть уверенным, что минимальным набором проверил все самое важное? Чуйкой. Помянуты классы эквивалентности - но только в двух словах. Хотя это, по идее, едва ли не основное. Зато статусы багов в баг-трекинг системе расписаны подробно и с примерами.
С другой стороны, объясняется, что такое системы баг-трэкинга и зачем они нужны. Циклы работы над программой - более-менее. В общем организация работы.
Но вот конкретно по тестированию... Ну, на вкус и цвет.
С самого начала не понравилось, что "читать про тестирование не надо". Ага. Тестировать - как писать рассказы/романы. Зачем этому учиться?
Собственно, как показалось, вся книга - не про то, как стать хорошим тестером, а как крутиться так, чтоб не получить по башке.
Не понравилось формирование образа "кругом - враги", "кругом - лентяи". Почему программеры делают ошибки? Потому что ленивые тупые сволочи, которые сутками сидят в ю-тюбе. Всю переписку сохранять, письма писать не для того, чтобы получить ответ - а чтобы сохранилось свидетельство, что вопрос был. И так далее, и тому подобное.
Ага. Как-то мне ближе "все в одной команде" и "надо подстраиваться под каждого программера" - по возможности, разумеется.
Осталось ощущение, что сам автор тестером не работал. Или у нас был кардинально разный опыт работы.
Не понравился стиль. Показалось, что стиль "простецкого чувака" вымучен, причем с большими мучениями. К чему посреди книги рассказ, "иллюстрирующий" что есть бранчи, не понял. Наверное, для занимательности. Иллюстрации - из той же оперы. Ну, тут, может быть, чисто мое субъективное мнение - "не зашло". Там, где автор забывал, что должен рассказывать "легко и непринужденно", читалось хорошо. Но он, к сожалению, редко забывал.
Не понял, на кого рассчитана книга.
Некоторые простые вещи разжеваны до невозможности - а некоторые, и более нужные, просто названы.
Вроде как для старт-апов, а подразумевается, что спеки есть всегда. Ага. Конечно. Именно в старт-апах. И полная структура компании, да. И с вопросами всегда бегать к тем, кто спеки писал. Ну да, ну да. Нет, это, конечно, правильно, но жизнь, она такая разная...
Противоречия водятся.
Для начала итерации спеки должны быть заморожены - но если очень надо - можно добавить запрос на изменение. И, наверное, не один. Это и называется - заморожена, да.
Тест-кейс должен быть конкретным, с прописанными данными на входе-выходе, иначе это плохой тест-кейс. Тест-кейс должен быть общим, иначе трудно будет поддерживать. Так каким должен быть тест-кейс? А вот как-то так.
Нельзя оценивать работу тестировщика по числу найденных багов - зато эффективность автотестирования именно так и оценивается. Сэкономленное время - так, сбоку.
Системное тестирование - термин, конечно, сложный. Но мнение Майерса, что это тестирование на уровне концепта - мне ближе, чем "это то же интеграционное, просто все и по порядку".
Как писать тест-кейсы - строго говоря, так и не написано. Просто "нагенерить" тестов, и отобрать нужные. Все. А как обеспечить покрытие? Как самому быть уверенным, что минимальным набором проверил все самое важное? Чуйкой. Помянуты классы эквивалентности - но только в двух словах. Хотя это, по идее, едва ли не основное. Зато статусы багов в баг-трекинг системе расписаны подробно и с примерами.
С другой стороны, объясняется, что такое системы баг-трэкинга и зачем они нужны. Циклы работы над программой - более-менее. В общем организация работы.
Но вот конкретно по тестированию... Ну, на вкус и цвет.