Last week was the grand finale of our course: guest lectures. We did not make these lectures mandatory for the participants of the course but I was hoping that everyone would attend. I have to say that those who did not missed a lot. And I do mean a lot. The lectures were perfect, a true grand finale for the course.
On Tuesday we were given insight about challenges related to testing cross-platform products in one nameless company. We were basically educated how they are organizing their testing activities and what are the biggest challenges they are facing. The lecture lasted almost two hours and was packed with huge amount of facts, solutions, problems, etc. What was surprising to me was the traditional "QA department" approach and lack of test automation. Still it is evident that the approach works for them.
I must say that I really enjoyed the presentation. No marketing b******t, just facts. No "we are succeeding in every area", instead successes and challeges were both presented. And the lecturer had so honest, down-to-earth style that I just loved listening to him. So I would give full 10 points for the lecture.
Thursday was dedicated to a lecture on tester's life. What is it like to work as a tester? Based on the lecture: challenging and fun. Again the lecture was perfect. Just perfect. The lecturer had prepared a lot of material and we did not have time to go through all of them but still many things were discussed. Exploratory testing, challenges when working with clients, variety of job descriptions for testers, what is actually testing etc. We also learned how to get over mistakes.
Again the session had good down-to-earth vibe and people attended by asking questions. I liked both the ideas presented and the approach to subject. So again full 10 points. I really hope to see that guy in action again some day.
Then some complaining. We have a lecturer from a company listed as one of the hottest in the business today. You would expect rush and excitement. You get approximately half of the course participants and handful of other people. We have a lecturer giving an insight on what it actually is like to work out there in the software testing business. You would expect all the course participants sitting eagerly in the room asking questions. And numerous other interested people. You get even fewer people than in the first lecture. That's a bit sad.
P.S. If you are interested on the lecture materials, you can get them from me.
18 Dec 2011
12 Dec 2011
Sessions
The fourth, and the last, dojo was not actually dojo at all. Reason for this arrangement was that one of the things we were supposed to study was sharing and organizing testing work. The easiest way for practising this was to let the groups self-organize their work using some of the ideas given in the theory part of the session. For me it seems that we didn't quite achieve the goal. Again, the concept would have needed some fine tuning.
Last time we realized that we needed some means to organize our testing efforts so that we would be able to answer some tough questions from the business side, divide our work among fellow testers and see where we are at when it comes to course of testing. So now was the perfect time to introduce some easy ways to organize notes related to testing (mindmaps, simple templates, SessionTester and RapidReporter). Also along with Session-based testing we were given even more ideas like timeboxing, charters/missions, testing metrics and debriefing.
Presentations were held and again people had done good work. In the Session-based testing presentation I especially enjoyed the small discussions on metrics and agility of the method. To summarize, I believe we ended up realizing that utilizing all the original Session-based testing things strictly might not be a good idea. And that everything related to metrics should be handled with care.
The tool topic was again structured nicely: emphasis was on demonstrating the tools. Although the latter of the two demos lasted a bit too long. I hope at least one thing related to any tool came clear based on the whole session: tools should be as simple as possible. I'm glad that people chose differently from the given notetaking methods when getting their hands dirty. Again, tools should always be chosen based on need coming from inside. Not forced by someone from outside. In this session people simply chose one serving their purpose best.
This time we were split into two groups a bit differently. Both groups were given different challenges and they were supposed to work as pairs, dividing the testing work related to their challenge so that they could get maximum coverage with minimum overlapping work based on testing strategy they chose. The Android team started their work wisely: the pairs were all given some time to get familiar with the product under test before starting to create the charters. Also the Utu team got their work going nicely and made a clever top-level decision on their tactic.
Things evolved without any big struggle so we decided to disturb the testing work a bit. After lunch the groups switched challenges and tried to continue work of the original groups based on their notes. This part was something that perhaps should've been instructed a bit differently. The idea was great, but the results of the switch could have been even better.
The one thing I was disappointed most in this session was the debriefing. We decided to leave the bugs out of the discussion and just tried to get some progress/metrics related things out of the groups. My questions were bad, they should have been more precise. Or we should have required more "official" summary from the team. Still, I hope the actual notetaking, designing charters, dividing the work and trying to figure out what you are supposed to do from other people's notes were something that made the session beneficial. At least based on the feedback students were still quite happy on the session.
Guest lectures still to go. Hopefully most of the students will come there. Every activity counts when grading...
Last time we realized that we needed some means to organize our testing efforts so that we would be able to answer some tough questions from the business side, divide our work among fellow testers and see where we are at when it comes to course of testing. So now was the perfect time to introduce some easy ways to organize notes related to testing (mindmaps, simple templates, SessionTester and RapidReporter). Also along with Session-based testing we were given even more ideas like timeboxing, charters/missions, testing metrics and debriefing.
Presentations were held and again people had done good work. In the Session-based testing presentation I especially enjoyed the small discussions on metrics and agility of the method. To summarize, I believe we ended up realizing that utilizing all the original Session-based testing things strictly might not be a good idea. And that everything related to metrics should be handled with care.
The tool topic was again structured nicely: emphasis was on demonstrating the tools. Although the latter of the two demos lasted a bit too long. I hope at least one thing related to any tool came clear based on the whole session: tools should be as simple as possible. I'm glad that people chose differently from the given notetaking methods when getting their hands dirty. Again, tools should always be chosen based on need coming from inside. Not forced by someone from outside. In this session people simply chose one serving their purpose best.
This time we were split into two groups a bit differently. Both groups were given different challenges and they were supposed to work as pairs, dividing the testing work related to their challenge so that they could get maximum coverage with minimum overlapping work based on testing strategy they chose. The Android team started their work wisely: the pairs were all given some time to get familiar with the product under test before starting to create the charters. Also the Utu team got their work going nicely and made a clever top-level decision on their tactic.
Things evolved without any big struggle so we decided to disturb the testing work a bit. After lunch the groups switched challenges and tried to continue work of the original groups based on their notes. This part was something that perhaps should've been instructed a bit differently. The idea was great, but the results of the switch could have been even better.
The one thing I was disappointed most in this session was the debriefing. We decided to leave the bugs out of the discussion and just tried to get some progress/metrics related things out of the groups. My questions were bad, they should have been more precise. Or we should have required more "official" summary from the team. Still, I hope the actual notetaking, designing charters, dividing the work and trying to figure out what you are supposed to do from other people's notes were something that made the session beneficial. At least based on the feedback students were still quite happy on the session.
Guest lectures still to go. Hopefully most of the students will come there. Every activity counts when grading...
8 Dec 2011
Exploratory Testing
The second to last session on our journey to know what testing really was was about exploratory testing. The presentations were really good. I learned a lot and to be honest I actually expected a lot from the presentations.
One of the one part I am feeling the least of confidence in software engineering is exploratory testing. Mostly because I haven't been really doing that. I have high hopes for the future and maybe, maybe I could use some of the learning in my current job. Maybe I could participate ET sessions where the whole team is doing that. Maybe there's something new for me next Friday.
I did not do extensive preparations to the 3rd dojo. More or less I came with all I had. No excuses about not having time - rather I prioritized something else more. Well, I did join to learn. And learn I did, that's sure.
As mentioned in the session, I haven't used any bug tracking software for ages now. I think the last time we tracked bugs in a tool was early 2007. That is, either we haven't had any (well, we did - in fact 2) or we have been tracking the bugs with orange index cards on the wall. Either way, seeing an open source bug tracking software (let alone project management) in action was a thrill.
That would be pretty much the kind of software I'd like to use. And I've heard quite a bit good rumors about Redmine. So, a tool well worth a study.
When it comes to the dojo, our decision of using the university web site as our problem context seemed to be a rather good call. The instant hassle after we revealed the big secret really meant that we selected a site that arouses interest. How cool would it be to find a bug in our university web site?
We took a deliberate *risk* in exposing the whole university web site for testing. Yes, it is a vast area. Bigger than most testing task ever will be. The groups ended up taking two different approaches to the challenge. All in all, testing turned up being somewhat random, or could I say even ad-hoc. No worries, it was pretty much what was expected. And the most important part was that it was fun.
About Feedback:
We were given feedback that the challenge was too big. That we would've learnt the same lessons in smaller sites. Yes, we agree. And we also see a lot of benefits in randomly going through the selected site. First and foremost it seemed to be fun. And, with no less of importance, we hopefully all realize that ET is not something that can be done with no planning. Just starting to 'do ET' does not make it necessarily exploratory. It is hard and it will be even more fun when getting 'into the zone' after some preparations.
So, the ad-hoc type hassle trying things here and there was pretty much what we expected. With no clear guidance from us. Nearly none, to be exact. And as said, it was a deliberate decision. Seeing what testing could end up being (ad-hoc) gives us (or rather, you) a great chance to introduce a more meaningful, planned and coherent way of doing ET. I am hoping that we are building a story of ET (from ad-hoc to planned) just like we did with ATDD.
Let's see how things go!
One of the one part I am feeling the least of confidence in software engineering is exploratory testing. Mostly because I haven't been really doing that. I have high hopes for the future and maybe, maybe I could use some of the learning in my current job. Maybe I could participate ET sessions where the whole team is doing that. Maybe there's something new for me next Friday.
I did not do extensive preparations to the 3rd dojo. More or less I came with all I had. No excuses about not having time - rather I prioritized something else more. Well, I did join to learn. And learn I did, that's sure.
As mentioned in the session, I haven't used any bug tracking software for ages now. I think the last time we tracked bugs in a tool was early 2007. That is, either we haven't had any (well, we did - in fact 2) or we have been tracking the bugs with orange index cards on the wall. Either way, seeing an open source bug tracking software (let alone project management) in action was a thrill.
That would be pretty much the kind of software I'd like to use. And I've heard quite a bit good rumors about Redmine. So, a tool well worth a study.
When it comes to the dojo, our decision of using the university web site as our problem context seemed to be a rather good call. The instant hassle after we revealed the big secret really meant that we selected a site that arouses interest. How cool would it be to find a bug in our university web site?
We took a deliberate *risk* in exposing the whole university web site for testing. Yes, it is a vast area. Bigger than most testing task ever will be. The groups ended up taking two different approaches to the challenge. All in all, testing turned up being somewhat random, or could I say even ad-hoc. No worries, it was pretty much what was expected. And the most important part was that it was fun.
About Feedback:
We were given feedback that the challenge was too big. That we would've learnt the same lessons in smaller sites. Yes, we agree. And we also see a lot of benefits in randomly going through the selected site. First and foremost it seemed to be fun. And, with no less of importance, we hopefully all realize that ET is not something that can be done with no planning. Just starting to 'do ET' does not make it necessarily exploratory. It is hard and it will be even more fun when getting 'into the zone' after some preparations.
So, the ad-hoc type hassle trying things here and there was pretty much what we expected. With no clear guidance from us. Nearly none, to be exact. And as said, it was a deliberate decision. Seeing what testing could end up being (ad-hoc) gives us (or rather, you) a great chance to introduce a more meaningful, planned and coherent way of doing ET. I am hoping that we are building a story of ET (from ad-hoc to planned) just like we did with ATDD.
Let's see how things go!
4 Dec 2011
Exploring
Moving on to manual testing. With an exploratory twist. How to teach a subject that may seem a bit abstract and is mostly about using your own brains? That is the question we had in mind when planning the first Exploratory Testing dojo. We ended up choosing a testing challenge that was obscure and broad but what we thought would be motivational and fun for the students. The fun part was a success, both groups seemed to really enjoy the bug hunting. I guess the challenge was motivational too because people really tried to find ways to weak spots in the website under test.
Presentations were again given and they were good. We decided to skip the Redmine part in the dojo, to keep the focus on ET. Still I would say that all students were given a good example of a bug report and a tool that could be used in tracking bugs. For a tester bugs belong to daily work so an introduction to reporting is a minimum in a testing course. One of the groups already reported a bug they found so they also had a glimpse on that.
The presenters and we gave a couple of "brain tools" for the groups before the actual challenge. It was interesting to see that both groups chose different approaches. The one I was in decided to hit the probable weak spots in the website. That was mostly forms, and translations also when they realized some problems in there. The other group chose to use some role heuristics. Both groups found plenty of small issues in translations, some logical problems, usability issues, expired certificates and also goldmines for spammers. So a lot of things in an application that is up and running. And well tested.
Prize for the groups were plus one to grades if they find and report a bug. My group has already reported one so they earned their prize. The other group had a plenty to choose from also, so most probably they will get their prize also.
We were a bit afraid that the session would be a big jumble. For my group I have to say it almost was. Still I would say that the end result was on the positive side: people had fun and used their brains to challenge the system under the test. That is testing, the rest is getting more professional. We will look into that in the next dojo when we try to find some ways to move from ad-hoc to more efficient, organized and trackable working methods.
Although I am really proud how things went on Friday some fine tuning on the challenge should have been made. If I use the same challenge again I will make it more clear and present it in a bit different way. Also the analysis part would look a bit different if I do it again. The good thing was that we went through some findings and also realized together that there were a lot of things we need to do differently to fulfill all the needs for testing. More on that next Friday...
Presentations were again given and they were good. We decided to skip the Redmine part in the dojo, to keep the focus on ET. Still I would say that all students were given a good example of a bug report and a tool that could be used in tracking bugs. For a tester bugs belong to daily work so an introduction to reporting is a minimum in a testing course. One of the groups already reported a bug they found so they also had a glimpse on that.
The presenters and we gave a couple of "brain tools" for the groups before the actual challenge. It was interesting to see that both groups chose different approaches. The one I was in decided to hit the probable weak spots in the website. That was mostly forms, and translations also when they realized some problems in there. The other group chose to use some role heuristics. Both groups found plenty of small issues in translations, some logical problems, usability issues, expired certificates and also goldmines for spammers. So a lot of things in an application that is up and running. And well tested.
Prize for the groups were plus one to grades if they find and report a bug. My group has already reported one so they earned their prize. The other group had a plenty to choose from also, so most probably they will get their prize also.
We were a bit afraid that the session would be a big jumble. For my group I have to say it almost was. Still I would say that the end result was on the positive side: people had fun and used their brains to challenge the system under the test. That is testing, the rest is getting more professional. We will look into that in the next dojo when we try to find some ways to move from ad-hoc to more efficient, organized and trackable working methods.
Although I am really proud how things went on Friday some fine tuning on the challenge should have been made. If I use the same challenge again I will make it more clear and present it in a bit different way. Also the analysis part would look a bit different if I do it again. The good thing was that we went through some findings and also realized together that there were a lot of things we need to do differently to fulfill all the needs for testing. More on that next Friday...
Subscribe to:
Posts (Atom)