1. В проекте, в котором заняты, скажем, 7 разработчиков, и где нет спецификаций, - работает тестировщик, студент; работает и учится, т.е. работает не full-time. Проект долгосрочный, скажем, уже прошло полгода и еще конца края не предвидется.

1.1. Достаточно ли такой занятости для серьезного проекта?

Проект без спецификаций НЕ МОЖЕТ быть серьёзным. О чём вы говорите? ;-|

1.2. Каковы плюсы и минусы такого подхода?

Плюсы - дешевизна: студент без опыта на part-time согласится работать за копейки.

Минусы - качество на нуле.

2. И еще подход - когда тестировщика переводят с проекта на проект - 2 недели там, месяц в другом проекте, потом опять на старый проект на 1 месяц.

2.1. Каковы плюсы и минусы такого подхода?

Плюсы: у тестировщика не замыливается взгляд, он не мается со скуки, есть разнообразие, проекте часто появляется человек, способный взглянуть свежим взором на его работу. Для руководства - экономия ресурсов.

Минусы: за две недели он не успеет изучить функционал, не говоря уж о подготовке тест-кейсов, нужен больший срок (месяца два). Для руководства - отсутствие ведущего проект тестировщика, которой всегда знает статус и баги проекта.

3. И еще: тест кейсы пишутся в начале проекта. Это правильная практика. Кто как использует документ с тест кейсами _потом_ (если это именно документ скажем в Word)?

Тест-кейсы в составе сценариев тестирования должны использоваться при КАЖДОЙ полной итерации тестирования.

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

Бывает.

Если так происходит, то в чем плюсы и минусы составления тест кейсов именно в таком документе Word или Excel, который не дает сам по себе возможности управления тестами и т.д., что позволяет, например,  Mercury TestDirector.

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

Плюсы - не надо покупапть и внедрять TestDirector, осваивать работу с ним.

Минусы - как и у любого половинчатого решения или использования непредназначенного для имеющейся цели инструмента, результат от внедрения заметно меньше, чем от использования спец-инструмента. О чём вы и пишите.

Например, на этапе разработки обнаружено 4000 багов на 1000000 строк кода.

Постойте, а при чём тут количество строк кода? Оценивать кол-во ошибок на строк кода может руководитель разработчиков, но не тестирование.

Для нас ошибкой явлется не косяк в коде, а косяк в работе программмы.

Ошибка в коде не равна ошибке в работе программы. Из-за опечатки в коде бага в работе программы может вообще не возникнуть, а может появиться с десяток.

Вышел релиз, не важно Альфа или Бета, или даже final - заявленная фунциональность по идее должна работать без ошибок.

Заявленная фунциональность по идее должна работать без ошибок только в финальном релизе. Кроме того, с точки зрения конечного пользователя, который проектной документации в глаза не видел, а о заявленном функционале имеет весьма туманное представление, показателем качества ПО явлется соответствие его ожиданиям, удобство и адекватность программы.

За время тестирования заказчиками (приемочные испытания) обнаружено еще 200 багов. Собственно вот эти 200 багов - это катастрофа или допустимо?

Как было верно сказано, баг багу рознь. Может статья, многие из этих двухсот окажутся и не багами вовсе, а запросами на изменение, фич-реквестами, ошибками в ТЗ, самим заказчиком и предоставленном. Кроме того, нужно учитывать критичность ошибки. Как и то, не является ли она дуликатом уже известной вам, которую по какой-то причине решили не править.

Но положим, все найденные заказчиком баги оказались важными или даже критичными. В таком случае процент серёжных дефектов, обнаруженных после сдачи проекта будет равен (200/4000) * 100% = 5%.

Много это или мало? А это уже должно быть записано в договоре, который вы заключали в заказчиком. И процент, при котором вам придётся бесплатно делать и поставлять исправленную версию или получать оплату в неполном объёме (а если проект внутренний - лишаться премии), для каждого проекта будет отличаться. Всё зависит от приоритетов.

Хотелось бы узнать, какие средства для работы с клиентами используют службы поддержки?

