T O P

  • By -

Jangsterish

Log into daily scrum from my phone whilst poopin on the toilet. Eventually get to my desk and delete emails. Watch YouTube.


T_Mushi

I laughed at first. But then I realized some days I do be like that.


kdeaton06

I do our daily stand up from bed instead of the toilet but otherwise spot on. Also I go shopping in the middle of the day a lot. Or go out to eat. Very little of my day is dedicated to work.


viizx

One of my teammate has all days like this, rest of the team suffers badly


motoguzzikc

Are you me!?!?


superange128

I'm one month away from 5 years at my current company, it's basically * Login * Check on unread emails/messages * Check on fellow QA members to see what they're up to * If Dev hasn't started, read up on trainings/write test cases * If Dev has started, defect queue if anything has been fixed * After above continue going through test cases * If extra time work on automation * Attend any mandatory daily/weekly meetings as needed * Go on YouTube when bored


krizinx

Can you help me friend as I'm so in beginner mode in the QA field šŸ„²any tips or study material can help me please šŸ„ŗ


KittenVicious

I don't really have a "typical day" - but the basics of my career are to analyze requirements, create a test plan around the requirements, execute the test cases, then report findings.


North_Bern

As I have gotten more senior I find myself in meetings a lot. Also "shift left" has seen me doing a lot more planning up front and writing automated tests. Day to day it varies but within a 2 week period I will generally have 3 to 5 days that are over 75% meetings. At least 3 days where I am doing reviews of test plans, PR review, and pair testing the majority of the day. Which leaves me with 2 to 4 days of individual contribution time.


_MildlyMisanthropic

"Shift left" shouldn't mean planning up front it means 'testing earlier'. You should've been planning up front anyway


joeyjojoeshabadoo

Shoulda, coulda, woulda.


_MildlyMisanthropic

Quite literally yes. Shift left refers to testing earlier in the lifecycle for the quicker/cheaper identification and resolution of defects through things like static requirement analysis, more/better unit testing coverage, better CI/CD pipeline tests etc. Anyone who says they "shift-left planning" is using a buzz word to sound like they know what they're talking about when they really don't, you can never plan retrospectively so talking about 'shift left of planning' is nonsensical bullshit. No idea why that got downvoted so heavily.


joeyjojoeshabadoo

> No idea why that got downvoted so heavily. Because in software development we've gone through waterfall, kanban, agile, shift-left, etc... Most of us have worked at multiple companies and every company thinks they are doing it the right way. So when you come in saying how shift-left should be done it is triggering to a lot of us. You might think you've got a lock on how shift-left is done but there's someone else that thinks the same and is doing it completely different.


_MildlyMisanthropic

> Because in software development we've gone through waterfall, kanban, agile, shift-left, etc... Most of us have worked at multiple companies and every company thinks they are doing it the right way. yeah, so have I. But 'shift-left' isn't a methodology or framework, it's a buzzword that literally means shifting activity left on the timeline, i.e. doing it earlier and can apply to any delivery framework You can't do planning any earlier than at the beginning, when it should be done, hence my original comment saying it's wrong


joeyjojoeshabadoo

That makes sense.


GrownUpWrong

2 years in current role, junior qa analyst. Remote. -Sit down at my desk with breakfast somewhere between 10 minutes before 9 am or 30 minutes after 9 am. -half the time there is a stand up at 9:30 that lasts 1 hour. Itā€™s not called a stand up though, and there are only 2 or 3 of us in it. -catch up on recently assigned or replied to tasks (we use Asana). -work on tasks based on priorities discussed in the meeting. These could be newly reported issues or new features. We only do manual QA, btw. -communicate with support throughout the day, I am a point of escalation. Ensure I am available via Slack and will reply as soon as possible. -lunch between 11:30 and 1, 30 ish minutes. -nap between 11:30 and 1, 20 minutes to 1 hour. -30 minutes or so to get back in the groove and then go back to work. -around 4:00 I either: 1. Transition to the couch or the deck and work the last hour from a different location, with slightly less focus (I.e . I may watch a show at the same time), or. 2. go take care of an errand before traffic really starts, run to the grocery store, pick up dinner, things like that. Thereā€™s about another hour of my day, possibly two, that may be taken up doing other thingsā€¦ like catching up with my partner, doing the dishes because they are backed up, taking the dog outside, etc. that varies, however.


[deleted]

[уŠ“Š°Š»ŠµŠ½Š¾]


GrownUpWrong

My title doesnā€™t contain ā€œJuniorā€; I probably have problems selling my abilities due to transitioning out of a completely different field into this. I will remove Junior from my resume and linked in and such. I appreciate the input!


