Показаны сообщения с ярлыком мелочи. Показать все сообщения
Показаны сообщения с ярлыком мелочи. Показать все сообщения
Mindmaps о тестировании
пятница, февраля 01, 2013
Ух и хорошая же ссылка попалась мне на просторах сети.
Здесь куча очень толковых интеллект карт о тестировании.
Вот только малая часть того, что есть по ссылке:
Здесь куча очень толковых интеллект карт о тестировании.
Вот только малая часть того, что есть по ссылке:
- Testing in Production by Software Testing Club, via Flickr
- MindMap – Heuristic Testing Strategy Model iOS
- Testing MindMap / Checklist
- What's in your toolkit? - Software Testing Club
- MindMap: Testing and Checking
- The Future of Testing – MindMap
- Chickenwings Test Consultancy: Rapid Test Management course mind map
- Error Messages MindMap
Текст сообщения и комментарии...
Никогда не говори никогда и другие 10 никогда...
пятница, февраля 25, 2011Десять фраз, которые не должны звучать из уст тестировщика:
1. Здесь багов нет - я гарантирую.
2. Всё равно, никто не использует Firefox!
3. Cem Kaner и James Bach вообще не понимают, о чем говорят.
4. Это срочно? Я тут просто в Farmville играю.
5. У меня на компьютере все работает!
6. Я только что написал в твиттере о дыре в нашей системе безопасности...
7. Использовать инструменты для тестирования? Я справлюсь без них!
8. На самом деле я отличный тестировщик, пока не трезв..
9. Ты прав, мне тоже кажется что сообщение об ошибке - это новая фича.
10. Если здесь остались баги, их найдут beta-пользователи...
Источник
1. Здесь багов нет - я гарантирую.
2. Всё равно, никто не использует Firefox!
3. Cem Kaner и James Bach вообще не понимают, о чем говорят.
4. Это срочно? Я тут просто в Farmville играю.
5. У меня на компьютере все работает!
6. Я только что написал в твиттере о дыре в нашей системе безопасности...
7. Использовать инструменты для тестирования? Я справлюсь без них!
8. На самом деле я отличный тестировщик, пока не трезв..
9. Ты прав, мне тоже кажется что сообщение об ошибке - это новая фича.
10. Если здесь остались баги, их найдут beta-пользователи...
Источник
Текст сообщения и комментарии...
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
"Для настоящего успеха задайте себе следующие четыре вопроса: Почему? Почему бы и нет? Почему не я? Почему не сейчас? "
(с) Джеймс Аллен
Текст сообщения и комментарии...
Первоисточник дороже всего!
среда, июня 23, 2010
Сколько раз себя убеждал, но все равно попадаюсь - сценарии тестирования исправления были написаны на основе действующей программы и слов программиста. Документация была пропуще сквозь призму слов и действительности...
..и естесственно это в итоге вызвало ошибку, да причем очень-и-очень больную для заказчика.
Ошибается каждый, но детские ошибки делать НЕ позволительно!
Это была лирика, а теперь выводы.
Текст сообщения и комментарии...
..и естесственно это в итоге вызвало ошибку, да причем очень-и-очень больную для заказчика.
Ошибается каждый, но детские ошибки делать НЕ позволительно!
Это была лирика, а теперь выводы.
Есть ситуации, когда другого выхода нет и приходится описывать то, что есть. Но если есть хоть небольшая возможность - изучайте первоисточник! Все его интерпретации могут быть:
- однобокими
- ложными
- недоправильными
- иметь больше деталей, чем оригинал
- и т.д.
Попросите 2-3 человека описать Красную площадь или Статую свободы - получите ли вы одно и то же описание? А если посмотите сами на картинку..а если потом "вживую" - сколько разных описаний вы получите?
- однобокими
- ложными
- недоправильными
- иметь больше деталей, чем оригинал
- и т.д.
Текст сообщения и комментарии...
1, 0 и 10
вторник, мая 11, 2010
Давеча посмотрел фильм ПОП Владимира Хотиненко. Там главный герой рассказывает нерадивому мужу о семейных отношениях между мужем и женой (мой вольный пересказ):
Когда это услышал промелькнула мысль: а ведь тестирование и программирование примерно в таком же ключе взаимосвязаны.
Программирование без тестирования способно что-то делать — назовем результат 1. А вот при включении в разработку тестирования (которое само по себе 0) — получаем в результате 10 (десять).А про то, как тестировщики в процессе работы помогают программистам «заточить» продукт, и говорить нечего.
P.S.: надеюсь что этот пост немного объяснит мою точку зрения о тестировании, которая, возможно, была не правильно понята судя по комментариям к этому посту.
P.P.S.: уважаемые девушки, по поводу того, что в притче девушка названа 0 — претензии к автору романа или сценаристу фильма :)
Текст сообщения и комментарии...
... Без жены я (мужчина, поп) всего лишь единица. Жена без меня — 0. А вместе мы образуем 10 (десятку)...
... Жена — это мой точильный камень. Благодаря ей, то что я делаю получается значительно лучше, чем без неё...
Когда это услышал промелькнула мысль: а ведь тестирование и программирование примерно в таком же ключе взаимосвязаны.
Программирование без тестирования способно что-то делать — назовем результат 1. А вот при включении в разработку тестирования (которое само по себе 0) — получаем в результате 10 (десять).А про то, как тестировщики в процессе работы помогают программистам «заточить» продукт, и говорить нечего.
P.S.: надеюсь что этот пост немного объяснит мою точку зрения о тестировании, которая, возможно, была не правильно понята судя по комментариям к этому посту.
P.P.S.: уважаемые девушки, по поводу того, что в притче девушка названа 0 — претензии к автору романа или сценаристу фильма :)
Текст сообщения и комментарии...
Самая острая память
четверг, февраля 04, 2010И вновь я возвращаюсь к теме цитат из народа.
«Самая острая память тупее самого тупого карандаша».
Если хотите что-то запомнить — запишите.
Текст сообщения и комментарии...
Суеверия тестировщиков
понедельник, января 18, 2010
Суеверие — суетная вера — вера в пустое.
Тестировщики, как и все остальные земляне, не остаются в стороне и верят. Верят, порой не имея особых на это оснований...
Профессиональное:
Менеджерское (о тестировании):
Программистское:
Пост Кризисное:
А во что верите вы?
Текст сообщения и комментарии...
Тестировщики, как и все остальные земляне, не остаются в стороне и верят. Верят, порой не имея особых на это оснований...
Профессиональное:
- в проекте обязательно должна быть позиция тестировщика
- если хватит времени проверить весь тестируемый продукт, то мы найдем все ошибки
- внедрение автоматизации уменьшает объем рутинной работы
- хорошо описанная документация — наше все! Нет документов — нет качества.
- качество продукта зависит о тестировщика
- выпуск релиза в срок — к очень хитрой ошибке, которую заказчик найдет при первой же проверке
Менеджерское (о тестировании):
- тестировщики стоят дешевле программистов
- если на проекте появляется новый тестировщик, вырастает количество ошибок, которые напишут программисты
- чем больше времени на тестирование, тем меньше ошибок попадет к заказчику
- тестировщики не просят дополнительного времени на тестирование — «они что там совсем не работают?»
Программистское:
- приход / письмо / «typing» в мессенджере от тестировщика — к багу
- тестировщик долго тестирует и молчит / нервно курит / ехидно улыбается / щебечет с такими же, как сам — к бООльшому багу
- если не дали бонусов в прошлом году/квартале/месяце, то в следующем обязательно дадут
- смена работы — не к добру.
А во что верите вы?
P.S.: Возможно не все из перечисленного суеверия...
Текст сообщения и комментарии...
В главном — единство...
понедельник, января 11, 2010«В главном — единство,
во второстепенном — свобода,
во всем — любовь»
Августин Блаженный
Единство:
Знают ли все члены вашей команды цель своей работы? Вы уверены, что цели ключевых фигур проекта совпадают? Вы можете однозначно сказать в нескольких словах, какова цель вашего проекта? Причем не в «космических кораблях, которые бороздят просторы...» ©Шурик_или_кто-то_там_другой.
Только тогда проект/билд/релиз/и т.д. будет успешен, когда ВСЕ, именно все, члены команды будут работать на эту главную цель.
Когда цель ясна:
— длительные рабочие дни (которые лучше уже называть рабочими сутками) не вызывают претензий;
— успешность деятельности не соразмеряется с уровнем зарплаты;
— удовлетворенность/увлеченность работой перевешивает какие-либо межличностные конфликты;
— т.д.
Причем, на мой взгляд часто дело даже не в проекте (был один проект, будет другой). Зачастую важно, что бы продуктивная команда знала, зачем они работают. Почему нужно выпускать софт, за который не стыдно. Почему, когда один начинает «лажать», другие вынуждены нести и его ношу ответственности на своих плечах. Ведь кажущаяся мелочь работы одного, второго, третьего — и вот уже их часть работы сваливается непосильным грузом на того четвертого, кто просто вынужден выполнять всю оставшуюся работу.
Свобода:
Свобода это хорошо, это даже просто великолепно, но только если оно идет после единства. Таким образом получается, что каждый член команды свободен в выборе способов достижения цели, если эти способы не есть суть главное. Каким образом тестировщики будут осуществлять нагрузочное тестирование все на самом деле побоку — главное, чтобы исходя из проекта это отвечало требованиям бизнеса. Каким образом программист положит значение вот в этой форме — пусть решит он в своем свободном профессиональном полете мысли — главное, чтобы это шло в унисон с целью проекта.
Любовь:
Святой Августин был верующим человеком, поэтому он оперировал и таким понятием как любовь. Что же такое «любовь» в контексте IT сферы? Ведь там где бизнес и деньги, там нету места чувствам. Кажется так говорили новоявленные «бизнесмены» последних 2-х десятилетий прошлого столетия? Тогда на самом деле нужны были винтики, человеко-роботы, которые никогда не ломаются и не болеют, не имеют вредных привычек и разных характеров. Сейчас же у нас совершенно другое время: сейчас не только работодатель выбирает себе работника, но и работник зачастую перебирает — где же ему будет комфортно работать. Подробнее об этом написал «директор белорусской силиконовой долины» .
Вот тут и проявляется своеобразная любовь между работодателем и работовыполнителем, которая проявляется с одной стороны в:
— интересных проектах/задачах
— финансовой компенсации проведенных за работой часов (читай зп)
— хороших условиях труда
— чего_кому_ещё_надо
С другой же стороны это выражается в:
— высокоорганизованной работе над проектами/задачами
— самоотдаче
— продуктивности
— всего_чего_надо_заказчику
О том, как работник и компания находят друг друга через половой отбор написано здесь.
В итоге:
Если нет последнего, то грош цена тому единству и свободе. Тут расписывать не буду — и так понятно, что отсутствие описанной «любви» накладывает неизгладимый отпечаток на цели и решения такого специалиста.
P.S.:
Как ни странно, но действительно умные замечания старцев работают даже тогда, когда они были сказаны совершенно по другому поводу.
Текст сообщения и комментарии...
Вызвать C#.Net dll в QuickTestPro (VBScript)
четверг, октября 29, 2009Есть у меня необходимость использования в рамках автоматизации внутренних библиотек dll, написанных на C#. Однажды гуглив столкнулся с фразой, что некомовские (non-COM) библиотеки нельзя использовать в VBScript. Тогда на этом шаге остановился и обошелся переносом кода тогда ещё маленькой функции на VBScript.
Теперь же дела обстояли иначе: функций на самом деле было не мало, да и их реализация должна была бы занять достаточное время. И значит, поиски начались сначала.
Стоит сказать, что попытки реализовать предоженный метод были и раньше, но почему-то они не увенчались успехом. Теперь же всё получилось, поэтому решил написать этот пост.
Создаем новую C# dll с кодом:
namespace namespacename
{
public class classname
{
public int GetValue()
{
return 1;
}
}
}Set obj = DotNetFactory.CreateInstance("namespacename.classname", "c:\\namespacename.dll")
MsgBox obj.GetValue()Вот и всё, теперь наша библиотека работает в QuickTest'e.
Есть небольшой нюанс: по своей глупости мне казалось необходимым после пути к dll ещё одним параметром ставить micString - тип возвращаемого значения. И в таком виде оно не работало - ругалось на меня почти матными словами.
Удач в использовании QTP ;)
Текст сообщения и комментарии...
Тестирование GUI или сферический конь в вакууме
среда, октября 07, 2009Тестирование GUI (graphical user interface) очень редко проходит отдельно от основного функционального тестирования. Конечно:
- бывают большие проекты, где этому уделяется внимание;
- бывают пропущены серьезные проблемы, после которых все тестировщики проекта некоторое (зачастую недолгое) время тестируют ГУЙ / ГУИ / УЙ / УИ / UI / GUI
Вот скажите мне, разве можно тестировать то, принципы чего сам до конца не понимаешь? Разве можно найти ошибки в калькуляторе, если не знаешь таблицы умножения?
Многие менеджеры считают, что можно! И тогда все тестировщики становятся не только ГУИтестерами, они сразу ещё и ГУИтворители (ведь программисты исправят ровно так, как это скажет тестировщик).
Такая ситуация очень похожа на историю возникновения самих тестировщиков: программисты (или их начальники) поняли, что писать код и выпускать ПО без ошибок не одно и то же!
Я понимаю, должно пройти время, когда всем станет более-менее понятно: функциональное тестирование и тестирование графического интерфейса пользователя - должны делать разные по своей профессиональной подготовке люди!
Ладно, от теории перейдем к практике.
Предположим, что у нас есть окошко, где нужно выбрать период выпуска на прогулку сферического коня из вакуума. У нас есть два поля для ввода даты: Date From и Date To и кнока Submit.
Кроме дизайно-цветового решения всё выглядит даже ничего: можем задать даты и нажать кнопку Сабмит.
Умный тестировщик проверит эти поля на ввод разных значений: прошлый век, наше время, будущее время, (возможно) проверит ситуацию From >To и т.д. А вот когда этим начнет пользоваться конюх сферического коня в вакууме и реально захочет настроить даты выгула этого животного, он встретит реальные проблемы.
Одна из них - как мне настроить выгул коня только на один день? Поставить Date From = 10/07/2009 и Date To = 10/07/2009? Такое правило зачастую не сработает, ведь мудрые девелоперы сохраняют в базу данных ещё и время, а для обоих дат это будет 00:00:00. Можно поставить Date From = 10/07/2009 и Date To = 11/07/2009, но откуда мне как пользователю знать, что мой конь не будет гулять два дня, вместо одного?
Только методом проб и ошибок, запросов на изменение и приперательств с поставщиком ПО.
А вот если бы тестировщик посмотрел заранее в книгу про ГУИ тестирование, на минуту представил себя конюхом в штанах с кожей на жопе коленях, подумал о ежедневном выгуле любимого коня - все могло бы быть совсем иначе.
Не буду продолжать сей короткий опус, но скажу лишь одно - я сам попался на такое - мне не понравилось, и теперь буду представлять себя ковбоем/конюхом/или другим пользователем тестрируемого софта.
Текст сообщения и комментарии...
Баг в счетчике LiveInternet
четверг, августа 27, 2009Решил глянуть свою скромную статистику на блоге, и с нерешительностью пытался понять, что же мне показывает мой счетчик LiveInternet.ru
Как вы видите на скриншоте, этот счетчик показывает количество показанных страниц за 24 часа, количество посетителей за последние 24 часа и за сегодня.

