tag:blogger.com,1999:blog-8951904624959546499.post8737161072419933295..comments2024-02-22T05:36:59.121-05:00Comments on Test This Blog - Eric Jacobson's Software Testing Blog: Documenting Tests – Part 2 (The Tester Leaves)Eric Jacobsonhttp://www.blogger.com/profile/08216361684596485033noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-8951904624959546499.post-6867041830796694572014-06-05T14:47:44.691-04:002014-06-05T14:47:44.691-04:00Anonymous, consider standing behind your ideas wit...Anonymous, consider standing behind your ideas with conviction, rather than hiding behind "Anonymous". There is nothing wrong with your ideas, nothing to be afraid of. Why not build a reputation?<br /><br />Per the comments so far, I see that I have not explained my position clearly. I just updated the post to say: add *details* to tests as late as possible (in bold).<br /><br />I agree that testers should usually do up-front test planning, which may include writing "test ideas", tests without detail.<br /><br />Does that help?<br /><br />Per my experiences, when the SUT changes, supporting documentation (e.g., specs, test cases) does not always change with it. People are lazy and said docs are secondary to the SUT. I have a feeling that is why Agile developers like to say the best documentation is the source code.<br /><br />But even for a team that is diligent enough to keep support docs in synch with SUT changes, adding details to tests as late as possible, would certainly be less work...IMO.Eric Jacobsonhttps://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-47141074758978282662014-06-03T13:21:18.834-04:002014-06-03T13:21:18.834-04:00I hear this issue often, "If test documentati...I hear this issue often, "If test documentation was written some time ago, and our system-under-test (SUT) changed, that documentation might be wrong." <br />My response is usually something along the lines of, "If the SUT is changing, then so should the documentation..." If we refactor code, change underlying logic or functionality, etc., then tests need to be made to ensure that the change is what was expected. The test would change from the original test, so the test case would change... this produces updated documentation. <br /><br />If the documentation is wrong, then it isn't being updated as it should, and if it's important to the org, then it's the test managers responsibility to make sure that test cases are updated. Especially in high churn departments. <br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-21239228017366711932014-06-02T08:56:29.910-04:002014-06-02T08:56:29.910-04:00"Write tests as late as possible because thin..."Write tests as late as possible because things change."<br /><br />You will end up with no TCs and QA cycle starting. There is a need to get QA involved in the beginning and them starting writing TCs asap. They can start with black box style and then move to white box one when reqs are full and available. <br />Otherwise, you will have QA sitting there waiting for reqs and company is paying for dead time. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-34414144235524394652014-05-30T12:41:40.806-04:002014-05-30T12:41:40.806-04:00Anonymous, in your case, the early requirements re...Anonymous, in your case, the early requirements review might be "as late as possible". This might mean writing vague tests early but leaving the details out until as late as possible...we don't know if it will be a dropdown or free-form text field but we can write a vague test or "test idea", as some like to call it.Eric Jacobsonhttps://www.blogger.com/profile/08216361684596485033noreply@blogger.comtag:blogger.com,1999:blog-8951904624959546499.post-57174644103138176312014-05-28T09:31:26.622-04:002014-05-28T09:31:26.622-04:00"Write tests as late as possible because thin..."Write tests as late as possible because things change."<br /><br />I've always objected to this. Nobody says to programmers "write code as late as possible because things change." <br /><br />I've always had to struggle to get my QA teams involved in early requirements review / design because I was told that things might change too much. But it was perfectly fine for the programmers to have to make these same changes.Anonymousnoreply@blogger.com