Боец тестирования банковского ПО в Минске, Гродно или Бресте будет успешно принят на работу
пятница, марта 25, 2011
Если ты не раз вспоминал программистов добрыми словами за ошибки и медленную работу программного обеспечения отделения твоего банка – есть шанс это исправить.
Ко мне в команду нужны бойцы невидимого фронта тестирования.
Требования:
- быть готовым за очень короткие сроки овладеть большим объемом информации
- знать, что такое функциональное тестирование (и чем оно отличается, скажем, от нагрузочного)
- разговаривать с компьютером на «ты»
Плюсом будет:
- знание любого скриптового языка
- знание SQL
- опыт тестирования
- огромное желание стать тестировщиком
- знание правил бухгалтерского учета
Если ты студент(ка) или не имеешь опыта работы, но безумно трудолюбив(а) и талантлив(а) – пиши, возможно именно для тебя осталось место!
Писать на colvir[гав]yatester.ru или нашему HR - ohaetckaya[гав]colvir.ru
Кстати, знание английского вовсе не требуется – совещаемся и пишем по-русски J
Текст сообщения и комментарии...
Никогда не говори никогда и другие 10 никогда...
пятница, февраля 25, 2011
1. Здесь багов нет - я гарантирую.
2. Всё равно, никто не использует Firefox!
3. Cem Kaner и James Bach вообще не понимают, о чем говорят.
4. Это срочно? Я тут просто в Farmville играю.
5. У меня на компьютере все работает!
6. Я только что написал в твиттере о дыре в нашей системе безопасности...
7. Использовать инструменты для тестирования? Я справлюсь без них!
8. На самом деле я отличный тестировщик, пока не трезв..
9. Ты прав, мне тоже кажется что сообщение об ошибке - это новая фича.
10. Если здесь остались баги, их найдут beta-пользователи...
Источник
Текст сообщения и комментарии...
Из-под пера Maksim Grinevich
Тэги:
баг,
мелочи,
перевод,
тестировщик,
James Marcus Bach
|
4
ответов, оставьте свой...
Тэги:
баг,
мелочи,
перевод,
тестировщик,
James Marcus Bach
|
4
ответов, оставьте свой...
Возможно ли построить идеальный процесс тестирования?
пятница, октября 29, 2010
ИПТ
На первый взгляд кажется, что самым верным ответом на поставленный в теме вопрос будет слово «Нет». Предлагаю немного углубиться в тему вопрос, возможно даже помечтав...
Что такое?
Идеальный процесс тестирования для меня – это процесс который позволяет решать поставленную задачу максимально эффективно, а так же создает комфортные условия для этого. Идеальный процесс, когда «лучше уже и не надо!»
Хотя само понятие ИПТ достаточно не однозначно, потому что каждый читатель может выдвинуть свои критерии идеальности процесса.
ИПТ не существует
ИПТ не существует, если вы хотите придумать один универсальный для всех людей или команд. (команда)
ИПТ не существует, если вы думаете, что может одна и та же команда на протяжении очень долгого времени работать по заранее заданному процессу. (время)
ИПТ так же не существует, если вы планируете использовать его на разных проектах. (проект)
ИПТ существует
ИПТ можно построить для конкретного набора людей, сплоченного в команду, даже если это всего два человека – фрилансер и пользователь. (команда)
ИПТ достижим, если вы готовы планомерно улучшать Ваш процесс на протяжении всего жизненного цикла проекта. (время)
ИПТ возможен только в рамках конкретного проекта и зачастую полностью непереносим на другие. (проект)
Как?
Создание ИПТ сопряжено с набором следующих действий, которые следует повторять в течении проекта:
I. Описать то место в проекте, времени и команде, в котором вы находитесь;
II. Идентифицировать проблемные места
1. идти от проблемы
2. с точки зрения цели:
- удобный для достижения цели
- предсказуемый результат
- понятный объем работ
1 решать по одной из каждой выделенной области в единицу времени
2 параллельное решение из несмежных областей
IV. Внести изменения
1 мотивация команды
2 обратная связь
3 довести изменение до конца
V. Проанализировать результат
Несколько примеров
Пример первый.
Небольшая продуктовая компания на 20 человек. Постановкой процесса занимались исключительно в случаях, когда были на то проблемы:
- частое обращение ПМа за информацией о состоянии задач, расчетным временем их исполнения -
введено и применяется сразу практически всей командой: обновление статусов задач в багтрэккере, выставление перед началом и изменение estimations в процессе работы над большими задачами.Убедившись в достаточной верности данных – ПМ реже задает свои вопросы.
- в отсутствие строгих и формализованных требований, задачи на разработку оформляются в виде тикета в багтрэккере. Проблема заключалась в том, что множество уточнений выяснялось только после того, как задача передавалась на тестирование
принято решение осуществлять «тестирование требований» - предварительный просмотр текстов задач тестировщиками.
Пример – второй.
Крупная оффшорная компания. Выделенный центр разработки для одного западного информационного агентства составом в Х человек, из которых 30-40 человек – группа тестировщиков.
- стремясь улучшить процесс для всей группы, изменения вносят на всех, проверяя на одной из групп.
Изменения успешные для группы из 5-7 тестировщиков валяться на группе из 2-х человек, т.к. они работают с другим типом ПО, у них свой «подкрученный» процесс тестирования.
Заключение
Подводя итог выше сказанному, следует отметить следующие моменты:
- стремиться к ИПТ необходимо – он существует и достижим;
- движение стоит начинать от проблемы;
- ...
В дополнение хочу показать карту памяти, которую я использовал для подготовки этого сообщения:
Спасибо mindmeister за сервис.
Текст сообщения и комментарии...
Why? Why not? Why not me? Why not now?
вторник, октября 26, 2010
Не совсем про тестирование, но очень понравилось:
"For true success ask yourself these four questions: Why? Why not? Why not me? Why not now?"
(с) James Allen
"Для настоящего успеха задайте себе следующие четыре вопроса: Почему? Почему бы и нет? Почему не я? Почему не сейчас? "
(с) Джеймс Аллен
Текст сообщения и комментарии...
20 причин почему не надо тестировать
воскресенье, октября 24, 2010
1) Нам не требуется такого уровня тестирования.
2) Это стоит
3) Слишком долго будете копаться.
4) Тестирование никогда «не завершится полностью».
5) Мы никогда не знаем, сколько времени уйдет на тестирование.
6) Слишком академично, мы же не NASA.
7) А его собственно и в плане то не было.
8) Тестирование сильно тормозит выход продукта.
9) Кастомер просто весь в нетерпении, а ваши тестеры тормозят процесс.
10) Тестирование выставляет нас идиотами.
11) А какой толк вообще от тестирования?.
12) Пока тестеры нароют все баги – рынок ушагает от нас.
13) Да и вообще всем пофигу на эти баги.
14) А собственно тестирование вообще не дает ответа ни на какой вопрос.
15) Разрабы сами все протестят.
16) Не надо ломать систему, и так работает не очень.
17) Пользователь сам найдет баг и мы все пропатчим.
18) Ну нет у нас времени, чтобы написать требования.
19) И вообще, тестеры никогда не находят самые нужные баги.
20) Тестирование все равно никогда не найдет всех багов.
Текст сообщения и комментарии...
Из-под пера Maksim Grinevich
Тэги:
память,
тестирование,
хорошо забытое старое
|
5
ответов, оставьте свой...
Тэги:
память,
тестирование,
хорошо забытое старое
|
5
ответов, оставьте свой...
Верное отношение...
среда, июля 21, 2010Когда вы что-то начинаете, и устройство процесса тестирования в том числе, важно не только как ВЫ хотите это сделать, как ВАМ нравится браться за эту работу, как ВЫ уже в голове распланировали свои следующие действия... Не менее (а иногда и более) важным является отношение тех, кто может прямо или косвенно влиять на вас.
Хорошее отношение менеджеров и лидов проекта к введению тестирования или преобразованию от «потестить что-то» к более менее результативному процессу значит:
— готовность самим немного «прогнуться», помочь, а так же интерполировать свою помощь на подопечных
— отсутствие явных противодействий, «палок в колесах»...
Как минимум нейтральное отношение рядовых программистов говорит:
— о желании делать хороший продукт, а не «хотфиксы» :)
— стремлении улучшить себя и свою работу (они ведь знают, что теперь за ними будут - следовательно стараются делать лучше)
Прежде чем улучшать процесс или даже говорить о необходимости изменений — следует исправить отрицательное отношение коллег, если таковое имеется. Примите во внимание, что новое зачастую принимается «в штыки».
Как это сделать? — Ответ для каждого случая свой, но для себя выделил несколько простых вопросов, которые помогают в разговоре:
1. Какая выгода менеджеру/девелоперу лично?
Иногда ясные факты сказанные громким голосом вполне действенны — даже если вы думали, что их все и так знают.
2. Можно ли сделать так, чтобы количество действий с их стороны или изменений в жизнедеятельности было минимальным?
Нас не напрягает, если от нас не требуют активных действий или не происходит изменения того, к чему мы так привыкли. (Использовал это часто, на сколько позволяли обстоятельства)
3. А проект/задача от этого выиграют?
Не такой влиятельный аргумент для людей, чем первые два, но так же имеет место среди списка причин внедрения «улучшений». А как бы хотелось, что бы это был самый важный :)
4. «Улучшения» выглядят как улучшения или как очередные заморочки тех, у кого работы не много?
5. Получено ли подтверждение/разрешение от «высокого» менеджмента?
Удар ниже пояса, но некоторых приходится «убеждать» именно так :(
Текст сообщения и комментарии...
Процесс это не про документы, это про людей.
вторник, июля 06, 2010Как же много людей считает, что
- если сделать процесс точно так, как пишут о нем его "евангелисты" - то получится очень крутой результат
- если жестко держаться рамок, которые описаны в книге Х большым Мозгом, то команда по умолчанию становится profitable
Сколько раз нужно расшибить лоб об острые углы "гибкого", прежде чем понять, что
только вся команда вместе с течением времени спасобна выработать тот порядок организации работ (процесс), который будет максимально отвечать сложившимся требованиям на проекте.
Процесс разработки/тестирования, как пицца - основа в большинстве случаев одна/две/три, а ингридиентов множество :)
Текст сообщения и комментарии...