Но почему-то сей счетчик показывает, что за последние 24 часа у меня посетителей было меньше, чем за сегодня!
Сколько не фантазировал, объяснения придумать не смог.
Есть у кого-нибудь толкование этому или это обычная бага-фича?
Текст сообщения и комментарии...
Должен ли тестировщик придираться к мелочам?
вторник, августа 04, 2009 Во время очередного батального сражения рабочего дня столкнулся с проблемой программистом, который в упор не хотел признавать, что допущенные при выполнении задачи мелочи тоже должны быть исправлены.
Проблема заключается в том, что уточнения по этим мелочам были получены по почте, а не указаны в таске сразу. Внесение изменений в таск с учетом таких мелочей заняло у программиста много времени, теперь же я прошу их убрать. Что вызывает естесственную реакцию противления: «Я убил столько времени, а теперь это все убрать???»
Собственно в этом и вопрос: На сколько придирчивым внимательным к мелочам должен быть тестировщик? Стоят ли такие мелочи напряжения в команде?
Мой ответ: всё зависит от сути этой «мелочи». Если на неё обратил внимание заказчик или другое важное лицо, то ответ очевиден. Если эта «мелочь» касается GUI, то я бы тоже хотел исправления таких «мелочей». Если же эта «мелочь» более внутренняя бага или мало заметная для пользователя, или заказчик даже не уточнил, как он хочет это видеть, тогда зеленый свет — программист может пока расслабиться и не исправлять такие мелкие замечания.
Кстати, в какую сторону едет автобус?
Ответ:в лево, ведь дверей не видно!
Текст сообщения и комментарии...













