Как стать автором
Обновить

Комментарии 48

А IT-компания что ответила в итоге?
Что у них техническая неувязка и в нашей деревне под названием Академгородк в данный момент позиций QA нет. Но все равно было приятно — компания хорошая, а от таких вещей получаешь удовольствие.
Все дело в том, что я вообще-то не QA… Я программист, и в последнее время даже с уклоном в сторону PM.
Но если что — буду иметь в виду, спасибо!
С терминологией стоит навести порядок, а то у Вас то «ствол» и «грифель» произвольно заменяются «стержнем». А шестигранный карандаш, говорят, придуман для того, чтоб не скатываться со стола.
Спасибо, поработаю над этим. На самом деле все писалось в условиях ограниченного времени, поэтому могут быть еще неточности.
Мой опыт использования карандашей говорит о том, что и шестигранные карандаши прекрасно скатываются со стола. В этом случае более удобная форма треугольные и плоские (их еще называют строительными) карандаши. Особенно плоские, благодаря форме они не скатываются вообще.

Возможно я проступила, но плоские карандаши в статье не были упомянуты: )
Но треугольными, а уж тем более плоскими, будет неудобно пользоваться.
Мне кажется, шестиугольные — это максимально сбалансированная форма между удобством и «нескатываемостью-со-стола» :)
Треугольными вполне нормально рисуется. Вот с плоскими, там сценарий использования другой, важно бы они совсем не катились, но удобство рисования не важно, скорее метку поставить, линию провести.
Космонавты на МКС не пользуются обычными грифельными карандашами, потому что пыль от графита на борту — это враг электроники.
Используются либо восковые карандаши либо специальные чернильные ручки.
Век живи — век учись… Не знал, спасибо.
У меня, кстати, есть такая — и она абсолютно восхитительна в обращении. Всем советую. Через интернет покупается.
А еще в одном худ. фильме это объяснялось тем, что грифель может отломиться и в невесомости куда-нибудь залететь.
Три идиота?
Три — это числительное )
Да, я этот фильм имел в виду.
Весьма наглядно, понравилось даже больше статьи.
очень даже нелохо!
я у себя в ВУЗе на лабах с товарищем дверь входную тестировал по всем параметрам =)
теперь где в двери может быть bottle neck? :)
Вот это класс!
Собственно говоря, это отсюда.
Или отсюда.
Реквестирую эту картинку в высоком разрешении!
Имхо задача тестировщика залезть в душу заказчика, узнать что же он хочет от продукта, узнать требования и потом проверить продукт на соответствие требованиям, а не неким измышлениям тестировщика. Исходя из этого предположения считаю данный отчёт о тестировании карандаша фактически неудовлетворительным. Хотя само задания также считаю совершенно неадекватным, если вы делаете продукт, так и даёте тестеру продукт. Не нужно писать толмудов о нём и его безопасности при поедании. Нужно выяснить у заказчика истинные цели, которые очень часто не отражены в ТЗ и дать заказчику краткое понятное описание того что не соответствует и что плохо, также можно кратко упоминуть что было протестировано чтобы заказчик осознал полноту и качество тестирования. Наилучшим ответом на такой вопрос посчитал бы такой: вот карандаш, он у меня с собой, пишет — нет не пишет, почему? Потому что сломался. Заточим его, заточился — ок, при точении крифель рассыпается не ок. Вот и всё тестирование. Иначе с таким подходом к реальному продукту, типа игры или приложения получим столько неадекватной инфы, что не будет понятно что куда. Просто экстраполируйте сложность карандаша как объекта материального мира и например автомобиля, или игры для мобильника.

— Поместим карандаш в воду, затем высушим.
— Поместим карандаш в кислотную, щелочную среду ненадолго.
— Заморозим, а затем отогреем. Вариант — положить в снег на морозе.
— Нагреем карандаш, затем охладим. Но поджигать все-таки не станем.