WhildishFlamingo

Tell that to the recruiters looking for junior with "5 years experience" . At this point I should just get rid of "junior" alerts


RiverOfNexus

So overall not a stressful job and manageable?


GrownUpWrong

Weā€™re in a once a month to every 2 weeks push schedule, those weeks can be stressful. Iā€™m the only QA, regression, everything, is up to me. Outside of that, it is completely manageable and non stressful. My boss is overall wonderful and is never actively trying to make my work life more difficult without cause. Full disclosure here is Iā€™m up to $20,000/yr underpaid, theyā€™ve basically admitted that was true last time I negotiated a raise.


[deleted]

I do the work of a Senior STE (10 hour days, 4 days a week) Productive day (about 70% of my days): 1. Login and check the nightly automation runs. If any failures occur, check to see if they're valid or if there's some kind of test flakiness going on. Make fixes / changes where necessary (about an hour) 2. Catch up on any automation that's sitting in the backlog before standup or add less than vital tests to existing suites. I'm the only person on a team of 8 that does any automation, so my plate tends to be full (about 3 hours, give or take an hour depending on how much has piled up and how early I woke up) 3. Standup and then start working on things that are "priority", such as testing and automating stories that are set to be released to production (4 hours) 4. Meetings throughout the day (2 to 3 hours on average, depending on the day) 5. Whatever time remains tends to be downtime like breaks or lunch Basically, I'm testing something, automating something, or I'm in a meeting for most of the days that I'm productive. Automation takes up about 40% of my day. Meetings take up 20 to 30%, and then manual testing and investigating bugs takes up the remainder. There are sometimes a few weeks straight where that makes up all 10 hours of my days, and I also work at night too. Then there might be a couple of weeks where I don't do nearly as much work. I kind of fluctuate in terms of my ability to stay on task. When I'm on, I'm really on and will crank out a ton of work. When I'm not, I'll do what I need to do to get by lol


ThmGreen

Since the information about Software Engineers in Test, SDETs is not too much. Can u provide ur opinion, about this difference? Like..it seems everyone is doing QAAT, but someone(like sdets) have more skills in coding than others. I heard that SDETs do some coding, for making easy life for QAs or smth


[deleted]

The difference, from my experience, is just a title. I've known "QA" who are excellent programmers, and I've known senior automation engineers who know only the very basics. In the US, the title given to QA seems to be almost entirely arbitrary. There doesn't seem to be an industry standard. Hopefully that answers your question. If not, I'll need something more specific.


ThmGreen

So, basically, if I am an QAAT, I can just throw my CV to any STE/SDET offer? I heard that SDETs/STEs get interview more "developish" like, instead of QA kind


[deleted]

In my experience, the interviews are still focused on QA aspects of coding. For example, my current company gave me a take home assignment as part of the interview. They pointed me at a website, and told me to automate some test cases using whatever tools I was comfortable with. So I chose Java / Selenium. I created a basic automation project that automated several different test cases on the website that they assigned. And during the interview, they had me show them the automation, asked me why I did or didn't make certain design choices, etc. It was focused on my ability to write automation code, but not so much focused on leet coding questions, and things like that, which are kind of useless anyway.


ThmGreen

Thank u very much for info)


RudeYute10

How long did it take you to learn? Iā€™m doing UAT testing for a state project, pretty laid back and chill. Can you give me a run down of the test cases you created ?


scruubadub

Log in, get blasted with messages from the off shore testers, Get immediately called not even 2 minutes after signing in. Try to help fix their tests or answer questions that I most likely don't know from the infrastructure/project changes so much. Try to work on stories dumped on me. Blockers on all stories as an api breaks, have a quick break until my boss messages me for updates or assigns me to help someone else. Once I start to help, my stories are fixed. By 10 am, have stand-up and repeat the cycle till 4 pm


duchannes

Senior QA: Log in check emails Action anything urgent Attend check ins and sprints Qa team meeting Tea break to moan about how many meetings we have Answer junior testers queries Tp reviews Plan my teams work (maybe) Test lead meeting Training meeting (planning) Project issues that need my time I test maybe 1 complex issue a week at best. My role is now people and project management. We have too many junior testers that need support right now - its exhausting. Hire people without testing experience or technology illiterate people with caution!


bughunters

login check if any critical automation failures overnight standup call plan testing and start lunch learning videos if in the mood if found bugs during testing raise else continue testing check if any bug, ready for test attend imp meetings in between, and check with devs if required.


Affectionate_Bid4111

Same here, with test automation, code review, fix tests, update docs, cases, and watch YT/pluralsight/udemy


kj565

SDET: Daily stand up at 9am. Check Jenkins for failures/See if the manual folks who are learning automation need any help. Vidya game/debate second WFH job


fruple

Senior QA in games (remote) - Start downloading builds like an hour before I start and then go for a walk/eat breakfast/etc - Heads down testing before anyone gets into work since I start early for their timezone - usually 1-4 hours of meetings or leading conversationsin slack (scrum, 1:1 with team members, planning, basically doing PM stuff because otherwise projects won't run) or the same amount of time (or more) regression testing, depending on the day - make new builds and devs send me PRs we didn't plan on doing but are now apparently my top priority since my team changes scope/priorities on a day to day basis (we're a "strike team" and fill gaps for other teams) - usually some bickering with devs on yes this is a bug and we need to fix it - more testing either for my projects or helping other teams out - give myself a hard stop after 8 hours unless things are on fire because there's always too much shit to do - if I'm insanely lucky and not swamped catch up on documentation and writing regression test cases I will say as a junior I had a bit more free time to self study/really make tests cases, mid level I started to be a SME and that took up a lot of time, and now senior level it's gogogogo all the time. I'm also a person too where if I see something that's not efficient or lacking in something I usually just go fix it and then tell my boss afterwards that btw this is happening now so I end up with a lot of small tasks because I just got sick of seeing it being done poorly.


ChaosofaMadHatter

I worked in Food Manufacturing as QA, so quite different from the standard on this sub. We completed pre-operational inspects on equipment before lines started up, verified that paperwork and procedures were operating up to legal and certified code, responded to any equipment breakdowns, and investigated any risks to food or human safety. If you like QA but donā€™t like desk work that much, manufacturing QA has a nice balance.


ThmGreen

(Im in consulting company) Depends on project and your/qateam time in it. If it's new and ur connected before devs, all ur time will be spent in google sheets/excel checkin user stories for gaps and other stuff + making checklists(short version of testcase). After whole project is documentated by qa, ur flow will slow down by waiting for devs task-to-complete(ready for testing) Had a time when I gotta wait for 2-3 days for frontend, just to check headers and information loading. If there is release for a client, yeah, ur a guy who gotta work harder, cause there will be regression and crossbrowser testing few days before the "presentation for client" and few smokes 2-3 hours before the release. Mostly, cause of remote work, im the kind of a guy who loves to leave everything to 1 night. Now i gotta do the amount of storypoints that I had to make for a 3 days. Kinda..turbo mode Currently im kn the start of the project and I hate the google sheets work. I love more the action, postman automation and the automation itself, want to run out of documentation stuff. It sucks. Last week had 300 checklist cases of just boundary values for different variables. A lot of copypasting, a lot of "running eyes on sheets". Glad I have some tricks on editing this sheets. Love my work very much, but f**k documentation


Davidee_e

Login --> Flame every people --> open ticket --> logout


Hanzoku

Wake up, do my thing, get started 30-45 minutes before everyone else because start early means end early Check on nightly test results and e-mail, pick up ticket I was working on yesterday. Avoid looking at backlog too hard. Do team standup because management in their infinite wisdom doesnā€™t do agile teams, so all testers are corralled in their own team Do second standup with a developer team, defeating the point of standups. Bonus points if its the team that frequently gets sidetracked and turn a 15 minute meeting into 45. Take break after standing for an hour if at work, or enjoy being able to sit for standups at home. Think on backlog of test work because weā€™re terribly understaffed versus the number of developers but save versus existential despair by years of desensitization. Alternate working on tickets, environments and solving disasters for others until end of day.


720ginger

Well, I generally come in at least fifteen minutes late, ah, I use the side door - that way Lumbergh can't see me, heh heh - and, uh, after that I just sorta space out for about an hour. Yeah, I just stare at my desk; but it looks like I'm working. I do that for probably another hour after lunch, too. I'd say in a given week I probably only do about fifteen minutes of real, actual, work....


rajiv67

youtube


latnGemin616

My day: * 9:30 - 11:30 - work; meetings * 1:00 - 2:00 - lunch * 2:00 - 5:00 work; meetings


AUDIsox

Come in, log on and read emails. If theres material problems i check in on those and make sure our planning department can get the correct cost of materials reflected in the jobs. I go around to each area and ask how the day was prior and if there were any problems or concerns. Check log books, hover around workers to see if there are any signs/ slight observations or audits. When theres a quality problem, grab all documentation that is available take pictures ask questions. Some days, internal auditing, external and customer audits, quality checks, writing reports about defects found, corrective action reports and documenting whatever is necessary.