Tuesday, September 29, 2009
Отличный рассказ об Империи
я впечатлился от истории о преобразовании России в Империю. Сказка, а жаль
Monday, September 28, 2009
Сервис коротких ссылок
Сервис коротких ссылок поможет не использовать длинные URL, особенно там, где длина ограничена - СМС через сайт оператора либо Twitter. Вставляете ссылку и нажимаете - сгенерировать. Всё.
О женщинах
Женщины - как дети, чуть что - сразу в слёзы и к маме.
Женщина - как Пётр Первый, хочет жить в столице, заставляет брить бороду и мечтает поехать в Европу.
Женщина - как ипотека, на 30 лет и по 10 тысяч в месяц.
Женщина - как инспектор ГИБДД: херни наговорит, деньги отберёт, настроение испортит, а ты ещё и виноват.
Женщина - как Фёдор Конюхов, хер знает где её носит и кто её спонсирует.
Женщина - как посольство, может и не разрешить с друзьями в Тайланд ехать.
Женщина - как шахматы, чуть не в ту сторону шаг, сразу мат.
Женщина - как фильмы ужасов, мне лично больше нравятся чужие.
Женщина в торговом центре - как маршрутка, пока не крикнешь - не остановится.
Женщина - как театр, сегодня комедия, завтра трагедия, а послезавтра гастроли в другом городе.
Женщина - как любимый свитер, ты его конечно очень любишь, но на фига он тебе в Турции нужен?
Женщина - как преподаватель на экзамене, вроде готовился всё правильно рассказал, а она тебя хоп и на какой то мелочи подловила.
Женщина - как чай, кто-то любит покрепче, кто не очень, а кто-то с другом один пакетик на двоих заваривает.
Женщина - как футболист, лежит стонет а ты думаешь "симулирует или нет?".
Женщина - как Пётр Первый, хочет жить в столице, заставляет брить бороду и мечтает поехать в Европу.
Женщина - как ипотека, на 30 лет и по 10 тысяч в месяц.
Женщина - как инспектор ГИБДД: херни наговорит, деньги отберёт, настроение испортит, а ты ещё и виноват.
Женщина - как Фёдор Конюхов, хер знает где её носит и кто её спонсирует.
Женщина - как посольство, может и не разрешить с друзьями в Тайланд ехать.
Женщина - как шахматы, чуть не в ту сторону шаг, сразу мат.
Женщина - как фильмы ужасов, мне лично больше нравятся чужие.
Женщина в торговом центре - как маршрутка, пока не крикнешь - не остановится.
Женщина - как театр, сегодня комедия, завтра трагедия, а послезавтра гастроли в другом городе.
Женщина - как любимый свитер, ты его конечно очень любишь, но на фига он тебе в Турции нужен?
Женщина - как преподаватель на экзамене, вроде готовился всё правильно рассказал, а она тебя хоп и на какой то мелочи подловила.
Женщина - как чай, кто-то любит покрепче, кто не очень, а кто-то с другом один пакетик на двоих заваривает.
Женщина - как футболист, лежит стонет а ты думаешь "симулирует или нет?".
Маразм крепчал
Биржа сайтов - смотреть и удивляться как люди сходят с ума, предлагая убогие странички за взрослые деньги
девелоперы - красавчики
Сегодня первый раз увидел скрипт в котором за 15 минут я не смог убрать "powered by Name_Of_Script".
Капец. но ничего, еще не вечер :)
Капец. но ничего, еще не вечер :)
Friday, September 18, 2009
Почему тестировщики пропустили эту ошибку?
Если вы проработаете в тестировании достаточно времени, то не раз встретите ситуации, когда вам зададут вопросы. Часть из них будет вполне разумными и честными, другая часть – наоборот. В этой статье, я помогу вам обнаружить и обезоружить такие вопросы, начиная с самого известного «Почему тестировщики пропустили эту ошибку?»
Доверие и безопасность.
Утверждают, что тестировщики должны были найти эту ошибку. Мы можем ответить, что действительно существует заслуживающая внимание причина, почему эта ошибка не была найдена. Далее несколько разъяснений, как я это использовал:
Минуточку: Должны ли были тестировщики найти эту ошибку? Было ли у них достаточно времени? Где был человек, который знал о возможности проблемы? Был ли запрос на использование программных средств, которые позволят найти ошибки такого рода? Такая ситуация может быть хорошим временем, чтобы сказать «Используя данные условия среды разработки/тестирования, мы не должны ожидать, что тестировщики найдут ошибки такого рода. Если же мы хотим не отдавать такие ошибки заказчику, нужно изменить...»
Вместо ответа «вот почему мы не нашли эту ошибку», вам стоит ответить своим вопросом. Это меняет вашу роль, вы перестаете быть жертвой, и становитесь... кем-то, кто действительно пытается повысить качество.
Вот один из примеров того, как можно ответить вопросом на вопрос: «Это верный вопрос, но я считаю, что подобные ошибки лучше предотвращать, чем находить в процессе тестирования. Другой вопрос, над которым стоит подумать: Почему эта ошибка возникла? Программисты ошиблись при реализации функциональности? Ошибка закралась, когда создавались требования? Или это ошибка коммуникации?»
Делая так, вы даете возможность интерпретировать эту ошибку шире – на пример, как эта ошибка появилась – это может спасти вас от враждебности и претензий.
Мой опыт говорит, что бывает три возможных пути развития событий: Команда разработчиков делает brainstorm и предотвращает подобные ошибки в будущем, или они пожимают плечами и говорят «ошибки случаются», или кто-то становится очень грустным. Первых два варианта выглядят хорошо. В третьем случае, иногда вы можете ответить «Я сам не люблю такие вопросы.» Но будьте осторожны. Вы должны знать тех, кому пишите. Мы стараемся построить дружественную атмосферу в команде.
Вместо того, чтобы чувствовать вину на себе и команде, обратите внимание беседы на то, что это всего лишь одна ошибка из сотен найденных в сотнях и тысячах (если не миллионах) строк кода. Если даже здесь ошибка, то что это меняет? Другими словами, вы можете изменить саму суть встречи: вместо упреков и порицания, к празднованию и радости.
Если ошибка на столько важна, что праздновать нечего, постарайтесь ввести самого вопрошателя в процесс проекта: «Это хороший вопрос, Иван. Ты считаешь, что тестировщики должны были найти эту ошибку? Я был бы рад услышать от тебя предложения о том, где бы мы могли улучшить свою работу.» Эта не защищает нас полностью от критики, но приглашает Ивана становится частью процесса, а не просто критиковать.
В своей книге Quality Software Management, Volume III Jerry Weinberg говорит, что не подходящее поведение может спасти команду от критики. Он приводит такой пример: «Посмотрите, какой пятнистый кот на крыше. Как он туда попал?» Тяжело критиковать кого-то, когда смотришь на котенка. Но вам стоит знать людей. С которыми разговариваете, ведь часть людей будут задавать эти вопросы раз за разом.
Консультант по командной работе Pollyanna Pixton предлагает другой вариант: Просто откажитесь отвечать на неудобный или нечестный вопрос.
Другими словами, если кто-то спрашивает у вас неудобный вопрос, ничего не говорите и смотрите на него, будто у него выросла ещё одна голова. Если вас продолжают спрашивать, продолжайте пристально глядеть. В итоге, он остановится. Точно вам говорю.
«Тряпка» или политик?
Я постарался представить конкретные предложения по тому, как отвечать на хорошо звучащие, но нечестные вопросы, такие как «Почему тестироващики пропустили эту ошибку?». Типичным ответом на мой очерк является фраза «Мой начальник был весьма зол.»
Да, это возможно. Традиционные альтернативы – отступление и успокаивание – могут быть менее болезненны. Если не считать того, что вы становитесь «тряпкой». Мой вам совет: знайте себе цену, и у вас будет что сказать в момент, когда вам зададут нечестный вопрос.
Да, начальник может быть зол. У вас может даже разгореться конфликт. Через пять лет, вы, возможно, будете работать на новой работе. Я предполагаю, что она будет лучше той, где вы работаете сейчас.
автор
Около 20 лет назад Tom DeMarco говорил о нечестных вопросах IT в своей статье Why does software cost so much?. Конечно, DeMarco не задает вопросы, он утверждает или предалагает тактику ведения переговоров. Такие вопросы часто так же возникают и в тестировании ПО. Вот мои любимые:
- «Почему тестировщики не нашли эту ошибку?»
- «Почему именно тестирование является «узким местом» проекта?»
- «Почему у нас столько ошибок?»
- «Что мы можем сделать, чтобы улучшить производительность отдела тестирования?»
- «Мы уже закончили тестирование?»
В зависимости от ситуации эти вопросы могут быть правильными и логичными. Но давайте посмотрим, какие утверждения спрятаны за этими вопросами:
- «Тестировщики должны были найти эту ошибку»
- «Тестирование – слабое место проекта»
- «У нас слишком много ошибок»
- «Тестирование занимает слишком много времени»
- «Тестирование должно быть завершено сейчас.»
Здесь и оценки и осуждения. Зачастую спрашивают таким способом, что разумные, логичные, правдивые ответы – всего лишь ... попытка защитить себя.
Доверие и безопасность.
Такие вопросы – это своеобразный трюк или техника. Руководство предполагает, что в ПО слишком много ошибок, и тестировщики несут за это прямую ответственность.
Лучшим ответом на эти вопросы будет занятие позиции, при которой они просто не будут заданы, - предотвратить это можно через обучение и общение. Стоит начать с внесения ясности руководству о том, что будет протестировано, в самом начале проекта. Затем, когда вы найдете ошибку, вы можете сказать: «4 недели назад мы договорились о том, что будет протестировано – за рамки этого я не вышел.» Другой способ – образование: я знаю одного менеджера , который подарил своему начальству в качестве новогоднего подарка копию Perfect Software: And Other Illusions about Testing.
Предупреждение проблем – это хорошая цель, но боюсь. Что это не поможет тестировщикам, которым приходится отвечать на такие вопросы прямо сейчас. Итак, моя цель сейчас – обезоружить вопрос, показать что такое осуждение не эффективно и направить команду на путь движения к честности, безопасности и командной работе. Делая это последовательно в итоге можете получить следующую ситуацию. Ваш новый вице президент задает похожий вопрос и тогда кто-нибудь из программистов или Product Managers объясняет ему на сколько данный вопрос нечестен. По крайней мере на это можно надеяться.
Думаю, что теории достаточно. Давайте представим. Что вы только что услышали в свой адрес «Почему тестировщики пропустили эту ошибку?». Вот возможные пути ответа:
1. Выбор исходных данных.
Утверждают, что тестировщики должны были найти эту ошибку. Мы можем ответить, что действительно существует заслуживающая внимание причина, почему эта ошибка не была найдена. Далее несколько разъяснений, как я это использовал:
- Ошибка воображения: Ошибка прошла потому что никто даже и предположить не мог о её существовании в этом месте . Программист не подумал о такой возможности, ведь именно он создал её. Команда , работающая над созданием требований, не представила возможности появления ошибки в этом месте, ведь иначе они бы написали более явные требования относительно этого места.Мне кажется, что вся команда допустила ошибку в этом месте. Возможно, в будущем,если группа тестирования будет иметь больше времени для обдумывания путей тестирования (кроме обычных действий), они придут к написанию таких сценариев, которые найдут эту ошибку.
Давайте теперь немного поговорим о давлении расписания и как это влияет на фантазию тестировщиков…
- Успешное управление рисков: хорошо. Одна ошибка смогла пройти незамеченной. Достаточно честно. Теперь давайте поговорим о том, что команда тестировщиков работала на протяжении последних двух недель и при этом они смогли найти 15 блокирующий ошибок, 19 критичных и 54 ошибки с приоритетом Normal. Если мы хотим, чтобы эта область была протестирована, мы должны уделить меньше времени другим областям. Итак, какой из 15 блокирующих тасков вы бы хотели, чтобы мы пропустили, потратив время на эту функциональность?
- Проблема коммуникации (общения): Мы не можем проверить все возможные комбинации входных данных, поэтому мы вынуждены их сортировать, выбирая более представительные. В данной ситуации мы ошиблись с выбором правильной выборки. Теперь, когда мы знаем о возможны проблемах, мы постараемся уделить больше внимания данной функциональности при тестировании. В будущем, если аналитики, программисты или другие участники проекта будут знать о возможных проблемах, они должны сообщать это команде тестирования.
2. Проблемы исходных данных.
Минуточку: Должны ли были тестировщики найти эту ошибку? Было ли у них достаточно времени? Где был человек, который знал о возможности проблемы? Был ли запрос на использование программных средств, которые позволят найти ошибки такого рода? Такая ситуация может быть хорошим временем, чтобы сказать «Используя данные условия среды разработки/тестирования, мы не должны ожидать, что тестировщики найдут ошибки такого рода. Если же мы хотим не отдавать такие ошибки заказчику, нужно изменить...»
3. Ответ вопросом.
Вместо ответа «вот почему мы не нашли эту ошибку», вам стоит ответить своим вопросом. Это меняет вашу роль, вы перестаете быть жертвой, и становитесь... кем-то, кто действительно пытается повысить качество.
Вот один из примеров того, как можно ответить вопросом на вопрос: «Это верный вопрос, но я считаю, что подобные ошибки лучше предотвращать, чем находить в процессе тестирования. Другой вопрос, над которым стоит подумать: Почему эта ошибка возникла? Программисты ошиблись при реализации функциональности? Ошибка закралась, когда создавались требования? Или это ошибка коммуникации?»
Делая так, вы даете возможность интерпретировать эту ошибку шире – на пример, как эта ошибка появилась – это может спасти вас от враждебности и претензий.
Мой опыт говорит, что бывает три возможных пути развития событий: Команда разработчиков делает brainstorm и предотвращает подобные ошибки в будущем, или они пожимают плечами и говорят «ошибки случаются», или кто-то становится очень грустным. Первых два варианта выглядят хорошо. В третьем случае, иногда вы можете ответить «Я сам не люблю такие вопросы.» Но будьте осторожны. Вы должны знать тех, кому пишите. Мы стараемся построить дружественную атмосферу в команде.
4. Направление дискуссии.
Вместо того, чтобы чувствовать вину на себе и команде, обратите внимание беседы на то, что это всего лишь одна ошибка из сотен найденных в сотнях и тысячах (если не миллионах) строк кода. Если даже здесь ошибка, то что это меняет? Другими словами, вы можете изменить саму суть встречи: вместо упреков и порицания, к празднованию и радости.
Если ошибка на столько важна, что праздновать нечего, постарайтесь ввести самого вопрошателя в процесс проекта: «Это хороший вопрос, Иван. Ты считаешь, что тестировщики должны были найти эту ошибку? Я был бы рад услышать от тебя предложения о том, где бы мы могли улучшить свою работу.» Эта не защищает нас полностью от критики, но приглашает Ивана становится частью процесса, а не просто критиковать.
5. Измени тему.
В своей книге Quality Software Management, Volume III Jerry Weinberg говорит, что не подходящее поведение может спасти команду от критики. Он приводит такой пример: «Посмотрите, какой пятнистый кот на крыше. Как он туда попал?» Тяжело критиковать кого-то, когда смотришь на котенка. Но вам стоит знать людей. С которыми разговариваете, ведь часть людей будут задавать эти вопросы раз за разом.
Консультант по командной работе Pollyanna Pixton предлагает другой вариант: Просто откажитесь отвечать на неудобный или нечестный вопрос.
Другими словами, если кто-то спрашивает у вас неудобный вопрос, ничего не говорите и смотрите на него, будто у него выросла ещё одна голова. Если вас продолжают спрашивать, продолжайте пристально глядеть. В итоге, он остановится. Точно вам говорю.
«Тряпка» или политик?
Я постарался представить конкретные предложения по тому, как отвечать на хорошо звучащие, но нечестные вопросы, такие как «Почему тестироващики пропустили эту ошибку?». Типичным ответом на мой очерк является фраза «Мой начальник был весьма зол.»
Да, это возможно. Традиционные альтернативы – отступление и успокаивание – могут быть менее болезненны. Если не считать того, что вы становитесь «тряпкой». Мой вам совет: знайте себе цену, и у вас будет что сказать в момент, когда вам зададут нечестный вопрос.
Да, начальник может быть зол. У вас может даже разгореться конфликт. Через пять лет, вы, возможно, будете работать на новой работе. Я предполагаю, что она будет лучше той, где вы работаете сейчас.
автор
Thursday, September 17, 2009
Как провести совещание
сегодня Майк Богдановский aka KpNemo даст свое видение на проблему организации и проведения совещаний. Майк работает программистом, но идея легко переноситься и на QA.
Прослушать сам подкаст можно здесь:
[audio:meetings.mp3]
Источник
Я продолжаю делиться разными знаниями на тему работы в стартапе и вообще в hi-tech. Сегодня я делюсь опытом на тему — “Как проводить совещания”. В подкасте:
* Как правильно посылать приглашение на совещание?
* Кого надо и кого не надо приглашать на совещания
* Как провести максимально эффективное совещание
* Как правильно проводить brainstorm?
* О чём говорить и о чем не говорить на совещаниях?
* В какие дни лучше всего делать совещания?
* Лучшая практика
* Итоги
Я думаю этот подкаст будет полезен тем, кто собирается окунуться в мир стартапов, или для тех кто уже там. Помимо этого я думаю этот подкаст будет полезен всем начинающим руководителям проектов.
Прослушать сам подкаст можно здесь:
[audio:meetings.mp3]
Источник
S.H.I.T.
TO: ALL EMPLOYEES
FR: MANAGEMENT
RE: SPECIAL HIGH INTENSITY TRAINING
In order to assure the highest levels of quality work and productivity from employees, it will be our policy to keep all employees well trained through our program of SPECIAL HIGH INTENSITY TRAINING (S.H.I.T.). We are trying to give employees more S.H.I.T. than anyone else.
If you feel that you do not receive your share of S.H.I.T. on the job, please see your manager. You will be immediately placed at the top of the S.H.I.T. list, and our managers are especially skilled at seeing that you get all the S.H.I.T. you can handle.
Employees who don’t take their S.H.I.T. will be placed in DEPARTMENTAL EMPLOYEE EVALUATION PROGRAMS (D.E.E.P. S.H.I.T.). Those who fail to take D.E.E.P. S.H.I.T. seriously will have to go to EMPLOYEE ATTITUDE TRAINING (E.A.T. S.H.I.T.). Since our managers took S.H.I.T. before they were promoted, they don’t have to do S.H.I.T. anymore, and are all full of S.H.I.T. already.
If you are full of S.H.I.T., you may be interested in a job training others. We can add your name to our BASIC UNDERSTANDING LECTURE LIST (B.U.L.L. S.H.I.T.). Those who are full of B.U.L.L. S.H.I.T. will get the S.H.I.T. jobs, and can apply for promotion to DIRECTOR OF INTENSITY PROGRAMMING (D.I.P. S.H.I.T.).
If you have further questions, please direct them to our HEAD OF TRAINING, SPECIAL HIGH INTENSITY TRAINING (H.O.T. S.H.I.T.).
Thank you,
BOSS IN GENERAL
SPECIAL HIGH INTENSITY TRAINING
(B.I.G. S.H.I.T.)
True tester
Первое сентября. Учительница первого класса - первоклассникам:
- Здравствуйте, дети! Меня зовут Марья Ильинишна. Если кто-то захочет задать вопрос, поднимите руку.
Вовочка тянет руку.
- Ты что-то хочешь спросить?
- Нет, проверяю как работает система.
- Здравствуйте, дети! Меня зовут Марья Ильинишна. Если кто-то захочет задать вопрос, поднимите руку.
Вовочка тянет руку.
- Ты что-то хочешь спросить?
- Нет, проверяю как работает система.
Недостатки интернет-магазинов на Украине
Сегодня обсуждали сервисы для пользователей(обсуждали с одним манагером в . Если кто не в курсе - это крупнейший интернет-аукцион в Голландии, куплен by ) и я задумался что мне больше всего нравится и не нравится в отечественных интернет-магазинах.
1. Не нравится: отсутствие фотографий товара или их наличие в количестве одной-двух штук в минимальном качестве и разрешении с убогими watermarks. Я в жизни не куплю товар который не осмотрю со всех сторон. Отстойные фотографии -> значит хозяева - школьники, которые тырят фотографии в google. Приговор.
2. Нравится: инет-магазин(кажется ) который пишет видео и выкладывает на с описанием товара. Что не очень - так это то, что сейчас не то время, когда трафик чего-то стоит и можно писать ролики в нормальном качестве. Да и каждая 3-я камера прекрасно пишет в HD.
2. Нравится: когда во время поиска выводится не просто тупой список товаров(для меня NP-R510-XAA0UA ничем не отличается от NP-R505-FS01UA, а для вас?) а список и фотографиями при наведении на иконку - сразу понимаешь то ты нашел или не то.
3. Не нравится: отсутствие товара. Ну это же не дело - писать на сайте "товар есть в наличии" и узнавать что его нет и не предвидится после связи с support.
4. Не нравится: почему до сих пор нет оплаты Визой или Мастеркардом я частично не понимаю. Не понимаю, почему не включать эту опцию для проверенных покупателей. Да и найти оплату вебманями иногда проблематично. А тот факт, что один WMZ считают за 0.97$ вообще раздражает - получите аттестат и выводите себе без процентов, ан нет - жмутся.. Неужели трудно понять что если я оплатил один раз, то я прийду с большой вероятностью еще и еще, особенно если у меня часть дохода в этих самых электронных деньгах?
5. Не нравится: попапы. Просто раздражают. Я думаю ведь совсем не трудно сделать ajax форму для ввода логина и пароля либо для восстановления пароля. Так нет - rozetka делает popup(наверное для IE, мне бабушка рассказывала что есть такой браузер) которые мало что вылетают, так еще и ресайз окон делают.
6. Не нравится: поддержка. Скажите, зачем писать на сайте номера icq, если по номерам никто не отвечает? И опять же, это я (почти) пропускаю тот факт, что имена в половине icq номеров не названия магазинов а Саньки, Евгении, Векторы и прочие.. Разве трудно завести 2 номера: первый с названием магазина и второй для общения с друзьями? Как вывод, лучшая поддержка - это сделанная с использованием siteheart.ru - конечно история не сохраняется, но то, что мне попадалось - отвечают довольно-таки быстро, а с профессионализмом тут конечно еще всё грустно(например, в -е на вопрос о выборе видеокамеры меня послали в раздел с видеокамерами.. хорошо что хоть туда..)
7. Не нравится: доставка. Вернее, та часть которая связана с отслеживанием товара. Ну почему я должен звонить и искать заказанный товар, если мне сказали что он будет сегодня в 11, а уже 17:50?
8. Не нравится: отсутствие отзывов. Это болезнь просто какая-то. я давно полюбил яндекс-маркет, мобиле-ревью и ixbt за то, что они дают человеческие отзывы тому, что я собираюсь купить. Технические характеристики не могут заменить человеское описание того, что пульт отстойный у телевизора или что данная модель не рекомендуется по причине частой поломки(эта часть наверняка далеко не всем выгодна). Попросите покупателей оставить отзыв, поощряйте тех кто оставляет отзывы - способов море и люди будут приходить минимум только чтобы почитать отзывы(а сейчас просто нет повода заходить, разве что цену посмотреть).
9. Не нравится: многие магазины не имеют своего адреса. Как и все люди я не люблю обман и кидалово и адрес является для меня успокоительным :)
Самыми критичными недочетами я считаю пункты 1 и 8. Надеюсь, мой отзыв прочитают владельцы украинских магазинов и это поможет им улучшить качество, к которому я так стремлюсь :)
1. Не нравится: отсутствие фотографий товара или их наличие в количестве одной-двух штук в минимальном качестве и разрешении с убогими watermarks. Я в жизни не куплю товар который не осмотрю со всех сторон. Отстойные фотографии -> значит хозяева - школьники, которые тырят фотографии в google. Приговор.
2. Нравится: инет-магазин(кажется ) который пишет видео и выкладывает на с описанием товара. Что не очень - так это то, что сейчас не то время, когда трафик чего-то стоит и можно писать ролики в нормальном качестве. Да и каждая 3-я камера прекрасно пишет в HD.
2. Нравится: когда во время поиска выводится не просто тупой список товаров(для меня NP-R510-XAA0UA ничем не отличается от NP-R505-FS01UA, а для вас?) а список и фотографиями при наведении на иконку - сразу понимаешь то ты нашел или не то.
3. Не нравится: отсутствие товара. Ну это же не дело - писать на сайте "товар есть в наличии" и узнавать что его нет и не предвидится после связи с support.
4. Не нравится: почему до сих пор нет оплаты Визой или Мастеркардом я частично не понимаю. Не понимаю, почему не включать эту опцию для проверенных покупателей. Да и найти оплату вебманями иногда проблематично. А тот факт, что один WMZ считают за 0.97$ вообще раздражает - получите аттестат и выводите себе без процентов, ан нет - жмутся.. Неужели трудно понять что если я оплатил один раз, то я прийду с большой вероятностью еще и еще, особенно если у меня часть дохода в этих самых электронных деньгах?
5. Не нравится: попапы. Просто раздражают. Я думаю ведь совсем не трудно сделать ajax форму для ввода логина и пароля либо для восстановления пароля. Так нет - rozetka делает popup(наверное для IE, мне бабушка рассказывала что есть такой браузер) которые мало что вылетают, так еще и ресайз окон делают.
6. Не нравится: поддержка. Скажите, зачем писать на сайте номера icq, если по номерам никто не отвечает? И опять же, это я (почти) пропускаю тот факт, что имена в половине icq номеров не названия магазинов а Саньки, Евгении, Векторы и прочие.. Разве трудно завести 2 номера: первый с названием магазина и второй для общения с друзьями? Как вывод, лучшая поддержка - это сделанная с использованием siteheart.ru - конечно история не сохраняется, но то, что мне попадалось - отвечают довольно-таки быстро, а с профессионализмом тут конечно еще всё грустно(например, в -е на вопрос о выборе видеокамеры меня послали в раздел с видеокамерами.. хорошо что хоть туда..)
7. Не нравится: доставка. Вернее, та часть которая связана с отслеживанием товара. Ну почему я должен звонить и искать заказанный товар, если мне сказали что он будет сегодня в 11, а уже 17:50?
8. Не нравится: отсутствие отзывов. Это болезнь просто какая-то. я давно полюбил яндекс-маркет, мобиле-ревью и ixbt за то, что они дают человеческие отзывы тому, что я собираюсь купить. Технические характеристики не могут заменить человеское описание того, что пульт отстойный у телевизора или что данная модель не рекомендуется по причине частой поломки(эта часть наверняка далеко не всем выгодна). Попросите покупателей оставить отзыв, поощряйте тех кто оставляет отзывы - способов море и люди будут приходить минимум только чтобы почитать отзывы(а сейчас просто нет повода заходить, разве что цену посмотреть).
9. Не нравится: многие магазины не имеют своего адреса. Как и все люди я не люблю обман и кидалово и адрес является для меня успокоительным :)
Самыми критичными недочетами я считаю пункты 1 и 8. Надеюсь, мой отзыв прочитают владельцы украинских магазинов и это поможет им улучшить качество, к которому я так стремлюсь :)
Помните об этом
С точки зрения QA, магия эта часто очень сомнительного качества.
Недавно прочитал рассказ одного человека, которого одна фраза преподователя в университете подстегнула к самообразованию и достижению тех высот, о которых он раньше только мечтал.
Рассказ был приблизительный такой: обычный универ, обычный экзамен у препода по праву. Препод не парясь ставит всем зачеты.. Студенты рады шаре, кроме одного. Собственно он и спросил препода - мол, не жалко ставить нашару оценки? На что препод ответил очень просто: "Оценок мне не жалко, и мне даже выгодно ставить как можно больше хороших. Выгода мне от этого прямая - чем больше будет на улице профанов типа вас, тем больше будут котироваться профессионалы к которым я отношусь и тем большие деньги я буду получать за свою работу". Признайтесь - есть в этом здравый смысл.
Так вот и с программистами - чем больше их будет, тем больше говно-программ будет писаться и тем больше пользователи будут искать и ценить качественные продукты, которые могут быть качественными только после цикла тестирования.
Вот и думайте после этого ;)
О Selenium на болгарском языке :)
Многие слышали о Selenium, который может очень хорошо помочь в автоматизации некоторой рутины во время тестирования веб приложений.
Так вот, сегодня ребята нашли неплохую презентацию по данному продукту, но.. на болгарском языке..
Почитайте ради юмора, некоторые серьезные вещи звучат очень и очень смешно :)
пара вырезок:
"на уеб приложения"
"съобщения за грешки"
"обикновено"
"трудоемко (и скучно)"
"человешки фактор"
"управлява браузър"
"парола"
ну и много таких прикольных, с точки зрения русского языка и смысла выражений :)
Так вот, сегодня ребята нашли неплохую презентацию по данному продукту, но.. на болгарском языке..
Почитайте ради юмора, некоторые серьезные вещи звучат очень и очень смешно :)
пара вырезок:
"на уеб приложения"
"съобщения за грешки"
"обикновено"
"трудоемко (и скучно)"
"человешки фактор"
"управлява браузър"
"парола"
ну и много таких прикольных, с точки зрения русского языка и смысла выражений :)
Об одном стиле менеджмента
Сегодня приведу описания одного из стилей управления, называемого микроменеджментом. Отрывок касается программистов, но отлично переносится и на лидов команды тестеров.
материал взят
Микроменеджмент - попытка сверхдетального контроля за работой подчиненного. По моим наблюдениям, в программировании это весьма распространненная практика.
Ведь обычно (проектный) менеджер - это вчерашний программист. Причем программист наверное неплохой, по крайней мере был таковым, когда программировал. Сейчас он проектирует/управляет и кодировать ему некогда, реализацией целая команда занимается.
Тогда и появляется боязнь, что “они” все сделают “не так” и желание проконтролировать процесс реализации, вплоть до выбора имен классов, советов по реализации конкретных алгоритмов и прочее. Причем часто технические вопросы продавливаются авторитетом - “я так сказал”.
Проблема в том, что такая “материнская опека” обычно только вредит. Она показывает, что менеджер не доверяет своей команде и не верит, что она способна самостоятельно вытянуть проект. А ведь “как вы яхту назовете …”. Теряется мотивация, инициатива подавляется, в конце концов, это просто раздражает (меня, по крайней мере).
Конечно же, контролировать процесс нужно. Но по возможности незаметно и ненавязчиво. Если команда слабая, то даже самая пристальная опека не поможет. Сильной же команде такое может принести урон значительно больший, чем потенциальные выгоды.
Программисты - как дети - имеют право на ошибку. Без ошибок нет роста. Безответственный программист (за которого все решает менеджер) - плохой программист. Найти же правильный баланс между свободой и контролем - это и есть забота хорошего менеджера.
материал взят
Сложности установки Nagios на Debian
Дома бился пару дней чтобы поставить Nagios на Debian.
Оказалось не всё так тривиально.
Хотел отметить пару моментов, с которыми мне пришлось столкнуться и какие решения я принял:
1. Когда ставишь библиотеку libjpeg-v6b для GD, то файлы не копируются автоматически в /user/local/lib & /user/local/include, т.е. надо их из распакованной папки надо копировать ручками.
2. Для установки GD надо предустановленную библиотеку gd-devel, так вот - я делал в директории Nagios пару дней ./configure и он мне выдавал ошибку что нет библиотеки GD, оказалось, надо ставить библиотеку libgd-dev с которой конфигурация нагиоса прошла "на ура" вообще без параметров.
3. Не работала обработка cgi-bin на apache2. Т.е. после запуска нагиоса, и прохождения базовой аутентификациии я видел главную страницу, но не мог открыть ни одной страницы, для которой путь значился как /nagion/cgi-bin. Для начала оказалось, что надо включить в apache2.conf строку "addhandler cgi-script .cgi"
4. Ну и последний момент, который пришлось долго гуглить: надо добавить в конфигурацию апача алиас для cgi-bin, приблизительно так:
Теперь надо понять как настроить мониторинг :)
Дальше по планам:
1. Буду ставить шифрованный впн
2. Буду переводить сайты на связку Apache + Nginx
3. Настроить безопасность.
Оказалось не всё так тривиально.
Хотел отметить пару моментов, с которыми мне пришлось столкнуться и какие решения я принял:
1. Когда ставишь библиотеку libjpeg-v6b для GD, то файлы не копируются автоматически в /user/local/lib & /user/local/include, т.е. надо их из распакованной папки надо копировать ручками.
2. Для установки GD надо предустановленную библиотеку gd-devel, так вот - я делал в директории Nagios пару дней ./configure и он мне выдавал ошибку что нет библиотеки GD, оказалось, надо ставить библиотеку libgd-dev с которой конфигурация нагиоса прошла "на ура" вообще без параметров.
3. Не работала обработка cgi-bin на apache2. Т.е. после запуска нагиоса, и прохождения базовой аутентификациии я видел главную страницу, но не мог открыть ни одной страницы, для которой путь значился как /nagion/cgi-bin. Для начала оказалось, что надо включить в apache2.conf строку "addhandler cgi-script .cgi"
4. Ну и последний момент, который пришлось долго гуглить: надо добавить в конфигурацию апача алиас для cgi-bin, приблизительно так:
ScriptAlias /cgi-bin/nagios /user/local/nagios/sbin
ScriptAlias /nagios/cgi-bin /user/local/nagios/sbin
Теперь надо понять как настроить мониторинг :)
Дальше по планам:
1. Буду ставить шифрованный впн
2. Буду переводить сайты на связку Apache + Nginx
3. Настроить безопасность.
Строить не ломать
Тестировщик, чтобы правильно ломать, должен уметь и строить. Иногда :)
Сегодня приведу список, с помощью которого можно ускорить работу сайта. Список будет непоследовательный, но не менее полезный из-за этого. Как известно, быстродействие можно улучшить либо а) сделав окружение мощнее б) оптимизировав текущие ресуры. Я пойду по второму пути.
до и после установки APC, я получил значительные изменения в лучшую сторону(connection time уменьшился в 57%, transfer rate увеличился на 64%, количество обработанных запросов в секунду увеличилось на 63%).
upd. следующий факт изрядно попортил мне крови: при переносе базы из локального вордпресса к хостеру, у меня постоянно вываливались разного рода ошибки, на maxsite рекомендовали удалить пустую строку после директивы ?> для php секции.. всё оказалось банально - phpmyadmin на локальной машине просто криво экспортировал дамп базы. Задача быстро решилась с помощью плагина для Wordpress: DB-backup.
Сегодня приведу список, с помощью которого можно ускорить работу сайта. Список будет непоследовательный, но не менее полезный из-за этого. Как известно, быстродействие можно улучшить либо а) сделав окружение мощнее б) оптимизировав текущие ресуры. Я пойду по второму пути.
- Установка APC на Дебиан. APC - это Alternative PHP Cache.
- Применить хотя бы часть из советов на этом сайте - например, включение gzip в Apache, компрессия css и js файлов, оптимизация изображения
- ПереСжать картинки
ab -n 1000 -c 2 -w http://iamqa.com
до и после установки APC, я получил значительные изменения в лучшую сторону(connection time уменьшился в 57%, transfer rate увеличился на 64%, количество обработанных запросов в секунду увеличилось на 63%).
upd. следующий факт изрядно попортил мне крови: при переносе базы из локального вордпресса к хостеру, у меня постоянно вываливались разного рода ошибки, на maxsite рекомендовали удалить пустую строку после директивы ?> для php секции.. всё оказалось банально - phpmyadmin на локальной машине просто криво экспортировал дамп базы. Задача быстро решилась с помощью плагина для Wordpress: DB-backup.
О необходимости точно формулировать задания
Периодически у меня возникают проблемы взаимопонимания с людьми. И вроде говорим мы оба на русском языке - ан нет, не понимаем, начинаем говорить громче и быстрее со всеми отсюда вытекающими..
В чем причина?
За последние пару недель мне пару человек подсказали в чем может быть дело и сегодня я наткнулся на статью, которая частично покрывает пробел.
Итак,
На самом деле, статья покрывает сразу 2 понятия: "необходимость точно формулировать мысли" и "нахождение общего языка", но от этого не стает менее интересной :)
авто статьи
В чем причина?
За последние пару недель мне пару человек подсказали в чем может быть дело и сегодня я наткнулся на статью, которая частично покрывает пробел.
Итак,
Пример 1:
Пошёл старик к синему морю. Стал он кликать золотую рыбку. А какую рыбку - не уточнил. Приплыла к нему золотая акула. Ну… и всё..
Пример 2:
Жил некий праведный человек. Праведную жизнь вёл же он для того, чтобы возымела силу молитва его, вознесённая к небу. И когда решил он, что пришло время, истово помолился он и возопил:
- Господи, пошли мне богатства!
В небесах хихикнуло, и хрипловатый голос, копируя интонации Вахтанга Кикабидзе, торжественно сказал:
- Твои года - твоё богатство!
И человек мгновенно поседел, одряхлел, сморщился и, прямо скажем, недолго прожил…
Пример 3:
Ты совершил великий подвиг, рыцарь. Что желаешь ты получить в дар?
- Волшебные доспехи хочу! Чтобы ни один меч на свете не мог их пробить!
- Угу. Есть такие. Сейчас найдём. Сейча-а-ас… Ага, вот. Носи на здоровье. Не в силах повредить их ни Дюрандаль, ни Эскалибур, ни любой меч на свете!
В ближайшей же стычке рыцарь был пробит насквозь копьём…
Когда-то давно мне объясняли, что у каждого человека существуют понятийные метаполя. Разговор двух людей в одном понятийном поле позволяет понимать друг друга “с полуслова”.
Первая проблема заключается в том, что, несмотря на то, что Вася (заказчик) и Петя (исполнитель) владеют несколькими понятийными полями каждый, эти поля могут не пересекаться. Тогда “ой”. Консенсуса достигнуть практически невозможно.
Вторая проблема заключается в выборе подходящего понятийного поля, в котором следует вести диалог. Когда Вася владеет несколькими понятийными полями, он может последовательно перебирать их пока не найдет 3-5 пересекающихся с Петей и не выберет то, в котором передача теорий происходит с наименьшими затратами. На это уходит время. Пары - тройки лет совместной работы бывает достаточно. А бывает, что и нет.
Классическим решением обоих проблем является “толмач”. Который, не только переводит с русского на английский фразу: “Мой папа секретарь обкома”, - но и трансформирует ее с учетом другого культурного контекста: “Данный проект имеет огромные шансы на успех, поскольку на него будут выделены все необходимые административные, материальные и людские ресурсы”. Или, если хотите “У него шило в …” трансформирует в фразу “Он занимает активную жизненную позицию”
Точно так же этот человек переводит фразу разработчика “Там это захардкожено в пяти десятках мест”, - в: “Наша система не отвечает требованиям качества по такому показателю, как расширяемость и поэтому выполнение вашей пустяковой заявки потребует 1500$ при допустимом риске пропущенных ошибок, которые обойдутся нам еще в 4000$ на пострелизной поддержке. Итого, это изменение встанет нам в 5500 плюс-минус 1500″.
Исторически сложилось, что понятийные метаполя заказчиков ПО и исполнителей программных проектом не пересекаются (ну почти). Для преодоления этой пропасти назначают “толмача”, которого называют аналитиком, или менеджером проекта, или продакт оунером, где как. Но большинство гуру сходятся в том, что этот толмач должен свободно ориентироваться как в культурном контексте заказчика, так и исполнителя. Иначе его работа не имеет большого смысла.
PS. Официант должен свободно ориентироваться в понятийном поле клиента. И автоматически должен трансформировать фразу “Гребешков мне! И побольше.” в то, что клиент хочет на самом деле. Иначе он плохой официант. Ну, вы их регулярно наблюдаете в естественно среде обитания.
PSS. “У вещей есть понятия, не требующие объяснений, по-умолчанию.” - это утопия. Я хотел бы побывать на таком глобусе. В этой стране мои совершенно недвусмысленные заказы исполнитель не понимает. И чаще мне приходится переходить на язык исполнителя, нежели наоборот.
На самом деле, статья покрывает сразу 2 понятия: "необходимость точно формулировать мысли" и "нахождение общего языка", но от этого не стает менее интересной :)
авто статьи
Работа с командной строкой в Windows XP
Банальные команды вида cd, dir и так далее пропустим, рассмотрим наиболее популярные и часто используемые:
"ping" - командой проверяем, есть ли удаленный хост в сети. Бывают случаи, когда firewall режет icmp пакеты, и тогда можно использовать утилиту telnet.
"telnet" - утилита позволяет управлять удаленным хостом, на котором выполняется telnet сервер либо для проверки сервисов на разных портах. Например, чтобы проверить, есть ли на удаленном хосте web сервер запускаем "telnet <хост> 80". Подобным образом можно проверить наиболее популярные сервисы: POP3(110), SMTP(25), SSH(22), FTP(21) и так далее...
"ipconfig" - показывает сетевую конфигурацию. В основном использую для обновления сетевых настроек "ipconfig /release" для сброса настроек всех сетевых интерфейсов и "ipconfig /renew" для получения настроек. MAC адрес можно получить либо набрав "ipconfig /all" либо командой "getmac"
"net use" - команда отображает ваши соединения к удаленным хостам
"net use * /delete" - эта команда используется когда, например, вы зашли на удаленный хост под одним именем(локальным или доменным) но по какой-то причине вам надо зайти на тот же хост, но уже под другим именем.
"net share" - команда показывает какие ресурсы отданы в общий доступ. Если добавить ключ "/delete" то можно удалить ресурсы из общего доступа за исключением системных C$, D$, ...
"tracert" - проследить путь маршрута от локального хоста до удаленного.
"nslookup" - используется когда необходимо получить ip адрес по доменному имени.
"route" - команда работает с таблицей маршрутизации
"shutdown" - утилита позволяет выключить или перезагрузить хост
Интересные, но не такие известные команды:
tree - строит в консоли дерево каталогов
taskkill - позволяет убить процессы или дерево процессов по фильтрам
tasklist показывает список процессов
systeminfo - выводит суммарную информацию по хосту
sfc - полезная команда - сканирует важные системные файлы на изменения и в случае изменений подменяет на оригинальные, которые были в установке Windows
netstat - показывает сетевые подключения
bootcfg - показывает содержимое boot.ini
at - утилита для запуска команд по расписанию
"ping" - командой проверяем, есть ли удаленный хост в сети. Бывают случаи, когда firewall режет icmp пакеты, и тогда можно использовать утилиту telnet.
"telnet" - утилита позволяет управлять удаленным хостом, на котором выполняется telnet сервер либо для проверки сервисов на разных портах. Например, чтобы проверить, есть ли на удаленном хосте web сервер запускаем "telnet <хост> 80". Подобным образом можно проверить наиболее популярные сервисы: POP3(110), SMTP(25), SSH(22), FTP(21) и так далее...
"ipconfig" - показывает сетевую конфигурацию. В основном использую для обновления сетевых настроек "ipconfig /release" для сброса настроек всех сетевых интерфейсов и "ipconfig /renew" для получения настроек. MAC адрес можно получить либо набрав "ipconfig /all" либо командой "getmac"
"net use" - команда отображает ваши соединения к удаленным хостам
"net use * /delete" - эта команда используется когда, например, вы зашли на удаленный хост под одним именем(локальным или доменным) но по какой-то причине вам надо зайти на тот же хост, но уже под другим именем.
"net share" - команда показывает какие ресурсы отданы в общий доступ. Если добавить ключ "/delete" то можно удалить ресурсы из общего доступа за исключением системных C$, D$, ...
"tracert" - проследить путь маршрута от локального хоста до удаленного.
"nslookup" - используется когда необходимо получить ip адрес по доменному имени.
"route" - команда работает с таблицей маршрутизации
"shutdown" - утилита позволяет выключить или перезагрузить хост
Интересные, но не такие известные команды:
tree - строит в консоли дерево каталогов
taskkill - позволяет убить процессы или дерево процессов по фильтрам
tasklist показывает список процессов
systeminfo - выводит суммарную информацию по хосту
sfc - полезная команда - сканирует важные системные файлы на изменения и в случае изменений подменяет на оригинальные, которые были в установке Windows
netstat - показывает сетевые подключения
bootcfg - показывает содержимое boot.ini
at - утилита для запуска команд по расписанию
Как проводить совещания?
Одна бывшая сотрудница компании, где я сейчас работаю, зная мою любовь к организационным мероприятиям, прислала ссылку на статью о том, как же стоит проводить совещания. Прочитав и проанализировав статью, пришел к выводу, автор несомненно прав в большинстве пунктов.
Как провести совещание? Как заинтересовать сотрудников? Как сделать совещание максимально полезным? Умение качественно провести совещание, по моему мнению, большой и редкий талант. Зачастую такие мероприятия превращаются в что-то скучное и занудное. Бороздя просторы интернета, нашел и собрал несколько интересных советов по проведению совещаний. Если вы хотите с максимальной эффективностью донести свои мысли и выслушать мысли собравшихся, поступайте в соответствии с правилами:
- Всегда сообщайте о теме совещания заранее. Мозг любит формировать связи и находить закономерности. Заранее давая ему пищу для размышлений, вы позволяете связать проблему с уже известными схемами и предложить новые идеи.
- Обеспечьте четкую структуру совещания. Мозг предпочитает располагать вещи в определенном порядке.
- Хвалите людей. Похвала повышает самооценку человека и создает атмосферу, способствующую генерации новых идей. Полезно поддерживать соотношение похвалы и критики в пропорции 4:1.
- Потратьте время на приведение участников совещания в должное эмоциональное состояние. В условиях стресса мозг работает только на примитивном уровне, необходимом для выживания организма. Если мы не добились состояния спокойной сосредоточенности, то эффективность нашей работы будет невелика.
- Делите обсуждаемую тему на более мелкие вопросы. Наш мозг работает лучше, когда получает возможность сосредоточиться на конкретных элементах. Подобная разбивка также улучшает запоминание.
- Используйте юмор. При смехе наш мозг вырабатывает нейротрансмиттеры, которые усиливают внимание и память.
- Используйте такую форму, как диалог. Наш мозг нуждается в обратной связи, непосредственным и постоянным источником которой служит именно диалог. Если вы что-то сказали человеку во время совещания, это вовсе не означает, что ваши слова оказали желаемое воздействие.
- Делайте выводы и устанавливайте связь с предыдущими и последующими совещаниями. Стремление мозга устанавливать связи и его способность отбирать главное говорят о том, что полезно предлагать идеи, над которыми можно работать после окончания совещания. С точки зрения запоминания схемы могут оказаться предпочтительнее традиционных записей.
- Наблюдайте за степенью концентрации людей. Время концентрации у всех различно, но регулярные перерывы позволят обеспечить мозг кровью, богатой кислородом и питательными веществами. Тем не менее увлеченное обсуждение иногда лучше не прерывать.
- Потратьте время на осмысление того, какие из приемов сработали, а какие нет. Еще один важный и часто игнорируемый элемент обратной связи заключается в обсуждении прошедшего совещания и планировании изменений для исправления ошибок.
Желаю Вам проводить совещания, связанные исключительно с положительными событиями и переменами, и всегда быть на высоте в этом нелегком ремесле!
Собеседование для соискателя в QA
Как проводить собеседование на тестировщика соискателя, который еще не имеет опыта тестирования?
В интернете можно найти много практик как проводить собеседование и что необходимо спрашивать, чтобы получить уверенность в том, что человек подходящий и не подведет во время процесса.
Расскажу, что можно спрашивать и какие ответы я ожидаю исходя из собеседований, которые проводил я. Правда надо сделать некоторую оговорку, что я не проводил психологическое тестирование - сугубо техническое.
Для начала, советую прочитать статью "Теоретик или практик" - это поможет определится с тем, на что делать упор во время собеседования. Как и в тестировании, интересней и полезней находить "пробелы в знаниях", нежели прийти к выводу, что соискатель всё знает. И потому теоретиков мы спрашиваем практические решения, практиков - спрашиваем теорию.
Определение кругозора соискателя.
Спрашиваем по несколько простых и по несколько сложных вопросов по разным областям: операционные системы(Windows, *nix), сети, программирование, БД, технологии, веб.
В интернете можно найти много практик как проводить собеседование и что необходимо спрашивать, чтобы получить уверенность в том, что человек подходящий и не подведет во время процесса.
Расскажу, что можно спрашивать и какие ответы я ожидаю исходя из собеседований, которые проводил я. Правда надо сделать некоторую оговорку, что я не проводил психологическое тестирование - сугубо техническое.
Для начала, советую прочитать статью "Теоретик или практик" - это поможет определится с тем, на что делать упор во время собеседования. Как и в тестировании, интересней и полезней находить "пробелы в знаниях", нежели прийти к выводу, что соискатель всё знает. И потому теоретиков мы спрашиваем практические решения, практиков - спрашиваем теорию.
Определение кругозора соискателя.
Спрашиваем по несколько простых и по несколько сложных вопросов по разным областям: операционные системы(Windows, *nix), сети, программирование, БД, технологии, веб.
Требования к тестировщикам
Требования к тестировщикам - перечень тех качеств, которыми должен обладать тестировщик для плодотворной работы в коллективе.
Хорошие технические знания. Компьютер не должен быть иконой, это должен быть инструмент для выполнения работы.
Внимательность. Важно замечать лююбое поведение тестируемого продукта и делать выводы о наличии дефектов.
Решительность и уверенность. Без этих качеств, трудно отстоять свою точку зрения. В итоге много времени(и своего и чужого) будет тратится чтобы решится на submit дефекта или написание письма руководителю.
Инициатива. Без этого качества у нас будет отряд хороших роботов, способных хорошо(допустим) выполнять только те задачи, которые мы перед ними ставим.
Стрессоустойчивость. Накануне релиза, все начинают очень быстро шевелится и часто нервозность приводит к неадватным постановкам заданий, напряженному общению, потери внимательности и так далее.
Умение работать в коллективе. Очень важная характеристика потому как вся работа строится на взаимоотношениях с коллегами.
Умение логически мыслить. Здесь все ясно.
Хорошие технические знания. Компьютер не должен быть иконой, это должен быть инструмент для выполнения работы.
Внимательность. Важно замечать лююбое поведение тестируемого продукта и делать выводы о наличии дефектов.
Решительность и уверенность. Без этих качеств, трудно отстоять свою точку зрения. В итоге много времени(и своего и чужого) будет тратится чтобы решится на submit дефекта или написание письма руководителю.
Инициатива. Без этого качества у нас будет отряд хороших роботов, способных хорошо(допустим) выполнять только те задачи, которые мы перед ними ставим.
Стрессоустойчивость. Накануне релиза, все начинают очень быстро шевелится и часто нервозность приводит к неадватным постановкам заданий, напряженному общению, потери внимательности и так далее.
Умение работать в коллективе. Очень важная характеристика потому как вся работа строится на взаимоотношениях с коллегами.
Умение логически мыслить. Здесь все ясно.
Теоретик или Практик?
На днях прочитал интересную статью Алексея Булата про классификацию тестировщиков на теоретиков и практиков. Задумался и пришел к выводу, что абсолютно солидарен с его мнением - каждый инженер должен владеть и той и другой составляющей для плодотворной работы
Сама статья без изменений:
Сама статья без изменений:
Вспомнились старые времена, когда приходилось в промышленных масштабах проводить собеседования на позиции от тестера до тест менеджера... Много интересного народу повстречал. Были и большие бородатые дядьки, и симпотные блондинки с голубыми глазами и просто серые мышки, готовые работать за хлеб и воду...
Так уж повелось, что собеседование у нас было построено на 4-ех уровневой основе. То есть проводили его 4 человека по очереди, у каждого были свои вопросы на свои темы, были свои тестовые задания ну и свой стиль, такой как "плохой и хороший полицейский"... шутка...
Ну а теперь ближе к телу. Была определенная группа соискателей, причем выделенная не только мной, но и моими коллегами, - это выходцы из Беларуси. Что в ней было особенного? А вот пример, конечно не 100% из жизни, но аналогию сразу можно будет провести:
- Что такое тестированием производительности?
- не знаю
- Ну может быть вы писали какие-нибудь скрипты на Лодранере, уж очень нам нужен такой специалист?
- ах вы про это... Ну конечно писал скрипты и гонял их.
Ну и ряд аналогичных вопросов, по результатам которых становилось ясно, что кандидат умеет очень много, но вот ничего не может объяснить, т.к. теоретической базы не хватает.Самое интересное, что на эти грабли наступают многие. По-молодости, все любят что-то ломать, крушить и рвать на части, не задумываясь, зачем это надо и кому от этого хорошо. Хотят выучить новые приемчики, освоить новые инструменты. Но приходят на собеседование и не могут ответить на большую половину вопросов, на тему в стороне от их непосредственных обязанностей.
Но есть и другая категория специалистов - это теоретики. Зачастую это достаточно симпатичные девочки, которые почему-то сразу хотят стать руководителями. Они отвечают на все вопросы, причем их ответы можно сравнивать с определениями из учебников - разницы не найдете. Как всегда пример, о девочке собеседовавшейся на роль руководителя группы тестирования:
прошло 1.5 часа собеседования, девочка выдержала кучу вопросов по видам тестирования, процессам разработки, жизненным циклам и т.д. и тут вопрос:
- вот вам тестовый пример, напишите баг репорт на вот такой-то случай:
- ой, я никогда не писала баг репорты...
- а кто занимался этим?
- у нас этим занимались простые тестеры, а мы ими руководили
- ну тогда вот еще задание, напишите тест кейс для тестирования вот этой формы.
- ой, я никогда не писала тест кейсы...
и т.д.
Как можно брать на работу руководителя тестеровщиков, который никогда не писал тест кейсы или баг репорты? - я вот тоже не знаю...
В результате, вы познакомились с 2-мя категориями работников: практиками и теоретиками.
Мораль этой истории такова, что какими бы вы не были хорошими специалистами в своей узкой области, вы должны знать на хорошем среднем уровне все, что происходит вокруг вас.
HTTP сниффер: HTTP watch
Simtec HttpWatch - интегрируется в Internet Explorer, предназначен для анализа загружаемых веб страниц. Показывает детали запросов по HTTP протоколу в том числе и посланных по SSL каналам, что позволяет вам точно определить расположение на удаленном сервере файлов, просмотреть содержимое cookies, headers и кода страниц. Также, в отличии от других программ подобного рода, он может показывать детали запросов сделанных с использованием каналов SSL (для тех сайтов, у которых адрес начинается с https).
HttpWatch интегрируется в Internet Explorer как панель, которая позволяет вам просматривать активность во время просмотра сайтов в интернете или в локальной сети:
Полученная информаци включает:
Требования: Windows 2000, XP, 2003 Server или Windows Vista с Internet Explorer 6 или 7.
Применение.
HttpWatch интегрируется в Internet Explorer как панель, которая позволяет вам просматривать активность во время просмотра сайтов в интернете или в локальной сети:
Полученная информаци включает:
- URL к которому было создано соединение.
- HTTP метод: GET, POST, прочее...
- Mime тип ответа, например, "text/html" или "image/gif".
- Время, затраченное для завершения запроса.
- Размер загруженной страницы, изображения или файла.
- HTTP код возврата.
- Cookies которые были посланы или приняты.
- HTTP заголовки, которые были приняты или отправлены.
- Параметры, которые были отосланы в строках запросов или в методе POST.
- Можно увижеть был ли контент загружен с HTTP сервера или из кеша браузера.
Требования: Windows 2000, XP, 2003 Server или Windows Vista с Internet Explorer 6 или 7.
Применение.
- Анализ страниц веб-приложения на скорость загрузки - снифер прекрасно покажет самые "тяжелые" компоненты страницы
- Анализ response кодов: можно серфить по сайту, выполняя обычное тестирование, а потом проанализировать логи снифера на предмет 404, 301, 302 и так далее response кодов
- Можно смотреть путь, откуда тянутся картинки во флешевых галереях ну и потом их грабить оттуда - самое корыстное примение :)
Про оптимизацию
Просто анекдот:
Очередные соревнования между представителями разных наций. Основная задача - за 30 секунд успеть написать письмо, завязать шнурки и полюбить девyшкy.
Первым вышел англичанин. Время закончилось при попытке дописать письмо... Вторым - француз. Вылетел на этапе завязывания шнyрков...
...
Наконец, выходит русский. Время пошло: oн пристраивается сзади к барышне (причем она нагибается и завязывает в это время емy шнурки) и кроме основного занятия, начинает писать письмо, положив лист бyмаги ей на спинy... Глядя на изумленных и молчащих членов комиссии, задает вопрос: "Может, вам еще дров напилить? Так вы мне пилy в задницy вставьте..."
Улучшение знаний SQL
Недавно натолкнулся на ресурс, которые помогает с практическим овладением языка SQL.
Сайт поможет каждому, кто хочет приобрести или повысить свои навыки в написании операторов манипуляции данными языка SQL. Суть обучения состоит в том, что вы сами пишете операторы, которые должны вернуть или изменить данные, требуемые заданием. При этом в случае неправильного ответа вы сможете узнать, какие данные возвращает правильный запрос, а также увидеть, что вернул ваш запрос. Кроме того, есть возможность выполнять любые операторы DML к имеющимся базам данных, отключив опцию проверки. Упражнения имеют разный уровень сложности (от 1 до 4), который проставлен во втором столбце списка упражнений. Предлагаются упражнения на выборку данных (оператор SELECT) и упражнения на модификацию данных (операторы INSERT, UPDATE, DELETE). По результатам решения задач на сайте ведется рейтинг участников. При этом упражнения на выборку разбиты на три этапа:
Упражнения первого этапа доступны без регистрации, причем задания можно решать в любом порядке. Для выполнения остальных упражнений требуется регистрация. Регистрация бесплатна.
По результатам тестирования на сайте можно заказать сертификат "SQL Data Manipulation Language Specialist", подтверждающий вашу квалификацию. Подробнее предлагаю почитать на .
p.s. в комментариях мне подсказали еще один сайт:
Сайт поможет каждому, кто хочет приобрести или повысить свои навыки в написании операторов манипуляции данными языка SQL. Суть обучения состоит в том, что вы сами пишете операторы, которые должны вернуть или изменить данные, требуемые заданием. При этом в случае неправильного ответа вы сможете узнать, какие данные возвращает правильный запрос, а также увидеть, что вернул ваш запрос. Кроме того, есть возможность выполнять любые операторы DML к имеющимся базам данных, отключив опцию проверки. Упражнения имеют разный уровень сложности (от 1 до 4), который проставлен во втором столбце списка упражнений. Предлагаются упражнения на выборку данных (оператор SELECT) и упражнения на модификацию данных (операторы INSERT, UPDATE, DELETE). По результатам решения задач на сайте ведется рейтинг участников. При этом упражнения на выборку разбиты на три этапа:
- первый (54 упражнения) без контроля времени на выполнение отдельного задания.
- второй (начиная с 55 упражнения) - с контролем времени на выполнение каждого задания.
- На третьем этапе, который называется оптимизационным и начинается с задачи 139, требуется не только правильно решить задачу, но и время выполнения запроса должно быть соизмеримым с временем выполнения авторского решения.
Упражнения первого этапа доступны без регистрации, причем задания можно решать в любом порядке. Для выполнения остальных упражнений требуется регистрация. Регистрация бесплатна.
По результатам тестирования на сайте можно заказать сертификат "SQL Data Manipulation Language Specialist", подтверждающий вашу квалификацию. Подробнее предлагаю почитать на .
p.s. в комментариях мне подсказали еще один сайт:
Отличия между QA и QC
Речь пойдет о сравнении QA(Quality assurance) инженера и QC(Quality control) инженера.
Вот какие определения дает нам Wiki для QC:
т.е. говоря простым языком, эта активность направлена на контроль текущего качества продукта и сравнение его с задуманными характеристиками. В этом определении ни слова не говорится об улучшении качества продукта - только контроль. А контроль можно начать только когда продукт уже создан и не ранее.
Что касается QA, то мы имеем такое описание:
т.е. активность, направленная на улучшение качества, причем учитывая эффективность(в моем понимании - эффективность, это наилучшее соотношение затраченных ресурсов к результату). Улучшать продукт можно десятки лет, но эффекта будет мало(задачи изменяться, конкуренты подсуетяться, стоимость возрастет значительно). QA может и должен начинаться как можно раньше, тогда вероятность появления досадных ошибок возможно будет избежать еще на ранних стадиях(на уровне архитектуры).
Оба понятия тесно связаны, и одно дополняет другое.
Различие возникает лишь в том, когда начинает работать каждая роль: QA на этапе, когда продукт еще не разработан и это связано с аналитикой, а QC на стадии, когда уже есть что тестировать.
Вот какие определения дает нам Wiki для QC:
In engineering and manufacturing, quality control and quality engineering are involved in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements.
т.е. говоря простым языком, эта активность направлена на контроль текущего качества продукта и сравнение его с задуманными характеристиками. В этом определении ни слова не говорится об улучшении качества продукта - только контроль. А контроль можно начать только когда продукт уже создан и не ранее.
Что касается QA, то мы имеем такое описание:
Quality assurance, or QA for short, is the activity of providing evidence needed to establish quality in work, and that activities that require good quality are being performed effectively.
т.е. активность, направленная на улучшение качества, причем учитывая эффективность(в моем понимании - эффективность, это наилучшее соотношение затраченных ресурсов к результату). Улучшать продукт можно десятки лет, но эффекта будет мало(задачи изменяться, конкуренты подсуетяться, стоимость возрастет значительно). QA может и должен начинаться как можно раньше, тогда вероятность появления досадных ошибок возможно будет избежать еще на ранних стадиях(на уровне архитектуры).
Оба понятия тесно связаны, и одно дополняет другое.
Различие возникает лишь в том, когда начинает работать каждая роль: QA на этапе, когда продукт еще не разработан и это связано с аналитикой, а QC на стадии, когда уже есть что тестировать.
Нахождение уязвимостей с помощью Nikto
Особенности:
Описание:
Nikto - это Perl сканер под GPL лицензией, который выполняет всесторонние тесты для веб-серверов, включая более 3500 потенциально опасных уязвимостей, вариантами для более чем 900 серверов, и специфическими проблемами для более чем 250 серверов. Позволяет находить ошибки в конфигурациях серверов и программ, ошибки в байлах, проблемы с безопасностью файлов и программ, устаревшие программы. Сканер поддерживает SSL, прокси сервера, аутентификацию, IDS evasion. База уязвимостей а также плагины очень часто обновляются и процесс обновления можно сделать автоматическим.
Nikto не был разработан как стелс сканер. Следы активности программы будут скорее всего отражены в лог-файлах. Однако, присутствует поддержка LibWhisker's anti-IDS(Intrusion-detection system) методов если вы хотите использовать именно этот метод ну или для тестирования вашей системы обнаружения вторжений.
Не обязательно каждая проверка нужна только для обнаружения проблем с безопасностью, в сканере есть несколько тестов информационного характера, которые могут показать информацию, которая не была известна вебмастеру или инженеру по безопасности.
- Uses rfp's LibWhisker as a base for all network funtionality
- Main scan database in CSV format for easy updates
- Fingerprint servers via favicon.ico files
- Determines "OK" vs "NOT FOUND" responses for file type, if possible
- Determines CGI directories for each server, if possible
- Switch HTTP versions as needed so that the server understands requests properly
- SSL Support (Unix with OpenSSL or maybe Windows with ActiveState's Perl/NetSSL)
- Output to file in plain text, HTML or CSV
- Plugin support (standard PERL)
- Checks for outdated server software
- Proxy support (with authentication)
- Host authentication (Basic)
- Watches for "bogus" OK responses
- Attempts to perform educated guesses for Authentication realms
- Captures/prints any Cookies received
- Mutate mode to "go fishing" on web servers for odd items
- Builds Mutate checks based on robots.txt entries (if present)
- Scan multiple ports on a target to find web servers (can integrate nmap for speed, if available)
- Multiple IDS evasion techniques
- Users can add a custom scan database
- Supports automatic code/check updates (with web access)
- Multiple host/port scanning (scan list files)
- Username guessing plugin via the cgiwrap program and Apache ~user methods
Описание:
Nikto - это Perl сканер под GPL лицензией, который выполняет всесторонние тесты для веб-серверов, включая более 3500 потенциально опасных уязвимостей, вариантами для более чем 900 серверов, и специфическими проблемами для более чем 250 серверов. Позволяет находить ошибки в конфигурациях серверов и программ, ошибки в байлах, проблемы с безопасностью файлов и программ, устаревшие программы. Сканер поддерживает SSL, прокси сервера, аутентификацию, IDS evasion. База уязвимостей а также плагины очень часто обновляются и процесс обновления можно сделать автоматическим.
Nikto не был разработан как стелс сканер. Следы активности программы будут скорее всего отражены в лог-файлах. Однако, присутствует поддержка LibWhisker's anti-IDS(Intrusion-detection system) методов если вы хотите использовать именно этот метод ну или для тестирования вашей системы обнаружения вторжений.
Не обязательно каждая проверка нужна только для обнаружения проблем с безопасностью, в сканере есть несколько тестов информационного характера, которые могут показать информацию, которая не была известна вебмастеру или инженеру по безопасности.
Плохой и хороший тестировщик
А вы когда-нибудь задумывались, чем отличается плохой тестировщик от хорошего?
Число дефектов? Или количество тестов, написанных тестером?
Или число лет или проектов, которые тестер прошел? Или тот, которым доволен кастомер?
Совсем не простой вопрос :(
Число дефектов? Или количество тестов, написанных тестером?
Или число лет или проектов, которые тестер прошел? Или тот, которым доволен кастомер?
Совсем не простой вопрос :(
Баг или дефект а также его жизненный цикл
В этой статье будет рассмотрен такой важный аспект в тестировании, как жизненный цикл дефекта.
Каждый день мы слышим слова - "глюк" и "баг". Я попробую описать что же такое дефект в программном обеспечении и какова у него "жизнь".
Дефект - это один из видов измерения эффективности тестировщика и программиста, только в первом случае - чем больше, тем лучше, а во втором - наоборот, а также одно из мерил качества программного обеспечения.
Каждый дефект, который был найден специально и который будет обработан, имеет ряд обязательных описательных "свойств" в defect tracking systems:
1. Уникальный номер или название.
2. Title или Summary или Short Description: короткая фраза, которая помогает понять что это за дефект.
3. Description: полное описание дефекта включая шаги для воспроизведения.
4. Окружение: ОС, версия продукта на котором был найден дефект, браузер, патчи, т.е. конфигурация системы, на который дефект был обнаружен.
5. Скриншот или видео - некоторые дефекты сложно описать и тогда проще показать нежели описать.
6. Важность этого дефекта - полей с понятием важность может быть несколько, но не все должны заполняться тестерами. То поле "важность", которое заполняется тестером служит для индикации возможности работы с системой дальше при наличии дефекта.
Пример: Наиболее важным дефектом является тот, для которого нельзя найти work around, который нарушает работоспособность системы, влияет на много других модулей либо на всю программу в целом. Наинизшим же приоритетом можно считать "пожелания" - например, изменить цвет, подписи к кнопкам и так далее.
А вот цикл, по которому пройдет дефект, попав в систему учета дефектов(Bug Tracking System)
Каждый день мы слышим слова - "глюк" и "баг". Я попробую описать что же такое дефект в программном обеспечении и какова у него "жизнь".
Дефект - это один из видов измерения эффективности тестировщика и программиста, только в первом случае - чем больше, тем лучше, а во втором - наоборот, а также одно из мерил качества программного обеспечения.
Каждый дефект, который был найден специально и который будет обработан, имеет ряд обязательных описательных "свойств" в defect tracking systems:
1. Уникальный номер или название.
2. Title или Summary или Short Description: короткая фраза, которая помогает понять что это за дефект.
3. Description: полное описание дефекта включая шаги для воспроизведения.
4. Окружение: ОС, версия продукта на котором был найден дефект, браузер, патчи, т.е. конфигурация системы, на который дефект был обнаружен.
5. Скриншот или видео - некоторые дефекты сложно описать и тогда проще показать нежели описать.
6. Важность этого дефекта - полей с понятием важность может быть несколько, но не все должны заполняться тестерами. То поле "важность", которое заполняется тестером служит для индикации возможности работы с системой дальше при наличии дефекта.
Пример: Наиболее важным дефектом является тот, для которого нельзя найти work around, который нарушает работоспособность системы, влияет на много других модулей либо на всю программу в целом. Наинизшим же приоритетом можно считать "пожелания" - например, изменить цвет, подписи к кнопкам и так далее.
А вот цикл, по которому пройдет дефект, попав в систему учета дефектов(Bug Tracking System)
Что такое тестирование?
Ответим на вопрос: что такое тестирование?
Тестирование - это получение удовольствия от нахождения ошибок других людей. И это совсем не скучно! Некрасиво.. А что делать? :)
В классической терминологии, тестирование - процесс, позволяющий определить корректность, полноту и качество разработанного программного обеспечения (ПО).
Разработчики - те же люди, и как всем людям им свойственно допускать ошибки. Ошибки можно не замечать, можно замечать и устранять их, а можно описывать их как особенности разработанной системы.
Работа тестировщика(немного утрированно) состоит в том, чтобы замечать ошибки, локализовывать их, описывать и вносить в систему ведения дефектов и этим влиять на качество продукта. Есть еще и работа, связанная с планированием тестирования, но это будет описано в других статьях.
Пример:
Продукт, который выпущен на рынок, может обладать отличными характеристиками, но популярностью он будет пользоваться только если нет аналогов. Что касается крупных компаний, то они очень сильно подумают чтобы пользоваться таким продуктом (мы предполагаем, что продукт писался не в условиях CMM) потому как риск от потери данных(и потенциальная потеря клиентов из-за некачественного сервиса) превзойдет все достоинства данной разработки.
Тестирование - это получение удовольствия от нахождения ошибок других людей. И это совсем не скучно! Некрасиво.. А что делать? :)
В классической терминологии, тестирование - процесс, позволяющий определить корректность, полноту и качество разработанного программного обеспечения (ПО).
Разработчики - те же люди, и как всем людям им свойственно допускать ошибки. Ошибки можно не замечать, можно замечать и устранять их, а можно описывать их как особенности разработанной системы.
Работа тестировщика(немного утрированно) состоит в том, чтобы замечать ошибки, локализовывать их, описывать и вносить в систему ведения дефектов и этим влиять на качество продукта. Есть еще и работа, связанная с планированием тестирования, но это будет описано в других статьях.
Пример:
Продукт, который выпущен на рынок, может обладать отличными характеристиками, но популярностью он будет пользоваться только если нет аналогов. Что касается крупных компаний, то они очень сильно подумают чтобы пользоваться таким продуктом (мы предполагаем, что продукт писался не в условиях CMM) потому как риск от потери данных(и потенциальная потеря клиентов из-за некачественного сервиса) превзойдет все достоинства данной разработки.
Что же такое качество?
Попробуем ответить на вопрос: что же такое качество?
С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО, с учётом следующих составляющих:
Скользкое определение, но ключевым словом является слово "покупатель". Именно для покупателя создается продукт или сервис, именно покупатель будет решать насколько удовлетворяет продукт его требования, насколько продукт работает в соответствии с его ожиданиями и соответствует ли он заявленной цене и только он в конце концов решит насколько продукт качественный.
С точки зрения ISO 9126, Качество (программных средств) можно определить как совокупную характеристику исследуемого ПО, с учётом следующих составляющих:
- Надёжность
- Сопровождаемость
- Удобство использования
- Эффективность
- Универсальность
- Функциональность
Скользкое определение, но ключевым словом является слово "покупатель". Именно для покупателя создается продукт или сервис, именно покупатель будет решать насколько удовлетворяет продукт его требования, насколько продукт работает в соответствии с его ожиданиями и соответствует ли он заявленной цене и только он в конце концов решит насколько продукт качественный.
Акронимы в QA
Читая форумы и тематические сайты, общаясь с коллегами, периодически проскакивают слова которые далеко не всем понятны.
Решил собрать их в одном месте с пояснениями. Список будет постоянно дополняться и обновляться.
Список будет постоянно обновляться и дополняться.
Решил собрать их в одном месте с пояснениями. Список будет постоянно дополняться и обновляться.
- QA - quality assurance
- QC - quality control
- QC - Quality Center(старое название Test Director) - разработка Mercury(сейчас HP) - продукт сопровождения разработки программного обеспечения.
- Кастомер - customer: покупатель, заказчик, клиент, завсегдатай :)
- ПО - программное обеспечение, он же софт (software)
- DFD (data flow diagram) - Средство построения (абстрактных) моделей процессов. Граф, вершинами которого являются источники и приемники данных (процессы, создающие и изменяющие данные, хранилища данных и внешние источники), а дугам соответствуют потоки передаваемых данных.
- ERD - Средство построения (абстрактных) моделей данных. Граф, вершинами которого являются сущности (т.е. "предметы", идентифицированные отличным от других "предметов" образом) а дугами - отношения. Под отношениями в данном графе понимают ассоциация между сущностями.
- RAD - Rapid Application Development. Быстрая разработка приложений. Семейство методик организации жизненного цикла, характеризующихся некаскадной организацией и систематическими возватами по основной последовательности жизненного цикла. Имеется стандартизованная методика RAD, называемая DSDN.
- CMM (Capability Maturity Model) — модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение
- QTP (Quick Test Professional) - программное обеспечение компании HP (раньше ПО компании Mercury). Это программное обеспечение с графическим интерфейсом позволяет реализовать автоматизизацию действий пользователя для веб или десктоп приложений. В основном используется для автоматизации функционального регрессионного тестирования.
- Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.
Список будет постоянно обновляться и дополняться.
Несколько слов обо мне
Александр Семишан.
Текущая позиция: QA TL в Lohika Systems (с Июля 2003 года)
Предыдущая позиция: Системный администратор в Лаборатории Информационных Технологий в Одесском Национальном Политехническом Университете.
Текущая позиция: QA TL в Lohika Systems (с Июля 2003 года)
Предыдущая позиция: Системный администратор в Лаборатории Информационных Технологий в Одесском Национальном Политехническом Университете.
FAQ по QA
Собрал небольшое количество часто задаваемых вопросов касательно QA, тестеров ну и всего, что окружает понятие "качество программного обеспечения" и дал свою точку видения данных вопросов.
1. Что такое баг? Синонимы понятия…
Баг - это факт обнаружения несоответствия между спецификацией и работой программы. Программа может не выполнять то, что
описано в документации, может выполнять что задумано, но с неверными результатами, а может выполнять и больше, чем от нее ожидают. Баги, дефекты, бага, фича(описанный в документации дефект), CR(change request) - это варьируется от запроса на новую функциональность до описания существующих дефектов
2. Кто такой бета-тестер? Синонимы понятия…
Популярное, но неверное название для "тестировщика", вообще правильно бы разделять понятия QA инженера и QC инженера, но у нас обычно все кидают в кучу и называют единым словом "тестировщик", "тестер", "кьюэй".
3. С чего нужно начинать освоение тестирования?
Для начала надо осознать, на каком уровне находятся знания компьютера и программ вообще. Компьютер - это инструмент, и если им не уметь пользоваться, то дальше некуда идти. Надо знать основные разделы, но необязательно очень глубоко. Тестирование же лучше начинать с чтения документации о самом тестировании, видах тестирования, понятии дефекта, приоритета, научится правильно описывать дефект, понять для чего нужно описание дефекта, для кого оно нужно и на что дефект влияет, не лишним будет изучить Жизненные Цикл Программного Обеспечения.
1. Что такое баг? Синонимы понятия…
Баг - это факт обнаружения несоответствия между спецификацией и работой программы. Программа может не выполнять то, что
описано в документации, может выполнять что задумано, но с неверными результатами, а может выполнять и больше, чем от нее ожидают. Баги, дефекты, бага, фича(описанный в документации дефект), CR(change request) - это варьируется от запроса на новую функциональность до описания существующих дефектов
2. Кто такой бета-тестер? Синонимы понятия…
Популярное, но неверное название для "тестировщика", вообще правильно бы разделять понятия QA инженера и QC инженера, но у нас обычно все кидают в кучу и называют единым словом "тестировщик", "тестер", "кьюэй".
3. С чего нужно начинать освоение тестирования?
Для начала надо осознать, на каком уровне находятся знания компьютера и программ вообще. Компьютер - это инструмент, и если им не уметь пользоваться, то дальше некуда идти. Надо знать основные разделы, но необязательно очень глубоко. Тестирование же лучше начинать с чтения документации о самом тестировании, видах тестирования, понятии дефекта, приоритета, научится правильно описывать дефект, понять для чего нужно описание дефекта, для кого оно нужно и на что дефект влияет, не лишним будет изучить Жизненные Цикл Программного Обеспечения.
Subscribe to:
Posts (Atom)
Posts
