=== Важны не любые знания, а те которые нужны на данном конкретном проекте.
===
С этим трудно поспорить :)
=== Если у меня будет свободное время на обучение — я сяду и буду читать про тестирование безопасности, тестирование локализации, но никак не про то как работает билд сервер.
===
А вот теперь понятно, почему возникли разногласия. Я более склонен к изучению предмета на практике и скорее разберусь в каких-нибудь технических подробностях своего продукта. Возможно появятся мысли о новых тестах или подходах. При изучении теории у меня такие мысли появляются намного реже.
А изучать же теорию по тестированию того, что мне тестировать не нужно я точно не буду вообще. Ну разве что на встрече нашего сообщества тестировщиков кто-нибудь будет рассказывать :)
«Ручной» тестировщик, который понимает как работает билд процедура, который сам может построить билд хуже другого «ручного», который этого не умеет? Не думаю, что вы так думаете.
Посмотрите на первое правило из статьи — про автоматзацию не тестирования. Абсолютно верно. Многие под автоматизацией понимают исключительно некий скрипт/тул, который умеет кликать, быстрее и тупее, чем самый быстрый и тупой кликер. Но это ведь не так.
Можно автоматизировать создание тестовых данных, сравнение логов, анализ результатов, да и еще кучу чего. При этом выполняя само тестирование руками.
В нашей профессии, чем больше знает и умеет человек — тем это более ценно.
Программист может годами писать код, пользуясь одним языком и одним фреймфорком, меняя конторы, и накапливая опыт и оттачивая свое умение. Тестировщик же должен быть всегда готов к новым тестам, т.к. если тестировщик годами тестирует одно и тоже он не развивается, а деградирует.
Я уверен, что человеку с 5-ти летним опытом уже есть, что рассказать. Судя по тому, как построена ваша статья — вы умеете подавать материал. А выступить и рассказать людям о своем опыте — это будет и слушателям интересно и весьма полезно самому. Я каждый раз много нового узнаю, при подготовке доклада.
Хорошая статья, все по делу. И написана хорошо. Честно говоря первая за последнее время длинная статья про тестирование, что я прочел.
Не думали о том, чтобы выступить на конференции SQA Days? Следующая будет осенью, дата пока официально не объявлена.
Да, возможно я смотрю с другой точки зрения и она подкреплена такими фактами:
1) В большинстве случаев одного лишь программирования недостаточно для разработки продукта, которым будет пользоваться конечный пользователь. И я не говорю, что тут обязано тестирование участвовать, вовсе нет, хотя, конечно, желательно.
2) Во многих западных компаниях (средних и крупных), все кто создает ПО обычно сосредоточены под названием R&D (Research&Development) или Product Development, куда включают и программистов и тестеров и писателей и много кого еще. (Development=разработка)
3) В совьет-стайл предприятиях (мне довелость поработать на ЛОМО) быть программистом — значит быть кодером. Программисты там (это должность, записанная в трудовой) пишут код по уже предоставленным и разработанным спецификациям. В рамках заданной архитектуры. От себя ничего не придумывают. И хотя их работа несомненно важна, но продукт, на самом деле, разработан людьми, писавшими требования.
Если отбросить тот факт, что английский нужен любому, кто занят в ИТ, то применительно к тестированию: много инструментов, описаний, хороших практик, да и нормальных книг существуют только в английском варианте. Чтобы человеку, занятому в тестировании, расти надо хотя бы свободно читать на английском — факт. Даже если кто-то работает в абсолютно российской конторе и имеет дело только с русскоязычным документооборотом.
Удивительно. Понятие «селедка» шире чем понятие «рыба» — если перефразировать ваше предложение.
По мне так программист — это разработчик. Тестировщик — тоже разработчик. И аналитик, и архитектор и релиз инженер.
Феликс, я использую и использовать буду. Ибо это калька с английского и ничего в ней нет плохого. И букв там меньше :)
Это все-равно, что говорить — «е-мэйл — это неправильно, а правильно электронная почта». Ну да, а все-равно говорим е-мэйл. И все главное понимают.
Не нужно никакой логики на сервере. Т.е. вообще серверная часть сводится к запуску httpd
Пример (у нас так документация устроена): документы (XML) лежат под системой контроля версий. И XSL документы лежат тоже там. Нужно добавить новый документ — берешь шаблон (ссылки на XSL файлы в нем есть), забиваешь данными и кидаешь под версионинг. При просмотре через веб (либо локально по файловым урл-ам) открывается не XML, а его преобразованый в HTML вид. С другой стороны, эти же самые данные могут поступать на вход компьютеризированной системы. Соотвественно: теже файлы по тем же урл-ам скачиваются как просто XML-документы, но никуда не преобразуются, а обрабатываются скриптами.
Важны не любые знания, а те которые нужны на данном конкретном проекте.
===
С этим трудно поспорить :)
===
Если у меня будет свободное время на обучение — я сяду и буду читать про тестирование безопасности, тестирование локализации, но никак не про то как работает билд сервер.
===
А вот теперь понятно, почему возникли разногласия. Я более склонен к изучению предмета на практике и скорее разберусь в каких-нибудь технических подробностях своего продукта. Возможно появятся мысли о новых тестах или подходах. При изучении теории у меня такие мысли появляются намного реже.
А изучать же теорию по тестированию того, что мне тестировать не нужно я точно не буду вообще. Ну разве что на встрече нашего сообщества тестировщиков кто-нибудь будет рассказывать :)
Посмотрите на первое правило из статьи — про автоматзацию не тестирования. Абсолютно верно. Многие под автоматизацией понимают исключительно некий скрипт/тул, который умеет кликать, быстрее и тупее, чем самый быстрый и тупой кликер. Но это ведь не так.
Можно автоматизировать создание тестовых данных, сравнение логов, анализ результатов, да и еще кучу чего. При этом выполняя само тестирование руками.
В нашей профессии, чем больше знает и умеет человек — тем это более ценно.
Программист может годами писать код, пользуясь одним языком и одним фреймфорком, меняя конторы, и накапливая опыт и оттачивая свое умение. Тестировщик же должен быть всегда готов к новым тестам, т.к. если тестировщик годами тестирует одно и тоже он не развивается, а деградирует.
Будем рады видеть в рядах докладчиков!
Не думали о том, чтобы выступить на конференции SQA Days? Следующая будет осенью, дата пока официально не объявлена.
1) В большинстве случаев одного лишь программирования недостаточно для разработки продукта, которым будет пользоваться конечный пользователь. И я не говорю, что тут обязано тестирование участвовать, вовсе нет, хотя, конечно, желательно.
2) Во многих западных компаниях (средних и крупных), все кто создает ПО обычно сосредоточены под названием R&D (Research&Development) или Product Development, куда включают и программистов и тестеров и писателей и много кого еще. (Development=разработка)
3) В совьет-стайл предприятиях (мне довелость поработать на ЛОМО) быть программистом — значит быть кодером. Программисты там (это должность, записанная в трудовой) пишут код по уже предоставленным и разработанным спецификациям. В рамках заданной архитектуры. От себя ничего не придумывают. И хотя их работа несомненно важна, но продукт, на самом деле, разработан людьми, писавшими требования.
По мне так программист — это разработчик. Тестировщик — тоже разработчик. И аналитик, и архитектор и релиз инженер.
Это все-равно, что говорить — «е-мэйл — это неправильно, а правильно электронная почта». Ну да, а все-равно говорим е-мэйл. И все главное понимают.
Пример (у нас так документация устроена): документы (XML) лежат под системой контроля версий. И XSL документы лежат тоже там. Нужно добавить новый документ — берешь шаблон (ссылки на XSL файлы в нем есть), забиваешь данными и кидаешь под версионинг. При просмотре через веб (либо локально по файловым урл-ам) открывается не XML, а его преобразованый в HTML вид. С другой стороны, эти же самые данные могут поступать на вход компьютеризированной системы. Соотвественно: теже файлы по тем же урл-ам скачиваются как просто XML-документы, но никуда не преобразуются, а обрабатываются скриптами.