Получить профессию «Тестировщик программного обеспечения», ну или какую-нибудь похожую в ВУЗах-СУЗах на постсоветском пространстве пока не представляется возможным. Большинство из работающих в области тестирования специалистов — самоучки или, в лучшем случае, прошли курсы в какой-нибудь компании.
Большая часть из нас учится на собственном опыте либо перенимая опыт у полее опытных коллег-самоучек, сидя на форумах и профессиональных информацонных сайтах. Однако есть ещё и книги по тестированию, которые постепенно переводятся на русский язык и делаются доступными более широкому кругу специалистов.
Люди, имеющие за спиной 2-3 года опыта в области уже врядли станут тратить время на книги в духе «Основы тестирования ПО» или «Тестинг для чайников», однако и в них тоже есть много полезного. Помимо мнения зарубежных специалистов на те или иные вопросы, есть ещё полезные или просто интересные отрывки-цитаты.
Ниже я собственно и приведу несколько таких цитат из книги «Тестирование Программного Обеспечения» с небольшими собственными комментариями.
«Правильный подход к проверке научной теории заключается в поиске не подтверждающих, а опровергающих её фактов — попытке доказать, что в ней есть ошибки. И чем более тщательное тестирование выдерживает теория, тем больше у нас уверенности в том, что она верна»
О одной из хабровских статей по тематике тестирования прочитал «Тест, который никогда не упал — бесполезный тест» и далее в комментариях более корректную формулировку «Тест, который ни разу не падал, практическую ценность имеет небольшую». Исходя из книжной и статейных цитат, можно сказать, что писать тесты, которые лишь подтверждают корректность поведения того или иного функционала проигрышно по сравнению с написанием тестов, которые «роняют» Приложение. Что-ж выражение спорное, поскольку, на мой взгляд, абсолютно необходимы и те и другие, вопрос лишь в разумных пропорциях.
«Абсолютно любая ошибка сделанная намеренно может быть допущена и случайно»
Суть в том, что многие баги «зарубаются на корню» резолюциями типа «won't fix», «functioning as designed», «invalid», поскольку разработчики сичтают, что ситуация, описанная в баг реквесте трудно воспроизводима в реальных условиях, посему фиксить её не надо. Однако от того, что данный баг «тяжело» воспроизвести, он не перестаёт быть багом и потенциальной угрозой падения Приложения, поэтому надо довести это до сведения заинтересованных лиц и обосновать свою точку зрения — отсюда следующая цитата
«Хороший тестировщик не тот, кто выявит больше всего ошибок, и не тот, кто заставит смутиться даже самого первоклассного программиста. Лучшим является тот, кто добъётся исправления наибольшего количества ошибок.»
Это действительно так. Найти баг и описать его чаще всего не является самой сложной частью работы тестировщика. Куда сложнее — обосновать необходимость исправления данного бага, несмотря на его маловероятную воспроизводимость в реальных условиях.
«Профессионализ сотрудников группы тестирования заключается в том, чтобы принять реальность такой, как она есть, не жалуясь и не пытаясь бороться с ней запретами, и успешно закончить тестирование продукта вместе с внесёнными изменениями»
Среди моих знакомых тестировщиков есть очень большое число людей, которые вечно жалуются, что «нет спеки, макапа, инфы по фиче...», «сроки опять сдвинули...», «опять билд собрали на код фризе...», «заказчик-собака ещё одну фичу впихнул, а на носу поставка...» и т.п. Конечно всё это плохо, но задача тестировщика не в том, чтобы протестировать Продукт в идеальных условиях, а скорее наоборот, чтобы не смотря на отсутствие необходимой информации, наличие «помех», максимально (на сколько это возможно) протестировать Продукт.
«Судить о работе других — в этом суть тестирования»
У тестирования есть и довольно непростая психологическая составляющая. Профессиональный тестировщик никогда не напишет баг реквест, в котором явно или косвенно указывается на недоработку какого-либо разработчика. Задача — писать реквесты таким образом, чтобы абстрагироваться от личностей и описать баг Приложения, а не ошибку программиста — ведь никому не приятно, когда указывают на его ошибки.
И в заключение этой небольшой заметки хочу добавить, что тестеры должны осознавать, что их цель не «поломать Приложение», а наоборот " помочь сделать его лучше".
Think positive!
Большая часть из нас учится на собственном опыте либо перенимая опыт у полее опытных коллег-самоучек, сидя на форумах и профессиональных информацонных сайтах. Однако есть ещё и книги по тестированию, которые постепенно переводятся на русский язык и делаются доступными более широкому кругу специалистов.
Люди, имеющие за спиной 2-3 года опыта в области уже врядли станут тратить время на книги в духе «Основы тестирования ПО» или «Тестинг для чайников», однако и в них тоже есть много полезного. Помимо мнения зарубежных специалистов на те или иные вопросы, есть ещё полезные или просто интересные отрывки-цитаты.
Ниже я собственно и приведу несколько таких цитат из книги «Тестирование Программного Обеспечения» с небольшими собственными комментариями.
«Правильный подход к проверке научной теории заключается в поиске не подтверждающих, а опровергающих её фактов — попытке доказать, что в ней есть ошибки. И чем более тщательное тестирование выдерживает теория, тем больше у нас уверенности в том, что она верна»
О одной из хабровских статей по тематике тестирования прочитал «Тест, который никогда не упал — бесполезный тест» и далее в комментариях более корректную формулировку «Тест, который ни разу не падал, практическую ценность имеет небольшую». Исходя из книжной и статейных цитат, можно сказать, что писать тесты, которые лишь подтверждают корректность поведения того или иного функционала проигрышно по сравнению с написанием тестов, которые «роняют» Приложение. Что-ж выражение спорное, поскольку, на мой взгляд, абсолютно необходимы и те и другие, вопрос лишь в разумных пропорциях.
«Абсолютно любая ошибка сделанная намеренно может быть допущена и случайно»
Суть в том, что многие баги «зарубаются на корню» резолюциями типа «won't fix», «functioning as designed», «invalid», поскольку разработчики сичтают, что ситуация, описанная в баг реквесте трудно воспроизводима в реальных условиях, посему фиксить её не надо. Однако от того, что данный баг «тяжело» воспроизвести, он не перестаёт быть багом и потенциальной угрозой падения Приложения, поэтому надо довести это до сведения заинтересованных лиц и обосновать свою точку зрения — отсюда следующая цитата
«Хороший тестировщик не тот, кто выявит больше всего ошибок, и не тот, кто заставит смутиться даже самого первоклассного программиста. Лучшим является тот, кто добъётся исправления наибольшего количества ошибок.»
Это действительно так. Найти баг и описать его чаще всего не является самой сложной частью работы тестировщика. Куда сложнее — обосновать необходимость исправления данного бага, несмотря на его маловероятную воспроизводимость в реальных условиях.
«Профессионализ сотрудников группы тестирования заключается в том, чтобы принять реальность такой, как она есть, не жалуясь и не пытаясь бороться с ней запретами, и успешно закончить тестирование продукта вместе с внесёнными изменениями»
Среди моих знакомых тестировщиков есть очень большое число людей, которые вечно жалуются, что «нет спеки, макапа, инфы по фиче...», «сроки опять сдвинули...», «опять билд собрали на код фризе...», «заказчик-собака ещё одну фичу впихнул, а на носу поставка...» и т.п. Конечно всё это плохо, но задача тестировщика не в том, чтобы протестировать Продукт в идеальных условиях, а скорее наоборот, чтобы не смотря на отсутствие необходимой информации, наличие «помех», максимально (на сколько это возможно) протестировать Продукт.
«Судить о работе других — в этом суть тестирования»
У тестирования есть и довольно непростая психологическая составляющая. Профессиональный тестировщик никогда не напишет баг реквест, в котором явно или косвенно указывается на недоработку какого-либо разработчика. Задача — писать реквесты таким образом, чтобы абстрагироваться от личностей и описать баг Приложения, а не ошибку программиста — ведь никому не приятно, когда указывают на его ошибки.
И в заключение этой небольшой заметки хочу добавить, что тестеры должны осознавать, что их цель не «поломать Приложение», а наоборот " помочь сделать его лучше".
Think positive!