працюєш собі тестувальником і не знаєш, що тобі бракує підписки на ютюб преміум і конференцій ( переконайте мене хтось що конференції мають якийсь сенс окрім — поїсти бутерів?)
зайшов почитати коментарі:)
Привіт, обширно відповісти не візьмусь, загалом як тут описано тест стратегію можна застосовувати постійно, а значить її можна ввести і для проєкту де вже змін не багато, і це про підхід до тестування.
Якщо є нові розробки чи щось переписується, код рефакториться, тут можна ввести тест план на ці конкретні плановані релізи, і врахувати регресію.
Щодо супорту, варто врахувати на це капасіті, причому чим більше буде покриття тестами критичних функціональностей, тим ця величина по факту має зменшуватись, як і ризики появи принаймні не специфічних баг.
Щодо відтворення баги: «ніколи такого не було, і ось знову».
Тут нічого нового, варто продумати за прекондишени в даних, кроки відтворення можуть відрізнятись, рідші ситуації — інша конфігурація системи ( в клієнта може бути винесено зберігання даних на інший континент, і тут буде просідати трафік передачі даних). Тобто що варто зробити це поговорити з клієнтом, якщо він може показати в реальному часі проблему- це чудово. Є ще трікі випадки — сторонні програми, наприклад скрін рідер для людей з вадами зору, він може викликати некоректну роботу з великою кількістю динамічних даних, так як пробуватиме прочитати все. Ну купа всякого такого, коли у нас ідеальна пісочниця, всі з адмін правами (LOL), а у клієнта налаштування вже років 15 не дуже і мінялись, і там адмін прав ніколи ні у кого не було.
Привіт, певні приклади є у книжечці нижче (або в самому силабусі). Але це все вам мабуть відомо...
А ось щодо підтримки, коли багато змін- «не плач, не псіхуй...»
розділ блек бокс тест технік (4.2.3) «Foundations of Software Testing ISTQB Certification, 4th edition by Dorothy Graham, Erik van Veenendaal, Rex Black».
Привіт, вибираєте медичний проєкт і будете мати того добра стільки, що «сраки горітимуть». Але це не через те, що всі лапочки і котики, а просто є державний регулятор. який дасть по шапці, якщо не було багатьох процесів...
проєкт написаний на коліні не проживе
ні ні, не всеодно замовнику, якраз тому хто рахує кошти, а за кордоном всі рахують кошти... так, навіть 100 баксів... Умовно ти раз заплатив за переписування продукту, другий раз... Потім платиш мідлу як тех ліду за підтримку застарілої техлогії, на котрій ніхто з адекватних сіньорів вже не сидітиме...
такого не є... як писали вище — потрібно обґрунтувати архітектуру...
я зачасту пояснюю проєкт як побудову будинку, копати будь де на газоні, заливати будь який фундамент не катіт...
а порахувати середні зарплати невеликої команди, помножити на 12 місяців, і вийде бютжет від 0.5 млн доларів... це не малі гроші, за них натягнуть, повір...
а як щодо SDET і перевірки серверсайду?
щодо кількості тестів, то є цікавіша метрика — покриття функціоналу
дякую!
щодо ставлення до грошей, відкладання
знаю буквально одну людину якій вдається жити у такому режимі, але це унікум, він і з сім’єю встигає побути, і вчитись, і звітує той час який працює (фул тайм+ парт тайм). Правда вихідні там теж з ноутом проходять...
Мені коли потрібно будо трішки допомогти на попередньому проєкті, то це була жопа і недоспані ночі.
мені одному почулось «найманий працівник» коли говорять про ФОПа?))))
податкова виїхала за вами... міу міу міу (звук сирен)
нє, ну ейчарам я писати не буду, щоб мені дозволили тут проголосувати)))
дякую
хм, все алежить чи ви взагалі кодити на ньому будете, весло і лодка на роботі є. а для віддаленого доступу і слабенької машинки вистачає. Як пограбували квартиру і винесли мій любимий thinkpad то я розстроївся і купив найпростіший ноут якого для фейсбуку, фільму онлайн і віддаленого стола вистачає більш ніж повністю+ так як проц слабенький він батарею майже не їсть, вистачає на
і музику і фільми:)
це мій висновок по вашим словам і ненависті до професії про яку говорите:) мда тут ви маєте право придертись що про цьотку Фроську в тексті не йдеться.
1. я з Вами не сварюсь, просто вважаю що ви не докінця розумієте роль тестувальника:)
2. йдеться ось про що:
— Всі тестувальники хочуть і мають бути програмістами апріорі ( це брєд і поверхневе знання тестування. так само можна сказати що всі ДБшники хочуть стати Java девелоперами :) хоча випадки переходу існують але це не означає що початкова мета це перехід( тут в коментах про це писали- що краще таку людину не брати );
— використання цієї цитати сприймаю як її підтримку
Туда, может быть, попасть даже проще, чем в QA, а работа не такая дурацкая, а всё-таки осмысленная, инженерская, в отличие от тестирования.людина не може бути задоволена роботою якщо вона дурацкая, і мабуть ви зустрічали в житті тестувальників які задоволені тим що роблять . і роблять це з ентузіазмом. Окрім того тестування як мавпа- то майже як цьотка Фроська, а тестувальник має продумати кейси які проходитиме, спланувати їх так щоб охопити ті частини функціоналу які або дуже важливі або часто відпадають по тих чи інших причинах... в будь якому випадку це не мала робота, і якщзо після програміста перевіряє тестувальник то після тестувальника перевіряє клієнт...
Но есть в работе программиста и тестировщика кардинальное различие. Один строит, другой ломает. Один оптимист, другой пессимист. Один любит, другой ненавидит.( чому? я оптимістично знаю що в продукті є дефекти:))) люблю продукт і хочу щоб в ньому залишалось мало дефектів,і взагалі щоб він був ідеальним, а замість баг були тільки нові фічі , і невеликі косметики після їхньої реалізації)
Программиста спасает вера в то, что все будет хорошо: «это не баг, это фича», когда QA уверен в обратном.( коли Програміст Увєрєн що це фіча. то QA повинен розкинути всі за і проти, проаналізувати і доказати і собі і всім іншим, що це або бага, або фіча, бо претензії будуть до нього- що є правильним)
«Аааа! Нашел!».коли ти тестуєш остаточно вилизайний продукт і знаходиш припустимо одну багу після тестування 10% функціоналу( припустимо 7 годин роботи) то будеш цьому радуватись ще не так. Це як програміст радіє коли його костиль запрацював))) і радість не того що — А я тебе взув, а того що — о найшлась падлюка... особливо якщо інші тесткейси цю багу пропускали( всяке буває в тому житті)
«Что ж ты радуешься, скотина?» — думаю я. Нашел проблему, дефект, чертов баг. А хочется лететь, двигаться дальше.( а далеко з тим багом продвинешся? коли ввін аукнеться? не треба буде переписуват половину коду і бекпортити кучу версій?)
«Здесь не работает!», — улыбается тестировщик, — «И в логах, глянь — одни epic fatal total kernel panic error’ы. Всё красным»,
программист с улыбкой объясняет, что это на самом деле не баг, а неправильная конфигурация environment’а,а зробити фічу щоб клієнту видавало повідомлення що база відвалилась чи ще щось,що інформує клієнта що його операція виконається не коректно. клієнт не такий уважний як тестувальник. він заповнить форму і відправить, а те що та форма полетіла в нібитійо він дізнається потім, коли його посилка не прийде за пів місяця чи його начальник не отримає автоматичний звіт по продажам. бо продажі не пройшли через багу
или что таки баг, но не критический, и погоды он не делает.— так це супер, тестувальник сам має оцінювати важливість, або принаймні навчитись її оцінювати, так як він повинен аналізувати наскільки швидко це потрібно фіксати, чи краще ’не резиновий’ час програміста направити на іншу багу/фічу
Он постарается убить её во что бы то ни стало, любым доступным способом, хоть голыми руками.краще він ніж замовник, бо тоді достанеться всім і замість 1 тижня фіксання треба буде фіксати asap
С другой стороны, именно поэтому он находится ниже на иерархической ступеньке, ведь главную работу делает программист. Отсюда возникает вопрос: какое занятие человек выберет — менее сытое, зато более спокойное, или же более выгодное, но при этом требующее больше нервов?( зневага до тестувальників детектед :) тестувальник не нервується? скажіть це їм ближче до QA freeze )) або коли вони знаходять пропущений баг, особливо якщо він критичний)
программисты не всегда ладят с тестировщиками.і дарма))))
К этому добавляется еще и иерархическая и зарплатная составляющая, а также дискриминация по признаку тестировщика.хороший дев і хороший тестувальник на ціну золота :) ( себе не хвалю мені ще вчитись і вчитись)
взяв вместо лупы отверткув тестувальника також викрутка, він не тільки косметики шукає, а також мусить знати і розуміти пояснення до кожної дії аплікації, спочатку вміти пояснити собі, а потім вміти пояснити комусь+ написати до того документацію у вигляді кейсів і очікуваних резалтів
Поэтому на старте неплохо бы еще разок обмозговать, куда поедет бетономешалка, но при этом не спешить заливать первый попавшийся фундамент. Кто знает, может, там дальше за горизонтом есть более интересные и стоящие заливки формы.робота повинна подобатись, це мабуть найбільший стимул над нею старатись..
ок, черга за Вами:)
А ви помітили, що автор написав що програміст може перейти в тестування, але весь текст розказує що роботу тестувальника може виконувати цьотка Фроська з
насправді було б цікавіше про курси з різних напрямків сказати (юдемі, чи от ютюб), ну і — для тестувальнику ок прочитати силабус istqb, а мудріше його розширену версію,
ну і не тратьте пару к на те все, норм компанія вам дасть ± підходяще обладнання, а оці приколи ви два роки на джуно-міжловій зарплаті відроблятимите...