Равносильно багрепорту о том что исключительно windows программа не работает на mac, и на linux, а под wine работает как-то странно и поглючивает. Абсолютно бесполезная, и даже вредная инфа если такие требования не предъявляются разработчиком.

Достаточно критично получилось, но я просто со стороны разработчика сужу о том что иногда получается при тестировании.
Особенно у индусов потом видишь кучу глупого копипаста в отчетах, типа полного указания параметров системы в каждом тест кейсе вместо вынесения в отдельный пункт, а приложение как крашилось на третьем экране и неверно рассчитывало курсы валют — так и крашится.
Вот почему интересно тестировать то, в предметной области чего имеешь представления.
Я в студенческие годы работал сисадмином. Поэтому, когда чуть больше чем год назад решил пойти в QA, то из нескольких предложений выбрал проект системы резервного копирования. Это было очень интересно, так как имею представления со стороны потребителя, чего требовать от продукта для резервного копирования.
>Космонавты на МКС пользуются обычными грифельными карандашами
Я что-то такое читал/слышал, что не совсем обычными. Обычные карандаши крошатся и засоряют воздушные фильтры. Простите, не хочется сейчас искать подробности, да и статья не об этом. Может быть кто-нибудь из хабровчан расскажет.
Спасибо, ответ оказался даже ближе.
Простой карандаш — это именно графитовый черный или серый грифель, так что простой карандаш не может быть цветным. Простой карандаш запросто может быть механическим.
Будь я на вашем месте, отказался бы от подобного «задания». Хотя это нас и отличает «я получил несказанное удовольствие от этого задания. ».
Было у меня на собеседовании подобное задание и я тоже стартанул генерировать идеи, шагая по списку критериев качества. Благодаря их комбинированию можно придумать еще пару сотен тестов на этот многострадальный карандашик.
Но меня осадили достаточно просто — у вас разве бесконечно времени и денег?

Первое. Во всей статье нет ни одного слова приоритет.

Зачем вообще вас попросили тестировать карандаши? Какую проблему решает клиент?
Второе. Во всей статье нет ни одного слова риск.

Вы тестируете карандаши в лаборатории по созданию карандашей? Вы тестируете карандаши на заводской линии? Вы тестируете карандаши на открузке в магазины?
Третье. У вас не указан контекст. Впрочем, несколько предположений вы делаете.

Возможно, человек поставивший задачу, ожидал не развёрнутого полотенца а нескольких уточняющих вопросов.
Верно. Каждому QA нужно постоянно самому себе напоминать, что цель тестирования — обеспечить планируемое качество.
Ну и не забывать, что QA активности строятся на основе требований к продукту. Если их нет, то я бы ожидал, что QA будет справшивать и уточнять требования. Особенно в условиях повсеместного Agile.
Спасибо! Вы просто оформили мои последующие мысли на эту тему в явно выражаемую форму. Я думал об этом позже, после прохождения задания. На самом деле это задание делалось несколько спонтанно… можно сказать, в поиске себя. Попытка посмотреть «с другой стороны». Со своими недочетами и ошибками. Так что прошу утюгами сильно не бить. Дело в том, что я не QA, а вообще-то программист. И в последнее время даже с большим креном в сторону Project Manager. Занимаюсь созданием своей команды и параллельно живу различными проектами. Вот как-то так, вроде пока получается…
Мне тема понравилсь, много интересного написали. Да и вашему терпению можно только позавидовать, я бы не осилил столько всего придумать.
Я тоже не QA, но интересуюсь процессами разработки и неплохо представляю деятельность всех участников. Вам рекомендую почитать CMMI-DEV, особенно если вы в сторону Project Manager поглядывете.
Познавательно. С точки зрения подачи материала (на мой взгляд): лучше сначала изложить краткий план тестирования, потом детализировать условия тестов.
По большей части это похоже на поиски не тестировщика, а задрота.
Как минимум, нужно сначала определить границы приемлемого для клиента качества карандаша, а не тестировать всё что можно.
Вам предложили решить одну из стандартных задач для тестировщика. Советую прочитать книгу Cracking the Coding Interview: 150 Programming Questions and Solutions (CareerCup — Book, amazon), в ней, в частности, профессиональный взгляд на решение задачи с тестированием карандаша. Описано, что от соискателя ожидают услышать, как вообще подходить к задаче «протестируйте Х».