В разных компаниях, где я работал, использовались: самописный helpdesk, Microsoft CRM, модуль helpdesk из "Bitrix: управление сайтом".

Инегрируются ли эти софтинки с вашими BugTracking Systems? Если да, то с какими?

А зачем? Эникейщикам доступ к BugTracking Systems не нужен, так как в норме баги в релиз (или на live-сервер, если у нас веб-проект) не попадают. А вот намусорить операторы операторы хелпдеска в базе могут порядочно. Так что если давать доступ, то только второму-третьем звену техподдержки, т.е. квалифицированным инженерам.

А какую-то интеграцию двух систем вообще не понимаю, зачем заваривать. Достаточно в настойках BTS сделать так, чтобы уведомления об обнаруженных на LIVE / в SHIPPED VERSION багах слались не только в QA и Dev, но и в Helpdesk, дабы в хелпдеске были в курсе обнаруженных багов, условиях их воспроизведения и workaround`ах.

Весьма веселенькая аналогия получается.
Представляю на сцене стрипклуба чемпионку по метанию ядра (молота, копья). Ну и в ту же сторону. Для танцоров еще и пластика нужна, а не только спортивная фигура.

Метание ядра/молота/копья - далеко не лёкая атлетика.

Лёгкая атлетика - это упражнения на брусьях, кольцах, коне и других спортивных снарядах, а также художественная гимнастика.

Уверяю вас, что у выступающих в этих дисциплинах алтетов с пластикой всё более чем хорошо.

Для работы нужно не только желание, но и способности.

Для работы нужны не только способности, но и желание.

Внимательней перечитайте пост, там приведены достаточно объективные суждения.

PS. Насколько я понимаю, относительно первой части - куда большей востребованности перечислявшихся качеств у тестировщиков, чем у программистов (от Если бы разработчики обладали усидчивостью, аккуратностью, въедливостью и терпением (читай - если бы эти качества требовались при найме разработчиков), то нашей с вами профессии не существовало бы! а далее) возражений нет?

Друзья, следуя вашей логике, женщин должно быть больше и, например, среди разработчиков -- разве там не требуется усидчивость и аккуратность? А уж сколько въедливости и терпения иногда бывает нужно при отладке и локализации какой-нибудь трудноуловимой ошибки -- по сравнению с этим тестировщики просто отдыхают.

Какое же это качество, которое препятствует женщинам занять лидирующие позиции среди разработчиков, но не мешает быть тестировщиками?

Если бы разработчики обладали усидчивостью, аккуратностью, въедливостью и терпением (читай - если бы эти качества требовались при найме разработчиков), то нашей с вами профессии не существовало бы!

По одной простой причине - усидчивые, аккуратные, въедливые и терпеливые программисты не делали бы ошибок, а если бы делали, то сами бы тут же исправляли.

А уж локализация багов - это и вовсе работа тестировщика, а не программиста.

Если после прочтения баг-репорта ваши программисты никогда не говорят "а у меня не воспроизводятся" или "из репорта непонятно, в каком модуле баг - rejected" или "условия воспроизведения неясны - rejected", а сразу садятся за отладку - поздравляю, вы работаете в идеальной компании.

Ну и самое главное, что вы упустили в моём сообщении - то, что у средней женщины нужные тестировщику качества (внимательность, усидчивость, аккуратность, въедливость) более выражены, чем у среднего мужчины, вовсе не означает, что в тестировании ПО будет больше женщин.

Для этого нужно, чтобы сфера IT (разработки ПО), которая традиционно больше привлекает мужчин, была бы для средней женщины не менее интересна, чем для среднего мужчины.

Ну не прикалывают девушек компы - вот и не идут они работать тестерами, админами и программерами. Так понятее?

Для этого также нужно, чтобы техническое и математическое образование, которое почти всегда требуется от кандидитов на вакансии в QA, было бы столько же востребовано девушками, столь и юношами (а у нас в стране девушки традиционно чаще идут в гуманитарные вузы)

Для этого нужно, чтобы работадетели перестали считать, что мужчины на технические должности подходят больше, чем женщины (а они не перестанут хотя бы потому, что для многих технических профейсий это действительно так)

Приведу ещё аналогию. У большинства людей, которые серьёзно занимались спортом, есть данные для работы в стриптизе, а именно - отличная спортивная фигура. Но почему-то среди работающих в стриптизе совсем не много чемпионов и чемпионок по лёгкой атлетике, Вас же это не удивляет?

Мне сегодня один программист сказал, в шутку, что у женщин есть больше качеств, подходящих для тестирования, чем у мужчин.

Это не шутка, это действительно так. Давно известно, что в среднем женщины усидчивей и аккуратнее мужчин. Конечно, умение придумывать нетривиальные ситуации и деструктивное мышление тестировщику тоже нужны, но внимательность и аккуратность всё-таки важнее. Так что коллега-программист прав. А то, что среди профессиональных тестировщиков женщин немного, ничего не доказывает - просто мало кому из девушек интересно идти работать в IT.

Посмотрел http://www.geocities...Dictionary.html. Возникли сомнения в том, насколько этому документу можно доверять. Например, там написано следующее:

Alpha Testing. Testing of a software product or system conducted at the developer's site by the customer.

А мне всегда казалось, что альфа-тестирование - это тестирование альфа-версии. И уж customer, то есть конечный пользователь ака заказчик, к альфа-тесту совершенно точно не допускается.

Так, а на сайт эти страницы как попадают? Закачиваются с компа разработчика, верно? Вот берём локальную копию и по ней проходимся.

И даже если страницы делаются непосредственно на сайте, никто не запрещает offline-броузером скачать весь сайт и сделать F3 полученной копии.

Ну или зайти на хостинг, который, скорее всего, работает под IIS, и делать F3 там.

Словом, вариантов масса.

Есть книжка по тестированию игр. Весит 10 мегов, могу залить куда-нить на ftp. Но она по консольным играм, так что рассказаное в ней малоприменимо к браузерным. Скорее, надо изучать тестирование веб-приложений, а по этому делу в инете инфы сколько угодно. Кстати, браузерная игра - тоже клиент-серверное приложение. Клиент - броузер, сервер - сервер игры.

Разумеется, есть. Называется "F3".

1. Открываете папку с сайтом
2. Нажимаете F3
3. Пишем "type="text/css" в "Слово или фраза в файле", включаем опцию "Просмотреть вложенные папки"
4. Нажимаете Enter

Просто, не правда ли?

Кто как считает, является ли задачей тестировщика проверка кода приложения на соответствие синтаксису?
Например, я случайно запустил валидатор (с w3c) для одной из страниц тестируемого приложения. И валидатор показал некоторое количество ошибок. Как быть? Должен ли я занести такие вещи в Bugzill-у?

Занеси - хуже не будет. Вообще, проверка требуемых компиляции исходников и проверка HTML-разметки - несколько разные вещи:

- первое сделать намного сложнее (QA редко дают доступ к исходникам)
- первое обычно берёт на себя среда разработки/компилятор (прога с кривым синтаксисом просто не скомпилится)

IMO, если есть время, то тестеру стоит проверить исходники, особенно для web-проектов.

Только несоответствие спецификациям HTML 4.0 не всегда ведёт к ошибкам на странице. Иногда следовать им - явно лишнее, а W3C`шный валидатор - известный пурист и паникёр, так что в большинстве случаев баг это малозначительный.

Должен ли тестер проверять код веб-страниц проекта на наличие подобной строки:

<meta http-equiv="content-type" content="text/html; charset=windows-1251"/>

...а конкретнее, проверять, указана ли кодировка страницы?

На практике лучше, когда кодировка страницы вообще не указана. Объясняю почему. Если случайно страница окажется не в той кодировке, которая указана в заголовке, то посетитель никакими ухищрениями не сможет её посмотреть - при попытке поставить другую кодировку броузер будет принудительно переключаться на указанную в заголовке. Единственный варинт для юзера - сохранить страницу на локальный диск, удалить оттуда злополучную строку и открыть получившийся файл. Согласитесь, это гораздо сложнее, чем просто выбрать другую кодировку в броузере.

Хотя страндарт, наоборот, требует указания кодировки.