LeshaL

C одной стороны вроде как и в статье подняты реальные проблемы, с другой - предыдущие коментаторы все правы.
На мой взгляд написано кособоко, сквозь призму негатива. Не стой стороны, если так можно сказать.
Хотелось бы, конечно, чтобы автор прочел коменты, вероятно у него еще больше глаза откроются.

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

1. Нет ощущения, что продукт «мой»
Каждому несомненно хочется, чтобы у сотрудников болела душа за проект, за фирму. А ведь много работодателей относятся к работникам как к винтикам, а что касается тестировщиков, так к ним относятся как к дешевой рабсиле, которая может вкалывать по выходным, тогда как программисты и руководство отдыхает. Будут люди считать фирму или проект "своим"? А может редка ситуация, когда отдел тестирования сидит где-то в углу и им приносят билд и говорят "вот два дня - тестируйте, с заказчиком уже договрились о поставке". Будет такой проект "своим"?

2. Нет понимания «достаточного» качества продукта.
Достаточнось качества зависит от размера кошелька заказчика и того времени которое он готов отвести на проект. Зависит от многих неинженерных факторов, возможно завязанных на бизнес заказчика, мировые тенденции и тд. Откуда у тест-лида может появится понятие нужного уровня качества, которое удовлетворит заказчика, если как не от заказчика? А ПМ - координатор работ по всему проекту почему отодвинут? Или это тест-лид должен строить программистов, чтобы те писали более качественный код, дабы довести проект до "достаточного" уровня? А может многие работодатели, например, делая софт под айфон или андроид покупают сотрудникам такие устройства, чтобы они могли сравнить качество своего продукта с конкурентами или вообще на рынке? Много? Я вот не уверен, обычно есть опытный образец в лаборатории, к которому в лучшем случае нет очереди.

3. Низкий порог входа в специальность и слабая конкуренция
Ага. Опять эта байка. Придите в фирму, где тестировщики ценятся: им и платят достойно, и они участвуют в производственном процессе изначально, и к мнению их прислушиваются и т.д. Порог попадания в такие фирмы ой как не низок. А просто попасть в контору где думают, что работа легкая, глупая, с низким порогом входа, где платить много не надо и можно нанять людей почти без опыта сразу в бой, не предоставив время и наставника для обучения (пусть и в бою). Ну так вот таких много от них-то и идет эта ерунда и люди от них стараются уйти, т.к. в фирмах где тестировщики ценятся они обычно и работают долго.

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

Мы пока сильно не попадаем в «западное» понятие хорошего тестировщика. Их тестировщики – это люди, которые знают больше как в теории и практике тестирования, так и в программировании.
А вот это вообще не соотвествует действительности. В нашей стране, точнее во всех странах СНГ, много квалифицированных тестировщиков. А вот опыт работы с зарубежными коллегами, не говоря уж о Индии/Китае - лично у меня вызывает много вопросов в проф. компетенции большинства тамошних товарищей. Ну а стоят они там как минимум раза в 4 дороже. Это не значит, что в америке или европе нет хороших тестировщиков, да полно наверняка и многие из них - русские, украинцы, белорусы, индусы, китайцы, чехи и прочие, которые туда переехали.

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

Порой обидно, что люди которые собеседуют кандидатов упор делают наоборот на знании предметной области или еще лучше тестового инструмента. Т.е. человек знает, например, лопату, копал 3 года или 5. Уже видеть не может её. Хочет пойти туда, где работают тяпками - а ему говорят: ты с тяпками не работал, мы понимаем, что ты научишься быстро, но нам нужен человек с опытом работы с тяпками не менее 3х лет. И ведь найдут такого - уставшего от работы с тяпкой, с замыленым взглядом, багажом идей, которые сработали на предыдущем месте и поменявшим работу, только потому, что тут больше бабла дают.

на fail можно придумать тысячи кейсов :)

кейсов да, но классов эквивалетности все-таки меньше...

Об том и речь. И вопрос НЕ такой, "а покажите мне решение". А вопрос тут в том, что люди не до конца разобрались в тестовом задании и надо всего-лишь их направить на путь к решению, что и сделал Freiman. Перечислять все варианты никто и не просил.

...
А вообщем спасибо =) некоторые мысли в голову пришли

Вот еще на подумать...

Как формируется запрос к серверу с данной формы (get/post)?
Как передается пароль - в виде хэша или плэйн-текстом в теле ПОСТа?
Как форма ведет себя если пароль запомнен средствами браузера? Если не запомнен...
Сколько раз может залогиниться один и тот же пользователь одновременно? А с разных браузеров? А с разных хостов?
Что происходит если сервер недоступен?
Что происходит при обрыве соединения, до получения ответа от сервера?
А что если в поле набрать что-то типа <script>alert(123)</script>?
...

Что будет если поля пустые (оба или одно из них)?

насчёт оба так это 1 сценарий который я писал, а насчёт 1 одного я думаю это уже очевидно. Просто если поле не заполнено то это NULL и при нажании на Sign In послывает в базу NULL соотвественно равносильно несуществующему пользователю или некорректному паролю

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

Добрый день, коллеги.
....
Буду рад любым советам.

Здравствуйте.
Как я понимаю, вас интересует не только саморазвитие но и карьерный рост тоже. Можно начитаться умных книжек и стать эрудированным младшим тестировщиком на долгое время.
Чтобы этого не произошло надо проявлять активность и инициативу. Посмотрите на своих коллег - большинство из них, скорее всего, просто делают свою работу и ничего больше. Они не хотят ничего сделать, придумать, улучшить (а может и хотят - но не делают!). Так вот станьте тем, кто делает. У вас есть две области где вы наверняка можете найти кучу недостатков. Первая - это тестируемые программы. Вторая - процесс вашей работы; для начала возьмем только команду тестирования. Нахождение недостатков - прямая обязанность, то что от вас ждут. Предложение по устранению недостатков - показатель того, что вы еще и думаеть умеете и более того, хотите чего-то добиться.

В первой области, помимо дефектов есть еще возможности для улучшения - удобство, время выполнения(оптимальность), логичность, да и просто что-то новое и нужное. Ищите такие места, думайте, предлагайте как можно сделать лучше (наверняка у вас в дефект-трэкере помимо категории Bug есть и Enhancement).

Вторая область даже еще интереснее. Оглянитесь и посмотрите где есть несоразмерные затраты ресурсов и как ситуацию можно улучшить - просто помечтайте (например "было бы хорошо, если бы вместо этого я бы делал ...") - а там глядишь и идея применимая на практике появится. Поймите, что это может быть не обязательно что-то автоматизированное - может быть и нарисованный на бумажке улучшенный процесс или переработанные какие-нибудь устаревшие policy. Ищите - вам на месте должно быть виднее. И да, чуть не забыл, всегда ставьте своего непосредственного начальника в известность о вашем предложении первым! Не надо слать на общий алиас какое-то рацпредложение не обсудив его с начальником.

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

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

ЗЫ: пока писал, коллега van, уже написал подобные рекомендации, с которыми я 100% согласен. Просто так читать книги или чего-то учить (ruby, perl, python, java, sql, xslt, regexp, html, xml, javascript, webdav ... продолжите дальше сами) - зачастую бестолку - забудете все нафиг. Приобретать же знания необходимые для решения конкретной задачи намного эффективнее.

ЗЫ2: да, еще, ваши рацпредложения должны быть интересны и полезны не только для вас. А решения каких-нибудь сложных или нетривиальных задач должны быть максимально эффективны с точки зрения затрат вашего времени. Не пытайтесь их решить в общем случае, решайте в частном и наиболее практичном для вас, вашей команды и вашей компании.

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

Хотелось бы отметить, что если кандидата нанимают на работу после одно единственного собеседования (четкого и лаконичного), то это говорит о:
- несерьезности работодателя
- то, что работодатель находится в цейтноте и надо очень срочно заткнуть вакансию хоть кем-нибудь, пока не прикрыли
- то, что работодатель имеет дефицит соискателей на должность и не из кого выбирать
Сам устраивался на работу, пройдя 3 собеседования (4 часа, 6 часов и ~час телефонное с америкой). Во время когда я приходил, было много кандидатов и пытались найти лучших. После, где-то пол-года спустя собеседования стали как-то попроще и покороче. Результат такой, что те кто пришел до меня или совместно со мной - большинство работают до сих пор (т.е. около 4-х лет). Те кто приходил позже- многие уже свалили из компании.
И ведь HR-отдела как такового не было, когда я устраивался. А были люди которые делали команду. И вся команда могла присутствовать на собеседовании. Помню. когда искали мэнеджера, то соискателей, будущих руководителей, допрашивали чуть-ли не всем составом (ессно не на первом собеседовании). И это правильно.
Абы-кого можно и без собеседования взять, хоть по знакомству - только вот работодатель от этого редко выигрывает.

Грубо говоря, в Use Case описываются правила/пути пользования определенного функционала, в Test Case - то как будет тестироваться функционал.
А вы сами что об этом думаете?

Таким образом получается что Test Cases включают в себя Use Cases + еще дополнительные моменты, которыми могут быть corrupt tests (тестовые данные, которые выходят за границы use cases). Я правильно Вас понимаю?

Я бы построил такую цепочку Product -> Product's Features -> Use Cases -> Test Cases. Т.е. продукт состоит из какого-то набора фич\функционала. Каждая фича имеет несколько вариантов использования.
Каждый вариант использования какого-либо фукнционала, порождает один или больше тесткейзов. В том числе и негативные тесты. (Не знаю, откуда появилось название corrupt test - обычно это negative test называется).
Пример.
Есть программа, простенький текстовый редактор я-ля notepad для txt файлов. Одна из фич - copy\paste. Один из вариантов использования - вставление (вставка, ну вообщем paste) скопированного текста из другого приложения. Один из тесткейзов - открыть другой текстовый редактор(word), скопировать в нем текст, вставить в тестируемый редактор -> убедиться, что все скопированное вставилось. Второй тесткейз: открыть графический редактор(paintbrash), скопировать картинку, попытаться вставить в тестируемое приложение -> убедиться, что... итд.
Другой вариант использования той же фичи - copy\paste внутри редактора
Третий - copy из нашего редактора\paste в другой аппликухе.
Итд.