По ней готовился к собеседованию в фейсбук. Она мне здорово помогла в подготовке, все необходимое в ней есть. В помощь также задачи с сайтов GeeksforGeeks, CareerCup.
Спасибо, прочитаю обязательно.
Немного позанудствую — шкала от 0 до 10 — это уже одиннадцатибалльная шкала

Написано здорово, мне понравилось!
НЛО прилетело и опубликовало эту надпись здесь
Я собеседовал по долгу службы много QA. Задавал пару раз, ради интереса этот вопрос. Многие начинали рассказывать и про юзабилити и про стресс-тестинг. К сожалению ответы, часто оригинальные и остроумные, никак не были связаны с опытом кандидата именно в области тестирования ПО. Ни один кандидат не дал мне развернутого ответа на вопрос: вы QA Lead, мы делаем новый продукт *предметная область N* по гибкой методологии, как будете тестировать: сроки, виды тестирования, необходимые ресурсы?

На данный момент существует достаточно обширная база знаний в области тестирования приложений. Нужно развивать именно такое комьюнити. Останавливаться на лучших практиках, развивать сообщество, а не карандаши тестировать.
Тоже довелось провести немало собеседований. Так вот, эти самые «карандаши» (двери/степлеры/что угодно) — это скорее показатель личностный, нежели технический. Что будет делать человек? Попробует ли уточнить? С чего начнёт? Как отстроит всю цепочку? В основном люди пытаются проецировать свой предыдущий опыт на эту задачу. Очень интересные решения, кто-то сразу просит бумагу и рисует миндмап, кто-то думает несколько минут и выпаливает всё хаотично, кто-то строго в порядке важности. Есть те, кто отказываются тестировать до того, как соберут все требования. Всё это даёт понимание о человеке, о его подходах, о привычках. И конечно же никто не собирается принимать окончательное решение исключительно на этом основании, это всего лишь одна субъективная техника, совсем не точная наука.
Плюсую. Во взгляде со стороны PM, ищущего себе в команду QA, я думаю, все очень приближено к этому: как поведет себя человек, как он мыслит, как реагирует на те или иные изменения и т.д.
Думаю, я проходил собеседование в эту же самую «одну известную российскую IT-компанию», на вакансию инженера-тестера. К счастью, успешно, сейчас в ней с удовольствием работаю.
Свой ответ строил в таком порядке:
1. Введение
2. Объект тестирования
3. Инструменты для проведения тестирования
4. Тестирование комплекта поставки
5. Тестирование функций карандаша
6. Тестирование интерфейса
7. Тестирование удобства использования
8. Тестирование надежности карандаша
9. Тестирование производительности карандаша
10. Тестирование совместимости
11. Стрессовое тестирование
12. Безопасность использования
Вобще интересное упражнение для ума.
Думаю, основной недочет был в том, что нужно было изначально задать вопрос о сроках и ресурсах — то есть подойти к задачи с позиции Project Manager.

Меня смутило как вы лихо между QA и QC прыгаете. Например, сколько карандашей из партии в N штук нужно протестировать на сооветствие характеристикам, чтобы принять или завернуть партию? Это же ГОСТы чистой воды, и это чистый материальный/инструментальный контроль, который на жизнь QA в мире ПО ложится очень плохо.

В контексте жизни QA отдела. Ну вот у нас есть тестер, задача которого проверить "Резинка со временем не «дубеет» и продолжает исполнять свои функции.". И вот садится QA проверять, что со временем резинка не дубеет. Сколько делать проверку? Год? Два? А карандашей много...

Я бы сказал, в тексте много шапкозакидательства и мало конкретики из жизни QA. Это как если бы программисты рассказывали про написание кода с подробным описанием процесса нажатия "разных кнопок".

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории