New ask Hacker News story: Ask HN: How can I help my devs solve “combinatorial test case scope creep”?
Ask HN: How can I help my devs solve “combinatorial test case scope creep”?
7 by quacked | 11 comments on Hacker News.
I work in between clients and programmers; my job is essentially to decompose client requirements into design documentation to be built by developers. [1] Since I started the job, I've been running into what I'm calling "combinatorial test case scope creep". For instance: > CHALLENGE: RENDER A CUSTOM HTML SCREEN WITH THREE LABELLED BUTTONS AND AN IMAGE. > Browsers: {Chrome, Firefox, Edge, Safari} > Devices: {iPad 9th Gen, Google Pixel 4, iPhone XR, Macbook Pro, HP EliteBook} > Languages: {English, Spanish, French} In this case, the custom screen must render properly in 4 Browsers x 4 devices x 3 languages = 48 individual test cases. And that's ignoring all of the other possibilities (landscape/portrait, OS version, browser version, etc.) We can quickly find ourselves in 2000+ possible renderings of the screen. I, not being a developer myself, have no idea how this is handled on the implementation end. The clients themselves are only dimly aware of this problem and will throw a fit if they notice the screen is broken, but are certainly not testing 50-2000 test cases to see when the screen breaks. I'd like to help the devs out by steering clients in the right direction, and also adding build instructions to solve this problem at the root. Are there any development principles, testing tactics, historical writings, past HN posts, zen koans, ancient scrolls, etc. that outline and explain solutions to "combinatorial test case scope creep"? Thanks in advance. [1] Disclaimers: I agree that in many cases it would make more sense for developers to work directly with clients and eliminate my job altogether. I was hired because I have a significant technical background but am not quite at the level of a junior dev. I would set my own team up differently if I owned the company.
7 by quacked | 11 comments on Hacker News.
I work in between clients and programmers; my job is essentially to decompose client requirements into design documentation to be built by developers. [1] Since I started the job, I've been running into what I'm calling "combinatorial test case scope creep". For instance: > CHALLENGE: RENDER A CUSTOM HTML SCREEN WITH THREE LABELLED BUTTONS AND AN IMAGE. > Browsers: {Chrome, Firefox, Edge, Safari} > Devices: {iPad 9th Gen, Google Pixel 4, iPhone XR, Macbook Pro, HP EliteBook} > Languages: {English, Spanish, French} In this case, the custom screen must render properly in 4 Browsers x 4 devices x 3 languages = 48 individual test cases. And that's ignoring all of the other possibilities (landscape/portrait, OS version, browser version, etc.) We can quickly find ourselves in 2000+ possible renderings of the screen. I, not being a developer myself, have no idea how this is handled on the implementation end. The clients themselves are only dimly aware of this problem and will throw a fit if they notice the screen is broken, but are certainly not testing 50-2000 test cases to see when the screen breaks. I'd like to help the devs out by steering clients in the right direction, and also adding build instructions to solve this problem at the root. Are there any development principles, testing tactics, historical writings, past HN posts, zen koans, ancient scrolls, etc. that outline and explain solutions to "combinatorial test case scope creep"? Thanks in advance. [1] Disclaimers: I agree that in many cases it would make more sense for developers to work directly with clients and eliminate my job altogether. I was hired because I have a significant technical background but am not quite at the level of a junior dev. I would set my own team up differently if I owned the company.
Comments
Post a Comment